Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-20
15:34:17 mriedem or is that not really an option?
15:34:23 lbragstad in that case, we have to add a little extra to the check string for each policy (only until we can assume the migration is over and we've communicated things to operators)
15:34:34 lbragstad "role:reader and system_scope:all" would solve that
15:34:43 lbragstad without having enforce_scope=True
15:35:04 mriedem do you envision we'd have two policy files for awhile, the existing one for backward compat, and a "this is the new fancy stuff which is here to use if you want, but it's experimental for now" kind of thing?
15:35:35 lbragstad i wouldn't recommend that approach - we tried that in keystone a long time ago and it didn't turn out too well imo
15:36:17 lbragstad instead, i would evolve the existing policies to account for those cases, like check_str="(role:reader and system_scope:all) or rule:admin_or_owner"
15:36:19 mriedem ok i don't have a good grasp on what the proposed migration looks like
15:36:39 mriedem i'm assuming the recommendation is to start migrating piece meal
15:36:59 lbragstad that's how we're doing it in keystone, yeah
15:37:21 mriedem i'm also assuming there is a summit video somewhere about the migration process?
15:37:39 lbragstad we're going to resource individually, adding a whole bunch of protection tests so we catch regressions, and then adjusting the policies accordingly
15:37:46 lbragstad going through*
15:38:20 lbragstad there have been forum sessions on the migration approach in the past, but nothing has been recorded afaik
15:40:02 mriedem ok, that could also be done with a recorded youtube session like these old ones that sdague used to organize https://wiki.openstack.org/wiki/BootstrappingHour
15:40:08 mriedem i wish we'd start doing more of those again
15:40:25 lbragstad i have done something similar for this work in the past, but not the migration
15:42:16 openstackgerrit Dan Smith proposed openstack/nova-specs master: Add request-filter-image-types spec https://review.openstack.org/644625
16:08:48 bauzas mriedem: efried_rolling: FWIW, I left https://review.openstack.org/#/c/644412/5 waiting for other reviews, we could just +W it tonight EOB if you want
16:08:57 bauzas ie. US folks EOB I mean
16:09:19 bauzas that leaves melwitt, dansmith or other West Coast folks to balance if needed
16:09:51 mriedem ack
16:23:47 openstackgerrit Dan Smith proposed openstack/nova-specs master: Add request-filter-image-types spec https://review.openstack.org/644625
16:24:36 gmann lbragstad: mriedem do we really need system_scope=all ? until enforce_scope=false scope_type will not be checked just log warning so operator will have time to consume the scope_type things
16:25:46 gmann I mean as we have configuration variable to enable/disable the scope_type then, we can directly do "role:reader", scope_type: 'system'
16:29:30 kashyap What are the other volume drivers besides: Quobyte, Virtuozzo, SMBFS?
16:30:21 lbragstad gmann i think we do need "role:reader and system_scope:all", especially in the case where we are applying that to things like hypervisors
16:30:37 lbragstad otherwise we could accidentally open the hypervisor API up to anyone with the reader role on anything
16:31:14 lbragstad since the check string would be "role:reader or rule:admin_or_owner" instead of "(role:reader and system_scope:all) or rule:admin_or_owner"
16:47:58 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: Use 'writeback' QEMU cache mode when 'none' is not viable https://review.openstack.org/641981
16:47:59 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: vzstorage: Use 'writeback' QEMU cache mode https://review.openstack.org/643376
16:47:59 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: smbfs: Use 'writeback' QEMU cache mode https://review.openstack.org/643377
16:48:50 kashyap mdbooth: ^ Has the bare-minimum doc update. For the volume drivers text: the 'vzstorage' and 'smbfs' patch should also merge along with the main patch -- for the "doc to tell the truth"
16:49:17 mdbooth kashyap: Thanks
16:49:20 cfriesen kashyap: everything under virt/libvirt/volume?
16:50:49 gmann lbragstad: ok. make sense until enforce_scope is not removed or defaulted to True.
16:51:36 mnaser lbragstad, mriedem: late but better than ever, i tried hacking a little bit on what it would look like and i was also unsure of how an ideal transition path might look like
16:51:50 gmann lbragstad: so in that case requested cred will have to add system_scope=all for such request then only they are auth otherwise not
16:52:17 mnaser i think the concern is bob's openstack deployment who hasn't deleted their policy.json file or is currently overriding a few things that finds themselves exposing a lot of things after an upgrade
16:54:11 lbragstad mnaser how so?
16:54:18 gmann mnaser: any policy rule overridden in policy.json file will keep working as it is because we will add old policy rule as deprecated_rule in new rules. But yes if anyone reply on policy in code default thing then they will see this impact
16:54:26 lbragstad because their overrides are obsolete?
16:55:15 mnaser lbragstad: if someone had role:support to GET hypervisor list, and now we updated it that they need system scope now for that specific policy
16:55:23 mnaser they find themselves with a non functional policy at that point i guess
16:55:59 mnaser yeah i think the concern is that it would break existing policies
16:56:00 lbragstad if they have a special role for listing hypervisors and an override for that policy, then it should still work even if we change the default
16:56:13 gmann yeah
16:59:30 gmann if bob reply on GET hypervisor with default policy which is say "admin" currently, we will change this to say "role:reader and system_scope:all" or something which control it not to expose to non-admin
17:01:49 mnaser lbragstad: if we change the scope to system, wouldn't it stop working then.. because that role is probably project scoped?
17:01:55 mnaser project scoped to the 'admin' tenant
17:02:12 lbragstad roles aren't scoped to projects per se
17:02:45 lbragstad roles can be associated to actors on targets, actors can be groups or users, and targets can be projects, domains, or system
17:03:13 mnaser right, but bob's openstack cloud probably has it targeting projects right now, as 99% of our docs have always said
17:03:26 mnaser "if you want to give a role for X, create a project and add X role to Y user into it"
17:03:41 gmann also scope_type will not be enforced until it is explicitly set True by enforce_scope. enforce_scope default is false as of now.
17:08:46 mnaser but if its not enforced then could that not introduce other eissues?
17:09:45 eandersson Morning
17:09:56 mnaser role:reader and system_scope:system without it enforced means role:reader can get hypervisor list?
17:10:05 eandersson What is the difference from disk_gb and disk_available_least?
17:11:03 lbragstad mnaser that's why we write the policy like "(role:reader and system_scope:all) or role:admin_or_owner"
17:11:08 gmann no, as lbragstad mentioned we will add a special case of scope_type for that what keystone did - role:reader and system_scope:all
17:11:29 mnaser ok so we would have a policy enforcing both .. until we decide to cut it off
17:11:38 gmann true
17:11:39 mnaser so maybe a train could be a transitionary release i guess
17:11:43 mnaser and then we can flip the switch
17:12:10 lbragstad we need to write slightly more complicated policy check_strs to allow for the migration
17:12:18 gmann I suggest to flip in V to give 1 2 cycle of transition phase as this is huger change in policy
17:12:34 mnaser can you enable enforcement of system_scope?
17:12:36 lbragstad then we can offload more to oslo.policy using enforce_scope=True in the future and simplify the check strings
17:12:57 mnaser could a deployer enable it AND put rule:admin_or_owner set to nothing
17:13:05 mnaser and they'd be using 'the new system'
17:13:51 lbragstad yeah... if a deployer wants to opt into the new system, they just have to maintain a policy file with the *new* defaults, which omits the logical OR with oslo.policy migration
17:14:07 lbragstad it's clunky... but...
17:16:52 openstackgerrit Merged openstack/nova master: Add known issue for minimum bandwidth resource leak https://review.openstack.org/644694
17:40:24 NobodyCam Good Morning Nova folks
17:54:00 jaypipes NobodyCam: mornin :)
17:54:08 jaypipes or afternoon.
17:54:31 NobodyCam hey hey jaypipes long time!
17:56:39 eandersson jaypipes, do you happen to know the difference between free_disk_gb and disk_available_least?
17:56:49 eandersson I assume disk_available_least takes images etc into account?
17:57:07 eandersson Trying to figure out why a vm that was destroyed and re-created won't fit into the same compute again.
17:57:25 eandersson free_disk_gb is large enough to accommodate the vm
17:58:47 eandersson also, manually creating the vm on that compute worked (free_disk_gb is now 4, and disk_available_least is -33)
17:59:27 sean-k-mooney eandersson: disk_available_lest will sometime be the same but it can be wildly different depending on your storage backend
18:00:00 eandersson so this is probably due to the rocky upgrade
18:00:45 eandersson we don't use a specified storage backend
18:00:49 eandersson so what ever is default
18:01:10 eandersson brb
18:01:45 sean-k-mooney eandersson: google could me this https://gist.github.com/JCallicoat/43505cab0535057ca4fb
18:02:14 sean-k-mooney i wonder if we have that comment in our code
18:02:33 NobodyCam so dumb question, when creating new project / user it's just the _member_ role that is required to launch instances?
18:02:55 sean-k-mooney NobodyCam: by defualt yes
18:03:11 NobodyCam :)
18:03:21 sean-k-mooney although you have to also have a default quota of instnaces greater then 0
18:07:32 sean-k-mooney eandersson: what i ment by storage spefic backedn is it gets a little broken when using shared storage e.g. nfs or rbd
18:08:55 sean-k-mooney eandersson: if free_gb is positive and disk_available_lest is negitive it means your worst case over commited for the instance that are shduled to the host exceed that allowed by your over commit raitio
18:10:12 klindgren Question re: live migration + configdrive + iso9960. Instead of scping the file between HV's. Can why can't we just recreate the config drive on the destination host?
18:10:48 sean-k-mooney klindgren: i belive there was a libvirt bug that prevented
18:10:52 sean-k-mooney klindgren: but we could
18:10:54 klindgren Are files that re passed in via the a boot command, not started as part of the vm data? So the config drive would be incomplete?

Earlier   Later