| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-12 | |||
| 11:00:51 | openstackgerrit | Ildiko Vancsa proposed openstack/nova master: Remove check_detach https://review.openstack.org/446671 | |
| 11:26:31 | openstackgerrit | Ildiko Vancsa proposed openstack/nova master: Add Cinder V3 Detach calls https://review.openstack.org/438750 | |
| 11:28:20 | openstackgerrit | Andrey Volkov proposed openstack/nova master: [WIP] [placement] Add api-ref resource provider https://review.openstack.org/456176 | |
| 11:49:14 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/455960 | |
| 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 DELETE RP inventory https://review.openstack.org/455215 | |
| 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: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 | |