-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add x_maturity #26
Add x_maturity #26
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In retrieve_kp_endpoints_from_smartapi, we're only looking at the first element in servers. We should probably take this opportunity to handle all the elements in that list. With multiple environments, one option that people may take advantage of is using the same registration, and pointing to both prod and dev as two server entries.
Also, I think we need to go ahead and implement the TODO on line 174/5 of registry.py and assume maturity is a list.
In order to pick the better instance, we need to be able to compare similar services. Right now, the only field that would remain constant between service instances is the infores, which is a relatively new required property. I'll need to add infores to the information we store on each service. Until all services add the infores property, we might lose some otherwise valid kps. |
Yes, that's why infores has been added. I think rather than loosing any, we should create a unique infores for anything that doesn't have one, and then complain to the offending team. |
Just for clarification, if we create unique inforeses for services that don't have them, we'll potentially be hitting both dev and prod of a service since we couldn't compare them correctly. |
Actually, if services have added x-maturity and multiple instances, then they would have also added infores, so we're probably fine. |
#25