Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-30
15:31:43 openstackgerrit Merged openstack/os-traits master: Add code hosting URL https://review.openstack.org/539224
15:36:41 cfriesen there's a novaclient patch up at https://review.openstack.org/#/c/520187/ that's sitting with a single +2 if any core feels like taking a look. Basically adding strict hostname matching.
15:38:00 cfriesen mriedem: thanks, I'll pester the author.
15:41:14 bkero- mdbooth: ping, is your nova-compute-maintenance.py script maintained anywhere, or is it just a gist?
15:42:58 mriedem dansmith: alex's patch to handle the old/new style allocation candidates in the scheduler report client merged, did you want to rebase https://review.openstack.org/#/c/531517/ ?
15:43:19 dansmith mriedem: I don't want to, no, but .. I will
15:44:26 mdbooth bkero-: It's not maintained. What's the interest in it?
15:46:51 bkero- mdbooth: using it to evacuate compute hosts for maintenance :)
15:47:06 mdbooth bkero-: Heh, that's what it's for :)
15:47:08 bkero- since host-evacuate-live leaves a bit to be desired
15:47:23 bkero- mdbooth: I've had to fix a few things, like add 'all_tenants' and make the auth work
15:47:27 mdbooth I was wondering if you wanted to incorporate it into another tool.
15:47:48 bkero- I'm incorporating it into ansible playbooks to do rolling maintenance
15:49:00 bkero- I think so too. Maybe that is too many batteries included though.
15:49:06 mdbooth It's much better than host-evacuate-live, for eg
15:49:18 bkero- I'm basically evacuating a host, doing maintenance (hint: kernel upgrade), then moving onto next host
15:50:28 bkero- I started writing my own tool for this, then found your tool and it saved me a bunch of time.
15:50:37 mriedem efried: the consistent ksa endpoint stuff might be worth a cross-project goal at some point
15:50:59 mriedem standard config for services to talk to each other
15:51:08 mriedem seems more valuable to me than removing mox
15:51:16 efried mriedem: I agree. I think mordred might have been gonna push that.
15:51:27 mriedem he pushed standard paging links
15:51:43 mordred what'd I do?
15:51:55 efried TBH, I wouldn't be likely to have the bandwidth to push a cross-project goal like that.
15:52:11 mordred efried: bah. you have unlimited bandwidth
15:52:17 mriedem mordred: i told efried that https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/use-ksa-adapter-for-endpoints.html would be a good cross-project goal
15:52:29 mriedem consistent config for inter-service communication
15:52:47 mordred mriedem: yes - I agree
15:53:00 mriedem nova's done it for all but cinder config, so there are examples, and it's tested in the gate
15:53:10 mordred ++
15:53:10 mriedem *and castellan i guess
15:53:22 efried We figured out that castellan was n/a
15:53:38 mriedem i'll at least throw something into the cross-project goal etherpad of doom
15:53:44 mordred efried: also - sorry, I never got the os-service-types integration added to keystoneauth this past cycle
15:53:44 efried mordred: You were talking about taking it a step further IIRC, getting rid of "clients" altogether and just using the adapter (which we would spin up in a standard way)
15:54:06 efried mordred: Me neither :)
15:54:34 efried mordred: I started focusing more selfishly on placement stuff.
15:54:55 mordred efried: yah. honestly the use of the python client libs for inter-service communication just makes things harder - but I haven't actually gotten far enough along on my list of rocks to push up hill to start on that one yet - maybe post-rocky
15:56:43 efried mordred: I started to feel like that might be a bit too idealistic, really. The clients can add some project-specific value - though there's certainly consolidation/refactoring that could be done.
15:56:58 mordred efried: the work to align on what you've done in nova - with using keystoneauth to register the oslo.config options and to consume the options is great in either case ... and should allow us to later refactor to use not-client-lib easily without any operator impact, should we choose to
15:57:15 efried Yuh
15:57:59 mordred efried: my experience is that they provide negative value as soon as you are a consumer of more than one service because each one 'adds value' in their own special way that you have to figure out - whereas the REST APIs themselves are ACTUALLY quite good and are surprisingly consistent already
15:58:12 mriedem mordred: efried: L463 https://etherpad.openstack.org/p/community-goals
15:58:14 efried mm
15:58:59 mordred efried: like, I thought openstack's rest apis were worse than they are back when my only consumption of them was the client libs - but as soon as I switch to REST, I realized that the openstack developers had actually done a great job in making me some excellent apis
15:59:14 efried mriedem: ack
16:17:55 openstackgerrit Hongbin Lu proposed openstack/nova master: Handle RPC timeout on get_console_output https://review.openstack.org/525335
16:19:59 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove unused tempest-dsvm-lxc-rc https://review.openstack.org/539244
16:22:54 openstackgerrit Ed Leafe proposed openstack/nova master: Fix invalid UUIDs in test_compute.py https://review.openstack.org/531479
16:33:11 openstackgerrit Stephen Finucane proposed openstack/nova master: trivial: Fix invalid UUIDs https://review.openstack.org/539247
16:33:25 stephenfin edleafe: I'd been working on something similar, thankfully with no overlap ^
16:35:33 edleafe stephenfin: heh, I'm just about ready to push a fix for the rest. Bet there's overlap there
16:35:34 openstackgerrit Stephen Finucane proposed openstack/nova master: trivial: Don't use 'Test' prefix for non-TestCase classes https://review.openstack.org/539251
16:35:35 openstackgerrit Stephen Finucane proposed openstack/nova master: trivial: Resolve "X is renamed to Y" warnings https://review.openstack.org/539252
16:35:35 openstackgerrit Stephen Finucane proposed openstack/nova master: Don't modify objects directly https://review.openstack.org/539253
16:35:55 stephenfin edleafe: Go for it. I'm guessing mine has issue anyway
16:36:00 stephenfin *issues
16:36:13 mriedem melwitt: i saw you posted backports for https://review.openstack.org/#/c/533371/ - i left some comments about impacts to the CachingScheduler, of which i'm not sure there are any, but it'd be nice to get a 2nd set of eyes on that part of it.
16:36:47 stephenfin ...as all code written on a Friday evening is likely to have
16:37:07 Spaz-Work really don't like this test...
16:37:18 Spaz-Work mock patching hurting my brain
16:37:27 openstackgerrit Ed Leafe proposed openstack/nova master: Fix invalid UUIDs in remaining tests https://review.openstack.org/539254
16:37:32 edleafe stephenfin: ^^
16:38:35 mdbooth stephenfin: https://review.openstack.org/#/c/539247/1/nova/tests/unit/virt/libvirt/test_vif.py does nova.network.model use o.v.o. ?
16:39:08 stephenfin mdbooth: It uses os-vif objects, which are o.v.o based
16:39:42 mdbooth stephenfin: I believe you, but... where?
16:39:44 stephenfin Wait, I have that confused
16:39:55 dansmith yeah, no
16:40:00 dansmith that stuff is not o.vo based
16:40:03 mdbooth Given that both you and edleafe have made the same changes, I assume they're required
16:40:04 dansmith nor versioned
16:40:12 mdbooth I just can't see where the dep comes in
16:41:09 stephenfin I never really thought to question the warnings, but there is something going on there with os-vif. Lemme root it out
16:41:59 edleafe mdbooth: did you see the warnings? They're listed in the bug
16:42:23 stephenfin mdbooth, dansmith: It's nova/network/os_vif_util.py
16:42:55 stephenfin We have code to convert nova's VIF/network/<other networking thingys> to os-vif equivalents
16:42:59 stephenfin which _are_ versioned
16:51:38 mdbooth stephenfin: How would I reproduce these warnings? I just ran the tests in nova.tests.unit.virt.libvirt.test_vif, and I didn't get any uuid warnings
16:51:57 mdbooth Just warnings about deprecation of api extensions
16:52:42 dansmith stephenfin: aye
16:53:10 stephenfin mdbooth: I think you've to trigger something to do with PYTHONWARNINGS. I was seeing them when I ran the testsuite with pytest
16:53:26 stephenfin mdbooth: They should be visible in any recent gate logs
16:54:45 stephenfin mdbooth: This is the warning that's being raised https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/fields.py#L346
16:55:01 dansmith mriedem: do we have a bug for the need-a-limit thing? if not, I assume I should open one at this point because FF
16:57:00 openstackgerrit Balazs Gibizer proposed openstack/nova master: cover migration cases with functional tests https://review.openstack.org/493865
16:57:28 mriedem dansmith: nope no bug but was considering it a bug fix anyway
16:57:28 openstackgerrit Matt Riedemann proposed openstack/nova master: Add a nova-caching-scheduler job to the experimental queue https://review.openstack.org/539260
16:57:34 mriedem dansmith: feel free to open one though
16:57:57 openstackgerrit Balazs Gibizer proposed openstack/nova master: cover migration cases with functional tests https://review.openstack.org/493865
17:00:09 openstackgerrit Dan Smith proposed openstack/nova master: Pass limit to /allocation_requests https://review.openstack.org/531517
17:00:14 dansmith mriedem: ^
17:13:39 openstackgerrit Brooks Kaminski proposed openstack/nova master: XenAPI/Stops the migration of volume backed VHDS https://review.openstack.org/533168
17:15:13 openstackgerrit Sylvain Bauza proposed openstack/nova master: Provide support matrix and doc for VGPU https://review.openstack.org/539266
17:15:27 openstackgerrit Ed Leafe proposed openstack/nova master: Fix invalid UUIDs in remaining tests https://review.openstack.org/539254
17:15:28 mriedem gibi: sorry, forgot about the notification meeting
17:15:54 bauzas mriedem: jianghuaw: see the first rev for documenting the VGPU feature https://review.openstack.org/#/c/539266/
17:18:09 Spaz-Work Thanks for the ideas again bauzas, I think I hit the points you were concerned about
17:18:52 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: Integrate Mypy Type Checking https://review.openstack.org/538217
17:30:11 gibi mriedem: no worries, as you saw there was nothing to talk about
17:34:32 mriedem bauzas: thanks, that's a nice start; comments inline

Earlier   Later