| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-28 | |||
| 16:31:28 | dansmith | sounds like we do | |
| 16:31:40 | melwitt | yeah, if we have topics, we can meet | |
| 16:32:12 | mriedem | unless we just want to skip and talk about the specific bug here | |
| 16:32:40 | melwitt | either way wfm | |
| 16:33:42 | dansmith | I'm good to skip if it's just one bug | |
| 16:33:45 | dansmith | I got nothing else | |
| 16:37:04 | mriedem | wait to see what tssurya says, she's the busy one | |
| 16:37:57 | tssurya | I am good to skip too | |
| 16:38:02 | mriedem | hot dog | |
| 16:38:19 | openstack | Launchpad bug 1759316 in OpenStack Compute (nova) queens "pre-cells_v2 nova-osapi_compute service in database breaks instance lookup" [Medium,Confirmed] | |
| 16:38:19 | mriedem | ok so just wanted to talk about options for https://bugs.launchpad.net/nova/+bug/1759316 | |
| 16:38:39 | mriedem | basically an upgrade issue for someone that was hard to figure out since there are no logs | |
| 16:38:39 | dansmith | okay | |
| 16:38:48 | mriedem | upgrading newton->ocata | |
| 16:39:16 | mriedem | at this point, if you're not using cells v1 and you get here, https://github.com/openstack/nova/blob/ed55dcad83d5db2fa7e43fc3d5465df1550b554c/nova/compute/api.py#L2269 - i think we should log a warning | |
| 16:39:25 | mriedem | ^ was added in newton | |
| 16:39:33 | mriedem | so if you're hitting that in ocata+ it likely means you're going to have issues | |
| 16:39:34 | dansmith | so, I thought we removed some of this recently | |
| 16:39:37 | dansmith | when I did the instance list bit | |
| 16:40:00 | mriedem | i've had some patches to try and remove some things from the cells v2 transition but they are in limbo, | |
| 16:40:21 | mriedem | there was also a thing i tried removing from the local delete flow and was hitting weird errors, but i forget the details | |
| 16:40:43 | dansmith | but on ocata we can't eliminate that check just yet | |
| 16:40:53 | dansmith | so yeah, you want to warn if we take that path and we're not on cellsv1 right? | |
| 16:40:57 | mriedem | i'm not saying remove it, | |
| 16:40:59 | mriedem | yes | |
| 16:41:02 | mriedem | warn and backport that warning | |
| 16:41:03 | dansmith | yeah I think that makes sense | |
| 16:41:04 | melwitt | yeah, warning makes sense | |
| 16:41:06 | mriedem | ok | |
| 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. | |