| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-19 | |||
| 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 | efried | mordred Okay, so I can really just use endpoint URL APIs. | |
| 21:33:30 | mordred | and yes- what jaypipes pasted is a good code example | |
| 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 | melwitt | hm. I think in the nova-network case compute would read limits for fixed ips | |
| 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 | mriedem | cked instances) | |
| 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 | flwang | good point | |
| 21:55:40 | imacdonn | yeah, that ;) | |
| 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 | flwang | that's very helpful | |
| 21:59:16 | melwitt | dansmith: most of them are limits. some are QuotaClass which has its own fields | |
| 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 | |
| 22:00:25 | dansmith | melwitt: it looks like we don't really have any of those existing methods that return raw data though right? we return an integer in one place I think, but.. nothing like a bag of dicts | |
| 22:01:26 | melwitt | dansmith: no, and I didn't realize the implications of what I added that needed to return things | |
| 22:01:41 | dansmith | hrm. | |
| 22:03:38 | melwitt | dansmith: another way I considered but didn't do is I could have added the new api db accesses to nova/quota.py and do the api/main straddle there | |
| 22:04:15 | flwang | mriedem: yep, it will. just like you delete a vm from vmcontrol instead of openstack :D | |
| 22:04:24 | dansmith | melwitt: what we need to avoid is returning unversioned data to the compute, which I don't think is solved purely by putting the straddle in quotas.py | |
| 22:04:37 | melwitt | dansmith: I was thinking of the Quotas object as an abstraction but wasn't think of the remotable methods part | |
| 22:04:45 | dansmith | melwitt: what we really need is a composite operation that just says "yo dawg, check this quota limit for me and raise if there's a problem" right? | |
| 22:05:00 | dansmith | melwitt: then all the data is on the conductor side and compute is just asking for a check instead of getting the data itself | |
| 22:05:03 | melwitt | dansmith: it's not but it would be doing the same thing it is now (without having a Quotas object version attached to it) | |
| 22:05:17 | melwitt | dansmith: yeah, that makes sense | |
| 22:05:39 | dansmith | melwitt: right now we remote the call to the quotas db code through the object action without returning data, right? | |
| 22:05:47 | dansmith | and your patch ends up with us returning that data to compute I think | |
| 22:05:54 | melwitt | dansmith: check_deltas is supposed to do that, but atm I'm confused as to where that occurs or if it solves the problem | |