| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-16 | |||
| 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 | |
| 12:28:46 | sean-k-mooney | it will be useful for project like kolla that need to figureout what to install | |
| 12:48:42 | openstackgerrit | Merged openstack/nova master: conf: Undeprecate and move the 'dhcp_domain' option https://review.openstack.org/480616 | |
| 12:49:00 | stephenfin | sean-k-mooney: We're going to have to make a call on https://review.openstack.org/#/c/555081/23/specs/train/approved/cpu-resources.rst@180 | |
| 12:49:21 | bauzas | stephenfin: I still need to provide my comments | |
| 12:49:41 | stephenfin | sean-k-mooney: On one hand, I totally get where you're coming from and agree that it's a valid concern | |
| 12:50:01 | sean-k-mooney | yes that is one of the bits im most uncomfortable with. | |
| 12:50:01 | stephenfin | On the other though, if we don't use 'vcpu_pin_set' to populate this stuff, the user will be left in a state where they can no longer boot any instances with 'hw:cpu_policy' configured until they do additional configuration on each host | |
| 12:50:20 | stephenfin | That's as much a breaking change as anything else we've discussed | |
| 12:51:19 | stephenfin | bauzas: Ack. Just focussing on that one point atm | |
| 12:51:32 | sean-k-mooney | yes its not simple. if we use the totally new config options i suggest we could have tehm pre set them and possible provide an upstread check in nova status? | |
| 12:52:07 | sean-k-mooney | vcpu_pin_set was never intended to be "pinned cpus" alther it was assumed to be that in some cases | |
| 12:52:23 | sean-k-mooney | so i dont know what the right way forward is | |
| 12:52:28 | kashyap | lyarwood: Okay, aside: the 'nvram' stanza in /etc/libvirt/qemu.conf will be depreacted. So we can ignore that | |
| 12:52:32 | stephenfin | Hmm, neither do I :\ | |
| 12:53:18 | stephenfin | I'm also thinking we need to kill 'hw:emulator_threads_policy=isolate' | |
| 12:53:49 | sean-k-mooney | i kind of feel we should require the dedicated_cpu_set to be in the config before enableing any of this | |
| 12:54:03 | sean-k-mooney | stephenfin: ya that i was original not sure about but i think i agree | |
| 12:54:20 | stephenfin | Because I can't think of anyway to account for the extra core without mangling the request | |
| 12:54:32 | sean-k-mooney | hw:emulator_threads_policy=share shoudl be sufficent and more efficent | |