Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-06-22
09:20:51 openstackgerrit Brin Zhang proposed openstack/nova-specs master: Filter instances by tenant_id https://review.opendev.org/737241
09:38:50 gibi bauzas: left feedback in https://review.opendev.org/#/c/733703
09:38:57 bauzas thanks
09:40:37 bauzas gibi: ack, seen your comments
09:40:43 bauzas gibi: honestly, it's a good question
09:40:58 bauzas I'm not opiniated but,
09:41:23 bauzas if we go with the neutron direction, I like it but I won't be able to provide the implementation I think :p
09:41:48 bauzas gibi: so, tbh, I like your concern
09:42:19 bauzas but maybe we should discuss it with some other folks :)
09:48:52 brinzhang gibi, bauzas: I submit a spec, but it has an error of docs. I cannot find which is wrong in line 22
09:49:03 brinzhang error: /home/zuul/src/opendev.org/openstack/nova-specs/doc/source/specs/victoria/approved/filter-instances-by-tenant-id.rst:22:Unknown target name: "1".
09:49:12 brinzhang https://review.opendev.org/#/c/737241
09:49:27 brinzhang can you fast check, where caused the error?
09:52:07 gibi bauzas: sure. this is why I said that put every neutron segment - aggregate related code in a single place in nova, so that later we can easily remove it, but I know this part is then becomes implementation detail
10:00:55 openstackgerrit Brin Zhang proposed openstack/nova-specs master: Filter instances by tenant_id https://review.opendev.org/737241
10:19:21 gibi brinzhang: the latest PS worked for me locally
12:05:26 jcath friends, I try to use "openstack server add volume --device /dev/hdc instance vol-name" to attach a volume to the instance as an IDE device, but it always attach as a virtio device (qemu-kvm as hypervisor) . as I check nova/virt/libvirt/driver.py, it seems that the device name parameter is ignored... so How I can force to attach a volume on IDE bus? thanks!
12:06:17 stephenfin elod: Could you take a look at https://review.opendev.org/#/c/708617/ today?
12:12:19 elod stephenfin: yes, looking
12:12:24 stephenfin ta
13:14:54 tbarron Is it possible via openstack/nova apis to do expose compute-host extra disks to guest VMs via somthing like pci-passthru?
13:15:17 gibi dansmith, stephenfin, melwitt: sorry I was out Friday afternoon. Thanks for reviewing the image cache bugfix. However I don't like the fact that we are mixing the question of "is this on the same dev?" with the question "is this exists?"
13:15:45 tbarron This has been suggested as a way for kubernetes clusters running with nova vms to do software defined storage (like ceph) without indirection
13:15:56 sean-k-mooney tbarron: in general no. if you have nvme disk you can confiture them for pci pasthough but it expects stateless pci device
13:16:13 tbarron in the data path like when they use RBD backed nova ephemeral or cinder storage
13:16:20 sean-k-mooney so we will not correctly clean them when a vm is deleted and there data will not be copied if you mvoe the guest
13:16:40 sean-k-mooney tbarron: so basically today no
13:16:49 sean-k-mooney tbarron: there is no way to do that
13:16:54 stephenfin gibi: Yeah, I'm on the fence about that now too
13:17:08 stephenfin especially given the confusion it resulted in
13:17:24 stephenfin I don't know what dansmith and melwitt settled on when I left
13:17:29 tbarron sean-k-mooney: thanks, I already said "no" but thought I better check with those who really know :D
13:17:57 gibi stephenfin: I will try to come up with a better factored solution in the next PS
13:18:05 stephenfin ack
13:18:18 sean-k-mooney tbarron: the quickest way to enable something like that would be to write a cyborg dirver to manage disk on the host and then extend libivt to accpet disks form cyborg
13:21:17 tbarron sean-k-mooney: interesting, and that makes sense
13:22:59 sean-k-mooney tbarron: a disk is not really an acclearator but if you think of cyborg as a generic device managment service it think it fit. espacially when you consider that imaging or erasing a disk is basically the same as programing or reseting an fpga
13:23:14 sean-k-mooney just with less $$$ for the hardware
13:24:08 tbarron sean-k-mooney: yeah, it fits with the general expose-hardware-features to VMs direction, I get it
13:25:10 tbarron and is somewhat in tension with present compute-instances as abstractions idea, thouhh I say "tension" and not contradiction
13:26:10 tbarron we have a similar tension in storage where different backends have different capabilities and it's tricky figuring which to expose as abstractions
13:34:03 sean-k-mooney tbarron: well the tension is relived in a sense that it would be abstracted via a device-profile and we would should based on the aviablity of the resouce like any other
13:34:29 sean-k-mooney tbarron: cinder does nto quite workin this usecase since you dont have an ideal of a local only cinder backend
13:35:17 dansmith gibi: I commented
13:36:14 dansmith gibi: making it non-public and specific to "decide if we should report zero" addresses my original concern I guess, but I don't understand what the problem currently is
13:38:36 gibi dansmith: my problem that it makes a coupling between nova.virt.libvirt.imagebackend.Image.cache and nova.virt.libvirt.imagecache.ImageCacheManager.cache_dir_is_on_same_dev_as_instances_dir as the later assumes how the former will create the directory
13:39:39 dansmith gibi: cache_dir is a property of the imagecache no?
13:40:09 gibi for me the reasoning like "the directory does not exists therefore it occupies 0 space" is easier to accept than "the directory is on the same dev as it is not created but we know that when it is created it will be a call to mkdir that creates it on the same dev"
13:40:19 dansmith are you just saying that the behavior of creating the cache_dir if it doesn't exist is something in the libvirt code?
13:40:52 dansmith gibi: until the directory exists, the same exact thing is returned right? zero?
13:41:52 tbarron sean-k-mooney: ack, cinder volumes are intended to have a life-cycle independent of compute instances or compute instance hosts
13:41:55 dansmith once the directory exists, we'll report what we see, which will almost definitely be the same dev, but if not, we'll report the value according to how the directory is at that point
13:42:11 gibi dansmith: the behavior of get_disk_usage() is the same in my PS2 and in PS5
13:42:49 gibi but I think the implementation is better strucutred in PS2
13:42:54 dansmith right, so I don't see that we're making any different assumptions
13:43:04 tbarron sean-k-mooney: so the cinder lvm backend is useful for testing iscsi but not so much for production deployments
13:43:21 dansmith gibi: well, I disagree because I think that a property should explode for a known condition
13:43:37 dansmith gibi: but make it not a property (and rename it) and you can have that structure
13:43:48 gibi dansmith: I accep that I'm ready to make that an internal helper instead of a public property
13:44:00 dansmith I think a property shouild /not/ explode I meant
13:44:07 gibi yeah, I agree ^^
13:45:09 gibi just to make sure I understand your point. Is it OK for you if change the property to an private helper method?
13:45:46 dansmith I don't like it, but it addresses the problem I had with PS2
13:46:40 gibi why don't you like it?
13:49:00 dansmith well, because as it is, the property has utility beyond what you're doing here. You're just changing it to "should I report zero for cache" which is a single conditional and might as well just be in the if statement of the get_disk_usage()
13:49:14 dansmith doesn't seem worth it being a helper to me
13:49:52 dansmith but all I really meant is that _I_ would keep it the way it is in PS5, but it matters to me less than you, so you should change it
13:50:15 dansmith what matters to me is not having that should-be-useful-but-dangerous public property
13:52:42 gibi dansmith: thanks
14:04:43 openstackgerrit Dan Smith proposed openstack/nova master: DNM: Try to make a glance multistore job https://review.opendev.org/734184
14:25:46 openstackgerrit Dan Smith proposed openstack/nova master: DNM: Try to make a glance multistore job https://review.opendev.org/734184
14:27:16 openstackgerrit Elod Illes proposed openstack/nova stable/train: Check cherry-pick hashes in pep8 tox target https://review.opendev.org/737279
15:08:06 jsuchome hey dansmith ... regular reminder about https://review.opendev.org/#/c/574301 once you have time...
15:28:00 dansmith jsuchome: I know, I haven't forgotten
15:45:46 openstackgerrit Balazs Gibizer proposed openstack/nova master: Guard against missing image cache directory https://review.opendev.org/736964
16:29:46 stephenfin melwitt: could you look at https://review.opendev.org/708617 too?
16:30:12 melwitt stephenfin: sure, will do
16:30:18 stephenfin thanks
17:22:33 openstackgerrit Stephen Finucane proposed openstack/nova master: fakelibvirt: Remove nova-network remnants https://review.opendev.org/737329
17:25:56 openstackgerrit Ghanshyam Mann proposed openstack/nova stable/stein: Make greande jobs n-v for EM and oldest stable https://review.opendev.org/737332
17:27:48 openstackgerrit Ghanshyam Mann proposed openstack/nova stable/stein: Make greande jobs n-v for EM and oldest stable https://review.opendev.org/737332
17:34:47 sean-k-mooney dansmith: you can increase the job timeout in the zull.yaml if you need to for the multistore job
17:35:05 sean-k-mooney dansmith: it looks like you glance api change made it this time https://zuul.opendev.org/t/openstack/build/18e4701c1a374bf09269778479160f25/log/controller/logs/etc/glance/glance-api_conf.txt
17:35:27 dansmith yep, and it asked for the copy
17:35:32 dansmith I think something else likely broke, looking now
17:35:37 dansmith Jun 22 15:42:22.928857 ubuntu-bionic-rax-iad-0017311577 nova-compute[23701]: INFO nova.virt.libvirt.imagebackend [None req-ca48174a-0bf4-4341-8d45-fcf69cc9a3de tempest-DeleteServersAdminTestJSON-1752858908 tempest-DeleteServersAdminTestJSON-1752858908] Asking glance to copy image e6b1a7d0-ccd8-4be3-bef7-69c68fca4313 to our rbd store robust
17:36:14 dansmith Jun 22 15:52:23.076886 ubuntu-bionic-rax-iad-0017311577 nova-compute[23701]: ERROR nova.compute.manager [instance: 2cb1f8e2-a6a3-4f42-b6e2-de6823c71e25] nova.exception.ImageUnacceptable: Image e6b1a7d0-ccd8-4be3-bef7-69c68fca4313 is unacceptable: Copy to store robust timed out
17:36:53 sean-k-mooney it might be a slow node
17:37:12 sean-k-mooney you could relax some of the times outs for image/volume creation
17:37:23 dansmith it waited ten minutes
17:37:38 dansmith that should be more than long enough to copy a cirros image on any node I think
17:38:03 sean-k-mooney ya fair point :)
17:38:33 sean-k-mooney i was more thinking it was a slow host becaue it hit the 2 hour job time out
17:38:46 sean-k-mooney althougyh i guess enough 10 minute wait would have the same effect
17:39:28 dansmith I think it's just because each time we went to spawn an instance, it waited ten minutes before failing,
17:39:35 dansmith which linearized is enough to run the timeout
17:40:11 dansmith https://zuul.opendev.org/t/openstack/build/18e4701c1a374bf09269778479160f25/log/controller/logs/screen-g-api.txt#7466
17:40:18 dansmith glance was failing to update its own property I think
17:40:35 sean-k-mooney right this si the image convertion https://zuul.opendev.org/t/openstack/build/18e4701c1a374bf09269778479160f25/log/controller/logs/screen-g-api.txt#440
17:41:03 sean-k-mooney so it looks like the inital import conversion worked

Earlier   Later