| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-19 | |||
| 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 | |
| 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 | |
| 22:06:29 | melwitt | check_deltas is the composite operation that calls count followed by limit_check | |
| 22:08:08 | dansmith | melwitt: where is check_deltas? | |
| 22:08:58 | dansmith | that must be something later in your patch series? | |
| 22:09:49 | melwitt | dansmith: third patch I think | |
| 22:10:29 | melwitt | dansmith: https://review.openstack.org/#/c/446239 | |
| 22:11:10 | cfriesen | config option question: when specifying the "live_migration_inbound_addr" config option, is it expected that an ipv6 address will be enclosed in square brackets? Or should nova handle that when parsing the config option? | |
| 22:11:39 | dansmith | melwitt: ah yep.. that just takes resources and counts (from compute in this case), remotes to conductor where it looks at all the stuff and either explodes or doesn't, right? | |
| 22:13:17 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP/PoC: nova.utils.get_service_url(group) https://review.openstack.org/458257 | |
| 22:13:23 | melwitt | dansmith: it takes the deltas but it does the count and pulls the limits itself | |
| 22:13:54 | dansmith | melwitt: right, it just takes a resource and count, and explodes if the quota would be violated | |
| 22:14:09 | dansmith | melwitt: that's what we need yeah | |
| 22:14:34 | clarkb | cfriesen: I thought I could answer based on how we configure things in multinode testing but that appears to be an entirely ipv4 control plane :/ | |
| 22:14:48 | melwitt | dansmith: if by count you mean delta, then yes. if you want to check if you have room for 5 more instances, you pass it 5 and then it will count how many instances your project and user have allocated, then it pulls the limits and compares | |
| 22:15:07 | cfriesen | clarkb: I'm wondering if maybe nova should do: | |
| 22:15:35 | cfriesen | migrate_data.target_connect_addr = utils.safe_ip_format(CONF.libvirt.live_migration_inbound_addr) | |
| 22:15:53 | dansmith | melwitt: yeah | |
| 22:17:21 | melwitt | dansmith: okay, so that solves that problem. so I need to figure out what to do about the db access methods I have in the Quotas object | |
| 22:18:11 | melwitt | I put them there as a universal place to call api/main db to do the right thing, and the caller should only be the quota driver in nova/quota.py | |
| 22:18:29 | melwitt | I think ... | |
| 22:18:56 | dansmith | melwitt: right but does compute call into nova.quota for anythign? I thought it did | |
| 22:19:09 | dansmith | if so, then your check_deltas conversion needs to come first | |
| 22:19:19 | melwitt | dansmith: it does, for the reserve/commit/rollback | |
| 22:19:24 | openstackgerrit | Peter Hamilton proposed openstack/nova master: Add configuration options for certificate validation https://review.openstack.org/457678 | |
| 22:19:48 | dansmith | melwitt: yeah, then you need to do something in a different order I guess | |
| 22:19:50 | melwitt | dansmith: check_deltas only works if the quota has been converted to Countable | |
| 22:19:56 | dansmith | yeah | |
| 22:24:34 | melwitt | I shall think on it | |
| 22:25:03 | melwitt | my brain's too fried at the moment | |