Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-09-08
14:38:36 gibi thanks for the feedback
14:40:39 gibi mriedem: also thanks for the ML reply on my notification question, elod will start working on adding the new interface_attach notification next week
14:43:04 mriedem \o/
14:44:05 gibi I'm logging off for the weekend. See you in Denver
14:44:10 mriedem have a good one
14:44:16 gibi thanks
14:58:55 openstackgerrit Lee Yarwood proposed openstack/nova stable/pike: Move hash ring initialization to init_host() for ironic https://review.openstack.org/502082
15:03:54 openstackgerrit Stephen Finucane proposed openstack/nova master: Fix AZ related API docs https://review.openstack.org/456655
15:11:22 sdague stephenfin: I think you dropped a word - https://review.openstack.org/#/c/456655
15:11:30 sdague after that, +2
15:12:16 openstackgerrit Stephen Finucane proposed openstack/nova master: Fix AZ related API docs https://review.openstack.org/456655
15:12:31 stephenfin sdague: Second time I've done that today :( Done
15:12:46 sdague +2
15:12:49 stephenfin ta
15:16:44 mriedem stephenfin: couple nits inline there
15:17:17 mriedem "Typically, you use availability zones to arrange OpenStack compute hosts into logical groups."
15:17:27 mriedem you (the end user?) doesn't actually arrange the compute hosts
15:17:31 mriedem the admin does that with host aggregates
15:17:50 mriedem and labels them with AZs that the end user (non-admin) can then use for isolation
15:18:07 mriedem but maybe i'm splitting hairs
15:22:25 openstackgerrit Stephen Finucane proposed openstack/nova master: Fix AZ related API docs https://review.openstack.org/456655
15:22:45 stephenfin mriedem: I agree, and I think I've addressed it
15:27:04 mriedem cool, +2
15:28:00 mikal sdague: can I get a +W on https://review.openstack.org/#/c/472229/ please? It has two +2's but the +W fell off when we went around a corner too fast.
15:31:40 sdague mikal: done
15:31:47 mikal Ta
15:32:18 sdague mikal: so, is there actually a privsep discussion area somewhere carved out yet for PTG?
15:36:12 mriedem it's in the etherpad
15:36:22 mriedem https://etherpad.openstack.org/p/nova-ptg-queens
15:36:32 mriedem i don't have a specific time slotted for that
15:36:56 sdague mriedem: right, it's on the big list, but not with a timeslot
15:37:10 sdague I was also wondering if it was in the class of things to have mon/tues time somewhere
15:37:18 sdague mostly to get folks more introduced to the idea
15:37:26 mriedem it's not in the mon/tues xp stuff as far as i know
15:37:30 mriedem unless mikal is driving that
15:37:38 mriedem friday is the default timeslot for 'everything else'
15:44:47 openstackgerrit Stephen Finucane proposed openstack/nova master: doc: Rework man pages https://review.openstack.org/502105
15:50:42 openstackgerrit Stephen Finucane proposed openstack/nova master: docs: Rename cellsv2_layout -> cellsv2-layout https://review.openstack.org/498821
15:50:42 openstackgerrit Stephen Finucane proposed openstack/nova master: WIP! doc: Add contents page https://review.openstack.org/498820
15:50:43 openstackgerrit Stephen Finucane proposed openstack/nova master: doc: Cleanup of existing index pages https://review.openstack.org/498819
15:57:43 mikal dansmith: https://etherpad.openstack.org/p/opendev-sf-use-cases
15:58:20 mikal mriedem / sdague: I had expected it to be scheduled in the nova thing, but that doesn't seem to have happened
15:59:00 mikal I kind of feel like we should do our thing this release, and then push it out to others next release
16:01:02 mriedem ok i still need to carve up the placement stuff into slots
16:01:03 sdague mikal: that's fine, it does seem like if there were interested parties on Tues afternoon or something to gather and do some bootstrapping
16:01:32 sdague it feels like one of those things that's enough of a shift some bootstrapping on what's going on, and good patterns, would be useful
16:02:06 mriedem i have moved some of the placement stuff to it's own etherpad https://etherpad.openstack.org/p/nova-ptg-queens-placement
16:02:20 mriedem i think we're going to do the high priority stuff in the 2 hour slot on wed afternoon
16:02:31 mriedem and then bump the other new stuff for placement to thursday afternoon after neutron
16:02:37 mriedem plus whatever else to friday
16:05:26 mriedem mikal: maybe we do privsep at 4 on wednesday
16:05:37 mriedem after everyone is exhausted
16:06:54 sdague less exhausted than friday
16:07:03 sdague we might be able to complete sentences
16:07:39 cdent .
16:10:47 alaski johnthetubaguy: mriedem I vaguely recall some brief discussions with bauwser about discovering scheduler hints. I was mostly taking the stance that codfying the API schema for scheduler hints was silly because there was no correlation between what the API allows and what the deployment allowed.
16:10:53 openstackgerrit Matt Riedemann proposed openstack/nova master: doc: fix flavor notes https://review.openstack.org/502112
16:11:26 mriedem alaski: i was mostly thinking about a GET /scheduler_hints or something that just listed what was available with a description
16:11:42 mriedem but that's really config-driven api
16:11:46 mriedem based on the enabled scheduler filters
16:11:55 mriedem but at least it's an api
16:12:06 alaski yeah, it would be a start
16:12:14 mriedem otherwise all mordred has to rely on is docs per cloud
16:12:32 alaski yep, and those are always up to date and accurate
16:12:43 cdent I suppose it is a step in the right direction if it is deemed impossible to leapfrog to some kind of generic capabilities thing
16:12:53 mordred mriedem: in fact, I generally don't have docs per cloud to depend on
16:13:27 mordred mriedem: and have to figure things out by trial and error, then writing a config setting and doc for the feature so other people don't have to trial and error
16:14:27 mordred cdent: I'd very much like to chat next week about cloud profiles, version discovery and general capabilities things
16:15:11 mikal mriedem: I live to obey
16:15:22 mikal mriedem: it would be good to explain the underlying ideas to core so that they know what to look for
16:15:23 cdent mordred: cool. we put it on the api room etherpad, so it is a known topic but I suspect we’ll have to chat about it multiple times to get all the right people
16:15:51 mikal mriedem: but it is my pleasure to serve and you can just wake me up from my nap whenever you need me
16:16:03 mikal Us funemployed bums only go to sessions which look personally interesting
16:16:07 mikal Or have snacks
16:16:52 alaski The issue as I saw it is that the scheduler was extensible, but that extensibility had ramifications on the API. So there was no way, given what was in place, to enforce uniformity across deployments. e.g. cloudA could have an 'affinity' hint and cloudB could have a 'closeness' hint that meant the same thing, or two cloud could have an 'affinity' hint that meant different things.
16:17:55 alaski Discovery of what is available is a big help, but there's a second layer issue of understanding what the discovered capability actually means
16:18:39 mriedem alaski: yeah, exactly
16:19:30 mriedem so you can maybe write something that understands how the common hints in nova work, and then at least check if they are available in cloud A and B (which are your preferred clouds in this case),
16:19:48 mriedem and then if you also know that cloud B has this other "fancy" hint, you can use that if it's available, otherwise you dont
16:22:36 alaski yeah. Understanding and discovering in-tree hints would be a huge boon. And then discovery of "custom" hints would be a nice addition for those who understand what they mean
16:24:37 mriedem sean-k-mooney: i could have sworn you had something about bandwidth-based scheduling in the nova ptg etherpad, linking to the neutron spec https://review.openstack.org/#/c/396297/
16:24:41 mriedem but i can't find it now
16:24:52 mriedem oh it's in here https://etherpad.openstack.org/p/nova-ptg-queens-generic-device-management
16:25:01 cdent the etherpad that consumes all topics
16:27:23 mriedem yeah no crap
16:27:33 mriedem some of that is going to be during the neutron slot
16:27:39 mriedem otherwise friday morning probably
16:39:45 tonygunk softball question: I recently changed to shared nfs for /var/lib/nova/instances on compute nodes for live migration. Getting this error and want to know where to look:
16:39:46 tonygunk http://paste.openstack.org/raw/620738/
16:40:19 tonygunk nova.compute.manager Stderr: u'qemu-img: Could not open \'/var/lib/nova/instances/b1b9c5c9-da00-4b2c-bc11-784c0da18b32/disk\': Failed to get shared "write" lock
16:40:55 openstackgerrit Ildiko Vancsa proposed openstack/nova master: WIP: Allow multi-attach in compute api https://review.openstack.org/271047
16:40:57 openstackgerrit Ildiko Vancsa proposed openstack/nova master: libvirt: Allow multiple volume attachments https://review.openstack.org/267587
16:44:31 cdent tonygunk: are you sure you have all your necessary daemons running? I can’t remember the details on linux, but maybe rpc.lockd?
16:44:51 cdent or rpc.statd
16:49:22 tonygunk I'll look into that thanks
16:58:41 openstackgerrit Sean Dague proposed openstack/nova master: Refactor ServerMovingTests for non-move tests https://review.openstack.org/498596
17:00:51 openstackgerrit Matthew Booth proposed openstack/nova master: Automatically revert resize which fails on destination https://review.openstack.org/462521
17:00:52 openstackgerrit Matthew Booth proposed openstack/nova master: Ensure errors_out_migration errors out migration https://review.openstack.org/479802
17:00:52 openstackgerrit Matthew Booth proposed openstack/nova master: Use Migration object in ComputeManagerMigrationTestCase https://review.openstack.org/502126
17:15:43 tonygunk all daemons running fine on nfs server

Earlier   Later