Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-28
16:53:41 mriedem bhagyashris: replies in https://review.openstack.org/#/c/511825/
16:54:02 openstackgerrit Mathieu Gagné proposed openstack/nova-specs master: Multiple Fixed-IPs support in network information https://review.openstack.org/312626
16:58:43 melwitt mriedem, dansmith: on this spec ^ it's about changing 'ip_address' in the metadata API to 'ip_addresses' to include all available interfaces for the guest, in a new metadata API version. there was a related issue about changing the metadata API to to show IP addresses even if there is a DHCP server present (currently it does not). there was a question on the spec about whether those two issues should be combined in one spec and one
16:58:44 melwitt new metadata API version or if they should be separated into two specs and versions
16:59:21 melwitt I had been thinking they two things would be separate specs and metadata API versions, but more input would be helpful
16:59:35 dansmith metadata changes have to be purely additive,
16:59:43 dansmith and in the past we've only ever had one metadata version per release AFAIK
17:00:35 melwitt okay, I wasn't aware of that. so it would not be allowed to change ip_address -> ip_addresses, but instead the possibility would be to add ip_addresses
17:00:43 dansmith right
17:01:47 melwitt okay. and then on the "show IP addresses even if DHCP server is present", is that type of change never allowed then? or maybe it would be because that is technically additive. that is, the behavior in the past would be "didn't show IP addresses if DHCP server" and it changes to "shows IP addresses if DHCP server"
17:02:19 melwitt (the use case there is, there is a DHCP server present but it's not being leveraged and IPs were statically configured)
17:02:33 melwitt currently, the presence of the DHCP server makes the API hide the static IP addresses
17:02:53 dansmith it's hard to say.. does cloud-init use the presence of that (or absence) to decide if it should try dhcp?
17:03:08 dansmith any custom-rolled cloud-init-like thing could though, so..
17:03:15 dansmith it's less additive really
17:03:17 melwitt that, I don't know
17:04:23 dansmith but dan-init could have,
17:04:29 dansmith which means it's probably not a great change
17:04:43 melwitt yeah. I see
17:05:59 melwitt there is some discussion about breaking compat on the spec, so now I understand in the metadata API we can never break compat. I had been thinking it would be like microversions
17:06:21 melwitt mgagne ^
17:06:39 dansmith yeah, not microversions
17:07:02 mgagne melwitt: I was under the impression that there is already a versioning system in place based on release date
17:07:20 melwitt mgagne: there is, but apparently it can only be additive and cannot break backward compat
17:07:27 melwitt I didn't know this before
17:07:41 mgagne melwitt: that's news to me too :O
17:07:42 dansmith there isn't
17:07:50 dansmith the date thing is just because that's how EC2 metadata is used,
17:07:54 dansmith but we don't really do it right
17:08:18 dansmith so it's once per release, and additive because we don't really generate the backward-looking versions properly
17:08:21 melwitt okay. I mistook the release date version to be microversion-like
17:09:12 dansmith melwitt: look at the comment above the version definitions
17:09:31 melwitt mgagne: so we can add 'ip_addresses' but have to also keep 'ip_address' there. and we can't change the behavior of the DHCP server + IP address show/not show
17:09:33 dansmith that doesn't fully explain the details I guess, but you can kinda see the "meh, this is .. meh"
17:10:17 mriedem we've had more than one version in a release i think,
17:10:32 mriedem and the $release version alias had to point at the newer one i think
17:10:50 mgagne NEWTON_TWO = '2016-10-06'
17:10:50 mgagne NEWTON_ONE = '2016-06-30'
17:10:58 mriedem right
17:11:24 mgagne but can't find comment about backward compatibility
17:12:30 mriedem mgagne: probably unwritten,
17:12:33 dansmith mriedem: that was because we had some problem.. it was an exception but I don't recall the details
17:12:36 mriedem but b/c it doesn't have microversions, that's about the only option
17:13:24 melwitt yeah, I'm guessing cloud-init and friends don't do anything to specify a version, so if you upgrade metadata API and compat is broken, everything breaks if you haven't grabbed the latest cloud-init that can handle it
17:13:52 mriedem if you don't specify a version,
17:13:53 mgagne what's microversion? a number you can increase to indicate a change? it's already done with date, just a different format. other than a different philosophical pov, I don't see the difference.
17:14:00 mriedem i believe you get a versioned dict back
17:14:13 mriedem or maybe that's just config drive
17:14:31 mriedem having said all this, mikal should probably be roped in
17:14:44 mriedem he's an old school metadata API guy
17:14:52 mgagne oh, I'm not familiar with metadata api at all, I only consume configdrive which does have all date/version in there
17:14:54 melwitt yeah, I was about to say, we need a mikal
17:16:04 dansmith I don't think we do
17:16:09 dansmith I mean, we need him in the cosmic sense
17:16:16 dansmith but we need to be additive here
17:17:41 mgagne ok, I don't mind update spec
17:18:07 mgagne but this needs to be documented somewhere because I thought for years that you could break compat
17:18:55 melwitt agreed, we should add explanation of that under the existing comment above the version list, at least
17:19:06 mgagne and cloud-init consumes configdrive by date: https://github.com/cloud-init/cloud-init/blob/master/cloudinit/sources/helpers/openstack.py
17:19:53 melwitt I'd appreciate a sanity check from mikal since those comments about the versioning are from him
17:22:36 dansmith mgagne: it also has a latest, which we honor and use the latest field
17:22:48 openstackgerrit Merged openstack/nova stable/queens: Fix and update compute schedulers config guide https://review.openstack.org/548873
17:23:37 mgagne dansmith: yes and IMO, it's like using master from git, if you want stability/predictability, don't use it.
17:30:08 melwitt lyarwood, dansmith: may I get reviews on this stable backport pls https://review.openstack.org/#/c/550498 for saving admin password to sysmeta
17:31:27 melwitt er sorry, didn't realize queens backport didn't merge yet. dansmith https://review.openstack.org/#/c/550489 instead
17:33:01 lyarwood melwitt: np, noted in the review for now
17:33:12 melwitt lyarwood: perfect thanks
17:45:23 openstackgerrit Eric Fried proposed openstack/nova master: Use ksa adapter for cinder client https://review.openstack.org/508345
17:45:32 efried mriedem: Let's see how that shakes out ^
17:47:08 openstackgerrit Merged openstack/nova stable/queens: libvirt: mask InjectionInfo.admin_pass https://review.openstack.org/548289
17:51:36 openstack bug 1752152 in OpenStack Compute (nova) "Attach Volume Fails with secure call to cinder" [Undecided,In progress] https://launchpad.net/bugs/1752152 - Assigned to Eric Fried (efried)
17:51:36 mriedem efried: hmm, we do need a backportable fix for bug 1752152 though
17:51:53 mriedem i also don't understand why our CI jobs don't fail with that bug
17:52:40 efried mriedem: The problem with backportability is that I can't use the _SESSION if I... don't have a _SESSION.
17:53:28 efried mriedem: It's a chicken/egg: I would have to use the CinderClient to make the request, cause that guy handles https already. But the microversion check is *before* the CinderClient is created. Soooo....
17:53:59 efried mriedem: Are you sure the CIs are using https? If it were me, I would have switched that off first thing to make things easier.
17:54:09 mriedem i thought there was a backportable way to fix this when i was posting stuff in the bug report before, but that's exited my brain so would have to look at all of this again, but in the middle of something
17:54:36 mriedem pretty sure yes
17:54:37 mriedem http://logs.openstack.org/45/508345/13/check/nova-next/aa61d86/logs/screen-c-api.txt.gz#_Mar_15_20_00_06_201395
17:54:38 efried mriedem: The backportable way would have been to s/https/http/ for the version discovery.
17:54:45 efried which is not a good solution.
17:55:35 efried mriedem: I'm not well versed on ssl etc, but isn't there a way to use https without a cert file?
17:55:50 mriedem don't konw
17:56:03 dansmith efried: no
17:56:20 mriedem another thing i mentioned as a hack workaround for backports, is use the internal cinderclient.Client.session
17:56:23 mriedem to get the version doc
17:56:30 mriedem then we replace all of that with the KSA thing in master
17:56:49 mriedem then it's just a session.get()
17:57:15 efried cinderclient.Client.session doesn't exist until we've created the client though, does it?
17:57:50 efried that's the chicken/egg
18:03:14 efried mriedem: (I know you're busy, but when you're available...) Any reason not to move the microversion check to after the client construction?
18:03:25 mriedem i think that was my idea from the bug report
18:03:31 mriedem "The alternative is on the nova side, we just construct a cinderclient Client object and use it's internal client (session) to make a request, or use a keystoneauth1 adapter to make the request."
18:05:07 efried okey, I'll see if I can work that up.
18:29:30 openstackgerrit Dan Smith proposed openstack/nova master: Make get_allocation_candidates() honor aggregate restrictions https://review.openstack.org/547990
18:29:30 openstackgerrit Dan Smith proposed openstack/nova master: Add aggregates list to Destination object https://review.openstack.org/544729
18:29:31 openstackgerrit Dan Smith proposed openstack/nova master: Add AggregateList.get_by_metadata() query method https://review.openstack.org/544728
18:29:31 openstackgerrit Dan Smith proposed openstack/nova master: Add an index on aggregate_metadata.value https://review.openstack.org/555851
18:29:32 openstackgerrit Dan Smith proposed openstack/nova master: Add require_tenant_aggregate request filter https://review.openstack.org/545002
18:29:33 openstackgerrit Dan Smith proposed openstack/nova master: WIP: Honor availability_zone hint via placement https://review.openstack.org/546282

Earlier   Later