| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-16 | |||
| 08:56:39 | openstackgerrit | Stephen Finucane proposed openstack/nova master: db: Remove cell APIs https://review.openstack.org/651309 | |
| 08:56:53 | lyarwood | kashyap: generating it for each instance is expense IMHO, I'm just looking for ways to avoid that. | |
| 08:56:53 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Remove cells v1 options, group https://review.openstack.org/651310 | |
| 08:57:16 | kashyap | lyarwood: Let me be sure I'm not misreading you: | |
| 08:57:44 | kashyap | lyarwood: You're saying to generate _once_ and reuse it? Or generate them ahead store them somewhere and _then_ use a unique VARS file per instance? | |
| 08:58:03 | kashyap | s/ahead store/ahead and store/ | |
| 09:00:05 | kashyap | lyarwood: Okay, I see what you mean: generate a template once, make copies and use that when needed. | |
| 09:00:16 | lyarwood | kashyap: yup that's it | |
| 09:00:24 | kashyap | Let me see if there's any gotchas there. (And yeah, I'd like to avoid needless expensive creations, too) | |
| 09:06:04 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Remove cells v1 options, group https://review.openstack.org/651310 | |
| 09:06:43 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Remove conductor_api and _last_host_check from manager.py https://review.openstack.org/651059 | |
| 09:20:14 | kashyap | lyarwood: Important bit - I didn't mention this at all in the spec: there's actually a config attribute in /etc/libvirt/qemu.conf that lets you specify the master 'nvram' template ("VARS" file) | |
| 09:28:48 | lyarwood | kashyap: and that can already have the keys enrolled? | |
| 09:30:30 | kashyap | lyarwood: So currently if you peek at your /etc/libvirt/qemu.conf, it has mapping of which _CODE.fd file belongs to which _VARS.fd file | |
| 09:30:47 | kashyap | lyarwood: Checking with the libvirt folks for further usage | |
| 09:58:22 | avolkov | kashyap: hi, have a couple of questions on https://review.openstack.org/#/c/506720/. Could you take a look? | |
| 09:58:44 | sean-k-mooney | ... i realised i jsut spent an hour reviewing patchset 8 of kasaps spec | |
| 09:58:48 | sean-k-mooney | its on 10 | |
| 10:02:32 | kashyap | sean-k-mooney: Heya | |
| 10:02:38 | kashyap | Thanks for the review, looking | |
| 10:02:55 | kashyap | A quick point top off the head: the key enrollment script should _not_ a libvirt feature | |
| 10:03:06 | kashyap | And we're _not_ "(Bash) shelling out" anything | |
| 10:03:25 | kashyap | If you read closely, I merely mentioned it to show what is going on behind the scenes. | |
| 10:03:33 | sean-k-mooney | the external tool is satring qemu and then executing command on the instance right | |
| 10:03:41 | kashyap | No. | |
| 10:04:15 | kashyap | As noted in an earlier response on the change, the VARS file generator script is _not_ launching any instance. | |
| 10:04:44 | sean-k-mooney | ok but it is printing raw bytes and stings to something | |
| 10:05:21 | sean-k-mooney | https://github.com/puiterwijk/qemu-ovmf-secureboot/blob/master/ovmf-vars-generator#L104 | |
| 10:05:40 | openstackgerrit | Chris Dent proposed openstack/nova master: Delete the placement code https://review.openstack.org/618215 | |
| 10:05:50 | kashyap | sean-k-mooney: Have you ever tried Secure Boot? | |
| 10:06:04 | kashyap | sean-k-mooney: It is simply sending the escape char so that you can _run_ the tool | |
| 10:06:04 | sean-k-mooney | only on phyical machines | |
| 10:06:47 | kashyap | Please rephrase. | |
| 10:07:10 | kashyap | It can work the same in a nested env. too. The script is merely launching the ISO and enrolling the default keys | |
| 10:07:19 | kashyap | The standard behaviour documented for all distribution wiki pages | |
| 10:07:21 | sean-k-mooney | i have used secure boot but on physical machines but i have never replaced the keys | |
| 10:07:28 | kashyap | (Ah, okay) | |
| 10:07:36 | sean-k-mooney | kashyap: yes so its using qemu to launch a vm | |
| 10:07:47 | sean-k-mooney | it may not be the guest vm | |
| 10:07:52 | kashyap | No, it is launching a QEMU process. Not every QEMU process is not a "VM" | |
| 10:07:54 | sean-k-mooney | but its still launching a vm | |
| 10:08:05 | kashyap | So what? | |
| 10:08:18 | kashyap | It is the correct thing to do. | |
| 10:08:33 | sean-k-mooney | so have you considerd how this will work on a host that is configred to run guest with hugepages only | |
| 10:09:05 | sean-k-mooney | e.g. where the host has been tuned so that there is not a large amount of free meory or on a realtime host | |
| 10:09:08 | kashyap | (The process for you to try on a guest: https://wiki.ubuntu.com/UEFI/OVMF) | |
| 10:09:45 | sean-k-mooney | what im concened about it how much memoy this will use and can it impact other guests | |
| 10:09:51 | kashyap | sean-k-mooney: That is not relevant. Because you only launch the process *once* with 256MB of RAM | |
| 10:09:57 | kashyap | And generate the VARS file, and that's it. | |
| 10:10:06 | sean-k-mooney | once per vm | |
| 10:10:09 | kashyap | sean-k-mooney: No need for concern. It's a one-time thing for a few seconds | |
| 10:10:12 | kashyap | No. | |
| 10:10:13 | kashyap | Just once. | |
| 10:10:17 | kashyap | We will use a template file. | |
| 10:10:34 | sean-k-mooney | ok so why is this not a step triplo should be doing | |
| 10:10:44 | sean-k-mooney | or why are we not just shipping a template file | |
| 10:10:58 | kashyap | That is a different topic. I don't want to derail the core thing at hand | |
| 10:11:02 | sean-k-mooney | or requiring the operator to do it manually as part of install. | |
| 10:11:05 | kashyap | (Two steps at a time.) | |
| 10:11:13 | kashyap | sean-k-mooney: Yes, that's what I discussed with Lee. | |
| 10:11:26 | kashyap | The first step is to document that it is an external step an operator must take | |
| 10:11:32 | kashyap | Please take a few minutes to read the conversation before. | |
| 10:11:37 | sean-k-mooney | well i dont think nova should be doing it. | |
| 10:11:42 | kashyap | (I'm repeating myself here) | |
| 10:11:43 | sean-k-mooney | ok ill reread | |
| 10:12:13 | kashyap | sean-k-mooney: Nova won't do it. | |
| 10:12:58 | sean-k-mooney | ok then it should not be in the spec. we should have domumention for it or at most mentionit in the other deployer impact if it in the spec | |
| 10:13:43 | kashyap | Yes, will mention it as such | |
| 10:13:45 | sean-k-mooney | the current way the spec is layed out implied that it was a required change to nova. the actuly require change will be knowing where the template file is | |
| 10:13:59 | sean-k-mooney | ok | |
| 10:15:15 | kashyap | No, it is _not_ required | |
| 10:15:19 | kashyap | I didn't say it as such | |
| 10:15:29 | sean-k-mooney | rather then copying over all my comments ill leve them on patchset 8 | |
| 10:15:31 | kashyap | I said "consider" if we should. That is different than "required". | |
| 10:18:38 | sean-k-mooney | actully you said "Work out a way to integrate the external Python tool, | |
| 10:18:40 | sean-k-mooney | `ovmf-vars-generator` into Nova. | |
| 10:18:42 | sean-k-mooney | " | |
| 10:19:13 | sean-k-mooney | i was reviewing pathset 8 remember | |
| 10:19:29 | aspiers | hi folks | |
| 10:19:31 | sean-k-mooney | in patchset 10 you have change it to document that the operator ... | |
| 10:19:49 | sean-k-mooney | aspiers: hi | |
| 10:19:51 | kashyap | Yes. PS 10 was there when you started reviewing :-) | |
| 10:20:08 | aspiers | Yesterday I updated the AMD SEV spec in case anyone has time to review today | |
| 10:20:19 | aspiers | Not sure how many other specs are in your queue ;-) | |
| 10:20:25 | sean-k-mooney | kashyap: yep but i click on it from a gerrit comment form lee and never checked it was the latest :) | |
| 10:20:31 | openstackgerrit | Lee Yarwood proposed openstack/nova master: compute: Use source_bdms to reset attachment_ids during LM rollback https://review.openstack.org/652800 | |
| 10:20:32 | lyarwood | mdbooth: ^ you might be interested in this if you have time today | |
| 10:20:32 | aspiers | I'll be around in case there are things to discuss | |
| 10:20:36 | sean-k-mooney | aspiers: link? | |
| 10:20:52 | aspiers | sean-k-mooney: https://review.openstack.org/#/c/641994/ | |
| 10:20:59 | mdbooth | lyarwood: Shiny | |
| 10:21:00 | sean-k-mooney | yep just found it | |
| 10:21:01 | aspiers | I also put it in https://etherpad.openstack.org/p/nova-spec-review-day | |
| 10:21:57 | aspiers | sean-k-mooney: In particular I am wondering if hugepages can help with memory accounting. It might be a problem if it can only account for guest RAM and not the other QEMU memory chunks | |
| 10:22:37 | kashyap | sean-k-mooney: Can't parse this sentence: "-1 while i see if any of the comments i just left on patchset 8 have been adressed" | |
| 10:22:38 | sean-k-mooney | kashyap: ill clear my head a bit and take it form the top later today. by the way haveing matial content in the work items section makes it much harder to review IMO | |
| 10:23:12 | sean-k-mooney | kashyap: well i was going to -1 pathset 8 and i wanted to see if my coment were adressed in 10 | |
| 10:23:22 | sean-k-mooney | most werent so my -1 woudl still stand | |
| 10:24:29 | kashyap | sean-k-mooney: After I read you review in full. I'll post a new iteration, and write a top-level summary addressing your comments (as needed). (Instead of more inline replies there.) | |
| 10:24:35 | kashyap | Thanks for looking. | |