| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-05 | |||
| 14:13:39 | mriedem | ok there was something else we found when investigating that other evacuate bug, | |
| 14:14:03 | stephenfin | sean-k-mooney: We are able to fetch that from neutron though, right? https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L1131-L1133 | |
| 14:14:09 | mriedem | was we can pass force=None here https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/evacuate.py#L120 | |
| 14:14:34 | mriedem | but the compute api assumes it's a boolean https://github.com/openstack/nova/blob/master/nova/compute/api.py#L4170 | |
| 14:14:42 | mriedem | but since it can be None that's not quite right | |
| 14:15:11 | openstack | bug 1658070 in OpenStack Compute (nova) newton "Failed SR_IOV evacuation with host" [High,In progress] https://launchpad.net/bugs/1658070 - Assigned to Matt Riedemann (mriedem) | |
| 14:15:11 | mriedem | anyway, we didn't fix that as part of bug 1658070 since the claim issue was fixed in the compute | |
| 14:15:22 | mriedem | i have to take maya to daycare | |
| 14:15:26 | mriedem | bbiab | |
| 14:15:35 | sean-k-mooney | stephenfin: you can but it would be good to include this in the os-vif network object so that you can jsut read it from there. that would require neutron to populated it in the vif binding details | |
| 14:16:43 | stephenfin | sean-k-mooney: Yeah, that's a good idea. I'll take a look and see how awkward it is | |
| 14:17:54 | sean-k-mooney | stephenfin: well this is what you would need to extend in os-vif https://github.com/openstack/os-vif/blob/master/os_vif/objects/network.py#L28-L39 | |
| 14:18:59 | sean-k-mooney | stephenfin: this is the neutron extention that provides access to the dns name https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/dns_domain_ports.py | |
| 14:23:11 | openstack | Launchpad bug 1702491 in os-vif "[RFE] 'os_vif.objects.network.Network' should expose dns_name" [Undecided,New] | |
| 14:23:11 | stephenfin | sean-k-mooney: https://bugs.launchpad.net/os-vif/+bug/1702491 | |
| 14:23:27 | stephenfin | I'll take a shot at that, using your MTU changes as a blueprint | |
| 14:25:41 | sean-k-mooney | stephenfin: you might want to add the info here https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L2186 and then extend https://github.com/openstack/nova/blob/0b9bacb3ef29f59f1461ce62f65f9d1f6efab761/nova/network/os_vif_util.py#L212 to populate the os-vif version | |
| 14:33:09 | openstackgerrit | Stephen Finucane (stephenfin) proposed openstack/nova master: metadata: Don't use nova-net DNS values with neutron https://review.openstack.org/480616 | |
| 14:46:53 | openstackgerrit | Stephen Finucane (stephenfin) proposed openstack/os-vif master: objects: Add 'dns_domain' attribute to 'Network' https://review.openstack.org/480630 | |
| 14:49:38 | mriedem | dansmith: replied to your comments in https://review.openstack.org/#/c/468227/ | |
| 14:53:55 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Fix arguments in calling _delete_nic_metadata https://review.openstack.org/480369 | |
| 14:54:39 | mriedem | ugh | |
| 14:55:40 | mriedem | someone want to +W that ^ ? | |
| 15:12:46 | mriedem | sfinucan: i think https://review.openstack.org/#/c/480616/ needs a tweak, | |
| 15:13:11 | mriedem | seems we should have always had a CONF.dhcp_domain or '' in the last substitution in that code | |
| 15:13:29 | mriedem | if CONF.dhcp_domain was set to None in nova.conf it would result in a weird hostname | |
| 15:14:11 | mriedem | anyway, don't really need to worry about that for nova-net if people are just using the default of novalocal | |
| 15:18:23 | avolkov | cdent: I finished with api ref for all methods (except POST inventories) and want to update api ref tool | |
| 15:19:27 | avolkov | cdent: nothing about publish job, but I think it's easy to fix | |
| 15:21:45 | gibi | mriedem: hi! could you express your opinion about binary vs. service here https://review.openstack.org/#/c/476538/4/nova/notifications/objects/base.py ? | |
| 15:28:26 | mriedem | ugh | |
| 15:28:36 | mriedem | can i not have an opinion? | |
| 15:29:19 | gibi | mriedem: can you just +2 it blindly? :) | |
| 15:30:41 | mriedem | nova-api isn't a binary | |
| 15:30:41 | bauzas | mriedem: you're the chief and we blindly follow you | |
| 15:30:45 | mriedem | calling it such isn't really correct | |
| 15:30:47 | mriedem | and just causes confusing | |
| 15:30:56 | mriedem | the api binary is actually nova-osapi_compute | |
| 15:31:25 | mriedem | when is the queens ptl election... | |
| 15:32:30 | gibi | mriedem: what about calling to 'source' | |
| 15:34:08 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix comment for API binary name in WSGIService https://review.openstack.org/480648 | |
| 15:35:41 | sean-k-mooney | sfinucan: mriedem what does the hydrate fuction do? https://github.com/openstack/nova/blob/bdd6876b8feca2532fa5d9e2e98028b4d19ba6b6/nova/network/model.py#L492-L496 i didnt know object could be thristy | |
| 15:36:00 | mriedem | sean-k-mooney: deserializes the json blob | |
| 15:36:14 | mriedem | *serialized json string i mean | |
| 15:36:36 | mriedem | that thing gets stored in the instance_info_cache.network_info column as a serialized json string | |
| 15:36:39 | sean-k-mooney | mriedem: ok and its not called load or deserialize because? | |
| 15:36:48 | mriedem | because hydrate is cooler? | |
| 15:36:53 | mriedem | idk | |
| 15:37:08 | mriedem | we should call it explode() | |
| 15:37:13 | mriedem | and implode() | |
| 15:37:24 | sean-k-mooney | ok well some new i learned today. | |
| 15:45:14 | mriedem | gibi: comments inline | |
| 15:47:39 | gibi | mriedem: thanks, looking | |
| 15:48:11 | mriedem | no sdague this week? | |
| 15:48:26 | mriedem | clarkb: can you peek at the assertions about compute endpoint format being made in here? https://review.openstack.org/#/c/479818/ | |
| 15:48:30 | mriedem | https://review.openstack.org/#/c/479818/6/novaclient/v2/versions.py | |
| 15:48:37 | ericyoung | we have a patch for nova, to use ScaleIO for ephemeral storage. It's passed CI and mdbooth had offered to review it for us. | |
| 15:48:59 | ericyoung | We haven't been able to get ahold of him, can someone else take a look for us at https://review.openstack.org/#/c/407440/ | |
| 15:49:37 | mriedem | ericyoung: just fyi, there are 35 blueprints that need review yet for pike https://blueprints.launchpad.net/nova/pike | |
| 15:50:21 | clarkb | mriedem: you can do unversioned if the endpoint supports version discovery which nova does do? | |
| 15:50:23 | clarkb | mordred: ^ | |
| 15:50:57 | mriedem | looking at https://developer.openstack.org/api-ref/compute/#api-versions it's not totally clear to me | |
| 15:51:41 | clarkb | mriedem: / list all major versions <- pretty sure that means /compute/ is valid rather than /compute/vWhatever | |
| 15:51:48 | ericyoung | mriedem: this blueprint was already approved for pike | |
| 15:51:51 | mriedem | i remember the openstacksdk team having a thread in the ML last year struggling with the plethora of possible endpoint url formats in the wild | |
| 15:52:03 | mriedem | ericyoung: yes, so are those other 34 | |
| 15:52:06 | mriedem | ericyoung: that's my point | |
| 15:52:51 | openstack | Launchpad bug 1631480 in OpenStack SDK "session endpoint lookup doesn't handle endpoints with paths" [Undecided,New] | |
| 15:52:51 | mriedem | clarkb: yeah i remember having reported this to the sdk team https://bugs.launchpad.net/python-openstacksdk/+bug/1631480 | |
| 15:53:03 | mriedem | because we had a network endpoint like this: publicURL: http://localhost:5000/network | | |
| 15:56:08 | mriedem | dansmith: will we be cellsv2 meeting today? | |
| 15:56:11 | mriedem | because i have developments | |
| 15:56:25 | dansmith | mriedem: sure | |
| 15:57:39 | ericyoung | mriedem: understood. I'm not trying to be a pain, just wondering if there was someone else who could look or if we should just sit tight. | |
| 15:57:54 | mriedem | ericyoung: you're basically in the latter camp at this point | |
| 15:59:22 | cdent | anybody want to put eyes on https://review.openstack.org/#/c/460147/ has one +2 already. bauzas ? mriedem ? | |
| 16:00:57 | mriedem | i've been -1 on that one a few times now, so i can look at it again | |
| 16:01:36 | gibi | mriedem: I will try to do a binary->source renaming with the major version bump. I think it is not that hard in this particular case. | |
| 16:05:11 | bauzas | cdent: looking | |
| 16:11:54 | bauzas | cdent: jaypipes: we're not passing back the generation bit when deleting ? https://review.openstack.org/#/c/460147/15/nova/scheduler/client/report.py@666 | |
| 16:12:17 | cdent | the response body is empty when deleting | |
| 16:12:32 | cdent | (in that case) | |
| 16:13:17 | mriedem | yeah, so our generation + 1 could actually be wrong | |
| 16:13:21 | mriedem | but, | |
| 16:13:29 | openstackgerrit | Mathieu Gagné proposed openstack/nova master: Add ability to signal and perform online volume size change https://review.openstack.org/454322 | |
| 16:13:31 | mriedem | i think when we try to use that incorrect generation we'll fail later, and get it corrected | |
| 16:13:32 | mriedem | somewhere in here | |
| 16:14:12 | mriedem | in _get_inventory_and_update_provider_generation | |
| 16:14:23 | stephenfin | mriedem: Random question. Is there any reason we would want 'refresh_cache' to be False for '_has_port_binding_extension'? https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L1013 | |
| 16:14:50 | mriedem | and _update_inventory_attempt | |
| 16:14:54 | mriedem | stephenfin: no idea | |
| 16:14:59 | stephenfin | I ask because I note that _has_multi_provider_extension always refreshes the cache, while _has_auto_allocate_extension never does (outside of tests) | |
| 16:15:00 | stephenfin | Ah :) | |
| 16:15:10 | mriedem | there is no rhyme or reason to when we refresh the cache of neutron extensions | |
| 16:15:18 | mordred | mriedem, clarkb: what's the question about unversioned endpoints? | |
| 16:15:28 | cdent | mriedem: yeah, it will get correct if wrong, what's being doing there is an optimistic sort of "this is more likely to be correct than it would be if we did nothing" | |
| 16:15:32 | mriedem | the auto allocation extension was new in mitaka and i believe not optional, or so i was told, | |
| 16:15:53 | mriedem | but we check for it's existence to see if we're talking to older neutron | |
| 16:15:57 | bauzas | mriedem: cdent: well, I'd say it's unfortunate but workable given we retry | |
| 16:16:07 | mriedem | mordred: https://review.openstack.org/#/c/479818/6/novaclient/v2/versions.py | |