Earlier  
Posted Nick Remark
#openstack-nova - 2017-07-05
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
16:16:18 bauzas cdent: yeah, from a REST PoV that's understandable
16:16:35 bauzas cdent: but I'm just thinking that we assert things a way too much hard
16:16:35 mordred mriedem: looking now
16:16:56 mriedem parsing that sentence is a way too much hard
16:16:57 mriedem :)
16:17:08 stephenfin mriedem: Given that the refresh_cache function actually does some sanity checks before firing off requests suggests we could _always_ refresh the cache https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L1003-L1005
16:17:32 mordred mriedem: the endpoints in the catalog should either be example.com/compute or example.com/compute/v2.1 if the operator puts a versioned endpoint into the catalog
16:17:37 stephenfin ...though maybe the auto allocation extension could be removed altogether. I'll have a look-see
16:18:09 mordred mriedem: we just added a crap ton of code to handle these things and tests for them in keystoneauth
16:18:18 mriedem stephenfin: yeah and that defaults to refresh every 10 minutes by default
16:18:32 mriedem stephenfin: is this cache refresh really a problem?
16:18:45 mriedem are operators enabling and disabling extensions ad hoc and it's causing real issues?
16:19:10 stephenfin I've no idea and was hoping you could enlighten me
16:19:10 mriedem mordred: and the sdk has a crap ton of code for it too :)
16:19:24 mriedem stephenfin: i assume operators are not doing that
16:19:48 mordred mriedem: yah - well, we should be porting the sdk over to use the code in ksa now so that there is only one place - but yeah
16:19:48 stephenfin mriedem: I would assume that too. I'm just adding a '_has_dns_extension' function and wanted to know if the cache check should be there or not
16:20:15 mordred mriedem: anyway - I'll leave some comments ...
16:20:23 stephenfin I'm going to stick it in to be safe but then go on a hunt for more info (likely goose chase - meh)
16:20:29 mriedem kevinbenton: do you know if the dns extension in neutron is optional?
16:20:57 stephenfin mriedem: I'm pretty sure sean-k-mooney said it was
16:21:05 stephenfin You need to have designate deployed for it to work
16:21:41 sean-k-mooney most of the extentions in neutron are optional.
16:22:00 stephenfin sean-k-mooney: Any idea where we'd find a definitive list?
16:22:59 mordred mriedem: OH - this is in novacient
16:23:07 mordred mriedem: I thought this was in nova server
16:23:10 sean-k-mooney well running openstack extension list | grep dns only gave me os-floating-ip-dns
16:23:21 sean-k-mooney so on ocata its not required.
16:23:21 mordred mriedem: as soon as we cut a release, you can straight-up delete this code
16:23:36 mordred mriedem: I'll make you a patch RSN
16:23:37 sean-k-mooney ill check master but i dont think its mandatoary
16:24:57 mriedem sean-k-mooney: os-floating-ip-dns is from the compute api
16:25:00 mriedem i.e. nova
16:25:03 mriedem i.e. nova-network
16:25:15 mriedem i don't know where or how openstack extension list gets it's data
16:27:17 mordred efried: https://review.openstack.org/#/c/479818 is worth looking at - it's right in the midst of all of the discovery work
16:29:34 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Add Cinder v3 detach to swap_volume https://review.openstack.org/456971
16:29:35 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Remove check_detach https://review.openstack.org/446671
16:29:36 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Implement new attach Cinder flow https://review.openstack.org/330285
16:29:57 dansmith efried: solidarity my brother.
16:35:25 dansmith mriedem: have you done any looking at this yet? https://review.openstack.org/#/c/416521/
16:35:26 dansmith doesn't look like it
16:40:45 mriedem dansmith: i looked at the LOC
16:40:51 mriedem and then i looked away
16:40:55 mriedem because i was flying over the pacific
16:41:08 dansmith ack
16:59:20 openstackgerrit Stephen Finucane proposed openstack/nova master: Always refresh cache when checking extensions https://review.openstack.org/480674
16:59:21 openstackgerrit Stephen Finucane proposed openstack/nova master: Add '_has_dns_extension' function https://review.openstack.org/480675
16:59:21 openstackgerrit Stephen Finucane proposed openstack/nova master: Use dns_domain value from neutron in os-vif wiring https://review.openstack.org/480676
17:01:12 dansmith mriedem: cells meeting?
17:01:18 mriedem yeah
17:09:58 sean-k-mooney mriedem: stephenfin running neutron ext-list on master also dos not have the dns extention enabled by default
17:18:10 sean-k-mooney igordcard: o/
17:19:19 melwitt dansmith: what did you mean by "get back the instance" before conductor is called? like if they did a GET and got an instance that was made from a BuildRequest?
17:20:24 dansmith melwitt: well, I mean: I do a create, I get back my instance uuid, which previously meant that I passed my quota check already, so I could wait for it to either go active or error
17:20:49 dansmith melwitt: now, I get that back, and for a split second, the instance continues to be in my list, but then goes away
17:20:53 dtp mriedem was your comment on https://review.openstack.org/#/c/464280/ for me?
17:21:00 melwitt oh
17:21:18 melwitt hmm
17:21:33 dansmith melwitt: I have scripts that poll instance list for the instance I just created
17:21:41 dansmith which will be confused as the instance will now just disappear
17:22:09 dansmith melwitt: definitely a behavioral change, so I think going to error instead of deleted is required here, right?
17:22:25 dansmith which will put them over budget by one, but it's a shell of an instance anyway
17:23:57 melwitt dansmith: yeah, I need to look at it in more detail bc what I'm doing there is deleting the record from the instances table, which isn't what you would have been seeing in your instance list prior to conductor finishing its work. but whatever exception handling that happens from the OverQuota raise might probably wipe out the BuildRequest that was giving the instance back before
17:24:25 dansmith you're following the same pattern as the other resources, but those are created and deleted synchronously
17:24:57 sean-k-mooney mriedem: stephenfin so if i deploy designate i get dns-integration added when i run neutron ext-list
17:24:57 dansmith melwitt: yeah, I think the buildreq will be gone, but you're not wiping out the instance record,
17:25:03 dansmith melwitt: you're setting it to deleted
17:25:12 dansmith melwitt: which is still findable via the instance map until purge
17:25:14 melwitt yeah, I know. the instances table record is created synchronously there too, it's just that prior to that, a BuildRequest is used to present an instance to keep the same behavior we had before moving instance create to conductor
17:25:25 dansmith melwitt: synchronous to the api call Imea
17:25:28 dansmith *I mean
17:25:43 melwitt okay, yeah
17:26:33 sean-k-mooney mriedem: stephenfin this adds some dns field to the port info http://paste.openstack.org/show/614483/
17:26:52 melwitt dansmith: so yeah, probably that's the only thing we can do, set it to ERROR
17:26:58 dansmith melwitt: aye
17:27:16 dansmith melwitt: and we need an instance action or fault message or something so people can tell why
17:27:29 dansmith melwitt: otherwise they'll just go create again, which I guess will probably fail immediately, but still
17:28:00 melwitt dansmith: right. yeah, good point
17:32:44 melwitt dansmith: I have a crazy idea of maybe counting BuildRequests as part of the instances count. not sure if there's any gotchas there
17:33:01 melwitt to make it so we dont return an instance if we go over quota during a race in the first place
17:33:07 dansmith melwitt: meaning counting both and taking the sum?
17:33:31 melwitt yeah
17:33:38 dansmith I don't think you can do that naively unless you filter out the dupes, because we do have dupes for a bit right?
17:33:49 sean-k-mooney stephenfin: if i boot a new instace after designate is there it correct populates the server name from the create command into the hostname and fqdn fields http://paste.openstack.org/show/614486/
17:34:07 dansmith melwitt: we create the instance and then delete the buildreq so the api code starts looking at the actual instance, IIRC
17:34:19 melwitt dansmith: hm, I didn't realize it dupes
17:34:25 melwitt yeah

Earlier   Later