| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-27 | |||
| 15:55:29 | zigo | lbragstad: Thanks, I'll read it all. | |
| 15:56:05 | dansmith | lbragstad: yeah I read that and I get it, | |
| 15:56:15 | dansmith | I thought there would still be a change to the user mechanics though | |
| 15:56:28 | dansmith | but likely because most of our discussions focus on our usage, which is generally admin | |
| 15:57:07 | lbragstad | dansmith unfortunately, because policy is completely configuration based, there could be deployments where this gets messy because the deployer wanted to let end users list hypervisors (or something weird like that) | |
| 15:58:06 | dansmith | yeah, so those users will need to learn something different now right? | |
| 15:58:23 | dansmith | does that mean they've lost (or will lose) the ability to list hypervisors and their instances with a single token? | |
| 15:58:59 | lbragstad | possibly - but it depends on how the deployer setup their custom policy | |
| 15:59:04 | dansmith | because I can imagine that sucking for scripts | |
| 15:59:13 | lbragstad | yeah - i completely agree | |
| 15:59:25 | gmann | yeah if both policy are override for same permission then they keep working | |
| 16:00:03 | gmann | if mix like one override and one was relying on default, now re-generated file will mesh up the single token | |
| 16:02:16 | lbragstad | zigo i typically put system users behind a different cloud profile, so i set system_scope: all in my clouds.yaml under a different name | |
| 16:02:50 | lbragstad | then i use --os-cloud system-admin or --os-cloud project-user (or whatever) | |
| 16:03:26 | lbragstad | ymmv - but if found that useful in the past when managing different scopes | |
| 16:03:32 | lbragstad | i found* | |
| 16:03:58 | dansmith | problem is, kinda, that we're enforcing our view on what is system-level information now in a way that they can't override | |
| 16:04:16 | dansmith | for single-tenant clouds, that just introduces unnecessary overhead for a distinction they don't care about | |
| 16:08:55 | gmann | when we enable scope by default at some point they anyways have to change their tokens. | |
| 16:09:30 | lbragstad | dansmith yeah - that's true | |
| 16:09:41 | dansmith | what I mean is, the scope-based system introduces complexity | |
| 16:09:43 | gmann | for single-tenant clouds, it might be weird | |
| 16:12:57 | zigo | GOT MY FIRST INSTANCE ON USSURI UP AND RUNNING !!! \o/ | |
| 16:13:09 | gibi | back | |
| 16:13:16 | gmann | anyways 're-generate fresh policy file' case for me is 'they want the new default-only always' and if old things stop working that need audit carefully from release notes or warnings. | |
| 16:13:19 | lbragstad | they'll need to be aware of the context they're operating on | |
| 16:14:50 | gibi | gmann, dansmith: do I understand correctly that we need at least a release notes update to document what zigo has found? What else we need to / can do in Ussuri? | |
| 16:14:53 | gmann | like uncap 'hacking' version in our requirement file which mean 'we will adopt the new changes always and if broken we fix our code' | |
| 16:15:39 | sean-k-mooney | gmann: well hacking is used by multiple project but not all projects will want to use the same checks | |
| 16:16:05 | sean-k-mooney | nova and neuton have completely different approchs to self.assert* methods | |
| 16:16:13 | gmann | sean-k-mooney: true, that is why many projects cap it | |
| 16:16:27 | sean-k-mooney | neutron blocked the use of any not in py27 and nova used mock the lib | |
| 16:18:03 | gmann | gibi: dansmith lbragstad in addition to release note for nova ussuri, should we have a clear doc from oslo/keystone or somewhere generic on 'how to generate and use policy file and how deployer can be broken for xyz cases'. i mean a single recommended way instead of supporting all possible way deployment doing ? | |
| 16:19:15 | sean-k-mooney | gmann: well that would be in oslo.policy correct | |
| 16:19:22 | sean-k-mooney | or rather should be | |
| 16:19:41 | sean-k-mooney | e.g. discribing how the lib should be used by developers | |
| 16:20:13 | gmann | I am not sure, we have. but lbragstad or bnemec can point to if there is any. | |
| 16:21:09 | gmann | i meant explicitly saying, 'this way of re-genrating policy file or having not-override rule in policy file etc etc can break you if you do not carefully audit on upgrades' | |
| 16:27:47 | openstackgerrit | Takashi Natsume proposed openstack/nova master: Fix list rendering in the accelerator support doc https://review.opendev.org/721846 | |
| 16:28:00 | lbragstad | gmann we have this | |
| 16:28:02 | lbragstad | https://bugs.launchpad.net/oslo.policy/+bug/1853170 | |
| 16:28:02 | openstack | Launchpad bug 1853170 in oslo.policy "Need documentation on recommended operator workflow for deprecated policies" [High,Triaged] | |
| 16:28:02 | openstackgerrit | Takashi Natsume proposed openstack/nova master: Update contributor guide for Victoria https://review.opendev.org/722647 | |
| 16:30:05 | lbragstad | gmann i don't think there is anything in review for that, yes | |
| 16:30:07 | lbragstad | yet* | |
| 16:32:06 | gmann | lbragstad: i see, thanks | |
| 16:32:33 | stephenfin | melwitt: confident enough to bump your +1 to +2 now? https://review.opendev.org/#/c/720725/ | |
| 16:35:47 | gibi | gmann: I have to stop for today. If you start writing a reno update for the policy thing then please link it to me and I will read it first thing in the morning | |
| 16:37:16 | gmann | gibi: ok, I will update the upgrade section for now to mention the re-generated policy file case. and later we can work on some generic doc (bug/1853170). | |
| 16:37:44 | gibi | gmann: ack, thanks | |
| 17:43:53 | sean-k-mooney | stephenfin: can you take a look at https://review.opendev.org/#/c/722407/ | |
| 17:44:02 | sean-k-mooney | stephenfin: it needt to merge before your change can merge | |
| 17:48:58 | AJaeger | any nova core available for two tiny cleanups related to Babel/translations, please? https://review.opendev.org/#/c/723206/2 and https://review.opendev.org/#/c/720725/1 ? | |
| 18:01:28 | openstackgerrit | Merged openstack/python-novaclient master: Use unittest.mock instead of third party mock https://review.opendev.org/723152 | |
| 18:19:56 | openstackgerrit | Merged openstack/nova master: Add placeholder migrations for Ussuri backports https://review.opendev.org/722546 | |
| 18:51:11 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Clarify the policy new defaults upgrade notes https://review.opendev.org/723645 | |
| 18:51:41 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Clarify the policy new defaults upgrade notes https://review.opendev.org/723645 | |
| 19:59:04 | openstackgerrit | Merged openstack/nova master: Fix list rendering in the accelerator support doc https://review.opendev.org/721846 | |
| 20:47:46 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Clarify the policy new defaults upgrade notes https://review.opendev.org/723645 | |
| 20:50:05 | gmann | dansmith: gibi stephenfin please check, i have added this upgrade notes for clarification on policy file things - https://review.opendev.org/#/c/723645/ | |
| 21:09:20 | melwitt | gmann: do we have people ready to review https://review.opendev.org/722551 ? wondering if I should wait on reviewing the nova change | |
| 21:10:31 | gmann | melwitt: i pinged few tempest core,may be we can get +A from masayukig once he wake up. | |
| 21:11:33 | melwitt | ok | |
| 21:12:50 | openstackgerrit | Artom Lifshitz proposed openstack/nova stable/queens: DNM: Partial cherry-pick of assertRequestMatchesUsage() https://review.opendev.org/723694 | |
| 21:12:51 | openstackgerrit | Artom Lifshitz proposed openstack/nova stable/queens: DNM: Partial cherry-pick of _check_allocation_during_evacuate() https://review.opendev.org/723695 | |
| 21:12:51 | openstackgerrit | Artom Lifshitz proposed openstack/nova stable/queens: DNM: Add nova-manage placement heal_allocations CLI https://review.opendev.org/723696 | |
| 21:12:52 | openstackgerrit | Artom Lifshitz proposed openstack/nova stable/queens: DNM: Don't heal allocations for deleted servers https://review.opendev.org/723697 | |
| 21:12:52 | openstackgerrit | Artom Lifshitz proposed openstack/nova stable/queens: DNM: Partial cherry-pick of FakeResponse https://review.opendev.org/723698 | |
| 21:12:53 | openstackgerrit | Artom Lifshitz proposed openstack/nova stable/queens: DNM: Heal allocations with incomplete consumer information https://review.opendev.org/723699 | |
| 21:14:10 | gmann | melwitt: or let's wait for these patches first to have ussuri branch setup properly - https://review.opendev.org/#/q/topic:qa-ussuri-release+status:open | |
| 21:14:55 | melwitt | gmann: ah k | |
| 22:48:22 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Clarify the policy new defaults upgrade notes https://review.opendev.org/723645 | |
| 23:14:59 | openstackgerrit | Artom Lifshitz proposed openstack/nova stable/queens: DNM: Partial cherry-pick of report client changes https://review.opendev.org/723750 | |
| 23:14:59 | openstackgerrit | Artom Lifshitz proposed openstack/nova stable/queens: DNM: Add a placement audit command https://review.opendev.org/723751 | |
| #openstack-nova - 2020-04-28 | |||
| 00:58:51 | songwenping_ | Hi, gibi. | |
| 01:00:01 | songwenping_ | i have a issue with filter_scheduler with accelerators. pls see the detail at https://etherpad.opendev.org/p/filter_scheduler_issue_with_accelerators | |
| 01:01:05 | songwenping_ | the relate fix patch is https://review.opendev.org/#/c/722651/ | |
| 01:02:33 | songwenping_ | the relate bug reported is https://bugs.launchpad.net/nova/+bug/1874664. pls help me have a look. | |
| 01:02:33 | openstack | Launchpad bug 1874664 in OpenStack Compute (nova) "Boot more than one instances failed with accelerators in its flavor" [Medium,Confirmed] - Assigned to Wenping Song (wenping1) | |
| 05:02:08 | openstackgerrit | Arthur Dayne proposed openstack/nova-specs master: new a test https://review.opendev.org/723794 | |
| 07:02:45 | gibi | good morning | |
| 07:02:57 | gibi | songwenping__: ack, I will look at it shortly | |
| 07:03:40 | songwenping__ | thanks, gibi. | |
| 07:11:16 | bauzas | good morning Nova | |
| 07:13:26 | aarents | good morning | |
| 07:14:59 | bauzas | fwiw, I'm a bit on and off this week due to children vacations at home | |
| 07:15:15 | bauzas | fortunately, it's after RC1 :) | |
| 07:18:26 | gibi | bauzas: a quick question. If we have a bug in the cyborg integration code https://bugs.launchpad.net/nova/+bug/1874664 and that code was added in Ussuri then Am I correct that such bug is an RC2 candidate? | |
| 07:18:26 | openstack | Launchpad bug 1874664 in OpenStack Compute (nova) "Boot more than one instances failed with accelerators in its flavor" [Medium,Confirmed] - Assigned to Wenping Song (wenping1) | |
| 07:19:48 | bauzas | gibi: MHO is that I don't think it's an urgent regression | |
| 07:20:05 | bauzas | gibi: given we weren't supporting Cyborg by Train | |
| 07:20:20 | gibi | bauzas: so it is a regression but it targets a small portion of a user base and it definetly does not break upgrade | |
| 07:20:48 | bauzas | gibi: do we have already a fix ? | |
| 07:20:57 | gibi | bauzas: there is a patch https://review.opendev.org/#/c/722651/ | |
| 07:21:05 | gibi | but I haven't looked it yet how complex it is | |
| 07:21:26 | bauzas | gibi: if not, we could just ask brinzhang to modify the documentation to say that Nova won't support more than one instance for Cyborg in Ussuri | |
| 07:21:49 | bauzas | and then we could backport the fix to a Ussuri later .z | |
| 07:21:56 | gibi | bauzas: good point. if the fix is problematic in RC timeframe then we can do a documentation patch | |
| 07:22:27 | gibi | bauzas: thanks for the consultation | |
| 07:23:22 | bauzas | gibi: anyway, it's just my opinion | |