| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-23 | |||
| 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/ | |
| 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 | aspiers | unless it's possible to have the libvirt driver allowing both Xen and KVM on one host | |
| 12:46:38 | gibi | mriedem: looking | |
| 12:46:43 | aspiers | which I assumed not | |
| 12:46:55 | aspiers | or at least that noone would be crazy enough to try that ;-) | |
| 12:47:04 | kashyap | aspiers: No, that's too FrankenStack to mix it like that :D | |
| 12:47:08 | aspiers | right | |
| 12:47:29 | kashyap | Okay, /me moves "office", home --> library; bbiab | |
| 12:48:57 | aspiers | kashyap: getting the emulator was the whole point of https://review.opendev.org/#/c/640483/ | |
| 12:51:54 | sean-k-mooney | aspiers: what were you going to use the emulator for? | |
| 12:52:35 | aspiers | for calling the API as per above | |
| 12:52:38 | aspiers | gotta run, biab | |
| 12:54:13 | sean-k-mooney | aspiers: you can only have kvm and zen on the same host if you run two agents. and are happy to support it entirly yourself because noone else will touch it :) | |
| 12:56:42 | sean-k-mooney | kashyap: if you did not restat the agent i think we would pick you the capablity changes via the periodic task but ya it would be an ill defined state untill that happened | |
| 12:57:08 | kashyap | Right | |
| 13:03:16 | mriedem | melwitt: about 5am i was thinking about quota and rebuild from cell0 - thoughts are in the spec https://review.opendev.org/#/c/648686/2/specs/train/approved/enable-rebuild-for-instances-in-cell0.rst@96 if you can check my thinking | |
| 13:03:49 | mriedem | tssurya: is your locked_reason stuff ready for review? if so, can you queue it up for runways? | |
| 13:04:58 | gibi | mriedem: what will happen if we run the migration, run archive, run migration, run archive again. Does that second archive fail to move the marker instance due to a unique constraint on the uuid field in the shadow table? | |
| 13:05:40 | openstackgerrit | Nikolay Fedotov proposed openstack/nova master: Fix disappearing ironic hypervisors after rebuilding hashring https://review.opendev.org/654584 | |
| 13:07:28 | gibi | mriedem: never mind, we dont add the unique constraint to the shadow tables | |
| 13:07:43 | gibi | mriedem: series starting at https://review.opendev.org/#/c/653098/ looks good to me | |
| 13:07:44 | mriedem | right | |
| 13:08:42 | mriedem | thinking about your migration + archive thing, i don't think we archive the deleted marker instance because of the fkey relationship to the vif | |
| 13:09:58 | mriedem | i also don't think we ever delete the marker vif even if we don't need to migrate any more records, | |
| 13:10:25 | mriedem | so eventually when we remove that online data migration, we'll likely also need to delete the marker vif so archiving can remove it and we can remove the hack in the api | |
| 13:13:05 | gibi | mriedem: hm, then I don't get how your functional test passes at https://review.opendev.org/#/c/653098/2/nova/tests/functional/regressions/test_bug_1825034.py@77 | |
| 13:13:35 | gibi | mriedem: or we delete the marker instance but no the marker vif? | |
| 13:13:49 | mriedem | correct | |
| 13:14:03 | mriedem | the instance record is soft deleted but the marker vif is not | |
| 13:14:19 | mriedem | efried: i reckon anything going into a runway slot today will get an extra week because of the summit yeah? | |
| 13:14:49 | gibi | mriedem: I see | |
| 13:15:30 | mriedem | melwitt: i removed the counting quotas from placement series out of the runway slot since the time expired but feel free to queue it back up | |
| 13:17:31 | bauzas | mriedem: sorry was on bank holiday yesterday, how can I help with some review ? | |
| 13:17:54 | openstackgerrit | Lucian Petrut proposed openstack/nova master: Expose Hyper-V supported image types https://review.opendev.org/655137 | |
| 13:18:13 | mriedem | bauzas: stein regression series starting here would be good https://review.opendev.org/#/c/653268/ | |
| 13:18:30 | mriedem | bauzas: and i need review on this queens backport https://review.opendev.org/#/c/640198/ | |
| 13:18:47 | mriedem | we're very close to closing out pike | |