Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-12
12:13:44 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/nova master: Read Neutron port 'binding_profile' during boot https://review.openstack.org/449257
12:23:26 openstackgerrit Andrey Volkov proposed openstack/nova master: [placement] Fix placement-api-ref check tool https://review.openstack.org/456198
12:25:07 openstackgerrit Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for PUT RP inventory https://review.openstack.org/455214
12:25:07 openstackgerrit Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for DELETE RP inventory https://review.openstack.org/455215
12:25:08 openstackgerrit Andrey Volkov proposed openstack/nova master: [WIP] [placement] Add api-ref resource provider https://review.openstack.org/456176
12:34:45 sfinucan sdague: When we deprecate an API in a microversion, does there come a point where we can delete all the code behind it?
12:35:27 sfinucan for example, is the deprecated nova-network API code still in the code base but not exercised?
12:35:43 sfinucan alex_xu: You might be able to answer that for me too ^ :)
12:36:49 mriedem sfinucan: nova-network is still used for cells v1
12:36:58 sdague sfinucan: nova-net is kind of a special case
12:37:04 mriedem sfinucan: also, we deprecate an api at a microversion so things don't work at that microversion or later, but 2.1 still works
12:37:48 sfinucan mriedem: Right, but what about for other APIs. Would we ever delete the code behind the APIs you'd like to deprecate this cycle, e.g. os-hosts?
12:38:35 sfinucan I imagine we can't because then microversion {version before deprecation} wouldn't respond the same way
12:38:52 sfinucan ...but, if so, what's the point of deprecating anything if we can't eventually remove the code
12:39:33 sdague you deprecate things as well to signal folks not to use that bit because it's not well maintained
12:41:24 sfinucan sdague: but crucially we had to keep that code ad infinitum and keep testing it?
12:43:12 openstackgerrit Stephen Finucane proposed openstack/nova master: Fix network metadata information - part 3/3 https://review.openstack.org/450297
12:47:55 openstackgerrit dane-fichter proposed openstack/nova master: Remove backend dependency for key types https://review.openstack.org/456204
12:47:57 mriedem sfinucan: if we ever start raising required minimums,
12:48:02 mriedem then we could delete some older code
12:48:12 mriedem sfinucan: ironic wants to do that, and i think it's going to be discussed at the forum
12:49:31 sfinucan mriedem: Ohhh, now that you mention it I do recall that being discussed at...the PTG (?) Thanks for the info :)
12:50:40 dane-fichter mriedem: pushed a fix for that cursive bug
12:50:59 dane-fichter mriedem: do we need to do the same for the hash algs too?
12:51:03 sfinucan johnthetubaguy: As our (my) resident "is reno required" expert - thoughts on https://review.openstack.org/#/c/450211 ?
12:51:57 mriedem dane-fichter: comments in https://review.openstack.org/#/c/456204/1
12:52:14 johnthetubaguy sfinucan: that looks like a breaking API change, so feels like users will need a heads up about that
12:52:38 frickler johnthetubaguy: sfinucan: reno for all three patches is in the final one: https://review.openstack.org/#/c/450297/3
12:53:10 sfinucan frickler: Aha - I didn't spot that :) Thanks for the heads up
12:53:26 johnthetubaguy sfinucan: I find it hard to review anything in the metadata right now, due to the general poor testing around that whole thing
12:53:35 frickler sfinucan: added it for you after your earlier review ;)
12:53:55 sfinucan johnthetubaguy: Aye, that's on my backlog of things to do this cycle
12:55:04 johnthetubaguy sfinucan: that looks like an API change without a spec, the reno covers the details I guess...
12:55:24 frickler sfinucan: not sure the W+1 on the first patch is intentional? doesn't seem to fit with your -1 review
12:55:25 alex_xu sfinucan: yea, as mriedem said, we can raise the min version of microversion. but we won't raise the min version easily
12:55:36 sfinucan johnthetubaguy: Think there's a spec required?
12:55:42 sfinucan dammit
12:55:44 alex_xu nova api meeting is in 5 mins at #openstack-meeting-4
12:55:51 openstackgerrit Stephen Finucane proposed openstack/nova master: Fix network metadata information - part 1/3 https://review.openstack.org/450211
12:56:21 openstackgerrit Stephen Finucane proposed openstack/nova master: Fix network metadata information - part 2/3 https://review.openstack.org/450212
12:56:27 johnthetubaguy sfinucan: I duno, that would be my default take for an API change, just so we have agreement on the change, we did talk about adding this in a new metadata version only
12:56:33 openstackgerrit Stephen Finucane proposed openstack/nova master: Fix network metadata information - part 3/3 https://review.openstack.org/450297
12:57:09 mriedem the release note makes it sound like the changes are additive, but yeah it's hard when we don't test the thing and it's an unversioned json blob
12:59:17 johnthetubaguy frickler: its a good change, don't get me wrong, just getting my head around protecting the folks that relay on the old behaviour in some way
13:00:07 sfinucan Yeah, the changes to the metadata API are all additive (by design, from the looks of things)
13:00:16 sfinucan I don't personally think a spec is necessary for this but I'll leave that to others to decide
13:00:36 moreless_ I have some error in my nova log files, I think it is crediterncails problem but I am not sure if it is my username and password or authentication mechanism it says it is using "AMQPLAIN" is it how it should be?
13:00:48 alex_xu nova api meeting is running
13:01:26 frickler well, the third one isn't, it changes the type ipv6_dhcp so something else, but then nobody IMO can be using it in a reasonable way currently, else the change wouldn't be necessary
13:02:11 mriedem frickler: i'd probably ask clarkb, mordred, jroll and mgagne to take a look at the changes
13:02:31 mriedem mgagne was recently updating the nw metadata json in an old spec that introduced it, so i know he cares
13:03:06 mordred frickler: we definitey care - but we'd LOVE for it to be something sane
13:03:32 bhagyashris Hi all, Is there any way to clean up the database table records for eg. I am trying to clean up/remove instances table records (instances entries from instances table) but haven't found any ways, Can any one suggest me how I clean up the records from table?
13:03:40 mordred main thing will be ability to detect if the data has new form or old form
13:04:27 frickler mordred: well, the first two patches only add data, if you can live without it, your code just has to ignore it, that should be simple
13:05:02 mordred frickler: canyou point me at the patches?
13:05:21 frickler mordred: for the network type, currently it is always shown as ipv6_dhcp even when it is slaac instead, so you cannot use it for configuration at all
13:05:36 frickler mordred: https://review.openstack.org/#/c/450211/3 and the two on top of it
13:06:03 openstackgerrit dane-fichter proposed openstack/nova master: Remove backend dependency for key types https://review.openstack.org/456204
13:06:46 mordred frickler: awesome. yes - I think we'd very much like to see this change
13:06:53 openstackgerrit John Garbutt proposed openstack/nova master: Add description to policies in servers.py https://review.openstack.org/451966
13:07:13 mriedem bhagyashris: nova-manage db archive_deleted_rows
13:07:17 mordred frickler: you will prevent clarkb from continuing to complain that "ipv6_dhcp doesn't always mean ipv6 using dhcp" :)
13:07:30 mriedem bhagyashris: that moves 'deleted' instances into the shadow tables
13:07:40 mriedem so they aren't purged from the database, but they are out of the main query paths
13:07:47 mriedem bhagyashris: we don't have a real purge command yet
13:08:24 frickler mordred: yeah, that's the main issue, the others are just random bits I found when looking at the data I got while testing
13:15:42 sdague frickler: why did all the new keys pop up in the test here - https://review.openstack.org/#/c/450211/3/nova/tests/unit/network/test_network_info.py ?
13:15:47 sdague that's not obvious to me
13:17:15 frickler sdague: as I state in the commit message, the old behaviour is to omit all that information if the type is dhcp. I claim however, that people still may want static configuration on their host even when dhcp is enabled
13:17:50 frickler sdague: so the patch effectively adds all that information indeed
13:19:41 mordred frickler: amusingly enough - the first two patches make me almost want to change glean to just do static network config if the data is available instead of dhcp - just because I know in openstack land that the ip isn't actually going to _change_ - mainly to simplify the code paths - but my sysadmin background can't quite be on board with that fully for reasons I can't explain
13:19:45 openstackgerrit Andy McCrae proposed openstack/nova master: Allow CONTENT_LENGTH to be present but empty https://review.openstack.org/455710
13:21:05 mordred sdague: yah - I mean, the way we dhcp in openstack is just a mechanism to get a statically pre-defined ip to a host - but if we also put it in the config-drive then even though it's not how _I_ would have liked to have gotten there, it would wind up being a thing you could count on being available in every cloud regardless of operator deployment decisions
13:21:40 mordred and that's neat, whichever way it goes
13:22:07 frickler mordred: I would be sceptical on always doing that static config, yes. But we do have use cases for it, like an instance connected to two networks both presenting a default route. in order for floating IPs to work, one needs to configure the other interface without the default route
13:23:01 openstackgerrit OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/455960
13:23:08 mordred frickler: wow - that seems like a TERRIBLE scenario! :)
13:23:13 bhagyashris mriedem: ok, Thank you for info.
13:23:30 sdague frickler: is there any other concern about other consumers of this data?
13:24:10 mordred sdague: currently the field is meaningless, as it's always set to ipv6_dhcp no matter if that's what's happening or not - so other consumers cannot be making decisions based on it
13:24:37 sdague mordred: not this field, all the extra stuff going into the dhcp responses
13:24:44 mordred ah - gotcha
13:25:15 mordred that I can't say - I know it won't break glean - but I can't say if someone is doing some sort of strict schema based thing that might throw them if extra fields show up
13:25:32 mordred (I obviously think those folks are doing things wrong, but people do things wrong all the time)
13:26:01 sdague yeh, I'm more concerned that we've now got the 2 clocks problem where there is authoritative source, but we're back channeling it as well
13:26:17 sdague because it does seem like if the answer is use dhcp, then use it
13:26:33 sdague don't say use dhcp, and also here is all the info from dhcp in a different channel
13:31:37 lyarwood ildikov: are you working on the tests for jgriffith's cinderv3 detach change? https://review.openstack.org/#/c/438750/ ./me is losing track of who is working on this change.
13:33:53 frickler sdague: cloud-init should be fine looking at https://git.launchpad.net/cloud-init/tree/cloudinit/sources/helpers/openstack.py#n571 , but I agree we can be discussing that patch seperately from the others, so I'm going to do a bit of reshuffling
13:34:02 sdague frickler: ok, cool
13:34:25 sdague yeh, I want to get the type fixes in there, this is just a bigger issue about expanding the dhcp return
13:34:34 lyarwood mriedem: as the UCA devstack change looks like it *might* land is there any chance of another review of my QEMU LUKS spec ahead of the deadline tomorrow? https://review.openstack.org/#/c/437070
13:34:37 sdague so lets get those type fixes first, land them, we can discuss the other thing
13:34:47 mriedem lyarwood: i plan on going through specs today
13:35:18 lyarwood mriedem: cool thanks
13:36:06 mriedem lyarwood: to be clear, my main concerns in there were the api
13:36:14 sdague mriedem: speaking of which, do you have final concerns before I pull the trigger on merging the UCA patch and us running libvirt 2.5 by default in the gate?
13:37:33 lyarwood mriedem: right, I removed the additional encryption provider constant and just left it up to the local nova-compute to decide which approach to use based on the available QEMU and Libvirt versions.
13:37:39 ildikov lyarwood: both of us are looking at it, like who has more bandwidth

Earlier   Later