Earlier  
Posted Nick Remark
#openstack-nova - 2017-03-21
16:36:25 mriedem nvm it's 1.3.3
16:36:31 mriedem because 1.3.2 was https://libvirt.org/git/?p=libvirt.git;a=commit;h=dca504a1b977060b844393daedd0da4bdb21ee76
16:37:59 cfriesen I don't see any tags applied to that commit. were you wondering what branch it was in?
16:38:12 mriedem no i sorted it out
16:38:23 cfriesen I usually use gitk to figure out branches/versions/etc.
16:38:45 cfriesen it shows "follows" and "preceeds" versions.
16:39:40 mriedem now to see if os-vif is doing any of this
16:40:33 mriedem doesn't look like it, whew
16:41:13 mriedem so this affects ivs_ethernet, iovisor, midonet, tap and vrouter
16:41:23 mriedem sean-k-mooney: ^ we don't have os-vif support for those vif types yet right?
16:42:04 mriedem doesn't look like it
16:53:51 sgordon mriedem, digging back through the commentary i think the right approach is the branch you suggest
16:54:17 mriedem should have a patch up shortly
16:54:18 sgordon mriedem, a straight revert is just going to switch back to the other group of upset operators yelling about it because the are on libvirt >= 1.3.3
16:54:22 mriedem this is going to be a bit of a mess in newton i suspect
16:54:30 sgordon mriedem, yeapppp
16:54:39 mriedem in ocata we have access to the libvirt version in the vif code
16:54:45 mriedem but i don't think i have that access in newton
16:54:50 mriedem so will have to poke around
16:54:54 sgordon mriedem, the revert approach also removed the rel note but given the combinations involved here i still think we will want to add one
16:55:07 sgordon mriedem, "if you see this behavior then do we have a deal for you..."
16:55:24 mriedem buy one get one half off bug sale?!
17:08:26 johnthetubaguy #success First few patches adding real docs for policy have now merged in Nova. A much improved sample file: https://docs.openstack.org/developer/nova/sample_policy.html
17:08:28 openstackstatus johnthetubaguy: Added success to Success page
17:20:29 openstackgerrit John Garbutt proposed openstack/nova master: Remove unused policy rule in admin_actions.py https://review.openstack.org/447611
17:26:29 mriedem sgordon: jamespage: actually the same fix i have should work on newton, we have the stuff i needed for the version check
17:27:19 openstackgerrit Matt Riedemann proposed openstack/nova master: libvirt: conditinally set script path for ethernet vif types https://review.openstack.org/448203
17:27:20 mriedem sgordon: jamespage: review/test of ^ would be appreciated
17:28:28 sgordon mriedem, thanks i'll add sfinucan as my proxy with a brain here ;)
17:29:50 dane-fichter johnthetubaguy: hey I'm back, had to step out for a meeting
17:30:09 sfinucan I'm starting to get why sysadmins don't like upgrading package versions
17:30:46 johnthetubaguy dane-fichter: no worries
17:31:41 dane-fichter johnthetubaguy: did my comment answer questions you have?
17:32:56 dane-fichter johnthetubaguy: it seems like the drivers have to support trusted flavors based on how the download() method gets called
17:33:35 johnthetubaguy dane-fichter: well I think you could hide that using driver capabilities
17:34:07 dane-fichter johnthetubaguy: Can you explain a little more? where in the code does that happen?
17:34:28 johnthetubaguy dane-fichter: yeah, I will try find an example, one sec
17:35:17 johnthetubaguy dane-fichter: here is one example: https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L1730
17:35:49 johnthetubaguy dane-fichter: its not perfect, but its a pattern I think you could re-use, that makes things consistent
17:37:04 dane-fichter johnthetubaguy: so that seems useful to just prevent the wrong drivers from trying to boot a trusted flavor instance
17:37:35 dane-fichter johnthetubaguy: but there's no real reason other than the semantics of download() that all drivers can't support this
17:38:04 dane-fichter johnthetubguy: seems like we should just modify download() to take the instance or flavor object as well
17:38:09 johnthetubaguy dane-fichter: oh, yes, agreed with you, well not all drivers use that download() method, the ones that do can support it
17:38:35 dane-fichter johnthetubaguy: ohh was not aware of that
17:39:01 sfinucan sgordon: Done
17:39:30 dane-fichter johnthetubaguy: so we could probably do both things here; use driver capabilities to prevent unsupported drivers from booting trusted flavors
17:39:37 johnthetubaguy dane-fichter: xenapi has its own in hypervisor route, to avoid a double hop, because nova-compute doesn't run somewhere with access to the hypervisor disk
17:40:15 johnthetubaguy dane-fichter: yeah, sounds like we are talking slightly cross purposes in there, agreed with with doing both things
17:40:58 johnthetubaguy dane-fichter: honestly, lots of that detail we can leave till code review, its just a saw detail in the spec that didn't look quite right to me, if that makes sense
17:41:37 dane-fichter johnthetubaguy: yeah. so maybe just tone down the detail in that implementation steps section?
17:42:08 dane-fichter johnthetubaguy: i'll definitely specify the driver capabilities wrinkle
17:42:41 johnthetubaguy dane-fichter: yeah, I think we need to add how to deal with "strange" virt drivers, but yeah the method calls and where the code exactly lives probable best left till later
17:43:49 johnthetubaguy s/probable/probably/
17:44:44 dane-fichter johnthetubaguy: yes, agreed. thanks john
17:45:15 johnthetubaguy dane-fichter: no worries
18:11:26 mriedem sfinucan: i've got to update that bug fix patch, missed a couple tests
18:13:02 openstackgerrit Matt Riedemann proposed openstack/nova master: libvirt: conditionally set script path for ethernet vif types https://review.openstack.org/448203
18:13:03 mriedem sfinucan: here we go ^
18:17:33 openstackgerrit Sujitha proposed openstack/nova master: Add description to policies in cells.py https://review.openstack.org/448224
18:18:39 openstackgerrit Gábor Antal proposed openstack/nova master: Pre-add functional tests stub to notification testing https://review.openstack.org/448225
18:22:31 dane-fichter mriedem: got a second to discuss the cursive change?
18:22:42 dane-fichter mriedem: this one https://review.openstack.org/#/c/351232/
18:30:02 mriedem dane-fichter: yeah
18:34:15 openstackgerrit Gábor Antal proposed openstack/nova master: Pre-add functional tests stub to notification testing https://review.openstack.org/448225
18:44:48 mriedem sdague: do you have an opinion on how to handle these tests? https://review.openstack.org/#/c/351232/11/nova/tests/unit/objects/test_fields.py
19:06:36 openstackgerrit Eric Fried proposed openstack/nova master: PowerVM Driver: console https://review.openstack.org/409402
19:08:32 sdague mriedem: I need a lot more context here
19:09:42 mriedem sdague: the signature_utils stuff is now in a library
19:09:49 mriedem used in nova and glance
19:10:04 mriedem we have versioned objects that use enum fields with values defined in that library now
19:10:31 mriedem we have tests in nova that check to make sure if you update the constants in signature_utils (now the library), we bump the enum lists in the versioned object,
19:10:37 mriedem that was all fine and dandy while it was all within nova,
19:11:11 mriedem but with the constants defined in a library now, it means if the library adds new constants, our unit tests will fail and requires a dance to get things working to use the library in upper-constraints
19:11:16 sdague ok, so don't you want to invert the iteration?
19:11:28 mriedem i left a comment in there about what i think the dance is,
19:11:30 mriedem if we leave things as-is
19:11:34 mriedem and get the constants from the library now
19:11:40 sdague so just test that the enum in Nova are all in in the signature utils lib ?
19:11:57 mriedem other way around,
19:12:09 mriedem the test makes sure that the constants defined in the lib are reflected in our enums,
19:12:13 mriedem which feed into ImageMetaProps
19:12:33 sdague mriedem: ok, I'm not sure why that's actually important to couple here
19:12:45 mriedem so if a new constant is added and released, we can't use that version of the library in upper-constraints until nova makes a change, before g-r is bumped, which is a bit odd
19:12:59 sdague mriedem: yeh, so, that's fine
19:12:59 mriedem i'm not sure it is either
19:13:08 mriedem that's just the way it was when it was all in tree
19:13:24 sdague the whole purpose of decoupling to a library is not to have lock step coupling with projects
19:13:27 mriedem i suppose to keep a reminder that if we support new hash methods and key types that our image meta properties object should also support those
19:13:34 sdague yep
19:13:45 sdague also, it's not like new hash methods just spring forth all the time
19:14:00 mriedem if the library adds new things now, and we don't keep our enums and versioned objects up to date, then i guess someone just has to do that when they actually want to use a new thing in the library
19:14:01 sdague they take years to a decade to proof out
19:14:05 mriedem yeah
19:14:22 mriedem so i'm also ok with just dropping the nova tests i think
19:14:28 sdague so the fact that you add to the lib, then add to the lib consumers, seems fine
19:15:10 mriedem ok so pro-drop the tests and coupling
19:15:26 mriedem that works for me, i just didn't like thinking this through in a vacuum
19:22:50 mriedem dane-fichter: ^ replied in the change too
19:30:11 dane-fichter mriedem: I see. Just read the discussion w sdague too. sounds good.
19:45:55 mriedem gcb: can't we do this now? https://github.com/openstack/nova/blob/master/tox.ini#L70

Earlier   Later