| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-19 | |||
| 20:31:34 | jaypipes | cheers | |
| 20:32:55 | openstackgerrit | Steve Noyes proposed openstack/nova master: Update detach to use V3 Cinder API https://review.openstack.org/438750 | |
| 20:42:15 | dansmith | vladikr: still around? | |
| 20:42:28 | dansmith | vladikr: can you look over this and see if there's anything missing from this that we should add? https://review.openstack.org/#/c/448283/4 | |
| 20:43:01 | vladikr | dansmith, sure, looking | |
| 20:52:56 | hypothermic_cat | mriedem: update posted, hope it looks better now | |
| 20:58:13 | mriedem | hypothermic_cat: ok | |
| 21:00:58 | vladikr | dansmith, seems fine overall. sriov VFs can be also "trusted" by it's PF. This will allow it to set a custom mac and enter promiscuous mode | |
| 21:02:00 | vladikr | dansmith, perhaps it should state the function (virtual/physical)? | |
| 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 | 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? | |