Earlier  
Posted Nick Remark
#openstack-nova - 2017-10-26
12:10:46 jaypipes avolkov: the user should be able to delete a provider unless that provider has allocations against it. nothing to do with traits.
12:10:53 jaypipes avolkov: does that answer your question?
12:11:19 efried Dinesh_Bhor FYI, spec freeze has passed - is this proposed for Rocky?
12:12:12 avolkov jaypipes: Yes, I file a bug then
12:12:21 Dinesh_Bhor efried: yes, I will do the needful for that. I just want to take the early feedback.
12:12:28 jaypipes avolkov: sounds good, thanks Andrey! :)
12:12:52 jaypipes Dinesh_Bhor: ok, I can review it. but as efried said, please update it to point to rocky first, ok?
12:12:56 efried jaypipes avolkov I don't remember if/where we landed on the issue of removing a trait from an RP with allocations against it.
12:13:11 alex_xu efried: I guess edleafe means two people work on different timezone, anyone can fix the problem when review the code?
12:13:24 Dinesh_Bhor jaypipes: yes, I will update it
12:14:02 efried alex_xu I think of it as a tighter collaboration than that. You and I would agree to work on a particular patch or series, like the one you're doing for AllocationCandidates, together.
12:14:20 jaypipes efried: since traits are not consumed, I don't have an issue with deleting providers that have traits assigned to them.
12:14:43 efried jaypipes Other way around: removing a trait from a provider if that provider has allocations against it.
12:15:08 efried jaypipes Objection being that then the RP may no longer "satisfy" the conditions that were originally in play when the allocation was made.
12:15:36 efried jaypipes My take: who cares? You're never, like, re-checking afterwards.
12:15:52 efried jaypipes If you need to do a migration or resize, you would have to reschedule anyway and find appropriate RPs.
12:16:05 alex_xu efried: ok, then what we can do?
12:16:06 efried jaypipes I guess it could make resize-to-same-host impossible. But so could resource exhaustion. So...
12:16:07 jaypipes efried: agreed.
12:16:37 efried alex_xu Each of us ensures we upload patches in progress before we sign off for the day (so that we don't have local work-in-progress that gets overridden by the other)
12:17:14 efried alex_xu Ideally we have a "handoff" time when we can briefly discuss anything as one of us leaves and the other comes on.
12:17:17 alex_xu edleafe: ok, that should be under the situation the direction is solid
12:17:37 alex_xu efried: yea, edleafe help me update the patches before when I'm sleeping
12:18:24 efried alex_xu Okay. I obviously didn't want to start patching up your changes without discussing it first :)
12:19:05 efried alex_xu So I assume you're at least close to done for the evening at this point. (What time zone are you in?) Want to talk about what's in progress, and how I can most effectively take over?
12:19:53 alex_xu efried: yea, I will upload a version, and I think I can write some todo note in the code
12:20:09 alex_xu basically, I want to add more unittest for next step
12:20:37 alex_xu and then overall to look at the code, and see if there is anything need to be adjust
12:21:11 efried alex_xu The ones about _get_provider_ids_with_any_resource returning incorrectly when there are exhausted inventories in play?
12:21:38 alex_xu efried: I totally rewrite that sql
12:21:59 alex_xu currently, what I'm doing is rewrite the comments...and add more unittests
12:22:50 artom_ kaisers1, ping?
12:22:52 alex_xu efried: how about I write some todo note in the commit message, then you can continue those todo, or fix anything you found when review the code?
12:23:03 efried alex_xu Perfect.
12:23:04 kaisers_ artom_: pong Hi
12:24:11 alex_xu efried: cool, let us try how was that
12:25:08 efried alex_xu 很好 :)
12:25:35 artom_ kaisers_, hey, do you still run quobyte ci with dynamic_ownership = 0 in libvirt conf?
12:29:27 efried jaypipes These failures are weird http://logs.openstack.org/93/385693/58/check/openstack-tox-py27/786b250/testr_results.html.gz -- you on top of it or want me to debug?
12:29:37 jaypipes efried: on it already.
12:29:41 efried jaypipes coo
12:30:16 kaisers_ artom_: i think the setup did not change, yes. why?
12:31:03 efried jaypipes Oh, the headers. I was misreading those as being part of the endpoint filter. Phew, not crazy.
12:31:11 artom_ kaisers_, we've run into an interesting side effect of the workaround we put in place for that
12:31:48 artom_ https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3033 specifically
12:32:14 artom_ If the compute node dies ungracefully, instances can't be started again because of permission denied on console.log
12:32:22 artom_ We can probably hack something around that
12:32:40 artom_ But I was kinda hoping the original reason for the original workaround had gone away
12:34:39 kaisers_ artom_: hmm, yeah, would be great to get rid of that whole thing. I think i've an open idea on how to improve on that but currently i'm not coming 'round to implement that, at least not in the next 5-8 weeks
12:35:11 artom_ kaisers_, does the idea depend on knowledge of quobyte? Otherwise I'm game :)
12:36:48 kaisers_ artom_: only marginally i think. I've to re-check my notes. I think it was centered around the idea to give a specific tag to libvirt which should ensure Quobyte is understood as a shared file system and libvirt should refrain from touching the files
12:36:59 kaisers_ artom_: but that's from clouded memory
12:37:03 kaisers_ pun not intended
12:37:23 artom_ kaisers_, ah, Dan Berrange's comment
12:37:26 artom_ I've read that
12:37:38 artom_ That wouldn't be in nova code though, correct?
12:37:49 kaisers_ artom_: yep, that's what i thought
12:37:57 kaisers_ artom_: i think it should be in nova
12:38:10 kaisers_ The libvirt xml would have to contain the tag iirc
12:38:27 artom_ kaisers_, ah? I'll try to read up on that
12:39:56 kaisers_ artom_: i think i started on that some time ago but had a hard time determining how exactly the tag has to look like
12:41:00 artom_ kaisers_, alright, I'll try and figure out what exact shape the fix should take
12:41:13 artom_ Are you usually around at this time? I might poke you for info :)
12:44:09 kaisers_ yep, usually i'm online around 07h - 15h UTC
12:46:18 artom_ kaisers_, gotcha, thanks! Right this instant I need to tend to daycare logistics, but I'll try to work on this some more this morning (I'm on NA east coast)
12:49:23 kaisers_ artom: Go for it! :)
12:54:40 openstackgerrit Chen Hanxiao proposed openstack/nova master: libvirt: properly decode error message from qemu guest agent https://review.openstack.org/511459
12:55:59 openstackgerrit Jay Pipes proposed openstack/nova master: placement: update client to set parent provider https://review.openstack.org/385693
12:57:05 jaypipes efried, gibi: ^ fixed unit test failrues
12:58:06 efried jaypipes +1 thanks
13:09:38 gibi jaypipes: thanks, I but back my vote
13:13:16 openstackgerrit Elod Illes proposed openstack/nova master: Transform keypair.import notification https://review.openstack.org/467514
13:13:22 mriedem claudiub|2: lpetrut: looks like hyperv ci might have issues on stable/pike https://review.openstack.org/#/c/515330/
13:13:58 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Fix AttributeError in BlockDeviceMapping.obj_load_attr https://review.openstack.org/515404
13:14:25 mriedem sdague: bauzas: simple fix backport for a regression in pike https://review.openstack.org/#/c/515404/
13:22:55 openstackgerrit Alex Xu proposed openstack/nova master: Add _get_providers_with_any_resource method https://review.openstack.org/514197
13:22:55 openstackgerrit Alex Xu proposed openstack/nova master: Enable _get_usages_by_provider_and_rc not filter on the resource class id https://review.openstack.org/514649
13:22:56 openstackgerrit Alex Xu proposed openstack/nova master: Add _get_traits_by_rp_ids method https://review.openstack.org/511184
13:22:56 openstackgerrit Alex Xu proposed openstack/nova master: Add ProviderSummaryList object https://review.openstack.org/514198
13:22:57 openstackgerrit Alex Xu proposed openstack/nova master: Add more caches for the ProviderSummary and ProviderSummaryList https://review.openstack.org/514199
13:22:57 openstackgerrit Alex Xu proposed openstack/nova master: Add AggregatedProviderSummary and AggregatedProviderSummaryList objects https://review.openstack.org/514200
13:22:58 openstackgerrit Alex Xu proposed openstack/nova master: Add has_resources method to the AggregatedProviderSummary object https://review.openstack.org/514650
13:22:58 openstackgerrit Alex Xu proposed openstack/nova master: Add as_allocation_request_obj method to AggregatedProvierSummary obj https://review.openstack.org/514651
13:22:59 openstackgerrit Alex Xu proposed openstack/nova master: placement: rewrite AllocationCandidates.get_by_filters https://review.openstack.org/479766
13:23:53 alex_xu efried: jaypipes, all the functional tests passed ^ in the last patch, but it still is WIP, more unittests, and better commit message, and so on...
13:24:31 efried alex_xu Ack. Anything in particular in there that I could/should work on today?
13:25:11 alex_xu efried: I added todo note in the commit message https://review.openstack.org/#/c/514197/
13:25:19 alex_xu I want to separate that single unittest to multiple one
13:25:29 cdent I like this todo in commit message handoff idea
13:25:48 efried alex_xu Okay, I'll see if I can tackle that today.
13:26:01 jaypipes alex_xu: yup, I'm getting to those reviews this morning. thanks for your patience.
13:26:35 alex_xu efried: and for other patch, few of them just missing the unittest, I didn't write the todo
13:26:43 alex_xu but you can find them easily
13:26:45 alex_xu jaypipes: thanks
13:27:09 efried alex_xu I think I mentioned this in a comment, but eventually I'd like to extend _get_providers_with_any_resource to be able to do either 'any' or 'all'.
13:27:21 efried alex_xu Because numbered groups are going to want *all*.
13:27:29 efried which is a much easier thing to write SQL for.
13:27:50 efried In fact, perhaps I can just write a separate method that does all resources *and* traits at the same time.
13:28:27 alex_xu efried: that what we doing currently, finally that will be huge sql, that is hard to maintain I think
13:29:08 efried alex_xu I think the "any" thing is what makes it really tricky. But I'll play with it and see if it winds up looking too heinous to do in one shot.

Earlier   Later