Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-24
15:16:31 mriedem jaypipes: https://review.openstack.org/#/c/443764/1/nova/compute/api.py@2066
15:16:32 bauzas oh man, just got an email asking me to take all my holidays before end of May
15:16:40 bauzas that's going to be legendary
15:16:53 sfinucan sean-k-mooney: Basic VIF definitions do exist - see 'doc/source/vif_types'
15:16:59 sfinucan bauzas: dibs!
15:17:43 mriedem dansmith: you can't upgrade the schema if you don't have cell0 in ocata
15:17:46 sean-k-mooney each plugin could discibe the the vif types it support but i would prefer to auto generate that documention form https://github.com/openstack/os-vif/blob/e133b8a3771ce6a49594af83b90586bdd88630ae/vif_plug_ovs/ovs.py#L67-L83 if we could
15:17:53 bauzas I'm always ashamed to speak about that here, but if I would take all my holidays, it could probably require me to stop working right after I come back from BOS :/
15:18:02 dansmith mriedem: unless you have an empty database because you're installing ocata for the first time
15:18:03 bauzas like not working for May
15:18:16 dansmith mriedem: and if you miss putting that record in, you get a unhelpful error condition
15:18:21 mriedem dansmith: if you have any empty db, how are you creating instances?
15:18:23 jaypipes mriedem: lovely..
15:18:25 sean-k-mooney sfinucan: any chance we could use something like your sphix click intergration to do taht
15:18:40 sean-k-mooney if not im sure i coudl script something up
15:18:57 dansmith mriedem: you had an empty database when applying the schema migrations, which made it past the cell0 check, then you start creating instances without doing your cell record setup
15:19:02 mriedem dansmith: this https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api_migrations/migrate_repo/versions/030_require_cell_setup.py
15:19:13 dansmith mriedem: right but that doesn't do anything for a fresh install
15:19:15 mriedem oh the gd flavor thing
15:19:21 mriedem ffs
15:19:52 mriedem jaypipes: yes soft delete is a turd
15:19:55 mriedem which should be flushed
15:21:21 mdbooth +1
15:21:38 sean-k-mooney sfinucan: basically in the docs job all we would need to do is load os-vif. loop over all the in tree plugins, call discribe and template our a descripts into a folder and then have sphinx auto include it in the docs that way its automatic and always up to date
15:22:37 sfinucan sean-k-mooney: I could but it might be overkill
15:22:50 sfinucan Realistically, how often are those lines going to change
15:23:25 sfinucan and, iirc, the plan is not to add any more plugins in os-vif (they should live in separate repos)
15:23:38 sean-k-mooney not that often we could just make it a requirement for adding more vif_types or port profiles to existing plugins as part of ongoing reviews
15:23:50 sean-k-mooney yep
15:24:31 mriedem dansmith: ok left a reply - but if we don't have cell0 to bury, we still have the build requests to list 'instances' and delete that 'instance', but we don't update the vm_state on the build request to ERROR
15:24:43 mriedem so those 'instances' just get stuck in scheduling state until you delete them (i think)
15:24:50 sean-k-mooney more vif types will be added to both plugins though and more port poriles but it wont be a large overhead to manually update the docs.
15:25:19 sfinucan sean-k-mooney: Yeah, I don't think it would be too much of a requirement
15:25:36 sfinucan docs usually help reviews anyway because they give way more context
15:26:33 sean-k-mooney sfinucan: one of the requests i got from the neutron folks was to allow os-vif to plug non vm interfaces so they could use it to plug the dhcp,l3 and tunnel ports when its intergrated into neutron
15:26:52 sean-k-mooney i opened some bugs for those with too do to fill them out later
15:27:47 dansmith mriedem: yep, but we have to have the big red warning I think
15:28:31 mriedem yeah i suppose.
15:28:45 sean-k-mooney we will need about 5 or 6 new vif_types to cover that (patch,vif_pair,vxlan,gre,geneve) i think im missing one but basically same pattern as vms and form and os vif point of view we dont really care what uses the port anyway.
15:29:00 mriedem dansmith: if we wanted to get the instance into ERROR state, we'd have to deserialize the build_request.instance, set it's vm/task state and then update the build_request right?
15:29:07 sfinucan sean-k-mooney: nova wouldn't care about those new ones, right?
15:29:41 dansmith mriedem: I dunno if that would do it, but perhaps.. I'm not too concerned about that I guess, since this is early setup you failed to do, so API semantics aren't that big of a deal, but..
15:30:16 sean-k-mooney on the one i was missing was tap. correct nova should not care though the tap vif type which is basically the existing generic vif type(i would proably just use that) could be used with calico
15:31:59 sfinucan sean-k-mooney: Yup, sounds good to me so
15:32:14 sfinucan sean-k-mooney: Going back to those docs then, I could probably put a note in saying that those supported vif_types are exposed using that host_info object, right?
15:33:11 sean-k-mooney sfinucan: yes if you could make them a link or somehow include the previous defintions of the docs from the global definiton that would also be good
15:33:43 sean-k-mooney i would prefer not to have multiple definitions of the same vif_type that could get out of sync if sphix supports that
15:33:57 sean-k-mooney if not its fine we can just keep them in sync with reviews
15:34:50 mriedem dansmith: fair enough
15:35:08 mriedem at some point if i care i might see how hard it is to reproduce and change the build request to error, but i might not care later either
15:36:04 dansmith heh
15:37:57 sfinucan sean-k-mooney: Ah, there is a difference. The general vif_type overview is provided in doc/source/vif_types
15:38:21 sfinucan The ones that we've added refer to how a given VIF is implemented for a given backend
15:38:53 sean-k-mooney sfinucan: thats the thing the vif_type is ment to be completly independent form that backend impelmtation
15:38:53 mriedem lyarwood: huzzah! https://review.openstack.org/#/c/459316/
15:39:09 mriedem mtreinish: sdague: ^ test_iscsi_volume in action
15:39:12 mriedem after so many years
15:39:42 sean-k-mooney the vif_type refers to how the hypervisor virtualise the interface not how that is connected to the datapalne but i can see why you would want to describe that also
15:39:43 sfinucan sean-k-mooney: Yes and no. It should expose the same API, but it has to work differently under the hood
15:47:38 lyarwood mriedem: nice :)
15:55:48 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove unused _create_block_device_mapping method from API https://review.openstack.org/459389
15:57:52 jaypipes vladikr, ralonsoh, sean-k-mooney, sfinucan, bauzas, edleafe and cdent: updated https://review.openstack.org/#/c/448283/. pls re-review at your convenience.
15:58:08 sfinucan (y)
15:58:39 ralonsoh ralonsoh: in a moment
15:59:04 ralonsoh jaypipes: in a moment (pfff I'm talking to myself)
15:59:20 sean-k-mooney jaypipes: running to meeting but will do after
16:01:32 sfinucan jaypipes: nice easy ones for you here too https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bump-min-libvirt
16:04:01 edleafe jaypipes: ack
16:04:49 jaypipes sfinucan: done.
16:05:09 sfinucan ta
16:16:44 openstackgerrit Stephen Finucane proposed openstack/os-vif master: Add documentation for OVS plugin https://review.openstack.org/459258
16:16:45 openstackgerrit Stephen Finucane proposed openstack/os-vif master: HW offload support for openvswitch https://review.openstack.org/398277
16:16:47 openstackgerrit Stephen Finucane proposed openstack/os-vif master: Add documentation for Linux Bridge plugin https://review.openstack.org/459291
16:27:29 mriedem sfinucan: nice easy cleanup win here https://review.openstack.org/#/c/391597/
16:27:41 mriedem and closes a bp to boot
16:45:37 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove BuildRequest.block_device_mapping clone workaround https://review.openstack.org/459406
16:47:06 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove BuildRequest.block_device_mapping clone workaround https://review.openstack.org/459406
16:48:21 mriedem dansmith: melwitt: ^ dredged up a lot of confusion over why we needed to do that in the first place https://review.openstack.org/#/c/394321/36/nova/compute/api.py@1056
16:48:50 mriedem i don't want to do the same thing for tags
16:49:07 mriedem i think we just pass the original dirty tag list to conductor like we do for bdms and we should be fine
17:02:51 cuhler Is it a known problem that nova.tests.unit.virt.libvirt.volume.test_iscsi.LibvirtISCSIVolumeDriverTestCase.test_iscsiadm_discover_parsing is failing?
17:02:57 cuhler It is holding up https://review.openstack.org/#/c/458688/
17:03:09 cuhler Is someone looking at it already?
17:06:21 cuhler The problem is that LibvirtISCSIVolumeDriver connector's _get_target_portals_from_iscsiadm_output method now returns a list instead of an array as it used to.
17:06:35 cuhler Either that's a bug or the unit test didn't get updated.
17:18:33 dansmith mriedem: do you plan to write tests for that cleanup patch?
17:18:49 dansmith doesn't fail anything now and it'd be an odd assertion in isolation I guess
17:19:13 openstackgerrit Chris Dent proposed openstack/nova master: Add pbr-installed wsgi application for metadata api https://review.openstack.org/459413
17:34:54 rfolco jaypipes, start using new delete inventories method implies in chaning put to delete in https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L625 - sounds correct ? I am just wondering where is the delete_inventory for a single inventory.
17:38:31 sean-k-mooney jaypipes: https://review.openstack.org/#/c/448283/5 looks good to me in it current form
17:38:51 mriedem dansmith: i didn't plan on it no
17:39:04 mriedem functional tests passing should be sufficient
17:40:07 dansmith okay
17:41:04 mriedem dansmith: unrelated, but looking at https://review.openstack.org/#/c/457338/ i didn't even think about how server groups could have members in different cells
17:41:18 mriedem at least for anti-affinity
17:41:30 dansmith yup
17:55:27 mriedem dansmith: ok comments in that patch
17:55:31 mriedem -1 for a test thing
17:55:57 dansmith thanks, will look in a sec
17:57:42 edleafe rfolco: there isn't a way to delete a single type of inventory for a RP. You should use set_inventory_for_provider() instead, and only include the inventory for the types that the RP has.

Earlier   Later