Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-01-14
16:29:56 openstackgerrit Balazs Gibizer proposed openstack/nova master: Reject resize with port having resource request https://review.openstack.org/630722
16:29:57 openstackgerrit Balazs Gibizer proposed openstack/nova master: Reject unshelve with port having resource request https://review.openstack.org/630725
16:29:57 openstackgerrit Balazs Gibizer proposed openstack/nova master: Reject evacuate with port having resource request https://review.openstack.org/630724
16:31:07 sean-k-mooney hehe i takeit you have resovled all the merge conflits
16:32:18 gibi sean-k-mooney: not just that, but make it so that the new external behavior is only active in a new microversion (which still needs to be added on the top)
16:32:35 gibi mriedem: ^^ fyi
16:33:07 sean-k-mooney gibi: cool and for the old micro version dose it ignore the request or reject
16:33:36 gibi sean-k-mooney: today it rejects. Ignoring the request leads to some hard to manage edge cases that I added to the etherpad
16:34:02 gibi sean-k-mooney: like create a server with a new microversion so there is port allocation but then migrate it with an old microversion
16:34:49 sean-k-mooney ok well we can disucss those on the call i guess
16:34:59 gibi sean-k-mooney: yes, definitely
16:35:11 sean-k-mooney on blance that might be safer but we need a failly big upgrade impact section to call it out
16:35:24 sean-k-mooney did you choose a time by the way
16:35:36 gibi sean-k-mooney: I still have to talk to mlavalle about it
16:35:56 gibi sean-k-mooney: as the last proposed time, Tuesday, does not seem to work any more
16:36:19 mlavalle gibi: will get back to you in ~30 mins
16:36:27 gibi mlavalle: OK, no worries
16:36:36 sean-k-mooney ok cool ill try and be there but i also dont need to be so ill keep an eye out on the ml
16:37:04 gibi sean-k-mooney: i will post to the ML in any case
16:38:09 gibi sean-k-mooney: btw if we go with the reject solution in nova, we can still turn off sending the resource request in neutron. That way we can get back the true legacy behavior, i.e. no resource request in the port et all
16:39:41 sean-k-mooney gibi: im not quite sure how you neutron would know when to do that. are you suggesting a config opion for it?
16:40:19 gibi sean-k-mooney: yes, it is config driven in this WIP patch https://review.openstack.org/#/c/627978/
16:40:58 gibi sean-k-mooney: it turned out that neutron api extensions are not selectively loaded but loaded by the service plugin
16:41:22 gibi sean-k-mooney: but everything in the neutron code is ready to make an api extension like our resource request selectively loaded
16:42:01 sean-k-mooney ah cool. so if you have stien neutron and rocky nova or older you would set the config option to disable it
16:42:48 sean-k-mooney gibi: well there are selectivly loaded in that you have to enable the service plugin or extentinon in the neutron.conf or in the agent/ml2_conf.ini
16:43:04 gibi sean-k-mooney: if you have stein neutron and rocky nova then nova does not check the resource request at all. if you have stein neutron and stein nova, but you want to go back to the legacy behavior then you can turn off the extension in neutron
16:43:31 gibi sean-k-mooney: as far as I know if you enable a service plugin then it loads every extension of that plugin
16:44:47 sean-k-mooney ok so its not that granular in say enable ingress qos only you can either enable qos or not
16:45:02 gibi sean-k-mooney: yes, as far as I understand
16:45:28 sean-k-mooney and you get all the qos oplicys or none today. i honestly did not look quite that closely at least not in a few years
16:47:03 gibi sean-k-mooney: I've never looked into it deeply. I rely on rubasov's and lajoskatona's neutron experties
16:48:07 ade_lee hi all -- we have a grenade test that keeps failing due to an error which is related to volume attachment. Is there anyone here that knows about how nova volume attach works and can help?
16:49:33 jangutter moshel, lennyb: I suspect the OVS_HW_offload CI is having some issues. Would you be able to check it?
16:50:48 ade_lee specifically, we're running into an error where we try to write to a volume before its ready --
16:51:33 ade_lee we do wait for cinder to show the volume as being "in-use", but that seems to be insufficient.
16:51:59 ade_lee what would we wait for to ensure that the volume is ready for use?
16:52:09 ade_lee and the instance knows about it.
17:01:04 stephenfin bauzas: I think you need to submit those gantt reviews by yourself, as it's just yourself and johnthetubaguy that have access. melwitt is OK with us retiring it
17:01:23 bauzas stephenfin: WDYM ?
17:01:28 bauzas fast-approving ?
17:01:33 stephenfin yup
17:02:15 stephenfin bauzas: Pretty much everyone else is no longer working on OpenStack https://review.openstack.org/#/admin/groups/253,members
17:02:16 sean-k-mooney stephenfin: well you can submit the change and bauzas and johnthetubaguy can approve
17:02:31 mdbooth Are folks aware that openstack-placement isn't listed in either requirements or test-requirements, btw?
17:02:47 stephenfin mdbooth: Neither is neutron, I'd imagine
17:03:05 mdbooth stephenfin: How's it supposed to be installed?
17:03:12 stephenfin They're all applications rather than libraries. You don't list applications in requirements.txt
17:03:32 mdbooth stephenfin: We pull in placement in functional
17:03:33 stephenfin If you're DevStack, usually by cloning the repo locally?
17:03:41 mdbooth Functional tests don't work
17:03:42 stephenfin Oh, then that's different
17:03:55 sean-k-mooney stephenfin: it should be in test-requiremetns if its needed to run the tests
17:04:24 stephenfin sean-k-mooney: Yup. It shouldn't be required to run tests though, otherwise we now have integration tests
17:04:38 stephenfin mdbooth: Then I can't offer any more info. Sorry for the noise :)
17:05:35 sean-k-mooney stephenfin: we import the test fixture form placement now so we can share it between nova and placement i think
17:05:36 mdbooth https://github.com/openstack/nova/blob/master/nova/tests/functional/fixtures.py#L19
17:05:49 sean-k-mooney cdent: ^ you would know better then i
17:06:18 cdent in the gate, it is happening a a result of tox-siblings
17:06:27 openstackgerrit Jan Gutter proposed openstack/nova master: Convert vrouter legacy plugging to os-vif https://review.openstack.org/571325
17:06:31 jangutter mriedem: would you be able to remove your procedural -2 from ^^ (a tag has been made!)
17:06:32 mdbooth Sounds cosy
17:07:19 sean-k-mooney cdent: how would you run tox locally to get the same effect. just pip install placement after the fact?
17:07:27 cdent one mo
17:08:02 cdent sean-k-mooney, mdbooth : look at the functional job def in tox.ini
17:08:21 cdent placement is installed explicitly for functional only because unit tests should not know about placement
17:08:31 cdent from git master
17:08:43 cdent tox-siblings makes sure in the gate that depends-on type things are respected
17:08:46 mriedem jangutter: done
17:08:59 sean-k-mooney cdent: mdbout is have import errors when runing placement
17:08:59 cdent if you need that locally, then pip install the git ref
17:09:07 sean-k-mooney * nova fucntional tests
17:09:30 cdent mdbooth: got any more details than that?
17:09:34 jangutter mriedem: thanks! (finally, the dominoes have started falling!)
17:10:35 mdbooth cdent: Ah, ha!
17:10:49 mdbooth I was running functional-py37 which looks like it's missing a line
17:11:16 cdent mdbooth: it does indeed appear to be missing a line
17:11:18 mdbooth py3{5,6} both have an explicit deps= referring to functional deps
17:11:21 cdent i bet that's a bad merge
17:11:34 cdent functiona-py37 was added around the same time the functional test changes were added
17:11:43 cdent but functional-py37 is not in the gate
17:12:01 cdent mdbooth: you happy to fix that as part of whatever else you are doing, or would like me to get it?
17:12:26 mdbooth cdent: 'whatever I'm doing' will merge shortly after the decay of the last proton, so you go ahead
17:15:52 jangutter mdbooth: you made me look up the current lower limit for proton decay. I think the only think that will beat that is COBOL code running in production.
17:16:22 mdbooth jangutter: lol
17:18:21 gibi mlavalle, sean-k-mooney, efried, mriedem: So the (hopefully) final timeslot for the bandwidth hangouts in Friday 17:00 UTC. Posted on the ML
17:18:32 gibi http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001710.html
17:18:35 mlavalle gibi: ack
17:18:49 efried ack
17:20:59 efried gibi: Hangout link to be provided day-of?
17:29:20 openstackgerrit Chris Dent proposed openstack/nova master: Make functional-py37 job work like others https://review.openstack.org/630745
17:41:21 stephenfin sean-k-mooney: thoughts on https://review.openstack.org/#/c/621528/5/nova/network/linux_net.py@1455 ?
17:42:47 sean-k-mooney exitcode 2 is file not found or interface not found in this case
17:42:58 sean-k-mooney 254 im not sure and 0 is success
17:43:38 sean-k-mooney what is that patch for
17:44:25 sean-k-mooney oh its the privesep changes im not sure if that code is used as os-vif should be used even for nova-networks
17:45:05 stephenfin sean-k-mooney: Aye, could be nova-network only code
17:45:37 sean-k-mooney you mean unrelated to vif plugging
17:46:25 stephenfin No I mean the file I'm linking to seems to be nova-network only code and unrelated to the neutron/os-vif code path
17:46:34 stephenfin We don't use os-vif for nova-net, do we?

Earlier   Later