Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-04-16
10:20:32 aspiers I'll be around in case there are things to discuss
10:20:32 lyarwood mdbooth: ^ you might be interested in this if you have time today
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.
10:25:58 aspiers sean-k-mooney: but TBH I am a bit confused because the QEMU memory usage breakdown in the table https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/amd-sev-libvirt-support.html#proposed-change seems to contradict what Daniel Berrange has said more recently https://review.openstack.org/#/c/641994/2/specs/train/approved/amd-sev-libvirt-support.rst@167 where he suggests a fudge factor
10:25:59 aspiers of 1.5
10:27:28 sean-k-mooney kashyap: cool sounds good. the main reason for the -1 is the implication that the nova libvirt driver ever supporte secure boot before ant that it was "actully" insecure.
10:27:43 kashyap sean-k-mooney: Just responding to that point. Will fix it.
10:28:00 kashyap sean-k-mooney: Why I wrote is that, some customers and users were _confused_ that Nova supports "SB"
10:28:20 sean-k-mooney yes they were wrong
10:28:38 sean-k-mooney but the release notes were pretty clear
10:28:54 kashyap Correct. I'll adjust the phrasing in spec
10:28:55 sean-k-mooney hyperv supprot SB and libvir only supports uefi boot
10:32:24 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Stop starting consoleauth in functional tests https://review.openstack.org/652966
10:32:24 openstackgerrit Stephen Finucane proposed openstack/nova master: docs: Remove references to nova-consoleauth https://review.openstack.org/652965
10:32:25 openstackgerrit Stephen Finucane proposed openstack/nova master: nova-status: Remove consoleauth workaround check https://review.openstack.org/652968
10:32:25 openstackgerrit Stephen Finucane proposed openstack/nova master: xvp: Start using consoleauth tokens https://review.openstack.org/652967
10:32:26 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Remove ConsoleAuthToken.to_dict https://review.openstack.org/652970
10:32:26 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove nova-consoleauth https://review.openstack.org/652969
10:33:04 kashyap sean-k-mooney: While removing "implications", I will definitely mention the point that some people can get confused.
10:33:09 kashyap (Wording in the new iteration coming soon.)
10:34:55 sean-k-mooney sure that is resonable i guess
10:35:32 sean-k-mooney it should part of the problem statement section right?
10:37:11 kashyap (Yeah)
10:37:45 kashyap sean-k-mooney: I see that you were commenitng as you read the spec; as I mentioned the 'os_secure_boot' & 'os:secure_boot' in the Work Items
10:37:58 kashyap sean-k-mooney: How about I add a pointer to Work Items in the "Proposed change".
10:37:59 sean-k-mooney ya
10:38:04 kashyap (It is clearer than paragraphs of text.)
10:38:25 sean-k-mooney no the work items section as i said really should be sort like 10 lines max
10:38:45 sean-k-mooney all that content in my opipion shoudl be in teh proposed chages section
10:39:56 sean-k-mooney just grabbed a random spec but this is about the extent of what should be in work items https://github.com/openstack/nova-specs/blob/master/specs/rocky/approved/list-show-all-server-migration-types.rst#work-items
10:43:29 kashyap sean-k-mooney: Note: on your remark: about extending Hyper-V also to report traits -- I don't want to "boil the lake" (much less an ocean) with one spec
10:43:38 kashyap Few things at a time, with reasonable scope.
10:43:50 kashyap (That Hyper-V thing should be a separate item)
10:44:10 kashyap sean-k-mooney: Well, "10 lines max" for Work Items is a personal preference.
10:44:25 kashyap I'd like to follow this structure (which I think is far more clearer):
10:44:35 kashyap - Describe the change at high-level in the "Proposed change" section
10:44:56 kashyap - Describe the "how" in _some_ detail in the Work Items section
10:45:34 aspiers In the SEV spec I've probably gone somewhere in between those two
10:45:59 cdent kashyap: I agree that that format would probably make more sense, but it isn't the pattern that's been followed in the past
10:46:04 aspiers "Work Items" is not short, but "Proposed change" has more detail.
10:46:23 kashyap cdent: Nod
10:46:28 aspiers However that's because for SEV, the design part is much more difficult than the actual implementation
10:47:00 aspiers We've had to debate the design for ages and consider all kinds of complex stuff, but once the design is decided, the actual coding reflected in Work Items is reasonably simple
10:47:35 aspiers I expect each spec will have a different ratio between design complexity and implementation complexity, therefore the two sections will differ in size accordingly
10:47:44 lpetrut hi guys, I work on maintaining the Hyper-v driver and I'd also be interested in reporting traits / provider inventory
10:48:15 lpetrut in fact, I was catching up on the specs / libvirt patches to see what needs to be done
10:55:32 aspiers lpetrut: I'm far from an expert so this might be wrong, but IIUC the driver needs to implement update_provider_tree()
10:55:54 lpetrut thanks for the hint
10:56:11 aspiers lpetrut: see the libvirt driver for an example
10:57:01 aspiers actually this is also documented very nicely
10:57:22 aspiers https://docs.openstack.org/nova/latest/reference/update-provider-tree.html
10:59:18 lpetrut that's great. I'm wondering how are hypervisor specific features handled: standard traits via os-traits or custom traits
11:00:07 aspiers I think best practice is that drivers are supposed to only provide standard traits
11:00:30 aspiers So if hyperv wants to provide a new trait, you should probably try to submit that to os-traits first
11:00:36 aspiers That's what I did with HW_CPU_AMD_SEV
11:01:06 aspiers lpetrut: You can also consider using capabilities since I managed to get that patch landed
11:01:30 aspiers https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#compute-capabilities-as-traits
11:02:09 aspiers lpetrut: efried_pto and I drew a diagram which might help https://pasteboard.co/I3iqqNm.jpg
11:03:06 aspiers but again I knew *nothing* about any of this a few months ago, so take it with a slight pinch of salt
11:03:12 sean-k-mooney cdent: i find the fromat that kashyap propsoed and uses to be much harder to read top to bottom and while syantatically correct i dont think it smatiaclly alines with the spectempalte defintions
11:03:35 kashyap No one else complained so far. I don't want to rework it.
11:03:45 kashyap I spend a _lot_ of time carefully choosing words and maintaining a structure
11:03:55 kashyap I will also note in the summary comment I'm writing
11:03:57 sean-k-mooney kashyap: if you like i can rework it
11:04:01 kashyap Please no
11:04:32 kashyap Let's not make specs into sterile and overly rigid enviroments. There is already a high-level structure. Let the author's thoughts reflect in their writing
11:04:33 sean-k-mooney i really thing think is a bad way to write specs. its one of the few documation forms i truely care about.
11:04:37 kashyap And if it is clear, it is fine.
11:04:46 kashyap sean-k-mooney: Again, "bad way" is an opinion
11:04:56 kashyap I've had several people read it, none of them had complaints
11:05:20 sean-k-mooney form the template "Work Items
11:05:22 sean-k-mooney Work items or tasks -- break the feature up into the things that need to be done to implement it. Those parts might end up being done by different people, but we're mostly trying to understand the timeline for implementation.
11:05:24 sean-k-mooney "
11:06:10 sean-k-mooney the intention is to descibe the order in which things need to be done to implent the feature
11:06:17 kashyap For now, I'm addressing the main points.
11:06:23 kashyap (Let's not lose sight of what is important.)
11:06:34 kashyap If many others complain, I will re-adjust the content a bit.
11:06:48 kashyap For now, I want to re-focus the attention on the actual design and content.
11:07:20 lpetrut aspiers: interesting, wasn't aware that driver capabilities are now reported through traits
11:07:33 sean-k-mooney well part of my main objection to the current formating is you dont present you actual design at all in the proposed chage section.
11:07:55 sean-k-mooney at least you didnt in the version i read. ill read the latest version when its ready
11:08:39 aspiers lpetrut: it's new, mriedemann originally prototyped it ~1 year ago and then I finished it off https://review.openstack.org/#/c/538498/
11:09:52 aspiers lpetrut: https://docs.openstack.org/releasenotes/nova/stein.html#new-features
11:14:53 openstackgerrit Merged openstack/nova master: Change a log level for overwriting allocation https://review.openstack.org/649788
12:17:11 NewBruce mnaser / sean-k-mooney howdy…
12:17:54 sean-k-mooney NewBruce: o/
12:18:00 NewBruce update on https://bugs.launchpad.net/nova/+bug/1822884 - we’ve finished upgrading all nodes on our site to rocky (service level 35), nut the issue still exists...
12:18:03 openstack NewBruce: Error: malone bug 1822884 not found
12:18:36 NewBruce (we have 3 rows in the services table not on level 35, but they have deleted > 0, so im hoping they are ignored)

Earlier   Later