| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-01-17 | |||
| 15:10:37 | openstackgerrit | Lee Yarwood proposed openstack/nova master: DNM Test the removal of g-api from subnodes https://review.opendev.org/703100 | |
| 15:10:40 | dansmith | has anyone asked glance if they're doing that on purpose? (or is it just our jobs?) | |
| 15:11:04 | dansmith | because they've been working on some multi-worker multi-store stuff lately which likely needs g-api on different nodes to accomplish | |
| 15:12:59 | sean-k-mooney | running the glacne api on multiple nodes does not require them to initalise the glance db multiple times | |
| 15:13:33 | lyarwood | right we aren't talking about that bug here, just if running g-api on a subnode is valid. | |
| 15:13:34 | sean-k-mooney | so if they are which would be resonable devstack need to be updated so that we can make sure the db is only setup on the contoler | |
| 15:13:48 | sean-k-mooney | lyarwood: sure you can do that | |
| 15:14:00 | sean-k-mooney | normally we would not need too but you can | |
| 15:14:18 | melwitt | I can't find where in the chat log someone mentioned it would be needed for grenade | |
| 15:14:22 | sean-k-mooney | i have seen it done on small 1-3 node deployments | |
| 15:14:41 | dansmith | specifically for edge it's a thing | |
| 15:14:48 | sean-k-mooney | where all the contoler were also computes and they split the contol plane across them | |
| 15:15:16 | melwitt | http://eavesdrop.openstack.org/irclogs/%23openstack-qa/%23openstack-qa.2020-01-16.log.html#t2020-01-16T18:56:14 | |
| 15:15:44 | sean-k-mooney | melwitt: it might be need for grenade to test that we can upgrade nova independly of glance or something like that | |
| 15:15:45 | lyarwood | yeah of course, I guess devstack-gate just needs some additional subnode flavours if you will covering a pure compute subnode, mixed subnode with g-api etc | |
| 15:16:17 | sean-k-mooney | lyarwood: or we could move to zullv3 | |
| 15:16:22 | lyarwood | or that | |
| 15:16:46 | sean-k-mooney | althogh devstack would still need to have configuration for the db | |
| 15:16:59 | sean-k-mooney | also crap im late for the bug call | |
| 15:17:29 | lyarwood | sean-k-mooney: you're not missing much :) | |
| 15:17:52 | sean-k-mooney | my only bug was closed so i didnt have anything to talk about. | |
| 15:18:05 | sean-k-mooney | i just realise what time it was | |
| 15:18:25 | sean-k-mooney | backporting functional test is annoying | |
| 15:19:07 | sean-k-mooney | apparently we rewrite how the numa ones work each cycle | |
| 15:20:50 | melwitt | I'm working on testing out grenade with zuul v3 in nova (https://review.opendev.org/701478 depends-on https://review.opendev.org/548936 and https://review.opendev.org/703005 | |
| 15:21:44 | melwitt | not as a fix for the gate but to get away from the gzipped log files | |
| 15:22:11 | sean-k-mooney | did my change not work | |
| 15:22:20 | sean-k-mooney | i saw a ping about it last night | |
| 15:22:28 | sean-k-mooney | but i did not fully get the context | |
| 15:22:45 | sean-k-mooney | but yes i would like use to adopt the v3 approch if we can too | |
| 15:23:07 | gmann | sean-k-mooney: it fixed for zuulv3 jobs not legacy which are d-g dependents not on devstack roles | |
| 15:23:30 | melwitt | yep, what gmann said | |
| 15:23:49 | sean-k-mooney | ah ok | |
| 15:24:34 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/stein: Remove global state from the FakeDriver https://review.opendev.org/703102 | |
| 15:24:35 | melwitt | so I found that proposed grenade patch that moves it to v3 and it mostly works. just needs a few updates | |
| 15:24:35 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/stein: Enhance service restart in functional env https://review.opendev.org/703103 | |
| 15:25:14 | gmann | melwitt: yeah only remaining things there is that does not work for plugin case yet. which is something should be figured out before we merge that | |
| 15:25:21 | sean-k-mooney | melwitt: yep i have been trying to get peopel to review it ever few weeks for a while | |
| 15:25:35 | sean-k-mooney | gmann: there is one other case too | |
| 15:25:46 | melwitt | gmann: oh I see | |
| 15:26:12 | sean-k-mooney | gmann: it can be done as a follow up but you cant specify a different local_conf section per version | |
| 15:26:18 | sean-k-mooney | you can do it for localrc | |
| 15:26:27 | gmann | sean-k-mooney: i could not get chance to find gzip log place for legacy jobs. busy for tempest plugins py2-drop drama bug. | |
| 15:26:38 | sean-k-mooney | but localrc does not allow you to set the post-config updates | |
| 15:28:01 | gmann | sean-k-mooney: yeah that(different local_conf section) is true, i failed to do that while IPv6 enable for legacy jobs. | |
| 15:28:44 | gmann | but i am not sure why devstsack fix is wrong, waiting for frickler re-reply | |
| 15:34:08 | sean-k-mooney | gmann: we will need that to be able to test placement reshapes on upgrade in grenade | |
| 15:34:39 | sean-k-mooney | because we sill need to change form using vcpu_pin_set to cpu_share_set and cpu_dedicated_set | |
| 15:34:51 | sean-k-mooney | although we dont test that today so its not required to move | |
| 15:35:53 | sean-k-mooney | im sure there are other examples too but having the ablity to specifc new/old/shared local_conf sections in the zuul.yaml will be useful | |
| 15:38:25 | tosky | melwitt: "mostly" - for some reasons, after we switched to Python 3, several python 2 packages are installed anyway, including python-openstackclient | |
| 15:39:16 | tosky | melwitt: so whenever "openstack foo" is called, the py2 version is used; and when the sahara plugin (or heat plugin) tries creating resources with "openstack dosomething", its own osc plugin (py3 only) is not found | |
| 15:39:23 | gmann | sean-k-mooney: or we can do that via direct config change via roles. something to explore may be. | |
| 15:39:26 | tosky | I'm failing to understand where the issue is | |
| 15:40:06 | tosky | gmann, sean-k-mooney or the from-<foo> update plugin maybe | |
| 15:40:09 | melwitt | I see | |
| 15:40:37 | sean-k-mooney | gmann: we could but im not sure that would be better. if it requrie new roles to be written i think it would be worse the adding supprot for local.conf in grenade | |
| 15:40:49 | lyarwood | random question, what's the best way of checking the stability of a given job over the last x number of months? | |
| 15:41:19 | sean-k-mooney | tosky: it might be the fact that on older brances we install everything twice. once under py3 then again under py2 | |
| 15:41:26 | gmann | lyarwood: http://status.openstack.org/openstack-health/#/ | |
| 15:41:37 | sean-k-mooney | tosky: we only stopped doing that in ussuri | |
| 15:41:39 | gmann | you can filter the jobs and time period | |
| 15:41:47 | tosky | sean-k-mooney: devstack, you mean? A pure devstack job does not install all those stuff | |
| 15:41:51 | gmann | but data is only for the gate pipeline | |
| 15:42:00 | sean-k-mooney | tosky: yes in devsack | |
| 15:42:11 | lyarwood | gmann: ack thanks | |
| 15:42:22 | tosky | sean-k-mooney: but comparing with a devstack job, I see much more components; so something happens in the grenade-specific roles | |
| 15:42:53 | sean-k-mooney | https://github.com/openstack/devstack/commit/63ab664baf99716e9a5d29eb82f974f8c3456816 | |
| 15:42:58 | sean-k-mooney | tosky: ^ | |
| 15:43:01 | lyarwood | gmann: so this wouldn't help if I wanted to look at NV jobs in the check queue right? | |
| 15:43:26 | lyarwood | gmann: trying to figure out a way of showing something is now stable and can be made voting | |
| 15:43:27 | gmann | oh . yeah n-v jobs data are not there | |
| 15:43:39 | lyarwood | kk np | |
| 15:43:48 | lyarwood | and thanks :) | |
| 15:44:47 | tosky | sean-k-mooney: but then I shouldn't see this in master | |
| 15:44:54 | tosky | sean-k-mooney: so there must be something else too | |
| 15:45:12 | sean-k-mooney | on master no but grenade installs with train frist then upgrdaes to master | |
| 15:45:20 | sean-k-mooney | so all the train deps will be installed with both | |
| 15:45:28 | tosky | oh, right | |
| 15:45:34 | sean-k-mooney | then we will upgrade to train without updateing the python 2 deps | |
| 15:45:51 | tosky | this means that when we install train/py3 we have a problem | |
| 15:46:14 | tosky | not a problem normally, as train is technically py2 for devstack | |
| 15:46:19 | tosky | but I'm not sure how to solve | |
| 15:46:24 | sean-k-mooney | yes well a traing/py3 intsall install both under py3 and py2 | |
| 15:46:40 | sean-k-mooney | tosky: well no | |
| 15:46:50 | sean-k-mooney | train should would with python 3 aswell | |
| 15:46:57 | efried | gibi: if you have a second, could you please remind me the context around why we're parsing a RP name to identify an interface? | |
| 15:48:01 | sean-k-mooney | tosky: what is the specific issue you are having | |
| 15:48:53 | sean-k-mooney | one way to solve it would be do a pip freeze and unistall any openstack package that is installed | |
| 15:49:00 | sean-k-mooney | on python 2 | |
| 15:52:32 | tosky | sean-k-mooney: see my comment above: both versions of osc are installed, but the osc plugins are py3 only, and then the py2 openstack fails to use them | |
| 15:55:34 | sean-k-mooney | ya so that is the same issue we have with console_scripts entry points | |
| 15:56:08 | sean-k-mooney | the python 2 version of osc console sript overites teh python 3 version on train | |
| 15:56:56 | sean-k-mooney | so grenade or devstack could be updated to explictly remvoe osc everytime it stacks | |
| 15:57:12 | sean-k-mooney | and install it again | |
| 15:57:15 | sean-k-mooney | that should fix it | |
| 15:58:31 | tosky | maybe devstack; at the end, if it's USE_PYTHON3, pip uninstall python-openstackclient (keeping the 3 version) | |
| 16:01:06 | sean-k-mooney | tosky: well it would want to do it near the start not the end | |
| 16:01:30 | sean-k-mooney | because you want to have it installed and ensure any place we use it in devstack to do things wew use the correct one | |
| 16:02:09 | sean-k-mooney | also you want it to deffinetly happen before the local.sh gets executed as its common to use the client to do things in the local.sh | |