Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-28
16:41:14 mriedem they were also asking if nova-status could check for this,
16:41:20 mriedem which isn't unreasonable
16:41:28 dansmith if you will do the nova-status change I'll do the warning :D
16:41:33 mriedem ha
16:41:52 openstack Launchpad bug 1759316 in OpenStack Compute (nova) queens "pre-cells_v2 nova-osapi_compute service in database breaks instance lookup" [Medium,Confirmed]
16:41:52 mriedem i'm ok with nova-status, but need input on how the check is going to work, see 2nd paragraph in https://bugs.launchpad.net/nova/+bug/1759316/comments/1
16:42:53 openstackgerrit Ed Leafe proposed openstack/nova master: Address issues raised in adding member_of to GET /a-c https://review.openstack.org/554357
16:43:13 edleafe jaypipes-away: mriedem: ^^ Addressed the outstanding issues
16:43:17 dansmith you can just return "maybe a problem" with basically that text right? "I found an old entry in cell foo and it might be a problem or might not, but fyi"
16:43:37 mriedem dansmith: yeah that's what i was thinking, we have ok, warning and error for nova-status
16:43:39 mriedem so this would be a warning
16:43:43 mriedem since we aren't sure how you've configured the api
16:43:46 dansmith righ
16:44:14 mriedem alright i can work up a nova-status patch for that
16:44:19 mriedem or die trying
16:44:27 dansmith cool
16:44:32 melwitt lol, pls don't die
16:45:35 tssurya melwitt: https://review.openstack.org/#/c/557369/
16:45:44 tssurya Just informing
16:47:23 melwitt okay, cool. spec for handling a down cell, we can start reviewing that. and I can depend on it for my related quotas-from-placement-and-instance-mappings spec
16:47:31 melwitt thanks
16:49:28 tssurya dansmith: this is the re-rebase after the UUID shift revert, https://review.openstack.org/#/c/539501/ , whenever you have the time have a look
16:49:57 dansmith okay
16:51:02 mriedem bhagyashris: so i guess we don't send notifications for createBackup?
16:52:40 openstackgerrit Merged openstack/nova stable/queens: Add --by-service to discover_hosts https://review.openstack.org/554600
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....

Earlier   Later