Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-09-08
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
17:18:06 cdent tonygunk: I’m not certain but I think you need some of it on the client too, but my info may be out of date
17:59:47 mriedem huh, horizon has a page for selecting scheduling hints when creating a vm
17:59:57 mriedem so i guess that must be plugged into the dashboard config somewhere
18:00:22 mriedem the fun things i find when i use horizon once per year
18:00:22 cburgess mriedem It comes from glance.
18:00:31 mriedem cburgess: scheduler hints?
18:00:35 mriedem you mean image meta?
18:00:59 cburgess mriedem Yeah... there is some facility in glance now to load up a bunch of arbitrary metadata that horizon then pulls to display all that.
18:01:02 cburgess Let me find it...
18:01:06 mriedem yes i know about that
18:01:08 mriedem this isn't that
18:01:22 mriedem https://github.com/openstack/glance/tree/master/etc/metadefs
18:01:27 mriedem ^ is the glance image meta stuff
18:01:51 cburgess mriedem You sure horizon isn't just pulling data from there for the scheduler hits as well?
18:02:06 mriedem glance image meta has nothing to do with scheduler hints in nova
18:02:33 cburgess mriedem I know that.. glance metaref has nothing to do with nova at all. YOu can load any arbittary thin you want. But its how horizon populates all those fancy pull downs.
18:02:57 mriedem chet, who is on first?
18:03:05 cburgess mriedem LOL
18:03:07 cburgess Fair
18:03:40 cburgess mriedem I haven't used horizon in a while either.. what panel is that being displayed in?
18:04:35 mriedem there is a scheduler hints sub-panel during 'launch instance'o
18:04:39 mriedem it's empty
18:04:48 mriedem so it must be something an admin can configure in horizon
18:07:49 cburgess mriedem I see glance metarefs that have a type association of OS::Nova::Server and a target of "scheduler_hint".
18:08:07 cburgess https://github.com/openstack/glance/blob/master/etc/metadefs/cim-processor-allocation-setting-data.json#L25-L28
18:08:36 cburgess I don't actually see anything that is a hint in that file though.
18:08:47 mriedem i don't know what "CIM Processor Allocation Setting" has to do with that
18:10:50 cburgess mriedem All I'm saying is that if you look under the hood I suspect that horizon is pulling a list from the metaref some how.

Earlier   Later