Earlier  
Posted Nick Remark
#openstack-nova - 2020-06-09
18:07:24 sean-k-mooney there is a bunch of stuff like this https://zuul.opendev.org/t/openstack/build/fe828e4e683841f5a079bb9342c48493/log/controller/logs/screen-n-cpu.txt#34772
18:07:37 sean-k-mooney asking the Image API where its store is
18:07:54 sean-k-mooney then creating snapshot(45941487007e4ecb876ca326b1245c50) on rbd image(c6f91c2a-085f-469e-a5f7-96652d96e9da_disk)
18:10:04 sean-k-mooney i gues this rbd image import is what your looking to see https://zuul.opendev.org/t/openstack/build/fe828e4e683841f5a079bb9342c48493/log/controller/logs/screen-n-cpu.txt#12725
18:11:16 sean-k-mooney in all the other cases it seams to just create a snapshot of the already imported image
18:12:14 sean-k-mooney dansmith: so that shows the its working properly right ^
18:13:04 sean-k-mooney we are now creatinging thin image snapshots on the RBD pool instead of copying the image over and over again
18:32:25 melwitt stephenfin: will do
18:33:32 melwitt elod: would you mind taking a look at these too please https://review.opendev.org/#/q/topic:bug/1550919+status:open
19:09:50 dansmith sean-k-mooney: I just got back. I think I'll need to further tweak it to make sure it uploads to one store and does the copy to the other, unless the default store thing magically made that happen
19:09:52 dansmith will check in a biot
19:35:57 elod melwitt: started to look at them but was a bit distracted, will do tomorrow (my) morning
19:36:25 melwitt thank you :)
19:37:04 elod no problem :]
19:46:53 openstackgerrit Dan Smith proposed openstack/nova master: DNM: Try to make a glance multistore job https://review.opendev.org/734184
22:28:51 openstackgerrit Dan Smith proposed openstack/nova master: DNM: Try to make a glance multistore job https://review.opendev.org/734184
22:29:52 openstackgerrit Dan Smith proposed openstack/nova master: DNM: Try to make a glance multistore job https://review.opendev.org/734184
#openstack-nova - 2020-06-10
00:05:34 openstackgerrit melanie witt proposed openstack/nova stable/ussuri: libvirt: Don't delete disks on shared storage during evacuate https://review.opendev.org/731248
00:44:09 openstackgerrit melanie witt proposed openstack/nova stable/train: libvirt: Don't delete disks on shared storage during evacuate https://review.opendev.org/731273
02:24:53 openstackgerrit melanie witt proposed openstack/nova stable/stein: libvirt: Don't delete disks on shared storage during evacuate https://review.opendev.org/732696
02:40:36 openstackgerrit sunhao proposed openstack/nova master: Add checks for volume status when rebuilding https://review.opendev.org/734734
02:49:28 openstackgerrit melanie witt proposed openstack/nova stable/rocky: libvirt: Don't delete disks on shared storage during evacuate https://review.opendev.org/732708
03:07:50 openstackgerrit melanie witt proposed openstack/nova stable/queens: libvirt: Don't delete disks on shared storage during evacuate https://review.opendev.org/732717
06:41:48 tony_su dansmith: A reviewer of ProviderConfigFile patch wanted to understand why additionProperties is set to true by default in the first place. https://review.opendev.org/#/c/673341/45/nova/compute/provider_config_schemas/provider_config_schema_v1.yaml might require your attention. Thanks.
07:09:45 bauzas good morning Nova
07:20:37 gibi bauzas: good morning
07:21:12 bauzas gibi: morning
07:21:29 bauzas fwiw, just created a blueprint for tracking reshape tooling work for Ussuri https://blueprints.launchpad.net/nova/+spec/offline-reshape-tool
07:22:46 gibi bauzas: cool. Do you agree that we had enough discussion about FFU on the PTG so that I can approve that bp without further discussion on the weekly meeting?
07:23:28 openstackgerrit sunhao proposed openstack/nova master: Add checks for volume status when rebuilding https://review.opendev.org/734734
07:31:04 bauzas gibi: well, I'm torn about it
07:31:28 bauzas gibi: we discussed at the PTG about how to call placement without having the service running
07:31:37 bauzas but i'm not sure we had a consensus
07:32:22 bauzas we have a way to do it that was accepted for the reshape spec in https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/reshape-provider-tree.html#direct-interface-to-placement
07:35:28 gibi bauzas: OK, then let's double check this with the team on the weekly meeting.
07:35:36 bauzas thanks
07:35:49 gibi I will add it to the agenda
07:36:04 bauzas gibi: looking at the spec, looks like we agreed on using PlacementDirect for this
07:36:28 bauzas so if folks agree in the meeting, we can have a specless bp
07:36:36 gibi bauzas: yes, but on the PTG I was tried to mention that fact and get a pushback because that would require DB access from the compute nodes
07:36:58 bauzas gibi: PlacementDirect supports oslo.config
07:37:28 bauzas so you would run the nova-manage command that would call PlacementDirect with DB options
07:37:29 gibi true, but our deployment model does not require db access for compute hosts so far
07:37:53 gibi so the db server might not even accessible from the compute hosts
07:37:59 gibi e.g network separation
07:38:11 bauzas gibi: surely, but that would be something we would comment
07:38:16 bauzas like a caveat
07:38:28 bauzas and it's just for FFUs
07:38:50 gibi OK
07:46:53 gibi let's go with the original plan from the spe
07:46:54 gibi c
08:14:12 sean-k-mooney gibi: bauzas well ingeneral we whould assume the db server is not accesable from the compute yes
08:15:41 sean-k-mooney this is why we discussed the need to potentialy seperate the data collection from the updating of placment or the db
08:16:18 sean-k-mooney e.g. we might need to run something on the compute node to generate some output which is the canges to be done via ssh then do the update from the contoler instead
08:16:38 sean-k-mooney i think johnthetubaguy brought that up or dansmith in the ptg sesssion
08:18:16 sean-k-mooney gibi: and ya its not even a case of our deployment model does not require it it activly discurages direct db acess form the compute on security grounds
08:18:56 sean-k-mooney at least it has sicne we got rid fo the local conducor stuff like 2-3 years ago
08:20:54 bauzas sean-k-mooney: operators can pipe their needs for just a FFU upgrade if they want
08:21:25 sean-k-mooney "pipe there needs" ?
08:22:53 sean-k-mooney by the way look like some people from vmware are fixing the vmware nsx ci
08:24:36 sean-k-mooney http://207.189.188.190/logs/58/734658/1/check-vote/ext-nova-zuul/f8d2e76/tempest_results.html.gz
08:25:57 sean-k-mooney i think it has to be manually triggered via vmware-recheck-patch but i guess that is still an improvement
08:26:16 bauzas sean-k-mooney: I mean, for example, to do something like piping netcat
08:27:49 sean-k-mooney bauzas: they could but i dont think we sould require direct db access
08:28:24 sean-k-mooney making them proxy it via netcat or ssh is a hack IMO
08:28:27 bauzas it's a nova-manage command so we need it anyway :)
08:28:40 bauzas they need to provide DB creds
08:28:57 sean-k-mooney bauzas: so that means nova-manage is not suitable solution to this probelem
08:29:14 bauzas but if you need to run this command on a nova-compute (and then you don't have a specific DB cred for it), then you could just use netcat
08:30:06 bauzas sean-k-mooney: it would work for any operator that doesn't want to have compute nodes be in a specific network
08:30:11 sean-k-mooney i think we should be providing a way to pass in some data structro to the nova-manage command which it uses to then do the reshapes
08:30:33 bauzas sean-k-mooney: we could do it, that's one of the things we said
08:30:41 bauzas hence two commands
08:31:07 bauzas and piping between them (or passing a data structure)
08:31:31 sean-k-mooney yep once command that you run on the compute node that gets the info form the virt driver and produces the reshap yaml or whatever and then a second that you run on a node with db access
08:31:36 bauzas sean-k-mooney: but tbc, https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/reshape-provider-tree.html#direct-interface-to-placement already thought about it
08:32:44 sean-k-mooney bauzas: that was not thinking about reshapes
08:32:49 sean-k-mooney it was thinking about db upgrades
08:32:55 sean-k-mooney those are very different things
08:33:27 sean-k-mooney well it mentions reshpaes but we did not have any at that point
08:34:45 sean-k-mooney actully i guess look ing at the spec in general this is the resahpe spec
08:35:17 sean-k-mooney i think it was making the assumtion however that reshaps did not need compute specific infomation
08:36:43 sean-k-mooney looking at the ironic_flavor_migration examle i dont think that is the same as the libvirt case
08:36:45 sean-k-mooney https://review.opendev.org/#/c/501025/12/nova/cmd/manage.py
08:36:58 sean-k-mooney because the ironic virt dirver talks to the ironic api
08:37:45 sean-k-mooney so the compute serivce virt driver does not need to be colocated on the same host as the hypervior
08:37:59 gibi the spec gives solution for one side of the problem. We don't have a running placement API service during FFU but we need to write into the placement db due to reshape
08:38:14 gibi placement direct allows that.
08:38:27 sean-k-mooney yes it will
08:38:28 gibi sean-k-mooney is right that collecting the data for the reshape is not solved in tha spec
08:39:21 gibi except that it mentions to start up a virt driver, but it does not handle the implication of that statemen
08:39:24 gibi t
08:39:41 sean-k-mooney gibi: https://review.opendev.org/#/c/501025/ is the implemeation for ironic
08:39:52 sean-k-mooney but that is very different then libvirt
08:41:13 sean-k-mooney the ironic virt dirver is used here https://review.opendev.org/#/c/501025/12/nova/cmd/manage.py@988
08:42:30 gibi interesting
08:42:31 sean-k-mooney we cant just call the reshape function in the libvirt dirver however.
08:42:53 sean-k-mooney ironic works because all the info it need is either in the nova db or in the ironic api
08:43:50 sean-k-mooney this is all that was doing https://github.com/openstack/nova/blob/b6f3d393aa5cb755f30fa70d4acc614c32216c99/nova/virt/ironic/driver.py#L570-L582
08:44:50 sean-k-mooney thats doing an online data migration but its not doing a reshape

Earlier   Later