Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-07-27
19:19:10 openstackgerrit OpenStack Proposal Bot proposed openstack/os-vif master: Updated from global requirements https://review.openstack.org/488086
19:21:33 openstackgerrit OpenStack Proposal Bot proposed openstack/python-novaclient master: Updated from global requirements https://review.openstack.org/488125
19:22:40 openstackgerrit Eric Fried proposed openstack/nova master: nova.utils.get_endpoint_data() https://review.openstack.org/488137
19:23:37 efried mriedem jaypipes mordred Having started poking at the cinderclient construction, I think ^this^ may be a better alternative to get_service_url
19:23:57 mriedem efried: the house is on fire
19:24:03 dansmith mriedem: jaypipes https://etherpad.openstack.org/p/y9sUcb6XW6
19:24:17 mriedem efried: have sdague check out the service catalog stuff
19:24:21 mriedem he knows more about that than i do
19:24:24 efried mriedem Roger wilco.
19:29:07 mordred efried: yes - that's a great approach
19:29:35 efried mordred Cool, thanks for looking.
19:31:29 mriedem https://review.openstack.org/#/c/244489/
19:37:00 cfriesen_ jaypipes: did you ever get anywhere with the issue we discussed at the end of June around duplicate scsi device numbers when using virtio-scsi?
19:37:28 jaypipes cfriesen_: nope :(
19:37:34 mriedem cfriesen_: the house is on fire
19:37:39 cfriesen_ jaypipes: I think bug 1702999 is related, as is the "cannot attach new volume to an instance" thread on the openstack-operators list
19:37:41 openstack bug 1702999 in OpenStack Compute (nova) "Can't attach volume if instance boot from volume and virtio-scsi is enabled in the image" [Undecided,Incomplete] https://launchpad.net/bugs/1702999
19:38:12 jaypipes oh wait, yeah I think we did have a patch for that...
19:38:36 jaypipes cfriesen_: gimme a while... on call
19:38:57 mriedem cfriesen_: this? https://review.openstack.org/#/q/topic:bug/1686116
19:42:12 cfriesen_ mriedem: looks like it might help. in the case I looked at it would boot (using sda) but trying to attach volumes would fail.
19:42:58 cfriesen_ might be the case that 1702999 is already fixed
19:49:10 cdent jaypipes: if you end up with something that has lose ends by the time you go to bed, feel free to let me know the state of things and I can poke in my morning
19:49:31 jaypipes cdent: thx Chris, will do.
19:57:30 openstackgerrit OpenStack Proposal Bot proposed openstack/python-novaclient master: Updated from global requirements https://review.openstack.org/488125
19:59:18 openstackgerrit Doug Hellmann proposed openstack/nova master: add a redirect for the old cells landing page https://review.openstack.org/487932
20:10:00 openstackgerrit OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/488034
20:12:24 jaypipes dansmith: fuuug... so confirm_resize() doesn't run on the destination host. It runs on the source host. :(
20:12:43 mriedem yeah it doesn't call back into rt
20:12:49 mriedem _prep_resize is on dest host right?
20:12:53 mriedem confirm just cleans up shit on the source
20:12:59 mriedem *i think*
20:13:13 jaypipes mriedem: yeah. and that's not the stage of the move operation that we want to have the destination host call PUT /allocations :(
20:13:31 mriedem and i think revert on the source doesn't do anything either, since it's already got resources claimed
20:13:35 mriedem so there is nothing to unclaim
20:14:10 bauzas folks, I will have to bail out, but I'll look at the IRC channel tomorrow morning
20:14:40 mriedem i'm just about to push a change to add some logging and crap in the scheduler.reportclient.delete_allocations_for_instance to sanity check the allocations before we blow them away, to at least see if we're hitting weird stuff in there during migrate tests
20:14:43 mriedem bauzas: o/
20:14:44 bauzas fer sur, if you need my review, lemme know
20:15:07 dansmith jaypipes: ugh
20:15:08 openstackgerrit OpenStack Proposal Bot proposed openstack/python-novaclient master: Updated from global requirements https://review.openstack.org/488125
20:15:47 sdague efried: link me
20:16:06 efried sdague https://review.openstack.org/488137 bam
20:16:10 efried sdague TIA.
20:16:26 sdague mriedem: https://review.openstack.org/#/c/487860/ - nova-manage list_cells enhancement
20:16:30 sdague with working tests
20:16:36 jaypipes dansmith, mriedem: so this means really the only thing we can do during confirm_resize() (since it's on the source host) is recalculate the allocation (which will be the doubled-up thing) on the source host RT and remove all entries in the allocation set that refer to the source compute host UUID
20:16:36 sdague I will keep bugging you about it :)
20:18:03 dansmith jaypipes: yeah
20:18:16 dansmith jaypipes: I was thinking something different, but that's smarter :)
20:19:39 sdague efried: I'm surprised this is 'glance' and not 'image' - https://review.openstack.org/#/c/488137/1/nova/image/glance.py@127
20:20:39 efried sdague It's the conf group name, which needs to correspond to the project name.
20:20:46 openstackgerrit Matt Riedemann proposed openstack/nova master: Sanity check delete_allocation_for_instance https://review.openstack.org/488187
20:20:53 mriedem dansmith: jaypipes: cdent: ^
20:20:58 mriedem just for testing at this point
20:20:58 efried sdague Which we then look up in service-types-authority to get the service_type, which is indeed `image`
20:21:27 sdague efried: ok, I was surprised we couldn't just call it image to start with, but if that's how it is, that's fine
20:21:36 jaypipes mriedem: coo.
20:21:56 sdague efried: do we have a test job running this with api_servers not set in devstack?
20:22:18 mriedem jaypipes: "is recalculate the allocation (which will be the doubled-up thing) on the source host RT and remove all entries in the allocation set that refer to the source compute host UUID" is i thought what dansmith and i were talking about earlier,
20:22:25 mriedem which is similar to what my patch is checkingfor
20:22:43 efried sdague Yeah, now that you're saying it, I admit it feels a tad weird. But the point is that nova.utils.get_endpoint_data needs to be able to use that param to find the appropriate conf to load, as well as to find the service_type if it's not specified in the conf.
20:22:48 dansmith mriedem: well, I was assuming we could do it on the destination host
20:23:03 dansmith mriedem: but it doesn't really matter, so yes it's pretty much what we were saying
20:23:05 mriedem ok, i wasn't - i was thinking this was purely source host
20:23:11 sdague efried: yeh, it would be nice in the future if we could just specify "image" as well
20:23:12 dansmith well, you're just smarter than us
20:23:26 mriedem heh
20:23:52 mriedem i wouldn't go that far
20:23:55 jaypipes I would
20:24:00 efried sdague You can specify it in the conf: [glance] service_type = image
20:24:01 jaypipes in any case, I'm on it.
20:24:02 dansmith hey
20:24:34 efried sdague I think you're saying you want to specify the service type directly to nova.utils.get_endpoint_data
20:25:04 mriedem dansmith: was there more to that hey or just that your feelings were hurt?
20:25:27 mriedem dansmith: is this similar to what you were thinking? https://review.openstack.org/#/c/488187/1/nova/scheduler/client/report.py@1085
20:25:27 efried sdague That would get confusing if the operator did in fact specify [glance] service_type = <whatever>
20:25:29 dansmith mriedem: like, it's okay for me to say you're smarter than me, but not okay for jaypipes to say it
20:25:35 mriedem oh i get it
20:26:00 jaypipes everyone's smarter than me
20:26:02 mriedem feel free to compliment me on my ability to dig up useless pop trivia
20:26:08 mriedem but not my smarts in general
20:26:23 mriedem laura had to explain her work schedule to me for this weekend at least 4 times
20:26:34 dansmith heh
20:27:16 sdague efried: ah
20:27:29 sdague efried: I didn't realize people were allowed to override these
20:27:40 sdague efried: what's the use case there?
20:27:51 dansmith mriedem: yes, that's similar to what I was thinking
20:27:54 openstackgerrit OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/488034
20:28:09 sdague efried: anyway, on this patch, I think it looks overall good, I want to see a devstack run with api_servers not set to see it working
20:28:23 sdague after which I'll +2
20:28:31 sdague and I'll leave the rest of my questions for mordred
20:28:36 sdague and you at later dates
20:28:42 efried sdague Well, the overall use case is to consolidate/centralize/consistentify (look it up) the way we get clients.
20:29:09 efried sdague So for glance it might be a no-brainer that the service type should always be 'image'.
20:29:13 melwitt mriedem: what type of things will be allowed after today feature freeze? quota cleanups (like test coverage, removing unused stuff, changing the name of recheck_quota config option) or just bug fixes?
20:29:30 efried sdague But we want to be able to do it more or less the same way for e.g. cinder, which (egads) is nowhere near as simple.
20:30:15 sdague efried: yeh, the cinder edge case definitely is a thing.
20:30:50 efried sdague If you want a leetle preview of what that *might* look like: https://review.openstack.org/#/c/487621/1/nova/volume/cinder.py
20:31:02 mriedem melwitt: test coverage is obviously ok, and removing dead code

Earlier   Later