Multiple Deployments

[cbizon]

We need 2 deployments of KP. One Prod and one Dev.

• [x] At runtime, there needs to be a config defining the environment
• [x] Based on the config, use components with the same x-maturity level (as defined in smartapi)
• [x] (temporary) because not everybody will have x-maturity level at the same time, assume no x-maturity is usable
• [ ] deploy both

[maximusunc]

I have a couple design questions:

1. The KP Registry is somewhat of an internal tool (not registered on smartapi), so it's not going to have its own x-maturity set. How are other services going to know which "version" of the kp registry to use? Will they need to have hard-coded urls to choose from based on their own maturity?
2. I'm currently setting it up to have an ordered list of allowed maturities where it will store only the "better" KP if there are multiple allowed. Another design option might be to only have one deployment of the kp registry, and it will store all current KPs. We then add a maturity arg to the get methods and it will return all KPs with that maturity. What are thoughts on this?

@cbizon @kennethmorton

[kennethmorton]

1. There is no reason KP Registry shouldn't have a maturity level. It probably should. Yeah it should even if other downstream things reference it directly rather than some discovery process.
2. This is what I was trying to communicate yesterday. I think maturity should be an arg when you request KPs for a given query. But I can be convinced otherwise, as I am not fully clued in.

[cbizon]

1. Agree with @kennethmorton , we're attaching x-maturity to things like aragorn-ranker as well. Even if external tools don't make use of them, we may want to.
2. I hadn't understood that point.... I had imagined one kp reg per strider, but in retrospect I'm not sure why we wouldn't just have a single one. Does that change make the deployment any simpler or more complicated?