| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-01-24 | |||
| 13:56:44 | sean-k-mooney | which we shoudl clean up eventually | |
| 13:58:40 | gibi | yepp | |
| 14:57:52 | opendevreview | Dan Smith proposed openstack/nova master: Add service version check workaround for FFU https://review.opendev.org/c/openstack/nova/+/826097 | |
| 14:57:59 | Guest295 | sean-k-mooney: gibi ^ | |
| 14:58:18 | gibi | dansmith: ack , will check | |
| 14:58:43 | dansmith | gibi: I assume you saw that thread on the ML | |
| 14:58:51 | gibi | yes | |
| 14:58:54 | dansmith | gibi: I've been working on an FFU grenade lately and poked that pretty easy :/ | |
| 14:59:08 | gibi | and we talked it through with sean-k-mooney last week | |
| 14:59:31 | gibi | I'm not against the WA flag | |
| 14:59:47 | gibi | as it is disabled by default | |
| 15:00:06 | dansmith | I think it sucks to need it, especially to set it for an upgrade, but I think it's probably the most straightforward mitigation at the moment | |
| 15:01:10 | gibi | yeah. I'm +2 on it, it is simple | |
| 15:01:17 | sean-k-mooney | i would proably have gone with "compute_service_check_is_fatal" to align with teh vif_plug checks but ya as a temp fix i think its the simplest thing to do | |
| 15:02:06 | sean-k-mooney | i can take a looks at it in a few just finishing up something | |
| 15:02:06 | dansmith | sean-k-mooney: workarounds were all supposed to be boolean, =False by default and opt-in to some alternate behavior | |
| 15:02:17 | dansmith | so that they should all be "off" in normal operation | |
| 15:02:28 | dansmith | we've deviated from that quite a bit unfortunately, but I hold the flame :) | |
| 15:02:48 | sean-k-mooney | ya i agree it should be off by default | |
| 15:03:05 | sean-k-mooney | and is_fatal woudl be one by default so what you suggested is more correct | |
| 15:03:13 | sean-k-mooney | i was orginially thinking this would not be a workaround | |
| 15:03:42 | sean-k-mooney | i guess my main question is do we know what we want to replace it with long term | |
| 15:03:47 | dansmith | we probably need to figure out how to fix this without a workaround, as noted, but this is a simple backport to get people out of the box | |
| 15:03:49 | dansmith | yeah, I dunno | |
| 15:04:01 | sean-k-mooney | you made a good point that looking at "up" is potentially racy | |
| 15:05:14 | dansmith | yeah | |
| 15:05:56 | sean-k-mooney | so for your grenade job i assuem you are just going to set this to true | |
| 15:06:14 | sean-k-mooney | we need to backport this to wallaby before that job can merge howere right | |
| 15:06:21 | sean-k-mooney | since it need to be set pre upgrade | |
| 15:06:36 | sean-k-mooney | or i guess xena not wallaby | |
| 15:06:57 | dansmith | sean-k-mooney: no we only need it on the target | |
| 15:07:01 | dansmith | but we need to backport it for people | |
| 15:07:19 | sean-k-mooney | well we only need it on the target but we are not ment to requrie config updates on upgrade | |
| 15:07:33 | sean-k-mooney | so to have both be true we should have the config option avaiable in the source version right | |
| 15:07:43 | sean-k-mooney | so just another reason to backport | |
| 15:08:40 | sean-k-mooney | actully so i guess design question for FFU are we going to assume the "no config updates are requried" part still hold true | |
| 15:08:46 | sean-k-mooney | or is that just for n to n+1 | |
| 15:09:04 | dansmith | well, this is really a FFU-specific config option, so it's appropriate for grenade until it's fixed, IMHO | |
| 15:09:14 | dansmith | running (base) with this enabled would be wrong and not like production | |
| 15:09:42 | sean-k-mooney | ack ok i can buy that. | |
| 15:09:43 | dansmith | no config updates from n-2 to n is a different thing, and I don't think we need to stick to that, no | |
| 15:09:51 | dansmith | however, this is an upgrade bug/quirk mitigation | |
| 15:29:56 | opendevreview | Lee Yarwood proposed openstack/nova master: WIP libvirt: Register defaults for undefined hw image properties https://review.opendev.org/c/openstack/nova/+/800708 | |
| 15:29:57 | opendevreview | Lee Yarwood proposed openstack/nova master: WIP manage: Add image_property commands https://review.opendev.org/c/openstack/nova/+/824392 | |
| 15:30:14 | sean-k-mooney | dansmith: https://review.opendev.org/c/openstack/nova/+/826097/1/nova/service.py#265 do you want this to work for just the conductor/schduler or also the api | |
| 15:30:55 | dansmith | sean-k-mooney: conductor is the important one, because it's how computes update their record.. does the api check separately? | |
| 15:31:02 | sean-k-mooney | yes | |
| 15:31:10 | sean-k-mooney | https://github.com/openstack/nova/blob/909cfc76369b94b026cf42b86fb5a310dce21a8c/nova/api/openstack/wsgi_app.py#L50 | |
| 15:31:34 | dansmith | ah, for wsgi yeah | |
| 15:31:45 | sean-k-mooney | when i was check rpc compatiabliy for train-> wallaby i had to commet out both | |
| 15:31:59 | dansmith | yeah I'll update | |
| 15:32:13 | dansmith | I imagine systemd is restarting api enough that it wasn't a problem for me in my grenade | |
| 15:32:27 | dansmith | I'm running a job on top of that now, but I will update when it's done | |
| 15:32:39 | dansmith | thanks for catching | |
| 15:36:44 | sean-k-mooney | no worries ping me when its up and ill rereview. | |
| 15:54:15 | opendevreview | Dan Smith proposed openstack/nova master: Add service version check workaround for FFU https://review.opendev.org/c/openstack/nova/+/826097 | |
| 16:01:11 | opendevreview | Balazs Gibizer proposed openstack/placement master: Extend the RP tree DB query to support any-traits https://review.opendev.org/c/openstack/placement/+/825849 | |
| 16:06:10 | opendevreview | Balazs Gibizer proposed openstack/placement master: Extend the RP tree DB query to support any-traits https://review.opendev.org/c/openstack/placement/+/825849 | |
| 16:52:19 | dansmith | huzzah https://review.opendev.org/c/openstack/grenade/+/826101 | |
| 16:55:36 | sean-k-mooney | nice | |
| 17:33:30 | artom | Wow | |
| 17:33:50 | artom | Also, I will never not think of https://knowyourmeme.com/memes/rage-guy-fffffuuuuuuuu | |
| 17:48:51 | opendevreview | sean mooney proposed openstack/nova master: [WIP] add initial healthcheck support https://review.opendev.org/c/openstack/nova/+/825015 | |
| 18:22:37 | ade_lee__ | gmann, sean-k-mooney trying to decide how to handle issue in https://review.opendev.org/c/openstack/tempest/+/810808 | |
| 18:23:28 | ade_lee__ | gmann, sean-k-mooney it sounds to me like we're never going to fix the plain encryptor provider . | |
| 18:27:34 | gmann | ade_lee__: I am very unclear on how many tests we are going to skip or fix for FIPs mode. so my suggestion is to exclude the tests run using --exclude-regex/--exclude-list instead of permanently marking those tests as skip in code. | |
| 18:28:07 | gmann | that is how we do for ceph case, 'xyz list of tests does not work for ceph backend so just do not run' | |
| 18:29:23 | ade_lee__ | ok | |
| 18:41:59 | sean-k-mooney | gmann: the regex approch makes sense to me | |
| 18:42:35 | sean-k-mooney | proably using the exclude regex in this case to skip non fips complent tests | |
| 18:42:35 | gmann | cool | |
| 18:42:42 | gmann | yeah | |
| 18:42:45 | sean-k-mooney | the disadvantage to that is running locally | |
| 18:42:53 | sean-k-mooney | so can we do it with a tox env | |
| 18:42:58 | sean-k-mooney | rather then in the job | |
| 18:43:07 | sean-k-mooney | so you can repoduce locally too | |
| 18:43:42 | sean-k-mooney | e.g. like https://github.com/openstack/tempest/blob/master/tox.ini#L151-L162 | |
| 18:44:20 | sean-k-mooney | we can define an integrated-fips target | |
| 18:45:39 | gmann | yeah, we can do that. | |
| 18:46:45 | sean-k-mooney | ade_lee__: does ^ work for you | |
| 18:48:13 | ade_lee__ | gmann, sean-k-mooney we can do that. | |
| 18:48:58 | sean-k-mooney | i think from a downstream pserspcitive that wil make things simpler since we wont have to translate the regex into a jenkins jobs it will just invoke the fips target and get teh same set of test as upstream | |
| 18:49:22 | gmann | ade_lee__: cool, so let's add that in follow up patch after paramiko one which has already +2 and under zuul result. | |
| 18:49:23 | sean-k-mooney | with that said i have not looked at what our downstream jobs will look like | |
| 18:50:04 | ade_lee__ | gmann, sean-k-mooney I suspect for nova though the test suite might pass without the skip, given that the test did not have the fips flag set | |
| 18:50:52 | ade_lee__ | so this may be moot for right now for the nova fips test -- it shows up for sure in the cinder tests though | |
| 18:51:10 | sean-k-mooney | i dont really see how this would be project specific | |
| 18:51:32 | sean-k-mooney | we are both using the the same integrated-fips jobs no? | |
| 18:51:43 | ade_lee__ | sean-k-mooney, its more a matter of which tests run in which test jobs .. | |
| 18:52:13 | sean-k-mooney | well my point is the latest version fo the nova patch uses a common job | |
| 18:52:26 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/790519/20/.zuul.yaml | |
| 18:52:27 | gmann | yeah it run all the tests | |
| 18:52:30 | sean-k-mooney | its not nova specific | |
| 18:53:22 | ade_lee__ | sean-k-mooney, gmann where the fips flag was shown to be needed was here -- https://review.opendev.org/c/openstack/cinder/+/790535/24/.zuul.yaml#134 | |
| 18:53:52 | ade_lee__ | one or more of those in any case .. | |
| 18:54:11 | sean-k-mooney | that because fo ceph? | |
| 18:54:27 | sean-k-mooney | where is the common job currently defiend | |
| 18:54:28 | ade_lee__ | tempest-integrated-storage-fips I think .. | |
| 18:55:06 | gmann | this one https://github.com/openstack/tempest/blob/master/zuul.d/integrated-gate.yaml#L301 | |
| 18:55:25 | sean-k-mooney | here https://github.com/openstack/tempest/blob/master/zuul.d/integrated-gate.yaml#L300-L314 | |