| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-05 | |||
| 13:46:37 | stephenfin | sean-k-mooney: Any ideas on https://bugs.launchpad.net/nova/+bug/1698010 ? | |
| 13:46:41 | stephenfin | ralonsoh too ^ | |
| 13:48:02 | ralonsoh | stephenfin: let me take a look at this one | |
| 13:48:18 | mriedem | stephenfin: that is a duplicate, | |
| 13:48:21 | mriedem | just need to find the other bug | |
| 13:48:24 | stephenfin | I can get network info from the instance using 'Instance.get_network_info', but it just returns a list of 'os_vif.objects.vif.VIFBase' subclass instances | |
| 13:48:29 | stephenfin | mriedem: Oh hai | |
| 13:48:38 | mriedem | the dhcp_domain option is read in the metadata api code and that's how it gets into config drive | |
| 13:48:48 | mriedem | as noted by bnemec in the bug report it's showing up via cloud-init | |
| 13:49:08 | stephenfin | Yup :( I was trying to see where I could get the neutron equivalent from, but we don't seem to cache it anywhere | |
| 13:49:27 | stephenfin | and I don't want to call out to neutron for every instance (assuming that is even an option) | |
| 13:50:07 | mriedem | we already call to neutron for dns info when we create or attach to a port | |
| 13:51:05 | stephenfin | Hmm, so is that a viable path to pursue? | |
| 13:51:37 | openstack | Launchpad bug 1702454 in OpenStack Compute (nova) "Transforming the RequestSpec object into legacy dicts doesn't support the requested_destination field" [High,Confirmed] - Assigned to Sylvain Bauza (sylvain-bauza) | |
| 13:51:37 | bauzas | mriedem: permission to apologize, captain. https://bugs.launchpad.net/nova/+bug/1702454 | |
| 13:52:18 | bauzas | mriedem: tl;dr: evacuations providing a target don't verify that target since newton | |
| 13:53:04 | mriedem | i thought the bug said that was only for legacy specs or whatever? | |
| 13:53:27 | mriedem | someone from suse was just fixing bugs in stable related to evacuate with a targeted host, so something must work | |
| 13:54:17 | bauzas | mriedem: see the description | |
| 13:54:39 | bauzas | mriedem: that's because we turn into dicts only for evacuate | |
| 13:54:41 | mriedem | stephenfin: could we just make dhcp_domain default to None? that would change how https://github.com/openstack/nova/blob/0b9bacb/nova/api/metadata/base.py#L546-L549 behaves | |
| 13:55:00 | bauzas | mriedem: and tbh, the bug was reported internally on our Newton branch | |
| 13:55:35 | bauzas | so I doubt it's fixed upstream but just master because of https://review.openstack.org/#/c/469037/ | |
| 13:55:42 | bauzas | that's where tech debt kills us | |
| 13:56:10 | bauzas | and I wouldn't like to backport https://review.openstack.org/#/c/469037/ | |
| 13:56:20 | bauzas | rather fixing the problem with the transformating | |
| 13:56:58 | stephenfin | mriedem: It would change it, but I don't think it would deliver the desired behavior. bnemec did that, and cloudinit added a default 'localdomain' domain instead of what neutron had configured ('nemebean.com') | |
| 13:58:23 | openstackgerrit | Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766 | |
| 14:05:44 | dansmith | mriedem: are we going to go ahead with this? https://review.openstack.org/#/c/468227/2 | |
| 14:07:37 | mriedem | dansmith: related to bauzas' evacuate in newton clusterfunnery above? | |
| 14:07:53 | mriedem | is there a rhosp newton evacuate red alert going off this morning? | |
| 14:08:20 | bauzas | not really | |
| 14:08:24 | bauzas | AFAIK | |
| 14:08:24 | dansmith | mriedem: is it related to that? I don't think so | |
| 14:08:34 | bauzas | just some internal BZ triage I did | |
| 14:08:44 | dansmith | I don't know about bauzas' thing so I assume unrelated | |
| 14:08:52 | mriedem | dansmith: but yes we should get that in - the evacuate stuff with forced target was broken since newton i think | |
| 14:08:54 | bauzas | yup, unrelated | |
| 14:09:01 | dansmith | mriedem: yeah it's definitely broken | |
| 14:09:01 | bauzas | mriedem: not forced | |
| 14:09:07 | dansmith | mriedem: okay then I'll review | |
| 14:09:09 | bauzas | mriedem: just 'passed' | |
| 14:09:25 | bauzas | dansmith: mriedem: I need to write a change, should be quick | |
| 14:09:47 | openstack | Launchpad bug 1702454 in OpenStack Compute (nova) "Transforming the RequestSpec object into legacy dicts doesn't support the requested_destination field" [High,Confirmed] - Assigned to Sylvain Bauza (sylvain-bauza) | |
| 14:09:47 | bauzas | dansmith: context is https://bugs.launchpad.net/nova/+bug/1702454 | |
| 14:09:57 | mriedem | ok i guess i don't know how the evacuate api handles passing a host and forcing a host differently | |
| 14:10:15 | bauzas | mriedem: that's simple | |
| 14:10:47 | bauzas | since 2.29 (or 2.30, don't remember which one), if you pass a target to the API, then we verify that target by the scheduler | |
| 14:11:08 | bauzas | unless you pass a specific parameter to the API, namely 'force' | |
| 14:11:37 | bauzas | in that case, we fully bypass the scheduler call and we directly cast the compute service with the hostname | |
| 14:11:42 | sean-k-mooney | stephenfin: without designate im not sure how you can have instance use teh neutron dns_domain unless we add it to vif_binding details in some way. | |
| 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() | |