| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-23 | |||
| 07:57:31 | kashyap | sean-k-mooney: My comment on PS-4, on: Apr 9 6:38 PM | |
| 07:57:43 | sean-k-mooney | that did not rendeer from me | |
| 07:58:08 | sean-k-mooney | i just see open and close quotes | |
| 07:58:14 | kashyap | I can add additional details and answer questions -- sure. But what is already there is sufficiently clear enough, no? | |
| 07:58:24 | kashyap | sean-k-mooney: Yeah, that was intentional; sorry :-) I didn't paste anything | |
| 07:58:33 | kashyap | (Because I didn't wanted to paste the large comment from the change) | |
| 07:58:46 | kashyap | sean-k-mooney: See my comment on PS-4: https://review.opendev.org/#/c/645814/4 | |
| 08:00:15 | sean-k-mooney | ya but the poblem with that comment is you dont say how nova will handel it | |
| 08:00:18 | kashyap | sean-k-mooney: I told Nova's guest CPU selection is lacking. And even provided a rough example like: | |
| 08:00:21 | kashyap | "Is this combination of IvyBridge + 'pcid' & 'pdpe1gb' supported by KVM, QEMU and libvirt on the host?" | |
| 08:00:26 | kashyap | sean-k-mooney: Yes, that part, I will addres. | |
| 08:00:28 | sean-k-mooney | e.g. will the agent refuse to start | |
| 08:00:54 | kashyap | Right, will address them, once I finish addressing comments on the Secure Boot spec. | |
| 08:01:39 | sean-k-mooney | by the way nova has no cpu selection logic outside of host-model so its not really lacking as non existent | |
| 08:02:57 | sean-k-mooney | i just found out that weechat has mouse support and gesture ... | |
| 08:03:04 | sean-k-mooney | i dont think i like them | |
| 08:04:05 | kashyap | sean-k-mooney: I'm of course aware that we default to 'host-model'. That's not the point. When I say "CPU selection", it also means CPU model + features (obviously). | |
| 08:04:11 | sean-k-mooney | kashyap: for what its worth i only barely followed what you were proposing in that spec. | |
| 08:04:17 | kashyap | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3948,#L3957 | |
| 08:04:30 | sean-k-mooney | kashyap: yes but that is hardcoded effectivly via the config | |
| 08:04:40 | sean-k-mooney | its not nova making the selection in this case its the operator | |
| 08:04:50 | kashyap | (I will rephrase the spec with a couple more examples.) | |
| 08:05:04 | kashyap | (Not entirely, some bits. While adding additional details.) | |
| 08:05:13 | openstackgerrit | Boxiang Zhu proposed openstack/nova master: Add host and hypervisor_hostname flag to create server https://review.opendev.org/645520 | |
| 08:06:08 | sean-k-mooney | one thing i was wondering is do you want to merge this spec with https://review.opendev.org/#/c/642030/ | |
| 08:06:32 | kashyap | No, I want to keep it separate. | |
| 08:06:32 | sean-k-mooney | the current one has no end user visable impact | |
| 08:06:38 | sean-k-mooney | ok | |
| 08:06:45 | kashyap | As I'm not even sure if we should do: https://review.opendev.org/#/c/642030/ | |
| 08:06:57 | sean-k-mooney | ya i guessed that is why | |
| 08:07:21 | sean-k-mooney | if we do implment the second spec https://review.opendev.org/#/c/642030/ it will depend on this new api | |
| 08:07:26 | sean-k-mooney | or it should use the new api | |
| 08:07:39 | kashyap | Also, not every spec needs to be "user visible". (That said, in this case, it _is_ "operator visible" in a way. Will save the write-up for the spec) | |
| 08:08:06 | sean-k-mooney | well its not other then the agent will stop if its not compatible | |
| 08:08:31 | sean-k-mooney | there is not rest api changes | |
| 08:08:40 | sean-k-mooney | or traits changes | |
| 08:09:34 | kashyap | sean-k-mooney: It is not just about 'compat check'. The resulting CPU + flags will be more _useful_ and _useable_ | |
| 08:09:46 | sean-k-mooney | how | |
| 08:10:22 | kashyap | I explained it in the spec. I wonder if you even read that. | |
| 08:10:24 | sean-k-mooney | the set of flag we get back for what the host support wont change | |
| 08:10:30 | sean-k-mooney | yes i did | |
| 08:10:36 | sean-k-mooney | you did not explain it well | |
| 08:10:44 | sean-k-mooney | in terms of how its more useful to nova | |
| 08:10:57 | sean-k-mooney | beyond we can as if the value in the config are valid | |
| 08:12:09 | kashyap | sean-k-mooney: Did you read this at all? | |
| 08:12:11 | kashyap | [quote] | |
| 08:12:12 | kashyap | - While determining guest CPU models, Nova can take into account several other aspects, e.g. the type of virtualization (pure emulation vs. hardware-accelerated), QEMU binary's capabilities, guest machine type, and CPU architcture to construct a better-informed guest CPU. | |
| 08:12:16 | kashyap | [/quote] | |
| 08:12:20 | kashyap | What is unclear about that? | |
| 08:12:38 | kashyap | Your "how" is answered by the above. | |
| 08:12:42 | sean-k-mooney | what is uncleare is what does "better-informned guest cpu" mean | |
| 08:13:13 | sean-k-mooney | will the cpu flag in the guest (via lscpu) change | |
| 08:13:31 | kashyap | Please wait. | |
| 08:13:38 | kashyap | One thing at a time. | |
| 08:14:35 | kashyap | You get a "better-informed guest CPU" because: the newer API, when calculating baseline, baselineHypervisorCPU() will *filter out* CPU features that are not supported by QEMU on the host. | |
| 08:16:44 | sean-k-mooney | o/ | |
| 08:52:29 | openstackgerrit | Surya Seetharaman proposed openstack/nova-specs master: Support server power state update through external event https://review.opendev.org/636132 | |
| 11:21:39 | alex_xu | emm...US evus enrollment not compatible with google chrome :( | |
| 11:46:20 | jangutter | alex_xu: Could be worse, according to https://help.cbp.gov/app/answers/detail/a_id/1090/~/technical-difficulties-submitting-my-esta-application the ESTA system supports IE 5 SP 2, or Netscape 6.2 | |
| 11:53:21 | sean-k-mooney | jangutter: firefox worked for me but ya government sites then to be updated infrequently | |
| 12:01:57 | jangutter | (the versions of Netscape and IE probably correspond to the date that the original software was delivered by the contractors.) | |
| 12:02:40 | sean-k-mooney | ya the current maintainer (if there is one) proably has never seen that page | |
| 12:04:40 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Remove unused param from _fill_provider_mapping https://review.opendev.org/655107 | |
| 12:04:41 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Move _fill_provider_mapping to the scheduler_utils https://review.opendev.org/655108 | |
| 12:04:41 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: prepare func test env for moving servers with bandwidth https://review.opendev.org/655109 | |
| 12:04:42 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: allow getting resource request of every bound ports of an instance https://review.opendev.org/655110 | |
| 12:04:42 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Pass network API to the conducor's MigrationTask https://review.opendev.org/655111 | |
| 12:04:43 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: handle port allocation during migration https://review.opendev.org/655112 | |
| 12:04:43 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: func test for migrate server with ports having resource request https://review.opendev.org/655113 | |
| 12:04:44 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Extend NeutronFixture to handle migrations https://review.opendev.org/655114 | |
| 12:13:39 | mriedem | i need a stable core to hit this queens backport https://review.opendev.org/#/c/640198/ | |
| 12:22:12 | openstackgerrit | sean mooney proposed openstack/nova master: [WIP] Libvirt: add nfv job https://review.opendev.org/652197 | |
| 12:26:48 | openstackgerrit | Matt Riedemann proposed openstack/nova master: DNM: debug config opts infinite recursion https://review.opendev.org/654468 | |
| 12:26:49 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Don't run tempest/devstack jobs on nova/test.py only changes https://review.opendev.org/655121 | |
| 12:32:53 | aspiers | vcpu:1 | |
| 12:32:57 | aspiers | oops | |
| 12:40:24 | kashyap | aspiers: When you're about -- remind me again, are you planning to cache the result of getDomainCapabilities(), as part of SEV work? | |
| 12:41:20 | aspiers | kashyap: not just planning, but https://review.opendev.org/#/c/633855/12/nova/virt/libvirt/host.py already does that | |
| 12:41:56 | kashyap | aspiers: Ah: | |
| 12:41:57 | kashyap | domain_caps[arch][machine_type] = \ | |
| 12:41:57 | kashyap | self._get_domain_capabilities(emulator_bin, arch, | |
| 12:41:57 | kashyap | machine_type, virt_type) | |
| 12:42:02 | aspiers | right | |
| 12:42:11 | kashyap | aspiers: So something to consider: | |
| 12:43:08 | kashyap | aspiers: This morning, while talking to a libvirt developer (Michal Privoznik), he was saying: caching domain capabilities probably doesn't make sense -- because it will be outdated everytime libvirt and QEMU are updated. | |
| 12:43:09 | arshad777 | Hi everyone: I am trying to create an instance on multi-node setup. But getting error "no valid host found". For detail refer url http://paste.openstack.org/show/749631/ | |
| 12:43:43 | arshad777 | compute services are running. Please refer url http://paste.openstack.org/show/749630/ for more detail | |
| 12:43:47 | aspiers | kashyap: it would only be cached in the running service, not persisted to disk | |
| 12:43:53 | kashyap | aspiers: As we know, there are 4 input values (path to qemu binary, guest architecture, machine type and virt type) -- so any change if one of them and we get a different set of capabilities | |
| 12:44:04 | kashyap | aspiers: Noted | |
| 12:44:05 | aspiers | kashyap: if a compute node's libvirt/QEMU gets updated, it seems reasonable to expect that nova-compute will get restarted too | |
| 12:44:19 | aspiers | or at least for major updates | |
| 12:44:32 | kashyap | aspiers: Yes, not "reasonable", it should, to avoid any surprises :-) | |
| 12:45:20 | mriedem | jaypipes: can you take a look at the stein regression bug fix series starting with the functional recreate test here? https://review.opendev.org/#/c/653268/ | |
| 12:45:48 | aspiers | kashyap: qemu binary path will have a single value and is programmatically obtained | |
| 12:46:11 | aspiers | and virt type will presumably be fixed within the context of the libvirt driver anyway | |
| 12:46:18 | aspiers | so in reality it's just two values which can change | |
| 12:46:23 | mriedem | gibi: can you take a look at the stein regression bug fix series starting here? https://review.opendev.org/#/c/653098/ | |
| 12:46:32 | kashyap | aspiers: True, good point. (So you're aware of it; just thought I'd notify.) | |
| 12:46:38 | gibi | mriedem: looking | |