Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-20
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?
18:11:53 sean-k-mooney klindgren: i think that depends. i think we store user-data in the db in the instance extra table
18:12:13 klindgren Yea, we changed the code (we have a new enough libvirt) on the scp to look for iso9961 vs iso9960. And the migration works, it just creates a sparsely populated file with no data in it on the dst.
18:12:20 sean-k-mooney klindgren: what files are you spscically refering to
18:13:11 klindgren Nova boot --file /seomdest=blah --file /anotherdest=asdf
18:13:27 klindgren Which gets put in to config drive under content/000, content/0001
18:14:17 sean-k-mooney klindgren: ya so openstack server create --user-data < my data> is stored in the db i dont think we store teh contets of files passed with --file
18:14:18 NobodyCam another dumb question: is there a trick to allowing the admin to launch service instances: I'm seeing Policy check for os_compute_api:os-hide-server-addresses failed with credentials <blah> when attempting to launch Octavia instances
18:20:31 sean-k-mooney NobodyCam: am the amdin account i think need but admin and _member_ roles
18:20:43 sean-k-mooney but the admin account still had a quota
18:21:14 sean-k-mooney in the case of octavir the octavia service account allso has a quota typeiclay it will be set to -1 to have no limit however
18:30:47 openstackgerrit Merged openstack/nova master: docs: Misc cleanups https://review.openstack.org/644616
18:32:21 mriedem klindgren: correct personality files (file injection) are not stored in the db so if they are only in the config drive and you rebuild the config drive on the dest, those will be gone

Earlier   Later