Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-04-28
15:08:08 dansmith if it was something we really had to do, then I'd be for this approach, let the DB server do the hard bit, but...
15:08:33 dansmith the other thing about this, is for instances created since like 2018, this is just pain for no reason
15:08:41 dansmith or whenever we moved to the new format
15:08:54 dansmith this is really just looking for super ancient instances that have been nursed for a long time,
15:09:00 dansmith which definitely puts it into perspective for me
15:09:12 stephenfin 2014
15:09:17 dansmith hah
15:12:27 artom stephenfin, your call I guess - looks like update on read might be a more acceptable solution, though with it we'd never be 100% sure we got all of those ancient instances
15:12:39 stephenfin And this isn't OCD. I've to maintain the hardware.py module and uglier corners of libvirt driver code, and I'm continuously trying to burn down tech debt inflicted upon me by others to make that job easier
15:13:39 openstackgerrit Merged openstack/nova master: Imported Translations from Zanata https://review.opendev.org/722644
15:14:12 stephenfin artom: personally, I was for deleting all the compat code to handle instances that hadn't been _touched_ since 2014, but dansmith said that wasn't good enough so I did this
15:14:23 stephenfin and have been working on it for two years
15:14:41 artom stephenfin, sorry dude, didn't mean to sabotage it :(
15:14:57 artom But it would have been dishonest to silence my concern
15:15:37 artom belmoreira, around? We're having a DB performance discussion, and figured CERN's scale might shed some light
15:17:21 belmoreira artom I just need to leave now. If you can I will be around tomorrow
15:17:47 artom belmoreira, ok, I'll ping you again earlier tomorrow morning (I'm on EDT)
15:20:27 artom I'm trying to read up on LIKE performance, which I *assume* is what sqlalchemy boils down .contains() to...
15:21:08 dansmith like is a little more expensive than a strstr() I think, although it might collapse to that if mysql notices there are no pattern characters
15:25:01 gibi dansmith, gmann, stephenfin, zigo: OK so I see that the change in the policy generator is not feasible before ussuri GA and might also seemed as a step backward to have that change in V. Then are we suggesting to zigo that his use case is not really valid / supported in Ussuri and in Victoria?
15:25:29 gibi or what is the way forward top of the reno update?
15:26:17 dansmith gibi: no, I think zigo's case is very valid, and common
15:26:55 dansmith gibi: I think we've screwed up here, and I think all I've said is that I don't think we have a lot of good options
15:27:45 gmann but should we consider the "new policy file generated without deprecated rules to switch to new defaults" are not valid ?
15:28:18 gmann because in both cases, policy file can be used that way
15:28:19 gibi dansmith: thanks. I feel that we have no good options
15:28:27 dansmith indeed :/
15:29:19 gibi gmann: do you mean that use the new generated file and configure nova and keystone with scopes?
15:29:36 gibi gmann: I think that is a valid use case
15:29:43 dansmith we can't do that in the upgrade I think
15:29:55 dansmith because people with non-scoped current policy files will break
15:30:04 gmann yes. and in past also if we deprecate any policy rule and operator want to move to new defalt, policy overwrite is the option they had
15:30:06 gibi dansmith: true, not for the upgrade, but for the new deployments
15:30:23 dansmith gibi: only distros have the ability to do something different for upgrade vs. new I think
15:30:33 dansmith gibi: we the nova project have to assume upgrade
15:30:40 gmann yeah
15:30:59 dansmith I think what we can do is set up for the most default case, which is where we are now, and accept that the case where you're using the generation tool is going to break
15:31:12 dansmith it's likely common, but less common than all the other cases I think
15:32:05 dansmith accept, and document/warn about the potential problem I mean
15:32:29 openstackgerrit Merged openstack/nova stable/ussuri: Imported Translations from Zanata https://review.opendev.org/723160
15:32:34 gibi OK, I see. thanks. I will summarize it in the bug
15:32:42 gmann dansmith: i agree it might be common to re-generate policy file and end up no deprecated rule but is not that wrong usage ? and some point we have to tell them its not right one
15:33:26 dansmith gmann: no, I don't think it's wrong.. it's not what we want people to do, but what we want them to do isn't very convenient or user-friendly, which is why I think it's likely common
15:33:48 dansmith gibi: also the other action item is to switch to yaml policy by default going forward I think, and encourage people to move to that
15:33:51 gmann and it is like it was not reported before when few policy default were changed. i am not sure if new default were superset of old so that same problem would occur
15:34:22 gmann dansmith: +1 on switch yaml.
15:34:30 gmann and this bug - https://bugs.launchpad.net/oslo.policy/+bug/1853170
15:34:30 openstack Launchpad bug 1853170 in oslo.policy "Need documentation on recommended operator workflow for deprecated policies" [High,Triaged]
15:34:30 gibi dansmith: good point about yaml, adding that to the PTG etherpad
15:34:30 dansmith gmann: this we can all agree on :P
15:34:50 gmann we need some consistent usage guide also
15:35:10 gmann gibi: its there, in cross project section
15:35:24 gibi gmann: even the yaml usage?
15:36:08 gmann gibi: ah i thought it is written in description but i missed. please add
15:36:29 gibi done :)
15:36:34 gmann thanks
15:38:21 gmann dansmith: gibi new flag aded in ussuri (https://bugs.launchpad.net/nova/+bug/1875418) to switch to new default instead of overwriting the policy file can improve the usage at some extend.
15:38:21 openstack Launchpad bug 1875418 in OpenStack Compute (nova) "Generated policy.json in Ussuri is broken by default" [High,In progress] - Assigned to Ghanshyam Mann (ghanshyammann)
15:38:35 gmann sorry, this flag - 'oslo_policy.enforce_new_defaults'
15:39:22 dansmith gmann: this is separate from the full switch to only scoped policies right
15:39:23 dansmith ?
15:39:31 gmann dansmith: yes.
15:39:47 dansmith so, I think maybe we should just go ahead and shut the door in V on using the old stuff
15:40:12 dansmith because this is now a failure on the upgrade "policy" we should just hard pivot over to the new stuff in V,
15:40:21 dansmith apologize for the short notice, and move on
15:40:41 dansmith and maybe our U renos need to state that.. "might as well go ahead and convert in U to avoid this again in V"
15:41:10 bauzas gibi: others: procedural question but https://bugs.launchpad.net/nova/+bug/1875418 should have a ussuri-rc-candidate tag or not ?
15:41:10 openstack Launchpad bug 1875418 in OpenStack Compute (nova) "Generated policy.json in Ussuri is broken by default" [High,In progress] - Assigned to Ghanshyam Mann (ghanshyammann)
15:42:13 gmann dansmith: yeah mentioning V upgrade in reno is good idea. but removing old stuff in V might be difficult now as we have conveyed the old support till W in few wanrings and original reno
15:42:23 gibi bauzas: as far as I see we will keep the bug open after Ussuri so it should not be tagged
15:42:34 dansmith gmann: we still have time to correct those warnings though right?
15:43:45 gmann dansmith: humm, we can do and bakport. but i am thinking if that is too early for people not re-generating the file. i mean they need to adopt new scope token which is very new things.
15:43:48 gibi I've updated the policy bug with the current agreement above. I have to leave for today, will read back tomorrow
15:43:52 bauzas honestly, this bug scares me
15:44:24 bauzas couldn't we just tell that we won't support new policies until V ?
15:44:27 dansmith gmann: well, it just feels like extending this any longer than necessary is worse than concentrating al the pain
15:44:38 dansmith bauzas: we've already broken a set of users though,
15:44:44 bauzas chances are that operators wouldn't read relnotes
15:44:50 bauzas dansmith: :(
15:45:01 dansmith so I was going to say instead of breaking 25% of them now, and then 75% of them later, we should just get it over with
15:45:27 bauzas like, "take a pill, and suffer in silence" ? :)
15:45:35 dansmith or "rip off the bandage"
15:46:06 bauzas I guess we can't obviously make it a pre-upgrade check
15:46:12 gmann or we add the oslo guide on best handle the deprecated rule in file - https://bugs.launchpad.net/oslo.policy/+bug/1853170
15:46:12 openstack Launchpad bug 1853170 in oslo.policy "Need documentation on recommended operator workflow for deprecated policies" [High,Triaged]
15:46:41 bauzas this would require us to write some Train patch and a release
15:47:07 bauzas but this would be nice, they'd get the warnings before upgrading to U
15:47:37 dansmith bauzas: we could definitely do some nova-status guessing, yeah
15:48:06 dansmith bauzas: not a train patch, a U patch.. nova-status from U helps warn about things from T->U
15:48:11 bauzas dansmith: but this would be a pre-Victoria check, right ? (unless we backport to Train the patch itself)
15:48:18 openstackgerrit Merged openstack/nova master: Switch to TOX_CONSTRAINTS_FILE https://review.opendev.org/722814
15:48:25 openstackgerrit Merged openstack/nova master: Test multi create with vGPUs https://review.opendev.org/723858
15:48:25 bauzas mmmm, amiwrong ?
15:48:27 dansmith bauzas: depends on which bit you're talking about warning for
15:48:33 openstackgerrit Merged openstack/nova master: Update contributor guide for Victoria https://review.opendev.org/722647
15:48:41 dansmith bauzas: the stuff we're breaking in U would be a nova-status U patch to warn the T people
15:49:02 bauzas this would require a U install somewhere but okay
15:49:13 dansmith that's the way nova-status works
15:49:21 bauzas I'm then confused
15:49:29 bauzas then, it's all good

Earlier   Later