| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-12 | |||
| 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 | |
| 13:38:36 | ildikov | lyarwood: I checked on the patch and fixed the nits, we might move some parts to follow up one if we cannot decide on it quickly | |
| 13:38:38 | lyarwood | ildikov: no problem, if you don't have time just let me know and I can take a look ahead of the meeting tomorrow. | |
| 13:39:55 | ildikov | lyarwood: sure, Tnx | |
| 13:43:00 | openstackgerrit | Gábor Antal proposed openstack/nova master: Transform instance.live_migration_rollback notification https://review.openstack.org/402124 | |
| 13:43:39 | mriedem | sdague: i don't | |
| 13:43:42 | mriedem | i thought it was already done | |
| 13:59:25 | sdague | no, but I just pressed approve | |
| 13:59:28 | sdague | so soon | |
| 14:00:34 | frickler | mriedem: johnthetubaguy: btw. I think https://review.openstack.org/356335 should have had a reno as well. I spent some time searching to find out why our Newton cluster doesn't create libvirt.xml anymore after an update. | |
| 14:00:59 | openstackgerrit | Jens Rosenboom proposed openstack/nova master: Update network metadata type field for IPv6 https://review.openstack.org/450297 | |
| 14:01:05 | mriedem | frickler: i'm assuming that was an unintended side effect | |
| 14:01:15 | mriedem | frickler: we should definitely reno now though | |
| 14:01:18 | mriedem | for anyone upgrading | |
| 14:01:41 | mriedem | frickler: i see it was also backported to newton https://review.openstack.org/#/c/386676/ | |
| 14:01:47 | mriedem | frickler: would you like to work on a reno? | |
| 14:02:24 | frickler | mriedem: sure, I can do that. I assume it would be added to master and then backported? | |
| 14:02:59 | johnthetubaguy | frickler: +1 good call out | |
| 14:03:17 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Read Neutron port 'binding_profile' during boot https://review.openstack.org/449257 | |
| 14:03:45 | frickler | sdague: clarkb: mordred: so https://review.openstack.org/450297 is now just a single patch fixing the ipv6_dhcp type issue | |
| 14:05:18 | sdague | frickler: +2 | |
| 14:05:39 | frickler | btw. can anyone give that EMC ScaleIO CI a kick? | |
| 14:06:22 | sdague | the fact that it emails everyone about patches all the time | |
| 14:07:40 | openstackgerrit | Dan Smith proposed openstack/nova master: Fix hypervisors api missing HostMappingNotFound handlers https://review.openstack.org/456227 | |
| 14:08:00 | frickler | sdague: it seems to do multiple NOT_REGISTERED votes per patch for some time now, yes | |
| 14:08:30 | openstackgerrit | Sylvain Bauza proposed openstack/nova-specs master: Placement doing claims https://review.openstack.org/437424 | |
| 14:08:39 | mriedem | frickler: yeah | |
| 14:08:57 | openstackgerrit | Gábor Antal proposed openstack/nova master: Transform instance.live_migration_rollback notification https://review.openstack.org/402124 | |
| 14:09:07 | mriedem | emc scaleio is xyang1's team i think | |
| 14:09:38 | sdague | frickler: yeh, it's just massively misconfigured I think | |
| 14:09:44 | mriedem | well, | |
| 14:09:45 | xyang1 | mriedem: hi | |
| 14:09:51 | mriedem | it also relies on something that isn't merged yet | |
| 14:10:06 | mriedem | xyang1: can we get the emc scaleio ci in nova just restricted to the one patch that it cares about? | |
| 14:10:17 | mriedem | this one https://review.openstack.org/#/c/407440/ | |
| 14:10:24 | mriedem | xyang1: it shows up as NOT_REGISTERED for all nova patches | |
| 14:11:08 | xyang1 | mriedem: oh, the nova CI. I think our CI team is still working on it. It is not working properly yet | |
| 14:11:31 | xyang1 | mriedem: I'll ask them to turn it off for now | |
| 14:11:36 | mriedem | ok, but it really won't work on anything except https://review.openstack.org/#/c/407440/ yet, | |
| 14:11:42 | mriedem | and probably not even that given the state it is in | |
| 14:11:46 | mriedem | xyang1: great thanks | |
| 14:11:52 | sdague | xyang1: they should also configure it to not email | |