Bug 822020
| Summary: | Need info in gear_groups indicating which gear_group the ha_proxy controls | ||
|---|---|---|---|
| Product: | OKD | Reporter: | Clayton Coleman <ccoleman> |
| Component: | Master | Assignee: | Abhishek Gupta <abhgupta> |
| Status: | CLOSED NOTABUG | QA Contact: | libra bugs <libra-bugs> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 2.x | CC: | rmillner |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-06-19 14:08:23 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
This does not affect users and is only required by the site at the moment. Also, based on email conversation between Krishna and Clayton, this is not required by the site till the next sprint. Need this for scaling UI this sprint. Also need the current scale multiplier. Currently we have to infer it from the other groups (find out which is scaling, add up gears), but most clients are going to want to read something simple to find this out. Client wants to get: whether app is scaling what current scale multiplier for a particular web cart (or cart in general) is the minimum and maximum scale parameters (I thought this was implemented last sprint but don't see it) For now if gear group with haproxy includes a number indicating the current scale out that would be enough for us to complete US2339 Further revision - all of this is some ugly complexity. I don't mind gear groups exposing it, but application also needs to expose it. The :embedded field object is kind of hackish - it really needs to be something clean like:
{
name: "appfoo"
...
scales: {
'php-5.3': {with: "haproxy-1.4", min: 1, max: 5, times: 3}
}
}
Opened a story for this as a feature - US2445. |
In order to properly indicate scaling in the UI, we need to be able to unequivocally determine from gear_groups that the comp-web and comp-proxy components are related. Using cart name feels not future safe: example of scaled app "data": [ { "gears": [{ "id": "6d5f993faffa47cf81ea4b9b99453ce1", "state": "started" }], "cartridges": [{"name": "php-5.3"}], "name": "@@app/comp-web/cart-php-5.3" }, { "gears": [{ "id": "c04ecc1c06a64692baf4110e0adb362a", "state": "started" }], "cartridges": [{"name": "haproxy-1.4"}, {"name": "php-5.3"}], "name": "@@app/comp-proxy/cart-php-5.3" }, { "gears": [{ "id": "05795073f4f2426e9e8aea1d858f05fa", "state": "unknown" }], "cartridges": [{"name": "mysql-5.1"}], "name": "@@app/comp-proxy/cart-mysql-5.1/group-mysql" } ] What the UI has to represent based on this info is: Cart: [PHP 5.3] - 2 Small gears - is scaled Cart: [MySQL] - 1 Small gear - is not scaled Using the example above, a caller could assume that because the 'php-5.3' cart is colocated with the ha-proxy, that 'php-5.3' is being scaled and so the two gear groups are related. However, if we ever add a separate ha-proxy that relationship breaks and so a caller would be broken. Will we ever have a more complicated topology than 1 haproxy and X instances of a web cart? If not, I would prefer to establish a clear relationship - possibly something like: { "gears": [{ "id": "6d5f993faffa47cf81ea4b9b99453ce1", "state": "started" }], "cartridges": [{"name": "php-5.3"}], "name": "@@app/comp-web/cart-php-5.3" }, { "gears": [{ "id": "c04ecc1c06a64692baf4110e0adb362a", "state": "started" }], "cartridges": [{"name": "haproxy-1.4", "scales": "php-5.3", "scales_with": "@@app/comp-web/cart-php-5.3"}, {"name": "php-5.3"}], "name": "@@app/comp-proxy/cart-php-5.3" }, We can talk tomorrow, but I want to get closure on this before i implement something hackish.