Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-24
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.
18:00:18 rfolco edleafe, that explains, thank you. Also, I am using a specific error message (previously returning db api error) when 409 conflict for inventory in use... but there is no way to emulate it in gabbits since they run serially. The only emulation possible is bad generation id. Any thoughts ?
18:00:30 sdague mriedem: you were too hopeful that the uuid thing wasn't a problem :)
18:01:45 edleafe rfolco: you would allocate against that inventory, checking for success. Then the next test would try to delete that same inventory, which should raise the 409
18:02:12 mriedem sdague: the jsonschema thing?
18:02:18 sdague mriedem: yep
18:02:21 mriedem i was looking for an easy button
18:02:31 sdague I responded
18:03:25 rfolco edleafe, cool, will check on allocation then, thx++
18:03:27 sdague the format isn't jsonschema native, it just means it calls a dedicated validating function
18:05:05 mriedem sdague: ha
18:05:06 mriedem sob
18:06:00 mriedem i see your reply and raise you
18:06:45 sdague mriedem: yeh, we all see different parts of the elephant
18:14:51 openstackgerrit Matt Riedemann proposed openstack/nova master: libvirt: remove redundant and broken iscsi volume test https://review.openstack.org/459420
18:14:53 mriedem ^ fixes cuhler's issue pointed out earlier, and unblocks us from using brick 1.12.0
18:15:32 smcginnis Following the docs.o.o install instructions for Ubuntu. Getting this error :The requested URL /placement/resource_providers was not found on this server"
18:15:35 smcginnis Any pointers?
18:16:02 mriedem smcginnis: hello new user, please see the channel topic and gtfo
18:16:09 mriedem :)
18:16:23 mriedem smcginnis: where are you getting the error? which service?
18:16:29 smcginnis mriedem: Just remember that when you want us to adopt placement usage too. :P
18:16:51 smcginnis mriedem: In the nova-compute log when trying to create a first test instance.
18:17:07 smcginnis Actually, regular intervals it looks like.
18:17:10 mriedem if compute couldn't talk to placement it shouldn't have started up in the first place
18:17:15 mriedem yeah, it should be spewing errors
18:17:28 mriedem are you able to make curl requests to placement from your compute node?
18:17:33 smcginnis From this: Failed to create resource provider record in placement API
18:17:59 mriedem smcginnis: source the same credentials that are in nova.conf on your compute host, and then create a token for those creds and try a curl request to the same placement endpoint url in the service catalog
18:18:12 mriedem to see if it's compute misconfig or something else
18:18:27 mriedem also, is the placement service logging anything?
18:18:30 mriedem it runs under apache

Earlier   Later