Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-04-27
15:53:01 lbragstad yes - for the most part
15:53:36 dansmith okay that wasn't clear to me before, so that's good news
15:53:44 dansmith zigo: I guess you were using an admin user?
15:54:07 zigo dansmith: not only myself, but puppet-openstack too, yeah !
15:54:09 openstackgerrit Merged openstack/nova stable/ussuri: Update .gitreview for stable/ussuri https://review.opendev.org/722518
15:54:15 openstackgerrit Merged openstack/nova stable/ussuri: Update TOX_CONSTRAINTS_FILE for stable/ussuri https://review.opendev.org/722520
15:54:38 zigo dansmith: What first started breaking was puppet-octavia that couldn't create the Octavia flavor.
15:54:39 dansmith okay
15:54:54 zigo Then I tried as the admin user, and didn't understand what was going on...
15:55:13 lbragstad fwiw - we describe the concept and motivation behind all the scopes here - https://docs.openstack.org/keystone/latest/contributor/services.html#authorization-scopes
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

Earlier   Later