| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-06-09 | |||
| 16:17:00 | openstackgerrit | Stephen Finucane proposed openstack/nova stable/queens: libvirt: Fix misleading debug msg "Instance is running" https://review.opendev.org/732716 | |
| 16:17:00 | openstack | bug 1550919 in OpenStack Compute (nova) "[Libvirt]Evacuate fail may cause disk image be deleted" [Medium,Fix released] https://launchpad.net/bugs/1550919 - Assigned to Lee Yarwood (lyarwood) | |
| 16:17:00 | openstackgerrit | Stephen Finucane proposed openstack/nova stable/queens: Add functional test for bug 1550919 https://review.opendev.org/732715 | |
| 16:37:52 | openstackgerrit | Elancheran S proposed openstack/nova master: Removes the delta file once image is extracted https://review.opendev.org/734421 | |
| 17:48:52 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Don't allow "reserving" file-backed memory https://review.opendev.org/734658 | |
| 17:49:00 | stephenfin | sean-k-mooney: ^ | |
| 17:54:27 | sean-k-mooney | stephenfin: oh you have a fix altreay i asumed you were just going to file the bug | |
| 17:55:35 | sean-k-mooney | stephenfin: the code does not do what the title says | |
| 17:56:00 | sean-k-mooney | we still allow you to reserve the memory | |
| 18:02:09 | sean-k-mooney | dansmith: https://review.opendev.org/#/c/734184/ seames to work | |
| 18:02:16 | sean-k-mooney | dansmith: did you enable any test that use it | |
| 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 | |