| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-22 | |||
| 12:58:03 | aarents | so maybe workaround processutils.execute(*curl) can be the solution to check | |
| 12:58:08 | aarents | my | |
| 12:58:14 | bauzas | aarents: that's not the glance upload issue | |
| 12:58:28 | bauzas | aarents: IMHO the problem is with the semaphore we wanna take | |
| 12:58:30 | bauzas | hence the D | |
| 12:59:38 | bauzas | the problem with reviewing this code is that nobody documented which cases raise those exceptions we catch https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2358-L2359 | |
| 13:00:10 | bauzas | aarents: because we only fall back into this semaphore lock if you are not able to do the other way | |
| 13:04:07 | aarents | I think, I'm not sure, in my case, we are in NotImplementedError because because direct_snapshot is a feature used typically with ceph, not implemented in raw/qcow2 | |
| 13:04:17 | bauzas | that's correct | |
| 13:04:25 | bauzas | I found the change in question | |
| 13:04:31 | bauzas | aarents: https://review.opendev.org/#/c/205282/ | |
| 13:04:52 | bauzas | aarents: here in your case, we're not talking of RBD snapshots, right? | |
| 13:05:14 | aarents | right, local backed instance raw or qcow2 | |
| 13:05:35 | elod | lyarwood: I've prepared the Train release patch: https://review.opendev.org/#/c/721883/ if you have time please double-check the version bump and the reasons | |
| 13:06:30 | bauzas | aarents: kk, okay so the exception catch-up clause is the default when non-RBD | |
| 13:06:37 | bauzas | (just speaking out loud) | |
| 13:06:49 | aarents | exactly | |
| 13:13:24 | bauzas | aarents: https://review.opendev.org/#/c/609180/ | |
| 13:13:55 | bauzas | aarents: fwiw, I'm about to triage it as Invalid | |
| 13:14:14 | bauzas | but you could open a blueprint for optimizing how we manage I/O concurrency | |
| 13:18:53 | sean-k-mooney | stephenfin: i have added the topic of libvirt hardware profiles to the ptg topic list https://etherpad.opendev.org/p/nova-victoria-ptg on line 60 by the way | |
| 13:19:03 | stephenfin | sweet | |
| 13:19:10 | sean-k-mooney | i will start fleshing it out more here https://etherpad.opendev.org/p/libvirt-hardware-profiles | |
| 13:19:38 | sean-k-mooney | but im not sure if i will get to it this week | |
| 13:19:58 | sean-k-mooney | the spec template is more or less the same form last cycle right? | |
| 13:21:01 | sean-k-mooney | oh there already is one https://github.com/openstack/nova-specs/blob/master/specs/victoria-template.rst | |
| 13:22:01 | bauzas | sean-k-mooney: stephenfin: if you don't mind MHO, I'd not want to have the hardware profiles be operator-defined | |
| 13:22:10 | bauzas | this defeats interop | |
| 13:22:18 | sean-k-mooney | bauzas: yep its out of scope in the first version | |
| 13:22:29 | bauzas | in *any* version tbc :) | |
| 13:22:54 | sean-k-mooney | i said we could add that after if we wanted but only if they cannot modify intree ones and if we have an api to list and show the hardware profiles | |
| 13:23:08 | bauzas | if we go this way, we absolutely have to be pedantic and provide some abstraction that'd be versioned and defined by us | |
| 13:23:24 | sean-k-mooney | ill state teh same in the spec but i dont want to enable that in victoria | |
| 13:23:44 | bauzas | I think this absolutely needs to be discussed in the V spec | |
| 13:23:58 | bauzas | b/c this could be a terrible knob | |
| 13:24:03 | sean-k-mooney | bauzas: yes we would im planning for them to be version even if they are in tree only | |
| 13:24:21 | bauzas | or we would allow *custom* profiles | |
| 13:24:33 | sean-k-mooney | bauzas: well it wont provide anything that can be done with flavor extrra specs or image properties today | |
| 13:24:36 | bauzas | which would be yet another Far-West in Novaz | |
| 13:24:44 | bauzas | correct | |
| 13:24:52 | sean-k-mooney | *cannot | |
| 13:25:21 | bauzas | for this exact reason, I think we need to state in the spec that we WON'T support operator-defined profiles ever | |
| 13:25:35 | sean-k-mooney | e.g. its just a static set of profiles that change the default of existing tunables. | |
| 13:25:51 | sean-k-mooney | bauzas: if you want me to make that the starting point im ok with that | |
| 13:26:40 | sean-k-mooney | if someone else want to chagne that after Victoria we can have that discussion then but im totaly fine with only nova as a project being able to define these profiles | |
| 13:26:52 | bauzas | shoot, but again, I just want to be clear on the fact that I'm absolutely opposed to any attempt of delivering custom profiles unless they're explicitely stated "custom" | |
| 13:27:17 | bauzas | sean-k-mooney: this sounds reasonable | |
| 13:27:36 | sean-k-mooney | ok im fine with that too. i understnad the interop concern and i share that | |
| 13:27:46 | bauzas | leave others the pain to propose some customizable profiles in another spec | |
| 13:29:15 | sean-k-mooney | bauzas: yep, i intened to have no api or db changes and to store the profiles as yaml files that are packaged as data files as part of nova | |
| 13:29:35 | bauzas | sean-k-mooney: that's design discussion for sure | |
| 13:29:42 | bauzas | (but fwiw, I'll -1 this :D) | |
| 13:30:01 | bauzas | don't provide guns to kids | |
| 13:30:20 | sean-k-mooney | well i just dont want ot have a bunch of dicts in a module but my other appoch was to mirror the flavor validation work | |
| 13:30:26 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add docs and releasenotes for BP policy-defaults-refresh https://review.opendev.org/720129 | |
| 13:30:34 | bauzas | sean-k-mooney: the latter sounds good | |
| 13:30:56 | bauzas | but let's see what other ppl think | |
| 13:31:03 | sean-k-mooney | bauzas: it makes verioning harder which is the only reason i dont want to defautl to that but we can discuss in the spec later | |
| 13:31:20 | bauzas | sean-k-mooney: we have a couple of versioned objects you know | |
| 13:31:26 | bauzas | and we have versioned libs | |
| 13:31:58 | sean-k-mooney | yes but i want you to be able to say give me hw:profile=realtime-vicoria in W or Z | |
| 13:32:03 | bauzas | but this sounds a rathole to discuss this now :D | |
| 13:32:36 | bauzas | let's draft the UX in the spec ;) | |
| 13:32:39 | sean-k-mooney | where hw:profile woudl be an alias to the latest version of a profile | |
| 13:32:44 | sean-k-mooney | yep | |
| 13:32:57 | sean-k-mooney | anyway this was just an fyi that im starting to draft this | |
| 13:33:03 | bauzas | I'm not an API specialist, but I don't like explicit versioning on the flavor extraspec itself | |
| 13:33:09 | bauzas | but yeah, shoot | |
| 13:37:55 | gmann | gibi: stephenfin updated the policy doc, please re-look - https://review.opendev.org/#/c/720129/12 | |
| 13:40:30 | aarents | bauzas: ok thks | |
| 13:41:22 | bauzas | aarents: are you able to attend the virtual PTG ? | |
| 13:49:18 | aarents | bauzas: probably yes | |
| 13:49:59 | aarents | bauzas: I will dig soon the patch you share on bug report, if it can solve the issue | |
| 13:50:13 | bauzas | which one ? | |
| 13:50:33 | aarents | https://review.opendev.org/#/c/609180/ | |
| 13:56:20 | bauzas | aarents: ah you mean you'll try to conf setting ? sure, lemme know if this alleviates your issue | |
| 13:56:24 | lyarwood | elod: looking | |
| 13:56:31 | bauzas | you'll try the* | |
| 13:56:39 | lyarwood | elod: btw feel free to add me directly in these reviews in the future or anything really on stable :) | |
| 13:57:46 | aarents | bauzas: yep | |
| 13:58:50 | elod | lyarwood: oh, I forgot to add you to this :S and thanks, will do in the future :) | |
| 13:59:52 | bauzas | lyarwood: this sounds a configuration problem, nope ? 2019-09-05 16:08:30.057 8 ERROR nova.volume.cinder [req-522cbf47-a65a-4d46-8852-01adcfcbda2f - - - - -] The [cinder] section of your nova configuration file must be configured for authentication with the block-storage service endpoint. | |
| 14:00:14 | bauzas | lyarwood: context is https://bugs.launchpad.net/nova/+bug/1843643 | |
| 14:00:14 | openstack | Launchpad bug 1843643 in OpenStack Compute (nova) "VM on encrypted boot volume fails to start after compute host reboot" [Undecided,New] | |
| 14:00:19 | bauzas | lyarwood: I'm litterally 2 mins away from closing this bug | |
| 14:00:43 | bauzas | (comment #4 in the stacktrace) | |
| 14:02:59 | lyarwood | bauzas: if having that section configured allows n-cpu during init_host to have a valid admin context for grabbing secrets from barbican then yes | |
| 14:03:31 | lyarwood | bauzas: I think it might, I'd have to dig into the context code again as it has been a while | |
| 14:03:32 | bauzas | lyarwood: refresh the bug and see my comment | |
| 14:04:29 | bauzas | but I'm not a ksa specialist | |
| 14:04:57 | lyarwood | bauzas: yeah so I assume that would allow n-cpu itself to auth correctly, do we set that typically in devstack? | |
| 14:05:17 | lyarwood | yeah we do | |
| 14:05:58 | bauzas | lyarwood: well, if you don't, I don't see how you can get service tokens... | |
| 14:06:49 | lyarwood | bauzas: right | |
| 14:07:25 | bauzas | okay, closing the bug, asking the reporter to reopen the bug if fixing this doesn't help | |
| 14:07:27 | bauzas | done. | |
| 14:13:53 | bauzas | gibi: one day, we'll have to discuss what to do with bugs open since 2 years | |
| 14:14:33 | gibi | bauzas: ack, please add a line to the ptg etherpad and then we can start an ML discusison | |
| 14:14:43 | gibi | before the pt | |
| 14:14:43 | gibi | g | |