| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-22 | |||
| 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 | |
| 14:14:51 | bauzas | not sure I wanna be the messenger :D | |
| 14:14:57 | gibi | OK, I will do it :D | |
| 14:15:08 | bauzas | gibi: there is no rush | |
| 14:15:30 | gibi | I mean I will now add a line to the etherpad and later will think about an ML message | |
| 14:15:52 | bauzas | fwiw, we made it once, for example https://bugs.launchpad.net/nova/+bug/1018253/comments/5 | |
| 14:15:52 | openstack | Launchpad bug 1018253 in OpenStack Dashboard (Horizon) "No error message prompt during attaching when mountpoint is occupied" [Wishlist,New] | |
| 14:17:29 | gibi | bauzas: yepp | |
| 14:17:52 | gibi | anyhow added a line to the ptg etherpad | |
| 14:17:59 | bauzas | and I just provided this example | |
| 14:18:20 | bauzas | gibi: go back to your downstream work, man ! | |
| 14:18:24 | bauzas | :D | |
| 14:18:42 | gibi | :) | |
| 14:19:35 | lyarwood | sigh we need to kill mountpoint in the API | |
| 14:19:53 | lyarwood | now that we have attachments | |
| 14:23:32 | bauzas | lyarwood: feel free to triage this bug, not on my radar yet :) | |
| 14:32:07 | sean-k-mooney | gibi: im hoping that we wont use the mailing list to hevialy for converstaion that are not backed by a spec | |
| 14:33:17 | sean-k-mooney | gibi: we can do that but i think its not a great medium to have those kind of disucssions without a lot of pre work | |
| 14:33:50 | sean-k-mooney | that said we used to have a bot that jsut closed them so we could always just do that again :P | |
| 14:34:37 | gibi | sean-k-mooney: what do you suggest, how to prepare for the limited real time ptg discussion? | |
| 14:35:41 | sean-k-mooney | well im hoping our actul contact hours that are don vitually will not be less then we normally have in person but will just be spread over more days | |