| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-25 | |||
| 19:21:45 | melwitt | sean-k-mooney: instructions, you need the Previously-approved in the commit message https://specs.openstack.org/openstack/nova-specs/readme.html#previously-approved-specifications | |
| 19:22:02 | sean-k-mooney | melwitt ah perfect thanks | |
| 19:22:16 | efried | sean-k-mooney: You mean for the PTG? Unless there's something more to be discussed on them, I wouldn't think so. | |
| 19:22:47 | efried | sean-k-mooney: I guess they will come up in a "what do we prioritize for train" discussion, but that'll be fed by whatever's in the train approved blueprint list at the time anyway. | |
| 19:22:56 | sean-k-mooney | efried: no i wasnt sure if i was ment to add fast approavl spec to the nova team meeting agenda | |
| 19:23:01 | sean-k-mooney | ill just do what the doc says | |
| 19:23:30 | efried | oh, yeah, that won't be necessary. I (or someone) will push them as soon as they conform to what melwitt linked above. | |
| 19:24:01 | sean-k-mooney | efried: cool in that case ill fix them up and upload them later tonight | |
| 19:24:08 | efried | sean-k-mooney: ++ | |
| 19:25:00 | mnaser | melwitt: no both are long standing upgrade bugs afaik so yeah | |
| 19:29:09 | mriedem | mnaser: i've got a todo to try and recreate that first one with an in-tree functional test, which shouldn't take me long | |
| 19:29:33 | mriedem | idk about that oslo.service one - note that would require a release freeze exception on oslo.service and a minimum required version of oslo.service bump in nova (maybe that'd be optional though) | |
| 19:32:19 | mnaser | well, I think we need to come to consensus on if the issue is in Oslo service or nova. | |
| 19:32:37 | mnaser | Imho it’s Oslo service cause then what’s the point of sighup if you’re gonna stop and start... | |
| 19:32:53 | dansmith | mnaser: I've lost context here, but is there anything nova can do to _not_ be fully torn down and reset? | |
| 19:33:07 | dansmith | because I thought not, based on how we get started and managed from oslo | |
| 19:34:16 | dansmith | as it is, a "systemctl restart nova-compute" is much better than the behavior we're getting from HUP, IMHO | |
| 19:34:37 | mnaser | dansmith: based on my understanding it looks like Oslo service never really provides an API to handle HUP signals. | |
| 19:35:01 | dansmith | mnaser: you mean it grabs HUP itself, but doesn't do what a HUP signal should really do | |
| 19:35:09 | dansmith | and, if so, I agree :) | |
| 19:35:48 | mnaser | Exactly. It calls reload but only after calling stop and start after so that’s a bit useless at that point. | |
| 19:36:00 | dansmith | right | |
| 19:36:21 | mnaser | I think the most portable potential fix is adding a keyword argument to the stop() function call which includes sighup=bool | |
| 19:36:26 | dansmith | that doesn't seem like a reasonable status quo to me, which means I think it's an oslo.service bug, not a "nova should be doing something different" scenario | |
| 19:36:36 | efried | I agree with that | |
| 19:36:49 | mnaser | Yes. I think Nova is doing the right thing as well. | |
| 19:36:53 | dansmith | efried: agree with which? | |
| 19:37:05 | mnaser | Nothing except reload() should be called on SIGHUP. | |
| 19:37:07 | efried | dansmith: `it's an oslo.service bug, not a "nova should be doing something different" scenario` | |
| 19:37:12 | dansmith | efried: ack | |
| 19:37:21 | efried | And we've got stuff documented that is supposed to happen to nova on HUP | |
| 19:37:27 | dansmith | right | |
| 19:37:34 | efried | which currently does happen, but is worthless because it destroys the process | |
| 19:37:44 | dansmith | yarp | |
| 19:38:12 | efried | stuff I have the confidence to say in IRC, but not on the ML | |
| 19:38:21 | efried | but I have been watching that thread with interest | |
| 19:38:31 | mnaser | So my review here solved this but “changed” existing behaviour ... https://review.openstack.org/#/c/641907 | |
| 19:38:42 | mnaser | So is it a bug fix or behaviour change. Up for debate. | |
| 19:39:04 | efried | it can be both | |
| 19:39:27 | dansmith | the only argument not to do that would be to keep the existing behavior because it's always been broken, but that leaves us unable to resolve our issue | |
| 19:39:33 | mnaser | But it looks like nova is a heavy user of sighup and I can’t get other projects to talk about their usage. But it looks like neutron is broken because it makes the same (norms) assumption | |
| 19:39:33 | dansmith | which does not seem reasonable | |
| 19:40:01 | efried | Zane's comment is valid, though. The first time I heard of SIGHUP for openstack it was in the context of mutable config options. So if the "fix" makes some config options not mutable, that's a problem. | |
| 19:40:22 | dansmith | efried: I don't think it has anything to do with that | |
| 19:40:38 | dansmith | the only thing that would be impacted are things that you only look at on service start | |
| 19:40:57 | efried | like RPC settings? | |
| 19:40:58 | dansmith | however, those kinda by definition shouldn't be mutable, or you need to specifically handle the case where they have changed | |
| 19:41:13 | dansmith | efried: right, db connection and rpc connection have always been "these can't be mutable" | |
| 19:41:27 | dansmith | because it's unlikely people are going to handle them properly (as exposed here) | |
| 19:41:38 | efried | Okay. Can you respond to Zane in https://review.openstack.org/#/c/641907 ? | |
| 19:42:12 | dansmith | I can, but I don't really want to.. he's also not asserting that it makes sense to say that, | |
| 19:42:20 | dansmith | he's just coming up with some guess | |
| 19:42:38 | dansmith | oh, | |
| 19:42:53 | dansmith | I see his latest one | |
| 19:45:04 | dansmith | there, I said things | |
| 19:45:20 | mnaser | I'll try to keep following up on things and get it to land, I just don't know how back portable these things can be | |
| 19:55:40 | openstackgerrit | Chris Dent proposed openstack/nova master: Delete the placement code https://review.openstack.org/618215 | |
| 20:12:00 | mriedem | mnaser: there should definitely at least be a "fixes" release note in that oslo.service change if it's changing behavior but fixing a long-standing bug in HUP handling | |
| 20:12:10 | mriedem | related to your "I just don't know how back portable these things can be" comment | |
| 20:12:28 | mriedem | generally don't want to backport changes in behavior, but if we have a good reason to, let's make sure there is a release note | |
| 20:15:11 | mnaser | mriedem: ok, ill wait for zane's comments and try to write up a release note that explains how critical (and how it was pretty much broken in every project I've inspected) | |
| 20:17:33 | mriedem | mnaser: dansmith: efried: i've also dumped some thoughts in there | |
| 20:17:43 | mriedem | trying to compromise but give operators a switch | |
| 20:17:50 | mriedem | which could also be backportable | |
| 20:19:46 | mriedem | essentially add a [workarounds] style option to oslo.service | |
| 20:42:55 | openstackgerrit | Merged openstack/os-vif master: Drop testtools from test-requirements.txt https://review.openstack.org/647286 | |
| 20:57:09 | mriedem | mnaser: i wrote a functional test for bug 1821244 but can't recreate the issue | |
| 20:57:13 | openstack | bug 1821244 in OpenStack Compute (nova) "Failed volume creation can result in invalid `connection_info` field" [Medium,In progress] https://launchpad.net/bugs/1821244 - Assigned to Mohammed Naser (mnaser) | |
| 20:57:26 | efried | mriedem: Some bp questions if you have a mo | |
| 20:57:37 | mriedem | mnaser: i'll post it quick and see if you can poke holes in the test | |
| 20:57:47 | mriedem | efried: i have to run real quick, but should be back before 5 | |
| 20:58:13 | efried | mriedem: k, I'll leave this here for you: | |
| 20:58:13 | efried | 1) Why doesn't https://blueprints.launchpad.net/nova/+spec/add-locked-reason show up in https://blueprints.launchpad.net/nova/train ? | |
| 20:58:13 | efried | 2) Why can't I edit Series goalZ? | |
| 20:58:44 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: A functional test for bug 1821244 https://review.openstack.org/647603 | |
| 20:58:45 | openstack | bug 1821244 in OpenStack Compute (nova) "Failed volume creation can result in invalid `connection_info` field" [Medium,In progress] https://launchpad.net/bugs/1821244 - Assigned to Mohammed Naser (mnaser) | |
| 20:59:04 | mriedem | efried: i've noticed that sometimes (1) happens and i just have to reset the series and save it then it does, which i just dod | |
| 20:59:05 | mriedem | *did | |
| 20:59:12 | mriedem | so refresh https://blueprints.launchpad.net/nova/train | |
| 20:59:35 | mriedem | efried: you probably can't edit series goals b/c you're not a nova driver team member https://launchpad.net/~nova-drivers | |
| 20:59:37 | efried | ah, you changed it from "proposed for train" to "accepted for train" | |
| 20:59:47 | mriedem | oh | |
| 21:00:12 | mriedem | oh maybe tssurya had set the series goal which was 'proposed' | |
| 21:00:28 | mriedem | efried: now see if you can do #2 | |
| 21:00:29 | mriedem | https://launchpad.net/~nova-drivers | |
| 21:00:37 | efried | which isn't the same thing as approving the bp, which is an awkward distinction that's unnecessary for us. | |
| 21:00:38 | efried | okay... | |
| 21:01:41 | efried | mriedem: yup, thanks. | |
| 21:01:48 | efried | you may go now | |
| 21:02:47 | openstackgerrit | Merged openstack/python-novaclient master: Replace openstack.org git:// URLs with https:// https://review.openstack.org/647070 | |
| 21:03:08 | tssurya | mriedem, efried: err yea I meant "propose for train" I am not sure why it says accepted | |
| 21:03:33 | efried | tssurya: It's possible you can only say "proposed" and we have to say "accepted". | |
| 21:03:56 | efried | Because apparently "proposed" doesn't show up in the useful dashboard, it only shows up in the useless ones, or if you happen to know the exact url. | |
| 21:04:11 | efried | Launchpad woes | |
| 21:05:10 | efried | tssurya: as stated above ("useless distinction") that doesn't mean the bp is approved for train. It just means it... uhh... shows up instead of now showing up? | |
| 21:05:52 | tssurya | efried: should I just unset it or something ? still its strange I did the same for https://blueprints.launchpad.net/nova/+spec/nova-support-instance-power-update | |
| 21:05:58 | tssurya | and that looks okay | |
| 21:06:10 | tssurya | its "proposed" | |
| 21:06:23 | efried | tssurya: But it doesn't show up in https://blueprints.launchpad.net/nova/train | |
| 21:06:30 | efried | so let me fix it | |