| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-26 | |||
| 16:17:43 | dansmith | oh you mean it just reports error instead of your proposed warning? | |
| 16:17:50 | mriedem | https://github.com/openstack/nova/blob/master/nova/cmd/status.py#L230 | |
| 16:17:52 | mriedem | yes | |
| 16:18:15 | mriedem | there is the guantlet of ksa exceptions, | |
| 16:18:22 | mriedem | so without testing it in devstack i'm not exactly sure | |
| 16:18:23 | dansmith | okay | |
| 16:18:45 | dansmith | well, if it just reports error that's reasonable enough I think | |
| 16:19:22 | mriedem | that likely means any tooling running it during an FFU should ignore the results, which makes me wonder why even run it during FFU | |
| 16:19:57 | mriedem | but yeah, i just don't have the energy to figure out what our official process/stance is for upgrade checkers during FFU :) | |
| 16:20:03 | mriedem | especially that now it's a community wide goal | |
| 16:20:11 | mriedem | and FFU is still very nebulous to me | |
| 16:20:26 | dansmith | well, | |
| 16:20:37 | dansmith | the checking of things that have to be done before moving on is pretty critical to FFU | |
| 16:21:00 | mriedem | my most basic understanding is take all control plane services down, and roll through each release running data migrations and schema migrations | |
| 16:21:06 | dansmith | I think everyone right now is just doing it very manually, including the deployment projects | |
| 16:21:45 | dansmith | lyarwood might be a good person to ask about this | |
| 16:22:30 | dansmith | lyarwood: mschuppert: the question is why tripleo doesn't run nova-status during any upgrade, including ffu, even if just to collect/log the status | |
| 16:23:26 | dansmith | and/or I guess: if/do tripleo people use it whilst trying to get a particular N->M transition working, and then just not run it programmatically for everyone, assuming they have the steps perfected? | |
| 16:23:39 | lyarwood | dansmith / mriedem ; no reason, I did push an example up for the upgrades team a while ago and asked them to take it forward but I assume they just didn't follow up | |
| 16:24:17 | lyarwood | this came up again at PTG, didn't we create tripleo bugs to track this during S? | |
| 16:24:58 | openstack | Launchpad bug 1777060 in tripleo "nova-status should be used during deployment and upgrades" [High,New] - Assigned to Lee Yarwood (lyarwood) | |
| 16:24:58 | lyarwood | https://bugs.launchpad.net/tripleo/+bug/1777060 | |
| 16:25:34 | dansmith | cool | |
| 16:28:07 | mriedem | until we actually have any kind of FFU ci testing it's also hard for me to care a ton about stuff like this | |
| 16:28:22 | mriedem | i mean, i don't want to lose sleep over it | |
| 16:28:30 | mriedem | when i have so many other things i can lose sleep over | |
| 16:29:54 | dansmith | we could easily just run it during grenade before we bring things back up and log the output right? | |
| 16:30:23 | mriedem | we do run nova-status upgrade check during grenade | |
| 16:30:36 | dansmith | but not when *everything* is down right? | |
| 16:30:39 | dansmith | only during nova-upgrade? | |
| 16:30:56 | mriedem | http://git.openstack.org/cgit/openstack-dev/grenade/tree/projects/60_nova/upgrade.sh#n88 | |
| 16:31:02 | dansmith | right, | |
| 16:31:05 | mriedem | we specifically bring placement up before running the check | |
| 16:31:11 | dansmith | right | |
| 16:31:19 | dansmith | and other projects before us would be up (i.e. keystone) | |
| 16:31:42 | mriedem | yeah i mean i could run it before starting placement | |
| 16:31:43 | mriedem | and see it fail | |
| 16:31:49 | dansmith | actually verify preupgrade might run with nothing | |
| 16:32:01 | dansmith | sorry verify_noapi preupgrade | |
| 16:33:41 | dansmith | https://review.openstack.org/620104 | |
| 16:34:00 | dansmith | mriedem: anyway, don't lose sleep over it, I'll check in on that later to see how it goes | |
| 16:34:11 | mriedem | ack thanks | |
| 16:45:14 | openstackgerrit | Adam Spiers proposed openstack/nova-specs master: Add spec for libvirt driver launching AMD SEV-encrypted instances https://review.openstack.org/609779 | |
| 16:59:53 | mriedem | i guess we never documented anywhere officially that we only support n-1 computes.. | |
| 16:59:57 | mriedem | even though it comes up every so often | |
| 17:00:55 | sean-k-mooney | compute older then n-1 may work in some cases however we just dont test them | |
| 17:01:45 | mriedem | yes i know that. | |
| 17:01:59 | mriedem | what i'm asking is, didn't we ever document this because the last time it came up, i thought we said someone would document it. | |
| 17:02:04 | mriedem | which is i guess why it didn't get done. | |
| 17:03:39 | mriedem | https://docs.openstack.org/nova/rocky/contributor/project-scope.html?highlight=compatibility#upgrade-expectations is about as close as it gets | |
| 17:03:48 | mriedem | fuck i hate that banner | |
| 17:04:00 | sean-k-mooney | we dont state i t explictily in https://docs.openstack.org/nova/rocky/user/upgrade.html#rolling-upgrade-process but we do mention n to n+1 a few times | |
| 17:04:13 | cdent | oh yeah that banner doth suck | |
| 17:04:15 | sean-k-mooney | e.g. in relation to db changes | |
| 17:04:21 | cdent | "someone" has a lot of work on their place | |
| 17:04:41 | mriedem | https://docs.openstack.org/nova/rocky/contributor/process.html?highlight=compatibility#smooth-upgrades | |
| 17:05:51 | sean-k-mooney | mriedem: ok so we do say we only support "only support upgrades between N and N+1 major versions, to reduce technical debt relating to upgrades" | |
| 17:06:04 | mriedem | yes, that's good enough for me | |
| 17:06:24 | mriedem | the question in -dev and the ML is if that also applies to inter-service compat | |
| 17:06:27 | mriedem | e.g. nova and cinder | |
| 17:06:30 | mriedem | and i don't think it should | |
| 17:06:37 | mriedem | b/c we have versioned REST APIs | |
| 17:07:06 | sean-k-mooney | mriedem: right if the rest apis are versioned coorectly it should not | |
| 17:07:35 | mriedem | which means you shouldn't have to take down your entire cloud to upgrade nova | |
| 17:07:44 | mriedem | i.e. you can leave cinder n-2 and upgrade nova and it should work | |
| 17:07:51 | mriedem | we don't test it, but it should work | |
| 17:08:04 | mriedem | unless otherwise noted as we've dropped some compat | |
| 17:08:15 | sean-k-mooney | yes you should be able to do a service wise rolling upgrade | |
| 17:08:31 | sean-k-mooney | and you should be able to skip upgrade some services if you dont need too | |
| 17:09:51 | sean-k-mooney | i generally parsed the version n contolplane with n-1 agents compatiablity to only applcy within a singel service | |
| 17:11:48 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: [stable-only] Add report_ironic_standard_resource_class_inventory option https://review.openstack.org/620111 | |
| 17:13:06 | mriedem | smcginnis: cdent: regarding that question about nova requiring cinder >= rocky, i'll likely drop the API compat we have for cinder < rocky (really queens b/c nova-api checks for cinder 3.44 which was added in queens), with a release note and potentially an upgrade check to look at the service catalog and make sure cinder >= 3.44 is available | |
| 17:14:53 | smcginnis | mriedem: Queens should be a good point. I would think from there we can probably clean up a lot of code. | |
| 17:15:51 | mriedem | still need my patches to migrate old bdm attachments, as discussed in berlin, | |
| 17:16:03 | mriedem | or do someone online when the attachments are used, but i haven't put brain power into that | |
| 17:16:35 | mriedem | definitely need https://review.openstack.org/#/c/541420/ for bfv though | |
| 17:31:04 | KeithMnemonic | mriedem is there a chance to get some cores to review your patch https://review.openstack.org/#/c/614872/1 ? | |
| 17:31:08 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: [stable-only] Add report_ironic_standard_resource_class_inventory option https://review.openstack.org/620113 | |
| 17:32:19 | mriedem | KeithMnemonic: queens needs to go first https://review.openstack.org/#/c/614868/ | |
| 17:32:27 | mriedem | but yeah dansmith lyarwood https://review.openstack.org/#/q/I98a2785c07f7af02ad83650c72d9e1868290ece4 | |
| 17:32:31 | mriedem | easy backports | |
| 17:33:57 | KeithMnemonic | thanks! | |
| 17:34:13 | mriedem | yw | |
| 17:34:18 | mriedem | thanks for the reminder | |
| 17:35:12 | sean-k-mooney | anyone know a better tool to search irc logs then googles site search | |
| 17:35:39 | cdent | edleafe made a thing, but I don't know if he made it live | |
| 17:36:29 | edleafe | sean-k-mooney: It's still rough, but you can try https://ircsearch.leafe.com | |
| 17:37:30 | sean-k-mooney | edleafe: does that use a local copy of the logs or does it search easedrop.openstack.org | |
| 17:38:00 | edleafe | sean-k-mooney: it uses its own elasticsearch database | |
| 17:39:25 | openstackgerrit | Adrian Chiris proposed openstack/nova master: add get_pci_request_from_vif to request.py https://review.openstack.org/609166 | |
| 17:39:26 | openstackgerrit | Adrian Chiris proposed openstack/nova master: Add get_instance_pci_request_from_vif https://review.openstack.org/619929 | |
| 17:39:26 | openstackgerrit | Adrian Chiris proposed openstack/nova master: Allow per-port modification of vnic_type and profile https://review.openstack.org/607365 | |
| 17:39:27 | openstackgerrit | Adrian Chiris proposed openstack/nova master: SR-IOV Live migration indirect port support https://review.openstack.org/620115 | |
| 17:44:49 | mriedem | use_cow_images=true and force_raw_images=true (defaults) is always confusing | |
| 17:46:03 | sean-k-mooney | edleafe: thanks i found the message from bauzas i was looking for but looks like he did not past the placmetend output publicaly https://ircsearch.leafe.com/timeline-middle/%23openstack-nova/2018-10-03T17:18:56 | |
| 17:46:24 | adrianc | sean-k-mooney: Hi, added you to the above commits. ive also commented on the related spec: https://review.openstack.org/#/c/605116/ | |
| 17:47:51 | sean-k-mooney | adrianc: hi i was looking at the previous version earlier today. im planning to spend tomorrow testing what you have pushed so far | |
| 17:47:59 | sean-k-mooney | adrianc: is it in a functional state | |
| 17:48:27 | edleafe | sean-k-mooney: glad it was useful for you. I wrote it because I was annoyed that I couldn't find info from a conversation | |
| 17:49:28 | sean-k-mooney | edleafe: ya i spent 20 mins looking of it with googles site: feature and did not find it | |