| rm_work | trying to get these things to defer evaluation and it's not liking it | 00:05 |
|---|---|---|
| rm_work | I think because SQLAlchemy really wants to NOT do that | 00:05 |
| rm_work | this is probably why no one did this already <_< | 00:07 |
| *** ducttape_ has joined #openstack-lbaas | 00:12 | |
| *** chlong has quit IRC | 00:15 | |
| *** ducttape_ has quit IRC | 00:16 | |
| rm_work | yeah k not worth my time | 00:21 |
| *** ducttape_ has joined #openstack-lbaas | 00:24 | |
| *** ducttape_ has quit IRC | 00:38 | |
| *** ducttape_ has joined #openstack-lbaas | 01:06 | |
| *** ducttape_ has quit IRC | 01:13 | |
| *** ducttape_ has joined #openstack-lbaas | 01:15 | |
| *** ducttape_ has quit IRC | 01:16 | |
| *** ducttape_ has joined #openstack-lbaas | 01:16 | |
| *** fnaval has quit IRC | 01:33 | |
| *** fnaval has joined #openstack-lbaas | 01:34 | |
| *** fnaval has quit IRC | 01:38 | |
| *** ducttape_ has quit IRC | 01:57 | |
| *** yamamoto has quit IRC | 02:14 | |
| *** ducttape_ has joined #openstack-lbaas | 02:38 | |
| *** reedip has quit IRC | 02:39 | |
| *** ducttape_ has quit IRC | 03:15 | |
| *** yamamoto has joined #openstack-lbaas | 03:15 | |
| *** ducttape_ has joined #openstack-lbaas | 03:15 | |
| *** ducttape_ has quit IRC | 03:16 | |
| *** yamamoto has quit IRC | 03:22 | |
| *** aojea has joined #openstack-lbaas | 03:44 | |
| *** ducttape_ has joined #openstack-lbaas | 03:48 | |
| *** aojea has quit IRC | 03:48 | |
| *** madgoat has joined #openstack-lbaas | 03:52 | |
| *** madgoat has left #openstack-lbaas | 03:54 | |
| *** ducttape_ has quit IRC | 04:00 | |
| *** ducttape_ has joined #openstack-lbaas | 05:03 | |
| *** ducttape_ has quit IRC | 05:09 | |
| *** blogan_ has joined #openstack-lbaas | 05:28 | |
| *** blogan has quit IRC | 05:31 | |
| *** gcheresh_ has joined #openstack-lbaas | 05:41 | |
| *** ducttape_ has joined #openstack-lbaas | 06:34 | |
| *** ducttape_ has quit IRC | 06:39 | |
| *** sanfern has quit IRC | 07:05 | |
| *** sanfern has joined #openstack-lbaas | 07:06 | |
| *** aojea has joined #openstack-lbaas | 07:25 | |
| *** kobis has joined #openstack-lbaas | 07:28 | |
| *** aojea has quit IRC | 07:31 | |
| *** kobis has quit IRC | 07:36 | |
| *** aojea has joined #openstack-lbaas | 08:01 | |
| *** aojea has quit IRC | 08:25 | |
| *** aojea has joined #openstack-lbaas | 08:25 | |
| *** aojea has quit IRC | 08:30 | |
| *** yamamoto has joined #openstack-lbaas | 08:44 | |
| openstackgerrit | Merged openstack/neutron-lbaas master: Tests helper function _send_requests should catch socket.error https://review.openstack.org/452003 | 09:12 |
| *** yamamoto has quit IRC | 09:21 | |
| *** aojea has joined #openstack-lbaas | 09:26 | |
| *** aojea has quit IRC | 09:30 | |
| *** ducttape_ has joined #openstack-lbaas | 09:35 | |
| *** ducttape_ has quit IRC | 09:40 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/neutron-lbaas master: Imported Translations from Zanata https://review.openstack.org/449037 | 09:50 |
| *** yamamoto has joined #openstack-lbaas | 09:55 | |
| *** yamamoto has quit IRC | 09:56 | |
| *** yamamoto has joined #openstack-lbaas | 09:56 | |
| *** yamamoto has quit IRC | 09:58 | |
| *** yamamoto has joined #openstack-lbaas | 10:17 | |
| *** aojea has joined #openstack-lbaas | 10:26 | |
| *** aojea has quit IRC | 10:32 | |
| *** kobis has joined #openstack-lbaas | 10:59 | |
| *** ducttape_ has joined #openstack-lbaas | 11:06 | |
| *** ducttape_ has quit IRC | 11:11 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/neutron-lbaas master: Updated from global requirements https://review.openstack.org/452477 | 11:29 |
| *** yamamoto has quit IRC | 12:12 | |
| *** ducttape_ has joined #openstack-lbaas | 12:23 | |
| *** ducttape_ has quit IRC | 12:25 | |
| *** ducttape_ has joined #openstack-lbaas | 12:25 | |
| *** aojea has joined #openstack-lbaas | 12:28 | |
| *** aojea has quit IRC | 12:33 | |
| *** reedip has joined #openstack-lbaas | 12:50 | |
| *** ducttape_ has quit IRC | 13:01 | |
| *** ducttape_ has joined #openstack-lbaas | 13:02 | |
| *** yamamoto has joined #openstack-lbaas | 13:02 | |
| *** _ducttape_ has joined #openstack-lbaas | 13:09 | |
| *** ducttape_ has quit IRC | 13:13 | |
| *** belharar has joined #openstack-lbaas | 13:20 | |
| *** aojea has joined #openstack-lbaas | 13:29 | |
| *** aojea has quit IRC | 13:34 | |
| *** _ducttape_ has quit IRC | 13:50 | |
| *** ducttape_ has joined #openstack-lbaas | 14:20 | |
| *** gcheresh_ has quit IRC | 14:30 | |
| *** belharar has quit IRC | 14:32 | |
| *** ducttape_ has quit IRC | 14:32 | |
| *** ducttape_ has joined #openstack-lbaas | 14:35 | |
| *** ducttape_ has quit IRC | 14:50 | |
| *** ducttape_ has joined #openstack-lbaas | 14:55 | |
| *** ducttape_ has quit IRC | 14:59 | |
| *** ducttape_ has joined #openstack-lbaas | 15:00 | |
| *** _ducttape_ has joined #openstack-lbaas | 15:01 | |
| *** ducttape_ has quit IRC | 15:03 | |
| *** yamamoto has quit IRC | 15:04 | |
| *** kobis has quit IRC | 15:12 | |
| *** aojea has joined #openstack-lbaas | 15:22 | |
| *** aojea has quit IRC | 15:22 | |
| *** aojea has joined #openstack-lbaas | 15:22 | |
| *** _ducttape_ has quit IRC | 15:53 | |
| *** ducttape_ has joined #openstack-lbaas | 16:04 | |
| *** yamamoto has joined #openstack-lbaas | 16:05 | |
| *** ducttape_ has quit IRC | 16:09 | |
| *** fnaval has joined #openstack-lbaas | 16:11 | |
| *** yamamoto has quit IRC | 16:14 | |
| openstackgerrit | Nir Magnezi proposed openstack/octavia master: Auto detect haproxy user_group https://review.openstack.org/429398 | 16:15 |
| *** ducttape_ has joined #openstack-lbaas | 16:16 | |
| *** ducttape_ has quit IRC | 16:17 | |
| *** ducttape_ has joined #openstack-lbaas | 16:35 | |
| *** ducttape_ has quit IRC | 16:39 | |
| *** fnaval has quit IRC | 16:42 | |
| *** fnaval has joined #openstack-lbaas | 16:43 | |
| *** sputnik13 has quit IRC | 16:48 | |
| *** sputnik13 has joined #openstack-lbaas | 16:49 | |
| *** catintheroof has joined #openstack-lbaas | 17:05 | |
| *** voelzmo has joined #openstack-lbaas | 17:17 | |
| *** voelzmo has quit IRC | 17:21 | |
| *** reedip has quit IRC | 17:25 | |
| *** voelzmo has joined #openstack-lbaas | 17:36 | |
| *** ducttape_ has joined #openstack-lbaas | 17:36 | |
| *** voelzmo has quit IRC | 17:38 | |
| *** ducttape_ has quit IRC | 17:41 | |
| *** catintheroof has quit IRC | 17:45 | |
| *** catintheroof has joined #openstack-lbaas | 17:46 | |
| *** gcheresh_ has joined #openstack-lbaas | 18:05 | |
| *** ducttape_ has joined #openstack-lbaas | 18:58 | |
| rm_work | nmagnezi: i need to look at that soon | 19:04 |
| rm_work | nmagnezi: I am still confused about why it's so complex to autodetect whether to set that group or not T_T | 19:04 |
| rm_work | but I assume there's some weird complication | 19:05 |
| *** ducttape_ has quit IRC | 19:23 | |
| nmagnezi | rm_work, hi Adam :) | 19:29 |
| rm_work | o/ | 19:29 |
| nmagnezi | rm_work, the complication here is that this can be determined on the only on the (amphora) agent side, and we still want to allow ppl to choose their own custom user_group if they wish to (since it was supported up until now) | 19:30 |
| rm_work | hmm | 19:31 |
| rm_work | except | 19:31 |
| rm_work | why would user group be useful to set | 19:31 |
| nmagnezi | rm_work, so we basically keep default config per operating system flavor and use if only if user_group is unset | 19:31 |
| rm_work | you're literally dealing with what's on the amp | 19:31 |
| rm_work | and the amp is built once | 19:31 |
| rm_work | so why not just have it set *on the amp* | 19:32 |
| nmagnezi | rm_work, because not all images are created equal :) | 19:32 |
| rm_work | erm | 19:32 |
| rm_work | i mean | 19:32 |
| rm_work | haproxy itself is installed as part of the image build | 19:32 |
| rm_work | the groups on it are ... set | 19:32 |
| rm_work | as of the build | 19:32 |
| rm_work | so it doesn't seem like it'd make sense | 19:32 |
| rm_work | to change it to anything other than the group that is set up properly on the image | 19:33 |
| rm_work | IMO the only reason it isn't baked into the image already is because it has to be in the haproxy config file | 19:33 |
| rm_work | but we could have the agent side render the usergroup into the template after it receives it <_< | 19:33 |
| rm_work | given any image that is built, I can tell you exactly what group will work, and using any other group *will* fail | 19:34 |
| rm_work | without even looking at the image when deployed, or anything to do with the rest of the control plane | 19:35 |
| rm_work | which says to me that it should somehow be part of the image baking, to select the group | 19:35 |
| nmagnezi | rm_work, so the idea in the patch is slightly different, but close. haproxy can accept multiple config files (haproxy -f file1 -f file2 etc) so we render the user group in file1 in case if provided, if not -> we use file2 as well which contain the default user group for that image | 19:35 |
| nmagnezi | the default user group in the "file2" is baked into the image when it is created | 19:35 |
| rm_work | and file2 is baked into the image? | 19:35 |
| rm_work | k | 19:35 |
| nmagnezi | yes | 19:35 |
| nmagnezi | :) | 19:36 |
| rm_work | yeah though honestly i don't even see the point of allowing it to be overridden | 19:36 |
| rm_work | given ANY image, I don't think any group other than the one that we've set up will work | 19:36 |
| rm_work | there's no way for the user to create multiple groups | 19:36 |
| rm_work | or do anything on the system at all other than render a config template onto it | 19:36 |
| rm_work | it's like providing an option and saying 'if you actually use this, nothing will work, but here's the config option just in case you want to break everything!" | 19:37 |
| rm_work | why even expose that | 19:37 |
| nmagnezi | rm_work, honestly this is mostly in order to keep things backwards compatible. your argument will also be valid for the network interfaces file path | 19:37 |
| rm_work | i agree | 19:37 |
| rm_work | i don't even see the point of being backwards compatible | 19:37 |
| rm_work | let's just not even read the config options on the worker side | 19:38 |
| rm_work | they can put them in | 19:38 |
| rm_work | but it won't do anything | 19:38 |
| rm_work | i mean, that IS backwards compatible | 19:38 |
| rm_work | basically, i feel like we've got to be overcomplicating this | 19:39 |
| nmagnezi | rm_work, could you please capture this in a comment? if both you and johnsom feel the same way about this i will remove the config option | 19:41 |
| rm_work | hmm k | 19:41 |
| nmagnezi | rm_work, also, I think that since this config option was already released as part of ocata we might want to be careful not breaking ppls possible configurations. I do agree that this might be a bit of an overkill, but ppl do strange things with images :) | 19:43 |
| rm_work | I mean | 19:43 |
| rm_work | we just ... | 19:43 |
| *** catintheroof has quit IRC | 19:43 | |
| rm_work | don't read it | 19:43 |
| rm_work | it won't break anything | 19:43 |
| rm_work | we've made other changes that will require making a new image anyway | 19:43 |
| nmagnezi | which changes? | 19:44 |
| openstackgerrit | Ankur proposed openstack/python-octaviaclient master: Initialize plugin for OSC https://review.openstack.org/446223 | 19:44 |
| rm_work | kernel tuning stuff | 19:47 |
| rm_work | and | 19:47 |
| rm_work | the ramfs crypto thing | 19:47 |
| rm_work | both have changed this cycle | 19:47 |
| rm_work | and need to be updated IIRC | 19:48 |
| nmagnezi | well image updates may happen.. that is to be expected. this is one of the reasons we have the amphora tag in glance. | 19:49 |
| *** kong has quit IRC | 19:49 | |
| *** fnaval_ has joined #openstack-lbaas | 19:51 | |
| rm_work | right | 19:52 |
| rm_work | IMO we should make this change, require an image update... | 19:52 |
| rm_work | we can continue to pass it if configured for a cycle or something | 19:52 |
| rm_work | but not actually CARE on the amp side | 19:53 |
| rm_work | so a lot of that code simplifies | 19:53 |
| rm_work | commented | 19:54 |
| rm_work | I'm sorry I didn't get a chance to take a look at this before | 19:54 |
| *** fnaval has quit IRC | 19:55 | |
| rm_work | I've been really distracted with changing jobs, internal stuff, and apiv2, but i really should have at least glanced at it because it's been bothering me for a while that it isn't just a trivial change T_T | 19:55 |
| rm_work | I'm interested in what johnsom thinks | 19:55 |
| rm_work | maybe i'm missing something obvious | 19:55 |
| nmagnezi | that's perfectly fine i myself didn't have time to properly do all the tests for t this in the past month. thinks happen. | 19:56 |
| rm_work | i only commented on the systemd template but same comments apply to all of them, obviously | 19:57 |
| nmagnezi | rm_work, if Michael will think the same, maybe we can indeed mark this config option as deprecated for Pike and remove it afterwards. just in order to allow people to adjust in case anyone care about this. | 19:57 |
| rm_work | i gave up typing more comments once I decided you'd probably gotten the point :P | 19:58 |
| nmagnezi | hah | 19:59 |
| nmagnezi | yup. 6 comments delivered the message :) | 20:00 |
| rm_work | i mean you got the point before i even went to comment, I think, lol | 20:02 |
| nmagnezi | yup :-) let's see what Michael will say | 20:02 |
| rm_work | nmagnezi: yeah I think we deprecate it, continue to pass the value, but in the amp code just don't even bother reading it | 20:03 |
| rm_work | err, wait | 20:03 |
| rm_work | we do the render on the controller side... | 20:03 |
| rm_work | hold up | 20:03 |
| rm_work | which config takes precedence ? | 20:03 |
| rm_work | is it predictable? | 20:03 |
| rm_work | if we pass two configs with conflicting values to haproxy, does it use the first one, second one, random one, or freak out and bail? | 20:04 |
| nmagnezi | wait | 20:04 |
| nmagnezi | the logic is actually very simple | 20:04 |
| rm_work | right | 20:04 |
| rm_work | we ALWAYS want to override with the one baked into the image | 20:04 |
| nmagnezi | user_group has not default value at all. if it is set -> it is used with the provided value | 20:04 |
| rm_work | anything that happens to come in from the main config | 20:05 |
| rm_work | if we can do that | 20:05 |
| rm_work | then ... | 20:05 |
| nmagnezi | if user_group is unset -> we use the baked value | 20:05 |
| rm_work | ok | 20:05 |
| rm_work | right but i'm thinking about the case of upgrading the controller-worker but not the image | 20:05 |
| rm_work | if we upgrade the controller-worker to not render it into the config, then an older image won't auto-set it on the image side, and it'll die? | 20:05 |
| rm_work | so i'm wondering, what happens if we still pass it from the controller side in the config, exactly as we already have | 20:07 |
| rm_work | can we just... override that value on the image side | 20:07 |
| nmagnezi | if you upgrade the controller worker and still use the old image (Thus, the old amphora agent). you'll have to set some value in user_group | 20:07 |
| rm_work | *amp side | 20:07 |
| rm_work | right | 20:07 |
| rm_work | err, so what if we upgrade the image first and have old controller-worker code | 20:07 |
| rm_work | what happens | 20:08 |
| rm_work | if the image blindly applies the baked-in user_group config | 20:08 |
| rm_work | and there is one set in the listener config | 20:08 |
| rm_work | does it explode? | 20:08 |
| rm_work | or does it just pick one? | 20:08 |
| rm_work | hold up, gonna etherpad | 20:09 |
| rm_work | https://etherpad.openstack.org/p/octavia-user_group-deprecation | 20:09 |
| nmagnezi | r | 20:09 |
| nmagnezi | mmmm | 20:09 |
| nmagnezi | i have not tested this. but if you use a new image with the old controller it should be fine, and not use the baked option, since the old controller has a default value for user_group which is nogroup. | 20:10 |
| nmagnezi | alternately the operator can manually replace this value to 'haproxy' if he chose to use centos based amp | 20:11 |
| nmagnezi | this is exactly the case now actually | 20:11 |
| rm_work | I am saying, if on the amp-image we just ignore entirely | 20:15 |
| rm_work | and try to force the user_group | 20:15 |
| rm_work | trying to figure out a good way to arange this | 20:23 |
| *** ducttape_ has joined #openstack-lbaas | 20:24 | |
| rm_work | i think i'm just asking whether we can blindly force user_group in the amp | 20:26 |
| rm_work | and saying we make no changes on the controller-worker side at all right now | 20:26 |
| rm_work | other than deprecating that config option | 20:26 |
| *** ducttape_ has quit IRC | 20:27 | |
| *** ducttape_ has joined #openstack-lbaas | 20:28 | |
| rm_work | really that comes down to | 20:30 |
| rm_work | can we configure HAProxy to have an override | 20:30 |
| rm_work | hold on | 20:39 |
| rm_work | why is it "nogroup" in ubuntu? | 20:39 |
| rm_work | in my ubuntu install it seems to also be "haproxy" >_> | 20:39 |
| rm_work | ok so testing is interesting | 20:47 |
| rm_work | and ... not sensical | 20:53 |
| rm_work | trying to figure this out | 20:53 |
| nmagnezi | rm_work, in the default ubuntu image created by diskimage-builder.sh haproxy user group exists? | 20:55 |
| rm_work | hmmmm | 20:58 |
| rm_work | yeah not sure | 20:58 |
| rm_work | it does in MY ubuntu image with haproxy installed | 20:58 |
| rm_work | but this wasn't built with DIB | 20:58 |
| rm_work | i need to check an amp | 20:58 |
| rm_work | it might build it differently | 20:58 |
| nmagnezi | lets say, just for the sake of discussion that haproxy user group exists in the ubuntu default image | 20:58 |
| nmagnezi | do you think we should simply change the default user group to haproxy? | 20:58 |
| rm_work | I *still* think we should remove it and hand control to the image >_> | 20:58 |
| nmagnezi | or... completely remove everything and hardcode haproxy in the tamplate | 20:58 |
| rm_work | hmm | 20:59 |
| rm_work | maybe that honestly | 20:59 |
| rm_work | though | 20:59 |
| rm_work | i don't know that it's true for ALL things | 20:59 |
| nmagnezi | ack. so basically you vote against that first portion of the logic i described above. | 20:59 |
| rm_work | right now i'm trying to figure out what happens if you pass two configs with duplicate options | 20:59 |
| rm_work | it SEEMS like | 21:00 |
| nmagnezi | meaning you are in favor of the default user group per image. | 21:00 |
| rm_work | well | 21:00 |
| rm_work | it's being inconsistent | 21:00 |
| nmagnezi | two configs? | 21:00 |
| rm_work | yeah | 21:00 |
| nmagnezi | i don't follow | 21:00 |
| rm_work | haproxy -f main.cfg -f group_override.cfg | 21:00 |
| rm_work | or | 21:01 |
| rm_work | haproxy -f group_override.cfg -f main.cfg | 21:01 |
| rm_work | behave consistently differently | 21:01 |
| nmagnezi | the code should prevent it from happening | 21:01 |
| rm_work | but the WAY they behave is weird | 21:01 |
| rm_work | so if I pass main.cfg first then group_override | 21:01 |
| rm_work | [ALERT] 092/060221 (3715) : parsing [group.cfg:2] : gid/group was already specified. Continuing. | 21:01 |
| nmagnezi | if you pass the user_group the second config file will not get loaded at all | 21:01 |
| rm_work | ^^ I get that | 21:01 |
| rm_work | but | 21:01 |
| rm_work | if i do the other way | 21:01 |
| rm_work | I get no warning | 21:01 |
| rm_work | but it uses the group from the second config >_> | 21:01 |
| nmagnezi | well i have not done testing so i might have some bugs :< | 21:02 |
| nmagnezi | this is a WIP patch.. | 21:02 |
| rm_work | super weird | 21:02 |
| nmagnezi | but the logic is as i described. if user_group is provided we should only use 1 config file, as seen on the templates | 21:02 |
| rm_work | mayhaps | 21:03 |
| *** ducttape_ has quit IRC | 21:15 | |
| *** gcheresh_ has quit IRC | 21:15 | |
| *** aojea has quit IRC | 21:29 | |
| rm_work | nmagnezi: check out the bottom of https://etherpad.openstack.org/p/octavia-user_group-deprecation | 21:29 |
| nmagnezi | rm_work, i was just reading it :) | 21:30 |
| rm_work | not sure why it doesn't... | 21:32 |
| nmagnezi | rm_work, commenting there, if that is okay.. | 21:32 |
| rm_work | yeah | 21:32 |
| rm_work | not sure why one way it mentions it | 21:32 |
| rm_work | but the other way it doesn't | 21:32 |
| nmagnezi | i'm not following.. | 21:32 |
| rm_work | see i run haproxy config check twice | 21:33 |
| rm_work | flipping the order | 21:33 |
| rm_work | look below that | 21:35 |
| nmagnezi | rm_work, not sure why is specify 'nmagnezi' when there's that color diff :D | 21:37 |
| rm_work | note that when I pass group_override.cfg second, it ignores it | 21:37 |
| rm_work | but when I pass it first, it doesn't say it's ignoring the one in main.cfg | 21:37 |
| *** kong has joined #openstack-lbaas | 21:39 | |
| rm_work | very weird | 21:39 |
| rm_work | if it ignores the second passed one | 21:39 |
| rm_work | shouldn't it ALWAYS ignore the second passed one? | 21:39 |
| nmagnezi | rm_work, when the user_group is not passed from the controller at all, that param would *only* show in the second config file loaded. it will not render in the first file | 21:43 |
| rm_work | right | 21:43 |
| rm_work | but i'm talking about the case where we DO NOT change the controller at all | 21:43 |
| rm_work | so it might pass one | 21:43 |
| nmagnezi | rm_work, https://review.openstack.org/#/c/429398/24/octavia/common/jinja/haproxy/templates/base.j2 | 21:43 |
| rm_work | and change the image in such a way that it just *always overrides* | 21:43 |
| rm_work | i'm not even looking at your patch at the moment | 21:43 |
| rm_work | considering what a completely different patch would look like | 21:43 |
| rm_work | that basically JUST takes your element addition and changes to the haproxy init scripts, and that's it | 21:44 |
| rm_work | so, take these two files: | 21:44 |
| nmagnezi | rm_work, if you theoretically run code in the image that completely ignore the data coming from the controller, that data will just not be used by the amp agent.. no? | 21:44 |
| rm_work | elements/haproxy-octavia-ubuntu/post-install.d/20-haproxy-user-group-config | 21:45 |
| rm_work | elements/haproxy-octavia/post-install.d/20-haproxy-user-group-config | 21:45 |
| rm_work | and edit: | 21:45 |
| rm_work | octavia/amphorae/backends/agent/api_server/templates/systemd.conf.j2 | 21:45 |
| rm_work | to always pass the override config | 21:45 |
| rm_work | err | 21:45 |
| rm_work | so the problem is that the config comes in pre-rendered | 21:45 |
| rm_work | so it might have a "group" variable set | 21:46 |
| rm_work | can't ignore the whole config | 21:46 |
| rm_work | need to use that config, but just override that group variable | 21:46 |
| rm_work | and wanted to avoid editing the agent code in some way to strip it | 21:46 |
| rm_work | trying to be as braindead as possible | 21:47 |
| rm_work | which, if this was consistent and predictable, would be super simple | 21:47 |
| nmagnezi | in that case ^^ if you remove lines 20-22 from https://review.openstack.org/#/c/429398/24/octavia/common/jinja/haproxy/templates/base.j2 it will never render the data that came from the controller | 21:47 |
| *** ducttape_ has joined #openstack-lbaas | 21:47 | |
| nmagnezi | with the edits you suggested | 21:48 |
| rm_work | that's rendered on the controller side | 21:49 |
| rm_work | not the amp | 21:49 |
| rm_work | isn't it? | 21:49 |
| rm_work | 99% sure | 21:49 |
| rm_work | we just send a complete config from the controller to the amp IIRC | 21:49 |
| nmagnezi | i need to recall this. just a sec looking at the code | 21:50 |
| nmagnezi | rm_work, correct.https://github.com/openstack/octavia/blob/c00488143daf8e9306194ddcda636910bab532b6/octavia/amphorae/backends/agent/api_server/server.py#L112-L112 | 21:52 |
| rm_work | right, so | 21:53 |
| rm_work | that is why i'm saying | 21:53 |
| nmagnezi | rm_work, sorry i coded this couple of weeks ago, i had to refresh my memory | 21:53 |
| rm_work | if all we control is the amp-image | 21:53 |
| rm_work | we need to just... | 21:55 |
| rm_work | override whatever comes through | 21:55 |
| rm_work | until we can change the controller-worker side to just not pass it at all | 21:56 |
| nmagnezi | two problems here | 21:56 |
| rm_work | so it'd be AWESOME if we could predictably do that by just passing configs in the right order | 21:56 |
| nmagnezi | if we wish the agent to ignore user_group coming from an "old" controller, we would need to implement an agent side logic for that, no? | 21:57 |
| rm_work | i'm hoping not | 21:57 |
| rm_work | that's what i'm saying | 21:57 |
| rm_work | i am HOPING | 21:57 |
| rm_work | that we could just edit the init | 21:57 |
| rm_work | and have it pass an "override config" | 21:57 |
| rm_work | and have that work | 21:58 |
| rm_work | simple is best | 21:58 |
| rm_work | then we could simultaneously drop that line from the controller side config | 21:58 |
| nmagnezi | when will we use that "override config" exactly? | 21:58 |
| rm_work | so, moving forward, always | 21:59 |
| rm_work | the thing we want to do is: | 21:59 |
| nmagnezi | so strange, i'm trying to stack and for the second time i get cp: cannot stat '/opt/stack/keystone/etc/policy.json': No such file or directory | 21:59 |
| rm_work | 1) ensure if you upgrade just the controller-worker and use your old amp-image, everything still works | 21:59 |
| nmagnezi | i hope they didn't break keystone | 21:59 |
| rm_work | 2) ensure if you upgrade the amp image but not the controller-worker, it still works | 21:59 |
| rm_work | 3) ensure upgrading both works, obviously | 21:59 |
| rm_work | not that I recommend upgrading just one or the other, but | 22:00 |
| nmagnezi | so #2 is the tricky one.. | 22:00 |
| rm_work | you might have old amps running | 22:00 |
| rm_work | right | 22:01 |
| rm_work | so that's what i've been trying to make work | 22:01 |
| rm_work | with the stuff at the bottom of that etherpad | 22:01 |
| rm_work | but getting weird results | 22:01 |
| rm_work | basically, assume "main.cfg" == the config for the listener coming from the controller-worker | 22:01 |
| rm_work | so, if we assume it still (erroneously) includes the group param | 22:01 |
| rm_work | how do we just ... ignore that, in the simplest way possible | 22:01 |
| rm_work | don't want to fork the amp agent code depending on OS >_> | 22:01 |
| rm_work | which leaves us with, somehow just making sure that HAProxy reads both configs and chooses the right variable | 22:02 |
| rm_work | so I THOUGHT it'd always stick on the first value for each config param, and ignore the rest | 22:02 |
| rm_work | but it seems to only sometimes be the case | 22:02 |
| rm_work | actually... hmm | 22:05 |
| rm_work | i guess we don't need to fork it | 22:05 |
| rm_work | if we know that we will ALWAYS have the image passing a "group" config | 22:05 |
| rm_work | we can have the amp agent strip the group line from the config it receives | 22:05 |
| rm_work | <_< | 22:06 |
| nmagnezi | i wouldn't count on haproxy to choose the right one in case it gets a duplicate config. i tried to quickly look at the man page and didn't find such logic there | 22:06 |
| rm_work | not sure if that feels cleaner or dirtier than relying on haproxy config parsing behaviour | 22:06 |
| rm_work | yeah k | 22:06 |
| rm_work | so what if the only changes you make are | 22:06 |
| rm_work | adding the elements | 22:06 |
| rm_work | editing the inits to pass the config added by those elements | 22:07 |
| rm_work | and editing the amphora-agent to strip the "group" line from received config before writing it | 22:07 |
| nmagnezi | stripping the config file in the agent side is very hacky.. | 22:07 |
| rm_work | yeah | 22:07 |
| rm_work | but | 22:07 |
| rm_work | it's also SIMPLE | 22:07 |
| rm_work | which means a lot more predictable | 22:07 |
| rm_work | i think i'd rather have dirty but *dead simple* than "clean" but lots of moving parts / configurations | 22:08 |
| rm_work | could make a second competing patch | 22:09 |
| rm_work | and see which one people vote for | 22:09 |
| nmagnezi | https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/listener.py#L112-L114 | 22:09 |
| rm_work | rather than committing to one way or the other | 22:09 |
| nmagnezi | this is where we will need to do that | 22:09 |
| rm_work | right | 22:09 |
| rm_work | we can pull it into a buffer, remove the line, and then write out | 22:10 |
| nmagnezi | yup thats an option. | 22:10 |
| nmagnezi | a bit nasty, but in deed simple | 22:11 |
| nmagnezi | indeed* | 22:11 |
| nmagnezi | it's becoming a bit late here at UTC+02:00 :-) i'm about to call it a day | 22:11 |
| rm_work | kk | 22:16 |
| nmagnezi | rm_work, last question. per you last suggestion. if we modify the buffer the agent should: 1. always do that. 2. remove the user_group from the buffer if exists and used the baked one. right? | 22:22 |
| rm_work | yes | 22:23 |
| rm_work | always | 22:23 |
| rm_work | and on the controller-worker side we'd just mark the option deprecated and note that we don't read it anymore | 22:23 |
| rm_work | on the amp side | 22:23 |
| rm_work | but it'll still pass it until ... maybe one cycle | 22:23 |
| rm_work | by which point we REALLY hope you've upgraded your amp images? | 22:23 |
| rm_work | and recycled your amps | 22:24 |
| nmagnezi | ack. good night :) | 22:24 |
| rm_work | night :) | 22:32 |
| *** ducttape_ has quit IRC | 22:33 | |
| rm_work | ah a note, definitely do that as a different CR in case everyone else disagrees with me | 22:35 |
| *** ducttape_ has joined #openstack-lbaas | 22:41 | |
| *** ducttape_ has quit IRC | 22:48 | |
| *** sticker has joined #openstack-lbaas | 23:05 | |
| *** ducttape_ has joined #openstack-lbaas | 23:26 | |
| *** ducttape_ has quit IRC | 23:30 | |
| *** ducttape_ has joined #openstack-lbaas | 23:40 | |
| *** ducttape_ has quit IRC | 23:42 | |
| *** ducttape_ has joined #openstack-lbaas | 23:46 | |
| *** ducttape_ has quit IRC | 23:50 | |
| *** ducttape_ has joined #openstack-lbaas | 23:51 | |
| *** ducttape_ has quit IRC | 23:54 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!