Earlier  
Posted Nick Remark
#openstack-nova - 2017-07-13
09:38:07 gcb stephenfin^^
09:38:23 stephenfin gcb: Excellent. Thank you :)
09:40:39 cdent stephenfin: I'm not wise in the ways of policy, does this change (or the linked bug) make sense: https://review.openstack.org/#/c/481443/
09:42:04 stephenfin cdent: I was purposefully leaving that until if/when johnthetubaguy was back. Apparently we were removing all default rules, so I'd imagine that will have some bearing on that
09:43:03 cdent stephenfin: ah okay, so the burden of setting the default is on the deployment?
09:44:02 stephenfin cdent: Wait, no - that was _discoverable_ policies (because they no longer make sense)
09:44:40 stephenfin Looks like claudiub added a load of those default rules. Maybe he can review https://review.openstack.org/#/c/481443/ and see if it makes sense?
09:56:36 openstackgerrit Rikimaru Honjo proposed openstack/nova master: compute: Do not create bdms before successfully reserving a volume https://review.openstack.org/290793
10:07:07 openstackgerrit Stephen Finucane proposed openstack/nova master: Always set MTU when plugging devices https://review.openstack.org/408781
10:12:10 pallavi_ Hi , I have done ubuntu manual installation for ocata release. I have launched instance. But accessing to the instance is not happening.?? Can anyone please help me out to figure it out
10:17:00 claudiub stephenfin: replied. that patch LGTM.
10:18:30 stephenfin claudiub: Thanks :) If you're happy, so am I
10:23:27 claudiub stephenfin: if you're happy and you know it, clap your hands! *clap* *clap*. :D
10:23:49 cdent thanks claudiub
10:28:11 gibi bauzas: hi! There is a small test and doc only patch that needs a second +2. Could you check it please? https://review.openstack.org/#/c/480469/
10:28:22 bauzas gibi: roger this.
10:28:43 gibi bauzas: thanks!
10:35:51 sean-k-mooney jangutter: hi the bridge name is currently set here https://github.com/openstack/neutron/blob/8326a65a5e3c70c66a5297c618d0202c9395cc3f/neutron/plugins/ml2/drivers/openvswitch/mech_driver/mech_openvswitch.py#L94-L105
10:37:03 sean-k-mooney jangutter: so in you mech driver if you just overrided that fuction you can pass the bridge name via the vif binding details.
10:38:40 sean-k-mooney jangutter: this then get populated into the os-vif network object here https://github.com/openstack/nova/blob/d955eb1db753f191acb02eb9758080329da5b866/nova/network/os_vif_util.py#L225-L226
10:40:17 sean-k-mooney jangutter: and its used in os-vif here: https://github.com/openstack/os-vif/blob/4a8e07f6c502e5e3b99db9ba543a501fbb138596/vif_plug_ovs/ovs.py#L97 and anywayer else we need the bridge name
10:43:53 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove plug_ovs_hybrid, unplug_ovs_hybrid https://review.openstack.org/483030
10:43:54 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Remove useless test https://review.openstack.org/483031
10:44:00 bauzas stephenfin: gibi: something got messed up with our man pages
10:44:10 stephenfin ?
10:44:21 bauzas eg. <http://docs.openstack.org/developer/nova/man/nova-manage.html#nova-cells-v2 is pointing nowhere
10:44:32 stephenfin Yeah, that's a pbr bug
10:44:43 stephenfin *Oh, that's like that pbr bug
10:44:57 stephenfin *likely
10:44:58 stephenfin dammit
10:45:25 stephenfin bauzas: https://bugs.launchpad.net/pbr/+bug/1702872
10:45:26 openstack Launchpad bug 1702872 in PBR "pbr + Sphinx 1.6+ ignores the '[sphinx_build] builders' setuptools option" [Undecided,In progress] - Assigned to Stephen Finucane (stephenfinucane)
10:46:17 stephenfin I'll tack a fix onto the end of the https://review.openstack.org/#/q/topic:doc-migration+project:openstack/nova series, once pep8 fix patch goes in (it needs a rebase again)
10:46:23 bauzas stephenfin: I just +2d https://review.openstack.org/#/c/478472/7 because it workarounds the issue
10:46:47 bauzas stephenfin: I'm not sure it should be a cli/ section, but meh
10:47:10 bauzas at least it's understandable that nova-manage and nova-status are CLI tools
10:47:53 stephenfin Yeah, sdague said the same thing. However, we've no where else to put those man pages
10:48:05 stephenfin I wanted that section called 'man' instead, but didn't make my case strongly enough :(
10:55:17 openstackgerrit Alex Szarka proposed openstack/nova master: Transform instance.exists notification https://review.openstack.org/403660
11:13:54 openstackgerrit Chris Dent proposed openstack/nova master: Add functional test for two-cell scheduler behaviors https://review.openstack.org/452006
11:54:14 gibi cdent: thank you for your detailed answer on my placement question on the ML. It helps a lot
11:57:00 openstackgerrit Claudiu Belu proposed openstack/nova master: hyperv: Cleans up live migration Planned VM https://review.openstack.org/478943
11:57:31 jangutter sean-k-mooney: hmmm, I still get: ERROR os_vif NotImplementedError: Cannot load 'bridge' in the base class
11:58:28 sean-k-mooney jangutter: how are you accessing the bridge? via the network object?
11:59:33 jangutter sean-k-mooney: vif.network.bridge -> I think that might not be populated for vhostuser
11:59:49 sean-k-mooney jangutter: if you do a neutron port show or openstack port show do you see the bridge correctly set in the vif_binding_details
12:00:37 sean-k-mooney jangutter: it should be populated or it means that vlan aware vms dose not work for vhost-user and this is a nova bug we need to fix
12:01:55 sean-k-mooney jangutter: yep you are right.... https://github.com/openstack/nova/blob/d955eb1db753f191acb02eb9758080329da5b866/nova/network/neutronv2/api.py#L2157-L2179
12:02:17 sean-k-mooney jangutter: do you want to submit the patch or will i
12:02:27 jangutter sean-k-mooney: binding_vif_details -> ovs_hybrid_plug='False', port_filter='True'
12:03:40 jangutter sean-k-mooney: depends on what will get it merged faster :-)
12:03:40 sean-k-mooney actully no i misread that https://github.com/openstack/nova/blob/d955eb1db753f191acb02eb9758080329da5b866/nova/network/neutronv2/api.py#L2172-L2173 it is saved for vhost-user
12:04:21 sean-k-mooney jangutter: so ya the bug is in the neutron ml2 driver yuou are missing the bridge key in the vif_binding_details
12:05:21 jangutter sean-k-mooney: Aah, and the workaround is to add: elif vif_type == network_model.VIF_TYPE_AGILIO_OVS to that list.
12:05:42 sean-k-mooney jangutter: you really should not have a new vif_type
12:06:20 sean-k-mooney there will not be a new vif object in os-vif and you should not need one for nova or neutron
12:06:52 sean-k-mooney the vif type shoud just be VIF_TYPE_VHOSTUSER
12:07:14 jangutter sean-k-mooney: I am using VIF_TYPE_VHOSTUSER for the actual plugging.
12:07:28 sean-k-mooney jangutter: you should also be using it for port binding
12:08:11 sean-k-mooney we are trying to stop using vif types as a flag for how to plug interfaces and retrun them to being a statemant about what type if interface you want
12:09:03 sean-k-mooney or in otherwords the vif_type is an abstion for the hyperviser interface type and is not related to how that interface is pluged to the network backend at all
12:10:06 jangutter sean-k-mooney: yeah. so one thing that kinda breaks the abstraction is that the "forwarder" is actually a kind of translation layer on top of the hypervisor.
12:10:29 jangutter sean-k-mooney: and introducing another layer just leads to madness.
12:10:29 sean-k-mooney jangutter: that is captured by the vnic_type
12:11:00 jangutter sean-k-mooney: yep. let me see if I can figure out if I'm doing the wrong thing in my ML2 driver.
12:12:50 jangutter sean-k-mooney: (facepalm) network_model.VIF_DETAILS_VHOSTUSER_OVS_PLUG
12:13:43 sean-k-mooney jangutter: ya you might need to set that
12:14:14 sean-k-mooney that is a legacy thing that should go away when we can specify the plugin to use in the vif details
12:17:19 foutatoro hi all, I would like to know how to deploy hypervisors VMware vSphere and Hyper-V on compute nodes ?
12:18:14 openstackgerrit OpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata https://review.openstack.org/477091
12:18:41 openstackgerrit Béla Vancsics proposed openstack/nova master: Transform aggregate.update_metadata notification https://review.openstack.org/460625
12:19:28 openstackgerrit Balazs Gibizer proposed openstack/nova master: use already loaded BDM in instance. https://review.openstack.org/483324
12:30:54 cdent gibi: glad it was of some use, looking forward to seeing more of what you're doing
12:32:05 stephenfin sean-k-mooney, jaypipes: Fancy taking a look at this? Easy +1/2, imo https://review.openstack.org/#/c/483030/
12:34:09 toabctl is there a way to list hosts which are not attached to a cell (v2) ?
12:38:48 sean-k-mooney stephenfin: sure, looking at it now
12:42:57 stephenfin sean-k-mooney: Cheers. Out of curiosity, is the expectation that all the old, non-os-vif plugging/unplugging code would eventually be replaced by code that harnesses vendor-developed os-vif plugins?
12:43:04 stephenfin e.g. All of these https://github.com/openstack/nova/blob/master/nova/virt/libvirt/vif.py#L599-L764 would be replaced by these https://github.com/openstack/nova/blob/master/nova/network/os_vif_util.py#L346-L403
12:44:09 openstackgerrit Merged openstack/nova master: doc: Enable pep8 on doc generation code https://review.openstack.org/480469
12:44:33 openstackgerrit OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/483337
12:47:03 sean-k-mooney stephenfin: yes that was the original intention was to add an os-vif pluging for all the old types. modify neutron ml2 driver to pass plugin name in vif details and then eventurlly remove os_vif_util when we finally have neutron retrunin serialised os-vif objects from its api
12:50:54 stephenfin sean-k-mooney: OK, so regarding the comment here https://review.openstack.org/#/c/483030/2/nova/virt/libvirt/vif.py ...
12:52:13 stephenfin would we be submitting a bug against os-vif, or would that be a separate plugin maintained in its own repo by the floodlight team?
12:52:15 sean-k-mooney stephenfin: yep i was suggesting opening a bug against https://github.com/openstack/networking-bigswitch
12:52:31 stephenfin ahhh
12:54:12 sean-k-mooney stephenfin: IVS is a bigswitch networks competitor to ovs . it is the only thing that uses the IVS vif type https://github.com/openstack/networking-bigswitch/blob/master/networking_bigswitch/plugins/ml2/drivers/mech_bigswitch/driver.py#L422-L431
12:54:57 stephenfin sean-k-mooney: Yeah, so they'd "own" the repo. It would be merged into 'openstack/os-vif'?
12:56:01 sean-k-mooney stephenfin: no its an non reference backend so im proposing that we wright an os-vif plugin for them and proposes it to there repo then deprecate the nova code and remove it once it is merged
12:56:32 sean-k-mooney stephenfin: alternitively we can create our only os-vif-ivs repo and that we own for this backend
12:57:18 sean-k-mooney it depend on whetere you want to tie the packaging of the plugin to the packaging of the ml2 driver which arguably you might want to keep seprate
13:00:35 stephenfin We'll let them make that decision, I guess
13:00:57 stephenfin sean-k-mooney: ...though IMO they're separate products so they should be. We'll see
13:01:00 stephenfin I'll file that bug now
13:02:18 sean-k-mooney am well if we have a seperate repo we dont need a bug on networking-bigswtich though we could use that bug to disucss this with them i guess?
13:05:33 stephenfin sean-k-mooney: Yeah, that's what I think. They will probably have their own ideas too
13:05:44 stephenfin If nothing else, they'll need to give us a repo to populate
13:06:03 openstackgerrit OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/483337
13:16:43 stephenfin sean-k-mooney: https://bugs.launchpad.net/networking-bigswitch/+bug/1704129
13:16:45 openstack Launchpad bug 1704129 in networking-bigswitch "Add an IVS os-vif plugin" [Undecided,New]
13:19:24 openstackgerrit Balazs Gibizer proposed openstack/nova master: use already loaded BDM in instance. https://review.openstack.org/483324

Earlier   Later