| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-08-20 | |||
| 12:46:36 | openstackgerrit | Adam Spiers proposed openstack/nova master: Track libvirt host/domain capabilities for multiple machine types https://review.opendev.org/673151 | |
| 12:50:41 | openstackgerrit | Adam Spiers proposed openstack/nova master: Extract new base class for provider usage functional tests https://review.opendev.org/676964 | |
| 12:50:41 | openstackgerrit | Adam Spiers proposed openstack/nova master: Provide HW_CPU_X86_AMD_SEV trait when SEV is supported https://review.opendev.org/638680 | |
| 12:51:33 | openstackgerrit | Alexandra Settle proposed openstack/nova stable/rocky: Fixing broken links https://review.opendev.org/677460 | |
| 12:53:31 | alex_xu | aspiers: the line 697-701 of https://review.opendev.org/#/c/673151/11/nova/virt/libvirt/host.py is about the why we need that set of machine type? | |
| 12:54:10 | aspiers | alex_xu: We need to cover the main variants | |
| 12:54:39 | alex_xu | aspiers: ok, so the pc and q35 can cover all the cases, right? | |
| 12:54:43 | aspiers | yes | |
| 12:55:03 | aspiers | this is mentioned in the commit message | |
| 12:55:06 | alex_xu | aspiers: thanks, i see now | |
| 12:55:15 | alex_xu | aspiers: is it too arch specific? | |
| 12:55:31 | alex_xu | although I didn't see other arch need this method | |
| 12:55:32 | aspiers | pc / q35 are not hardcoded | |
| 12:56:18 | aspiers | alex_xu: they come from utils.get_default_machine_type() and libvirt's getCapabilities | |
| 12:56:28 | alex_xu | I mean in other arch, it is also about default and canonical covering all the cases | |
| 12:56:30 | aspiers | so other architectures will get a different set | |
| 12:56:36 | aspiers | yes, correct | |
| 12:57:03 | alex_xu | ok, I'm just going to trust the libvirt and platform experts | |
| 12:57:34 | aspiers | that's why I had to remove 'bamboo' from the fixture | |
| 12:58:15 | sean-k-mooney | bamboo as a fake arch or machine type :) | |
| 12:58:27 | alex_xu | hah | |
| 12:58:29 | aspiers | because the static fixtures for getDomainCapabilities on ppc did not return correct values for bamboo | |
| 12:58:30 | sean-k-mooney | i can see both working | |
| 12:58:44 | aspiers | bamboo is a real machine type for ppc | |
| 12:58:50 | sean-k-mooney | really ok | |
| 12:59:02 | sean-k-mooney | but ya its not in the static data we are using right | |
| 12:59:03 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Update api-ref for 2.75 to add config_drive in server update response https://review.opendev.org/677324 | |
| 12:59:03 | alex_xu | aspiers: so the only complain is no unittest for host.py change, but I'm ok with a followup. | |
| 12:59:04 | aspiers | https://review.opendev.org/#/c/673151/13/nova/tests/unit/virt/libvirt/fakelibvirt.py@1673 | |
| 13:01:20 | openstackgerrit | Mohammed Naser proposed openstack/nova master: requirements: move to using psycopg2-binary https://review.opendev.org/676684 | |
| 13:01:49 | openstackgerrit | Mohammed Naser proposed openstack/nova master: requirements: move to using psycopg2-binary https://review.opendev.org/676684 | |
| 13:02:52 | aspiers | alex_xu: hmm that's a good point | |
| 13:08:18 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient master: Microversion 2.75 - Multiple API cleanup changes https://review.opendev.org/676275 | |
| 13:10:16 | mriedem | final 2 patches for 2.75 https://review.opendev.org/#/q/topic:bp/api-consistency-cleanup+status:open | |
| 13:11:12 | alex_xu | aspiers: the spec said the trait "a) it cannot be used yet, only in the future when SEV support is fully implemented,"...that confuse me | |
| 13:11:30 | alex_xu | is there any update for the exist spec, we need that trait again? | |
| 13:12:29 | sean-k-mooney | alex_xu: we will need that trait only when intels mktme feature is supported | |
| 13:12:47 | aspiers | right | |
| 13:13:26 | sean-k-mooney | need is also a strong word there in that it is only needed if you specifica want SEV | |
| 13:13:52 | sean-k-mooney | if you jsut want encyrpetd memory you use the resouce class on its own | |
| 13:13:57 | alex_xu | sean-k-mooney: they share same resource class? | |
| 13:14:10 | aspiers | MKTME is not implemented yet | |
| 13:14:15 | aspiers | but we expect it to use the same resource class | |
| 13:14:21 | alex_xu | ok, i see now | |
| 13:14:32 | aspiers | the MKTME spec is still in draft | |
| 13:14:52 | alex_xu | yea, I didn't follow that spec | |
| 13:15:00 | aspiers | but the resource class is not used directly by users/operators, only internally | |
| 13:15:03 | alex_xu | but I "should" | |
| 13:15:17 | aspiers | externally they use hw:mem_encryption extra spec and hw_mem_encryption image property | |
| 13:15:40 | aspiers | and that gets translated in the RequestSpec to resources:MEM_ENCRYPTION_CONTEXT=1 | |
| 13:15:54 | sean-k-mooney | given that one is an intel only tech and the other is an amd only tech we do not expec a singel RP to have inventoies fo both so 1 resouce class and 2 traits for what is effectvly the same thing form a guest point of view | |
| 13:16:08 | aspiers | right | |
| 13:16:38 | alex_xu | got it | |
| 13:17:54 | openstackgerrit | Adam Spiers proposed openstack/nova master: Add extra spec parameter and image property for memory encryption https://review.opendev.org/664420 | |
| 13:18:33 | sean-k-mooney | by the way these keystone auth issues "keystoneauth1.exceptions.auth_plugins.MissingAuthPlugin: An auth plugin is required to determine endpoint URL" if i rebase my patch these should go away right | |
| 13:21:09 | sean-k-mooney | they are unrelated to my code in anycase so ill assume its as a result of keystone/sdk changes | |
| 13:22:25 | sean-k-mooney | aspiers: by the way https://review.opendev.org/#/c/666914/7..8/nova/tests/unit/test_utils.py resolved my python 3.7 failure just in case you hit similar issues. | |
| 13:23:04 | sean-k-mooney | mock.patch.dict works slightly different then some of the other patch function so you might not have issues | |
| 13:23:05 | aspiers | sean-k-mooney: nice, thanks. | |
| 13:23:21 | aspiers | this should work for my patch_{open,exists} too | |
| 13:24:29 | sean-k-mooney | yep i commented on that | |
| 13:24:36 | sean-k-mooney | on the older revision | |
| 13:32:56 | aspiers | saw that, thanks | |
| 13:38:37 | openstackgerrit | sean mooney proposed openstack/nova master: Libvirt: report storage bus traits https://review.opendev.org/666914 | |
| 13:38:38 | openstackgerrit | sean mooney proposed openstack/nova master: libvirt: use domain capablites to get supported device models https://review.opendev.org/666915 | |
| 13:39:41 | sean-k-mooney | ill be rebasing ^ after i update the last patch in the series | |
| 13:51:21 | openstackgerrit | Alexandra Settle proposed openstack/nova stable/rocky: [stable-only] Fixing broken links https://review.opendev.org/677460 | |
| 13:54:07 | alex_xu | sean-k-mooney: efried mriedem https://etherpad.openstack.org/p/vpmems-non-virt-driver-specific | |
| 13:54:25 | alex_xu | ^ I'm wating for Luyao ensure her code, but that is the basic idea | |
| 13:55:06 | efried | alex_xu: Whereas it would be nice to be able to do without data model changes, I think this makes sense and makes a number of things much simpler. | |
| 13:55:35 | alex_xu | efried: \o/ | |
| 13:56:35 | mnaser | https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#scheduling-considerations | |
| 13:57:04 | mnaser | is the note a bit contradicting, if i understand correctly, setting aggregate allocation ratios doesnt work in the scheduler anymore? | |
| 13:57:19 | mnaser | so AggregateCoreFilter is technically useless? | |
| 13:57:24 | mriedem | https://review.opendev.org/#/c/673496/ | |
| 13:57:38 | mnaser | ok | |
| 13:57:39 | mnaser | makes sense now | |
| 13:58:09 | mriedem | maybe "The AggregateCoreFilter, AggregateDiskFilter and AggregateRamFilter filters allow overriding per-compute allocation ratios by setting an allocation ratio value using host aggregate metadata. This provides a convenient way to manage a group of compute hosts with similar allocation ratios while leaving the configuration settings alone." should just be removed | |
| 13:58:29 | mnaser | yeah it seems to tell you "this is how to solve this problem. note, it doesn't work" | |
| 13:58:31 | mriedem | because it's essentially saying, "before ocata, ^ was true, but since ocata it's not" | |
| 13:58:46 | mnaser | so for a stein cloud, i can just update the placement service aggregate then? | |
| 13:59:11 | mriedem | you have to set the allocation ratio on each provider in the placement aggregate | |
| 13:59:24 | mriedem | mel has a convenience cli patch for doing this, sec | |
| 13:59:34 | mriedem | https://review.opendev.org/#/c/640898/ | |
| 13:59:52 | mriedem | so since pike your compute host aggregates and provider aggregates should be automatically mirrored, | |
| 14:00:10 | mriedem | the thing that isn't is the compute host aggregate allocation ratio metadata, since placement resource provider aggregates don't have metadata | |
| 14:00:11 | mnaser | oh neat, and technically i shouldn't worry about nova re-overriding it because it only adds it when the rp is first registered, right? | |
| 14:00:37 | mriedem | if you change the allocation ratio config on a nova-compute it would be updated in placement | |
| 14:00:50 | mriedem | that's where https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#usage-scenarios comes in | |
| 14:00:53 | mnaser | oh i thought we now had initial_foo | |
| 14:01:01 | mriedem | b/c some people (cern) want to manage allocation ratios in config always, | |
| 14:01:13 | mriedem | and others (mgagne) want to manage allocation ratios in an API always | |
| 14:01:29 | mriedem | config trumps api | |
| 14:01:33 | mnaser | hmm okay, so either stick to initial_foo and leave others empty or foo | |
| 14:01:33 | mriedem | if config is set | |
| 14:01:40 | mriedem | yes | |
| 14:01:42 | mnaser | yeah makes sense, i think ill stick to config for now | |
| 14:02:01 | mriedem | you just described scenario 2 | |
| 14:06:40 | mriedem | ok i see how the note got mixed in and is confusing, will push a patch to clean that up | |
| 14:07:05 | cfriesen | stephenfin: aspiers: we don't care about postgres anymore. :) | |