Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-07-05
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()
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"

Earlier   Later