Earlier  
Posted Nick Remark
#openstack-nova - 2017-04-19
21:02:14 dansmith vladikr: I'm in another meeting, but can you just comment on the review?
21:02:22 vladikr sure
21:02:26 dansmith thanks
21:06:12 cburgess Does the libvirt LXC driver still work? or is that dead-ish code?
21:19:19 flwang mriedem: ping
21:24:10 openstackgerrit Jon Bernard proposed openstack/nova master: Add tempest-dsvm-ceph-rc https://review.openstack.org/456292
21:25:40 mriedem cburgess: hard to say, we have a job in the experimental queue for it, but it's never been passing - it might be better now on the kernel in 16.04 though, i think the last time i looked at it, there were kernel issues with trusty
21:25:42 mriedem flwang: pong
21:25:57 cburgess mriedem Ew ok
21:26:06 flwang mriedem: may i get your comments on this spec https://review.openstack.org/#/c/190919/ ?
21:26:24 flwang especially if nova is still happy to keep the 'backup' function
21:27:16 flwang mriedem: Paul Murray commented it's not really necessary to backup a volume-backed instance, may i know your opinions? thanks
21:28:23 flwang mriedem: i revisited this spec because i got an email yesterday asked me why I gave up this patch, which means it's useful i think
21:31:20 efried jaypipes mriedem mordred How does a guy get "the" ServiceCatalog initially? I can find APIs to ask keystone for endpoint URLs, but presumably that goes to keystone every time, and we want to load up the service catalog just once.
21:31:21 melwitt dansmith: I replied to your comment on the quota review. I'm not sure what to make of the Quotas object. I used it as a place to do the api/main db straddle because no other place made sense, but it's not a true object like the others
21:32:28 mordred efried: it actually doesn't go to keystone every time
21:32:37 jaypipes efried: check out the code that starts here: https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L195-L198
21:32:58 mordred efried: the keystoneauth functoins to ask for endpoint urls all work from the catalog - unless they need to do version discovery because of what you requested
21:33:07 mordred if they do need to do version discovery, that is cached
21:33:30 mordred and yes- what jaypipes pasted is a good code example
21:33:30 efried mordred Okay, so I can really just use endpoint URL APIs.
21:33:32 mordred yes
21:33:53 mordred you, in fact, _should_ use the endpoint url apis - definitely don't try to do it yourself :)
21:34:10 efried neat.
21:35:21 dansmith melwitt: do those methods need to be remoted?
21:36:48 melwitt dansmith: I'm not sure. I thought the already existing update_limit and create_limit were that these should be too
21:37:08 melwitt *because the already existing
21:37:17 dansmith melwitt: are they ever called from compute? that's the reason they'd need to be remotable
21:37:21 cfriesen Hi folks...nova.virt.libvirt.driver.LibvirtDriver._supports_direct_io() checks whether we can mmap a 512-byte aligned block. How is this supposed to work with disks with 4K sectors?
21:37:26 dansmith since we're moving them to the api, I'd tend to thing not
21:37:54 dansmith melwitt: the problem is returning an unversioned dict from a supposedly-versioned ovo method
21:38:15 dansmith melwitt: those are all expected to, in almost all cases, return a class of the object, unless they return nothing
21:38:16 jaypipes cfriesen: probably good to just update the code to check the block size of the local disk before that mmap check.
21:38:24 mriedem cked instances)
21:38:24 mriedem flwang: i think paul's comments and questions are valid, i.e. you do backups for persistence of ephemeral disk, but if you're using volumes you already have persistence, and as john pointed out it's really an orchestration API that nova has been trying to pull away from, because we do orchestration API poorly in general (think boot from volume where nova creates a new volume, or the shelve API which is mostly broken for volum
21:38:24 melwitt hm. I think in the nova-network case compute would read limits for fixed ips
21:38:37 mriedem flwang: so i don't have great interest in adding support to the backup api personally
21:39:08 cfriesen jaypipes: I was wondering if we could just unconditionally switch to 4K
21:39:25 flwang mriedem: ok, got it. then i may stop putting more effort on that. thanks for the comments
21:39:49 jaypipes cfriesen: yeah, I suppose so. not like mmap'ing 4K on a 512-byte sector disk will fail.
21:40:55 melwitt dansmith: I see. hm, I need to go over it again as to which things compute will call. if it needs limit objects, then I would have to add a new object QuotaLimit or something I think. currently it's just reading them from its own database
21:41:07 mriedem flwang: alternatively work it through the operators or product work group and see if there has been any interest for the same thing from their customers
21:41:16 mriedem flwang: but i've never heard of anyone that wanted this besides you :)
21:41:22 dansmith melwitt: I would think limits are only read from the api regardless, yeah
21:41:44 melwitt dansmith: compute will read them for fixed ips at least though. when allocating a fixed ip
21:41:50 melwitt with nova-network
21:41:51 flwang mriedem: haha, we do have some customers want to see a built-in/outofbox backup, since the freezer is not really ready
21:41:52 dansmith oh, hm
21:42:09 dansmith melwitt: and how does this work with the move to the api db?
21:42:18 melwitt floating ips might be one too, it's been awhile
21:42:35 melwitt dansmith: compute would have to read them from the api db until nova-network is no longer a thing
21:42:43 mriedem uh oh
21:42:53 mriedem just like server groups
21:43:22 dansmith if it's just for n-net, then it's not a huge deal I guess
21:43:26 dansmith technically a violation
21:43:32 dansmith but in reality..
21:43:34 melwitt yeah
21:43:49 mriedem flwang: yeah i understand that - some people just want nova to do all of the orchestration, and we'd prefer that nova provide the APIs so that a higher-level service can put them together as the orchestrator
21:44:10 mriedem flwang: which it certainly could with the snapshot api
21:44:15 flwang mriedem: i see and i agree it makes more sense
21:44:45 flwang mriedem: yep. btw, another think i'd like to get your comments from nova view
21:49:12 flwang if I snapshot a volume-backend instance, then after delete the image in glance, do you expect the snapshot is fully delete?
21:52:07 flwang mriedem: i asked because currently, after delete the image, the volume behind the image will be left
21:52:35 mriedem flwang: an actual volume in cinder?
21:52:42 mriedem the volume snapshot right?
21:52:46 flwang yes
21:52:56 mriedem i wouldn't expect glance to delete the volume snapshot
21:53:02 mriedem when the instance snapshot image is deleted
21:53:15 flwang mriedem: interesting, why?
21:53:28 mriedem because glance shouldn't have control over cinder resources
21:54:14 mriedem and it would tightly couple the image snapshot from the server with the volume snapshot, based on an operation that nova is performing
21:54:17 mriedem which seems wrong
21:54:25 imacdonn there is no dependency between the volume and the image it was created from ... so I see no reason to delete the volume if the image is deleted
21:54:36 mriedem nova could just as easily not create a volume snapshot when creating an instance snapshot in glance
21:54:37 flwang mriedem: that's a good point, but why glance can delete an image when it's stored in swift, can you see the difference?
21:54:55 mriedem flwang: because swift is the backing store for the image right?
21:54:58 mriedem if you're using swift as the backend
21:55:20 mriedem cinder is not the backing store for the volume snapshot, cinder is
21:55:23 mriedem oops
21:55:33 mriedem glance is not the backing store for the volume snapshot, cinder is
21:55:40 imacdonn yeah, that ;)
21:55:40 flwang good point
21:55:51 mriedem swift is the backing store for the image
21:55:53 mriedem or ceph
21:55:54 mriedem or local file
21:55:56 mriedem or whatever
21:56:23 flwang but if glance is using cinder as the backend store
21:56:37 flwang for this case, should the snapshot being deleted?
21:57:55 dansmith melwitt: there are three fields on the quotas object.. those are not sufficient to return what we've got from those new calls?
21:58:26 mriedem flwang: only the image snapshot, not the volume snapshot
21:58:32 dansmith I'm not really sure what we're getting there actually.. usage I guess?
21:58:36 melwitt dansmith: I don't think so because those functions are returning db models that have like a limit attribute, for example
21:58:40 mriedem flwang: i go to glance to manage images, not volumes
21:58:45 melwitt dansmith: those are limits
21:58:52 mriedem flwang: regardless of what is storing those images
21:59:11 flwang mriedem: ok, cool, thanks for all the inputs
21:59:16 melwitt dansmith: most of them are limits. some are QuotaClass which has its own fields
21:59:16 flwang that's very helpful
21:59:27 mriedem if you're using cinder as the backend for glance (i didn't even know that was possible), and you delete the volume out of band via the cinder API, won't that totally mess up glance's representation of that image?
21:59:57 mriedem flwang: like if you boot a server in nova and then delete the guest via virsh

Earlier   Later