| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-16 | |||
| 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) | |
| 12:19:31 | NewBruce | so im officially out of ideas on this one…. | |
| 12:19:33 | sean-k-mooney | if deleted = id then its a soft delete service record | |
| 12:19:57 | sean-k-mooney | that bug link does not work form me by the way but i remember the bug you were having | |
| 12:20:06 | NewBruce | Nova-compute deleted = 10 | |
| 12:20:11 | NewBruce | deleted = 60 | |
| 12:20:14 | NewBruce | deleted = 61 | |
| 12:20:56 | NewBruce | yeah i moved the bug to private for now; some logs got i want to remove; but haven’t heard back from the nova admin on that yet | |
| 12:22:45 | sean-k-mooney | ah ok | |
| 12:22:46 | NewBruce | cleaned up and public again; i can mail you the log files if you are interested | |
| 12:22:56 | NewBruce | https://bugs.launchpad.net/nova/+bug/1822884 | |
| 12:22:58 | openstack | Launchpad bug 1822884 in OpenStack Compute (nova) "live migration fails due to port binding duplicate key entry in post_live_migrate" [Undecided,New] | |
| 12:23:51 | NewBruce | posted some more to the launchpad now | |
| 12:24:50 | sean-k-mooney | so at this point all compute nodes are running rocky. the neutorn contol plane is entirely on osa | |
| 12:25:22 | sean-k-mooney | and all compute services are using the same compute service version | |
| 12:25:51 | NewBruce | correct | |
| 12:27:28 | kashyap | lyarwood: sean-k-mooney: I forgot to mention: the key enrollment tool is already part of EDK2 package (at least in Fedora), as a sub-RPM, look for: 'edk2-qosb' | |
| 12:27:33 | sean-k-mooney | honestly i dont know either. cold miragtion should work as a last resort but i dont quite understand why this would happen | |
| 12:27:35 | kashyap | (Updating the spec) | |
| 12:28:07 | sean-k-mooney | ok yes that is good to add to the reference section | |
| 12:28:18 | kashyap | Yes, adding, actually | |
| 12:28:32 | kashyap | I totally forgot that we did it some 8 months ago. My memory is like goldfish's | |