| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-23 | |||
| 07:54:09 | kashyap | efried: I tried to be conscious to "not assume anything", _still_ my phrasing seems to be not sufficiently clear enough. Will rework. | |
| 07:55:58 | sean-k-mooney | kashyap: i think the issue is you assumed people understand and follow libvirt and did not present the usecase in terms of nova but instead present it as libvirt has this new api we shoudl use it with the assumtion people knew what libvirt api we currently use and what features it is used for | |
| 07:56:31 | kashyap | sean-k-mooney: I partly disagree. I didn't "assume" it that way. | |
| 07:56:49 | kashyap | How much more clearer can you phrase this: | |
| 07:56:52 | kashyap | [quote] | |
| 07:57:20 | kashyap | [/quote] | |
| 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 | sean-k-mooney | the current one has no end user visable impact | |
| 08:06:32 | kashyap | No, I want to keep it separate. | |
| 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: prepare func test env for moving servers with bandwidth https://review.opendev.org/655109 | |
| 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:42 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Pass network API to the conducor's MigrationTask https://review.opendev.org/655111 | |
| 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: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:43 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: handle port allocation during migration https://review.opendev.org/655112 | |
| 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 | machine_type, virt_type) | |
| 12:41:57 | kashyap | self._get_domain_capabilities(emulator_bin, arch, | |
| 12:41:57 | kashyap | domain_caps[arch][machine_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/ | |