Friday, 2017-04-21

*** winston-d_ has joined #openstack-nova00:00
*** ijw has quit IRC00:01
*** gouthamr has quit IRC00:03
*** jdurgin has quit IRC00:04
openstackgerritSean Dague proposed openstack/nova master: PowerVM Driver: power_on/off and reboot  https://review.openstack.org/42738000:09
*** artom has quit IRC00:10
*** artom has joined #openstack-nova00:11
*** artom has quit IRC00:12
*** artom has joined #openstack-nova00:12
*** Apoorva_ has joined #openstack-nova00:12
*** thorst has quit IRC00:12
*** kaisers has joined #openstack-nova00:15
*** Apoorva has quit IRC00:16
*** Apoorva_ has quit IRC00:16
*** dtp has quit IRC00:17
*** jdurgin has joined #openstack-nova00:17
*** jaypipes has quit IRC00:19
*** slaweq has joined #openstack-nova00:21
*** salv-orlando has quit IRC00:22
*** markvoelker has joined #openstack-nova00:25
*** slaweq has quit IRC00:29
*** MasterOfBugs has quit IRC00:37
*** mriedem has quit IRC00:43
*** jerrygb has joined #openstack-nova00:45
*** zhurong has joined #openstack-nova00:50
*** jerrygb has quit IRC00:52
*** lyan has joined #openstack-nova00:53
*** dimtruck is now known as zz_dimtruck00:56
*** ijw has joined #openstack-nova00:58
*** Sukhdev has joined #openstack-nova00:59
*** dillaman has quit IRC01:03
*** jerrygb has joined #openstack-nova01:04
*** ijw has quit IRC01:07
*** fragatina has quit IRC01:08
*** cNilesh has joined #openstack-nova01:11
*** zz_dimtruck is now known as dimtruck01:14
*** phuongnh has joined #openstack-nova01:16
*** dillaman has joined #openstack-nova01:17
*** salv-orlando has joined #openstack-nova01:19
*** dimtruck is now known as zz_dimtruck01:22
*** Sukhdev has quit IRC01:25
*** thorst has joined #openstack-nova01:25
*** slaweq has joined #openstack-nova01:26
*** Sukhdev has joined #openstack-nova01:29
*** Sukhdev has quit IRC01:30
*** slaweq has quit IRC01:31
*** gcb has joined #openstack-nova01:31
*** gjayavelu has quit IRC01:31
*** thorst has quit IRC01:32
*** sree has joined #openstack-nova01:35
*** kevinz has joined #openstack-nova01:38
*** sree has quit IRC01:39
*** kaisers has quit IRC01:40
*** yingwei has joined #openstack-nova01:40
openstackgerritHuan Xie proposed openstack/nova master: WIP: XenAPI use os-xenapi v2 in nova  https://review.openstack.org/45349301:43
*** j_king has joined #openstack-nova01:46
*** tbachman has quit IRC01:46
*** baoli has joined #openstack-nova01:46
*** Sukhdev has joined #openstack-nova01:47
*** Sukhdev has quit IRC01:47
*** salv-orlando has quit IRC01:48
*** smatzek has joined #openstack-nova01:49
*** zz_dimtruck is now known as dimtruck01:50
*** baoli has quit IRC01:50
*** baoli has joined #openstack-nova01:50
*** kaisers has joined #openstack-nova01:53
*** kaisers has quit IRC01:57
*** awaugama has joined #openstack-nova01:58
*** ssurana has quit IRC02:01
*** ssurana has joined #openstack-nova02:01
*** ssurana has quit IRC02:01
*** smatzek has quit IRC02:02
*** yamahata has quit IRC02:03
*** chatter29 has joined #openstack-nova02:04
chatter29hey guys02:04
chatter29allah is doing02:04
*** ijw has joined #openstack-nova02:04
chatter29sun is not doing allah is doing02:04
chatter29to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger02:04
*** thorst has joined #openstack-nova02:05
*** thorst has quit IRC02:05
*** thorst has joined #openstack-nova02:05
*** chatter29 has quit IRC02:06
*** ijw has quit IRC02:09
*** thorst has quit IRC02:10
*** gouthamr has joined #openstack-nova02:14
*** sdague has quit IRC02:16
*** gongysh has joined #openstack-nova02:22
openstackgerritTakashi NATSUME proposed openstack/nova master: api-ref: Fix parameters in servers-action-console-output  https://review.openstack.org/45871302:23
openstackgerritLei Zhang proposed openstack/nova master: Add sync traits command for placement  https://review.openstack.org/45012502:24
*** hongbin_ has joined #openstack-nova02:26
*** slaweq has joined #openstack-nova02:28
*** gcb has quit IRC02:31
*** slaweq has quit IRC02:35
*** thorst has joined #openstack-nova02:36
*** gcb has joined #openstack-nova02:44
*** gcb has quit IRC02:44
*** salv-orlando has joined #openstack-nova02:45
*** thorst has quit IRC02:50
*** thorst has joined #openstack-nova02:50
*** thorst has quit IRC02:50
*** ijw has joined #openstack-nova02:52
*** kaisers has joined #openstack-nova02:54
*** Shashi has joined #openstack-nova02:54
*** psachin has joined #openstack-nova02:57
*** dikonoor has joined #openstack-nova02:57
*** ijw has quit IRC02:58
*** amotoki has joined #openstack-nova02:58
openstackgerritTakashi NATSUME proposed openstack/nova master: api-ref: Use 'note' directive  https://review.openstack.org/45871703:00
*** dillaman has quit IRC03:01
*** salv-orl_ has joined #openstack-nova03:03
*** salv-orlando has quit IRC03:03
*** amotoki has quit IRC03:03
*** takashin has quit IRC03:04
*** winston-d_ has quit IRC03:04
*** winston-d_ has joined #openstack-nova03:04
*** takashin has joined #openstack-nova03:04
*** david-lyle has joined #openstack-nova03:11
openstackgerritGhanshyam Mann proposed openstack/nova master: Explicitly define enum type as string in schema  https://review.openstack.org/45643003:15
*** salv-orl_ has quit IRC03:16
*** fragatina has joined #openstack-nova03:19
*** david-lyle has quit IRC03:19
openstackgerritZhenyu Zheng proposed openstack/nova master: Support tag instances when boot  https://review.openstack.org/39432103:21
*** vladikr has quit IRC03:24
*** hongbin_ has quit IRC03:25
*** nicolasbock has quit IRC03:28
*** imacdonn has quit IRC03:28
*** coreywright has quit IRC03:28
*** imacdonn has joined #openstack-nova03:29
*** Sukhdev has joined #openstack-nova03:30
*** slaweq has joined #openstack-nova03:32
*** slaweq has quit IRC03:39
*** kaisers has quit IRC03:41
*** kaisers has joined #openstack-nova03:41
*** zhurong has quit IRC03:43
*** lyan has quit IRC03:44
*** coreywright has joined #openstack-nova03:45
*** ijw has joined #openstack-nova03:46
*** ijw has quit IRC03:46
*** thorst has joined #openstack-nova03:51
*** guchihiro has joined #openstack-nova03:54
*** haplo37 has quit IRC03:54
*** thorst has quit IRC03:56
*** dave-mcc_ has quit IRC04:02
*** haplo37 has joined #openstack-nova04:04
*** kaisers has quit IRC04:05
*** vks1 has joined #openstack-nova04:07
*** amotoki has joined #openstack-nova04:09
*** baoli has quit IRC04:09
*** salv-orlando has joined #openstack-nova04:13
*** gongysh has quit IRC04:14
*** awaugama has quit IRC04:15
*** trinaths has joined #openstack-nova04:16
openstackgerritTakashi NATSUME proposed openstack/nova master: api-ref: Parameter verification for servers-actions (2/4)  https://review.openstack.org/45556804:19
openstackgerritTakashi NATSUME proposed openstack/nova master: api-ref: Parameter verification for servers-actions (3/4)  https://review.openstack.org/45557004:19
openstackgerritTakashi NATSUME proposed openstack/nova master: api-ref: Parameter verification for servers-actions (4/4)  https://review.openstack.org/45557304:19
openstackgerritTakashi NATSUME proposed openstack/nova master: api-ref: Example verification for servers-actions.inc  https://review.openstack.org/45456504:20
*** yamahata has joined #openstack-nova04:24
*** xyang1_ has joined #openstack-nova04:29
*** xyang1 has quit IRC04:32
*** xyang1_ is now known as xyang104:32
*** MasterOfBugs has joined #openstack-nova04:33
*** kristian__ has joined #openstack-nova04:34
*** neilsun has quit IRC04:34
*** slaweq has joined #openstack-nova04:35
*** kristian__ has quit IRC04:38
*** ayogi has joined #openstack-nova04:38
*** salv-orlando has quit IRC04:41
*** udesale has joined #openstack-nova04:42
*** gongysh has joined #openstack-nova04:42
*** adisky_ has joined #openstack-nova04:45
*** salv-orlando has joined #openstack-nova04:46
*** neilsun has joined #openstack-nova04:48
*** armax has quit IRC04:50
*** thorst has joined #openstack-nova04:52
*** thorst has quit IRC04:57
*** kristian__ has joined #openstack-nova05:00
*** kristian__ has quit IRC05:00
*** kristian__ has joined #openstack-nova05:00
*** slaweq has quit IRC05:02
*** ratailor has joined #openstack-nova05:05
*** kristian__ has quit IRC05:05
*** kaisers has joined #openstack-nova05:05
*** dimtruck is now known as zz_dimtruck05:09
*** gongysh has quit IRC05:09
*** baoli has joined #openstack-nova05:10
*** kaisers has quit IRC05:10
*** nkorabli has joined #openstack-nova05:15
*** baoli has quit IRC05:15
*** kristian__ has joined #openstack-nova05:17
*** gcb has joined #openstack-nova05:18
*** kristian__ has quit IRC05:22
*** nkorabli has quit IRC05:25
*** nkorabli has joined #openstack-nova05:26
*** diga has joined #openstack-nova05:30
*** nkorabli has quit IRC05:30
*** prateek has joined #openstack-nova05:35
*** kevinz has quit IRC05:38
*** neilsun has quit IRC05:39
*** lpetrut has joined #openstack-nova05:47
*** hferenc has joined #openstack-nova05:48
*** Sukhdev has quit IRC05:48
*** kylek3h has quit IRC05:52
*** kristian__ has joined #openstack-nova05:52
*** ralonsoh has joined #openstack-nova05:52
*** kylek3h has joined #openstack-nova05:52
*** thorst has joined #openstack-nova05:52
openstackgerritAlex Xu proposed openstack/python-novaclient master: Add `instance-uuid` flag to the migration-list  https://review.openstack.org/45872805:53
*** kristian__ has quit IRC05:57
*** kylek3h has quit IRC05:57
*** neilsun has joined #openstack-nova05:57
*** thorst has quit IRC05:57
*** slaweq has joined #openstack-nova05:59
*** gongysh has joined #openstack-nova05:59
*** brault has quit IRC06:01
*** brault has joined #openstack-nova06:01
*** sridharg has joined #openstack-nova06:02
Dinesh_Bhoralex_xu: Hi, if you have time then may I have your attention on this? https://review.openstack.org/#/c/457890/06:02
*** slaweq has quit IRC06:04
*** brault has quit IRC06:05
*** jaosorior has joined #openstack-nova06:06
*** kaisers has joined #openstack-nova06:06
*** Oku_OS-away is now known as Oku_OS06:08
*** sree has joined #openstack-nova06:10
*** salv-orlando has quit IRC06:11
*** salv-orlando has joined #openstack-nova06:11
*** kristian__ has joined #openstack-nova06:13
*** kevinz has joined #openstack-nova06:13
*** rcernin has joined #openstack-nova06:15
*** salv-orlando has quit IRC06:16
*** kristian__ has quit IRC06:17
*** pcaruana has joined #openstack-nova06:18
*** hoonetorg has quit IRC06:19
*** zhurong has joined #openstack-nova06:21
*** tbachman has joined #openstack-nova06:25
*** tbachman has quit IRC06:27
*** kaisers1 has quit IRC06:30
*** phuongnh has quit IRC06:30
*** phuongnh has joined #openstack-nova06:31
*** hoonetorg has joined #openstack-nova06:32
*** voelzmo has joined #openstack-nova06:34
*** lpetrut has quit IRC06:37
*** udesale__ has joined #openstack-nova06:37
*** gouthamr has quit IRC06:39
*** zhurong has quit IRC06:39
*** satyar has joined #openstack-nova06:39
*** sridharg has quit IRC06:40
*** udesale has quit IRC06:40
*** kaisers1 has joined #openstack-nova06:41
*** ltomasbo|away is now known as ltomasbo06:42
*** zhurong has joined #openstack-nova06:42
*** gcb has quit IRC06:42
*** kristian__ has joined #openstack-nova06:43
*** kristian__ has quit IRC06:47
*** andreas_s has joined #openstack-nova06:47
*** ralonsoh_ has joined #openstack-nova06:49
openstackgerritZhenyu Zheng proposed openstack/nova master: Support tag instances when boot  https://review.openstack.org/39432106:49
*** ralonsoh_ has quit IRC06:51
openstackgerritAlex Xu proposed openstack/nova master: Deprecate Multinic, floatingip action and os-virtual-interface API  https://review.openstack.org/45718106:51
openstackgerritAlex Xu proposed openstack/nova master: Move all the deprecated server actions together into the bottom of doc  https://review.openstack.org/45873806:51
openstackgerritAlex Xu proposed openstack/nova master: Adjust the order of server actions in api-ref  https://review.openstack.org/45873906:51
*** ralonsoh has quit IRC06:51
*** kylek3h has joined #openstack-nova06:53
*** thorst has joined #openstack-nova06:53
*** zhurong has quit IRC06:54
*** gcb has joined #openstack-nova06:56
openstackgerritZhenyu Zheng proposed openstack/nova master: Add description to policies in hypervisors.py  https://review.openstack.org/45129406:58
*** kylek3h has quit IRC06:58
*** thorst has quit IRC06:58
*** ralonsoh has joined #openstack-nova06:59
*** slaweq has joined #openstack-nova07:00
*** salv-orlando has joined #openstack-nova07:01
*** markus_z has joined #openstack-nova07:01
*** MasterOfBugs has quit IRC07:09
*** tesseract has joined #openstack-nova07:11
*** baoli has joined #openstack-nova07:11
alex_xujohnthetubaguy: how about rename all of those titles in api-ref as URL, for example https://developer.openstack.org/api-ref/compute/#servers-run-an-action-servers-action rename to '/servers/{server_uuid}/action'07:12
*** guchihiro has quit IRC07:12
*** baoli has quit IRC07:16
*** rmart04 has joined #openstack-nova07:18
*** gongysh has quit IRC07:18
*** trinaths has left #openstack-nova07:19
*** kaisers has quit IRC07:20
*** mlakat has joined #openstack-nova07:23
*** udesale has joined #openstack-nova07:24
*** udesale__ has quit IRC07:26
*** kristian__ has joined #openstack-nova07:27
*** mkrai_ has joined #openstack-nova07:29
*** zhurong has joined #openstack-nova07:31
*** kristian__ has quit IRC07:32
*** sridharg has joined #openstack-nova07:32
*** damien_r has joined #openstack-nova07:32
*** sree has quit IRC07:33
*** sree has joined #openstack-nova07:34
*** sree has quit IRC07:36
*** jpena|off is now known as jpena07:39
openstackgerritTakashi NATSUME proposed openstack/nova master: WIP: Specify keymap on server boot (1/2)  https://review.openstack.org/45875207:48
*** kristian__ has joined #openstack-nova07:48
*** Shunli has joined #openstack-nova07:51
*** kristian__ has quit IRC07:52
*** kylek3h has joined #openstack-nova07:54
*** thorst has joined #openstack-nova07:54
johnthetubaguyalex_xu: I was thinking about those when I was going through your patches yesterday...07:55
johnthetubaguyalex_xu: I think we probably should reorganise based around the URL patterns, maybe we should etherpad out some possible ways to arrange those07:55
*** phuongnh has quit IRC07:56
johnthetubaguyalex_xu: https://etherpad.openstack.org/p/nova-api-ref-organisation07:56
*** slaweq has quit IRC07:58
*** kylek3h has quit IRC07:58
*** zzzeek has quit IRC08:00
*** zzzeek has joined #openstack-nova08:00
*** slaweq has joined #openstack-nova08:01
*** takashin has left #openstack-nova08:02
johnthetubaguyalex_xu: I take that back, its basically there08:03
*** lucas-afk is now known as lucasagomes08:07
*** gongysh has joined #openstack-nova08:09
*** jerrygb_ has joined #openstack-nova08:11
*** jerrygb has quit IRC08:11
*** derekh has joined #openstack-nova08:12
*** gouthamr has joined #openstack-nova08:13
*** rcernin has quit IRC08:13
*** thorst has quit IRC08:14
*** zhurong has quit IRC08:15
*** kaisers has joined #openstack-nova08:16
*** efoley_ has joined #openstack-nova08:16
*** slaweq has quit IRC08:17
*** slaweq has joined #openstack-nova08:17
*** efoley__ has joined #openstack-nova08:18
*** slaweq has quit IRC08:19
*** slaweq_ has joined #openstack-nova08:19
*** jerrygb_ has quit IRC08:21
*** efoley_ has quit IRC08:21
*** zhurong has joined #openstack-nova08:22
*** gouthamr has quit IRC08:22
*** jerrygb has joined #openstack-nova08:22
sfinucancfriesen: I am now08:23
*** karimb has joined #openstack-nova08:23
*** kristian__ has joined #openstack-nova08:24
*** brault has joined #openstack-nova08:27
*** rcernin has joined #openstack-nova08:27
*** ralonsoh has quit IRC08:30
*** ralonsoh has joined #openstack-nova08:32
mdboothimacdonn lyarwood: https://bugs.launchpad.net/os-brick/+bug/166403208:36
openstackLaunchpad bug 1664032 in os-brick "iSCSI Multipath may leave residual paths due to race condition" [Undecided,Fix released] - Assigned to Gorka Eguileor (gorka)08:36
openstackgerritBhagyashri Shewale proposed openstack/nova master: Don't create instance backup image if rotation is 0  https://review.openstack.org/40964408:37
lyarwoodmdbooth: nice, so limiting the rescans would help for iSCSI but I wonder how many other backends could still race?08:39
mdboothlyarwood: Well the issue is peculiar to a global rescan08:40
mdboothlyarwood johnthetubaguy: While I was thinking about this, though, a couple of things occurred to me08:40
mdboothNamely that os-brick probably should explicitly know about terminate connection08:41
mdboothAnd that the required scope of locks is always going be be driver-specific08:41
johnthetubaguyit does feel like we need to have a more well understood relationship with os-brick08:41
johnthetubaguyI like the idea of negotiation about locking08:42
lyarwoodwell, terminate connection no longer exists in v308:42
mdboothlyarwood: The function exists, though08:42
mdboothDelete attachment, presumably?08:42
*** kristian__ has quit IRC08:42
lyarwoodright, but that's terminate connection and detach08:43
lyarwoodin v208:43
*** kristian__ has joined #openstack-nova08:43
*** cdent has joined #openstack-nova08:44
mdboothjohnthetubaguy: The problem with having differing scope of locks is that it's hard to represent that across an api boundary08:44
mdboothI mean, if backend A requires X to be serialised only with itself, backend B requires X and Y to be serialised, and backend C has no such restrictions08:45
mdboothHow do you abstract that for the caller?08:45
*** kristia__ has joined #openstack-nova08:45
*** kristia__ has quit IRC08:45
mdboothI think the locking would need to live in the backend08:46
*** kristia__ has joined #openstack-nova08:46
*** kristia__ has quit IRC08:46
*** kristian__ has quit IRC08:46
asettlecdent: you around? :)08:46
*** kristian__ has joined #openstack-nova08:46
*** kristian__ has quit IRC08:46
cdentasettle: I just showed up, what's up?08:46
*** kristian__ has joined #openstack-nova08:46
asettleMagic@08:46
asettlePlacement API :(08:47
*** kristian__ has quit IRC08:47
asettleAny chance you could take a look at this bug to help out Brian and myself? https://bugs.launchpad.net/openstack-manuals/+bug/168358508:47
openstackLaunchpad bug 1683585 in openstack-manuals "Placement endpoint configuration incorrect as written" [Undecided,New] - Assigned to Brian Moss (bmoss)08:47
* cdent looks08:47
lyarwoodmdbooth: so just serialise all volume operations (both local n-cpu and remote via c-api) for all backends?08:48
mdboothlyarwood: You could do that, but that's a big hammer08:48
mdboothAkin to a GIL ;)08:48
lyarwoodGBDML08:49
cdentasettle: ah, that. Yeah, so the issue is that there hasn't been consensus between nova, devstack, deb packagers, rpm packages on "where" placement is supposed to live08:49
mdboothhehe08:49
lyarwoodbut yeah, massive hammer, slows everything down08:49
asettlecdent: yep. Which is causing issues, it's our second bug of the same nature. We're going to have to chat about reversing it, I think. IT's just not working.08:49
cdentasettle: I would guess that what needs to happen is find out from the packages where they are putting it (it can go wherever they like), and make the docs reflect that08:49
cdents/packages/packagers/08:49
mdboothSuspect the problem would mostly be that 1 slow/malfunctioning thing would kill everything08:50
cdentasettle: I can reflect this on the bug report too08:50
asettlecdent: who can we get to sort out the packaging then?08:50
*** afazekas has quit IRC08:50
*** gongysh has quit IRC08:51
cdentasettle: I don't have the names at the top of my head. johnthetubaguy and mdbooth you know who the contacts are for ubuntu and rdo packages?08:51
mdboothlyarwood: ^^^ ?08:51
*** gszasz has joined #openstack-nova08:52
* mdbooth reads the bug08:52
mdboothcdent: You looking for a default port number?08:53
cdentmdbooth: no08:54
cdentlooking for agreement between the various parties on where it will be placed, or at least authoritative statements on how things are current configured08:54
asettlecdent: thanks for looking into it. Contextually, could you please explain to me why this was implemented without consensus? Am I msising something? :/08:55
*** kylek3h has joined #openstack-nova08:55
cdenthmmm08:55
mdboothcdent: Being dim, just trying to understand what 'where' means in this context.08:55
cdentI'm pretty sure that the rpm and debs use the same port.08:55
mdboothwhere == port number?08:55
asettleOkay, well, that's good?08:55
alex_xujohnthetubaguy: yea, agree with that. begin to do some cleanup https://review.openstack.org/458738 https://review.openstack.org/45873908:56
bauzasasettle: mmm I do remember a problem with RDO packaging for the above bug, sec08:56
cdentThe issue entered into the discussion because there is a movement to stop using ports for hosting each of the individual services and instead put them on default http (80) or https (443) ports on the same controller host, distinguishing between services by a path prefix08:57
asettlebauzas: The same issue we were fiddling with a few weeks back?08:57
bauzasnot using ports means you have to have your virtualhost able to accept on this location08:57
openstackgerritjichenjc proposed openstack/nova master: [placement] Add doc for resource provider usages  https://review.openstack.org/45010508:57
*** amotoki has quit IRC08:57
cdentasettle, bauzas: there have been a few different bugs related to the configuration, for example, needing <Directory>08:57
bauzascdent: yup, AFAIR, it was related to that08:58
asettleOkay.08:58
bauzasI just have a shit ton of BZs to look at08:58
cdentasettle: I commented about those prefixes on the reviews, but it wasn't meant as a way of saying "do this", but rather as a way of saying "we should be moving in this direction, eventually"08:58
bauzasa-ha! think I found it08:58
cdent(like a warning of future change)08:59
bauzascdent: asettle: Red Hat Bugzilla – Bug 143494408:59
bauzasoops08:59
bauzashttps://bugzilla.redhat.com/show_bug.cgi?id=143494408:59
openstackbugzilla.redhat.com bug 1434944 in openstack-nova "[Ocata] openstack-nova-placement-api-15.0.0-1.el7.noarch missing <Directory> parameter" [Medium,Assigned] - Assigned to sferdjao08:59
*** kylek3h has quit IRC08:59
asettleI always liked the name 'bugzilla'08:59
asettlecdent: okay, thanks, that's a start :)08:59
asettleAh, this was after I pushed sgordon with a stick09:00
bauzasasettle: indeed :)09:00
* asettle waves her stick saround09:00
bauzasthat came back to my ears a week or so ago09:00
asettleThanks for finding this, bauzas09:00
asettleOkay, looks like Petr is on this.09:01
bauzasso I'd say the problem is on track for RDO, fix needs to go on its way09:01
cdentbauzas: this issue is different: it is making sure that the docs are aligned with the rdo config09:01
bauzasasettle: FWIW, Red Hat product-based OpenStack Platform is not impacted because we use TripleO09:01
*** aarefiev_afk is now known as aarefiev09:02
cdentthe directory thing causes a different issue09:02
bauzasasettle: where Puppet nukes that file and replaces by a correct config09:02
* asettle nods a lot09:02
asettleOkay09:02
bauzascdent: probably, have very few context09:02
bauzascdent: just saying that RDO .rpms aren't working anyway09:02
cdenthere's another semi-related thing the other day that I made: https://bugzilla.redhat.com/show_bug.cgi?id=144120009:02
openstackbugzilla.redhat.com bug 1441200 in openstack-nova "openstack-placement-api.conf not configured properly by the openstack-nova-placement-api rpm" [Unspecified,Post] - Assigned to nlevinki09:02
cdentsorry, I mean this one: https://bugzilla.redhat.com/show_bug.cgi?id=144120809:03
openstackbugzilla.redhat.com bug 1441208 in openstack-nova "placement api apache configuration does not align with documentation, ensure system does not work" [High,Closed: duplicate] - Assigned to nlevinki09:03
bauzascdent: BZ1441200 points to the same fix for RDO than 1434944 for resolution09:03
cdentthe first one is a duplicate of the one I created, mine has more context09:03
cdentbauzas: I'm providing these so asettle has context, which is what was asked for, not to find the right bug09:04
asettleYep, context me ahoy.09:04
asettleThanks cdent09:04
bauzascdent: np, just trying to understand the missing bits and the resolution path09:04
cdentasettle: in my bug report there are a lot of lurking "warnings"09:05
bauzasanyway, seems like the RDO fix needs to be aligned with docs, or the other way09:06
bauzassince both are pulling on two different directions09:06
asettleI completely agree.09:07
*** abalutoiu_ is now known as abalutoiu09:07
bauzasbut FWIW, whatever lands in RDO needs to properly amend the upstream docs, I do agree09:07
bauzasif those docs become wrong of course09:07
asettleProvided we're not going to have substantially broken docs for another month, I'm happy to do what we need to do.09:07
*** amotoki has joined #openstack-nova09:08
*** sambetts|afk is now known as sambetts09:08
*** djohnsto has joined #openstack-nova09:08
bauzasasettle: cdent: we have an internal bug triaging meeting today, will raise it up09:10
cdentbauzas++09:11
asettleThank you bauzas :)09:11
asettleCould you keep us up to date on the launchpad bug if I'm not around?09:11
bauzaswe = Nova team in Red Hat, not RDO team09:11
asettleI mean, I'm sure I will be :(09:11
bauzasasettle: that's at 1400UTC09:12
asettleLovely. Just in time for tea.09:12
cdentasettle: I think it is pretty clear that the communication for "how to do placement" went awry to many parties over the past... six months? So we can probably do some kind of retrospective or something to figure out what to do better in the future.  From my standpoint I didn't have enough insight into the process and made too many assumptions about it being under control09:12
bauzascdent: well, mostly because that's deployment choices09:13
*** brault has quit IRC09:14
bauzascdent: so that's hard to find a common denominator for all09:14
*** baoli has joined #openstack-nova09:14
bauzasand we all say that Service Catalog serves the purpose to enable services the way you want09:14
*** brault has joined #openstack-nova09:14
cdentbauzas: sure, but I think there's been a lot of confusion that we could have made less of a problem. The <Directory> thing, for example, seems like something that never should have happened because when that's wrong things simply don't work.09:14
bauzasso, you, as a deployer, just needs to make consistent what you have in your service catalog entry and what you configure server-side09:15
asettlecdent: thanks for your honesty. What can I do to help?09:15
bauzascdent: the port discussion clearly showed up that a lot people were having wrong expectations09:16
bauzasthe fact that the service catalog exists is for the exact reason that you can provide any endpoint you want09:16
bauzasthis is not aimed to be consistent across all openstack deployments09:16
cdentbauzas: yes, I know, I'm not suggesting we change any of that. but the docs process has been more fraught with error than it should have been. we should figure out why and try to make it better09:17
cdentasettle: will you be in boston?09:17
bauzasand application developers wanting to integrate with APIs need to use the Service Catalog as the discovery system09:17
asettlecdent: sure will be. You?09:17
cdentyup, we should gather and chat09:18
bauzascdent: sure, I guess that's the crux of providing upstream documentation that sets kind of de-facto standard09:18
*** baoli has quit IRC09:18
*** huanxie has quit IRC09:18
*** huanxie has joined #openstack-nova09:18
asettleOkay, let's aim for that. I've got a shitty tight schedule Mon - Wed with updates and all that jazz.09:19
*** brault has quit IRC09:19
asettleBut I'm there until Friday :)09:19
*** claudiub|2 has joined #openstack-nova09:19
asettlebauzas: you gonna be there?09:19
bauzasyup09:20
bauzaswe have a couple of sessions around placement09:20
asettleLucky meeee09:20
bauzasboth in the Forum and the conference itself09:20
bauzaslike, jay (pipes) has 2 sessions for talking $placement, one targeted for users and architects, the other more for devs09:21
asettleWell, it should be interesting.09:21
bauzas2 talks09:21
asettleOkay. Well. I'll try and make sure I get along to some of them. I'm a bit of a lone wolf this summit.09:21
*** litao has joined #openstack-nova09:24
*** kaisers has quit IRC09:27
*** amotoki has quit IRC09:30
*** kiwi_rot has joined #openstack-nova09:31
*** zhurong has quit IRC09:33
openstackgerritfengzhr proposed openstack/nova master: Modify the description of flat_injected in nova.conf  https://review.openstack.org/45878909:33
*** amotoki has joined #openstack-nova09:33
fricklerit seems that the scheduler docs are outdated, can anyone confirm that it should mention e.g. filter_scheduler.enabled_filters instead of scheduler_default_filters here? https://docs.openstack.org/ocata/config-reference/compute/schedulers.html09:35
fricklerI'm also struggling to get scheduling to a specific az to work with Ocata, are there known issues?09:35
*** gouthamr has joined #openstack-nova09:35
*** zhurong has joined #openstack-nova09:36
*** ralonsoh has quit IRC09:36
*** brault has joined #openstack-nova09:37
*** zhurong has quit IRC09:38
*** ralonsoh has joined #openstack-nova09:38
fricklerbauzas: cdent: regarding deployment of placement-api, are end users supposed to talk to it or would it rather be for admins/operators only? i.e. do I really need to deploy a public endpoint for it or would I rather only do an internal one?09:39
cdentfrickler: it is admin _for now_ but the expectation is that might change in the future, as having dashboard views over one's own usage is expected09:40
openstackgerritLee Yarwood proposed openstack/nova master: compute: Detach volumes on _rebuild_default_impl failure  https://review.openstack.org/44210509:42
fricklercdent: ah, that is a good point, so a public endpoint will make sense in the long run.09:42
cdentfrickler: another one of the things that might happen in the future warnings (like described above with asettle) is that the preference is for interface type to notmatter09:42
cdentbut that's a long way off09:42
*** Shunli has quit IRC09:44
*** gouthamr has quit IRC09:44
asettleHey cdent since you're loving doc nova bugs, want another one? :D09:46
cdentasettle: I can certainly look, but I'm making no promises09:46
* asettle claps09:46
asettleHooray!09:46
asettle:p thanks09:46
asettlehttps://bugs.launchpad.net/openstack-manuals/+bug/168310409:46
openstackLaunchpad bug 1683104 in openstack-manuals "instance is not created rightly" [Undecided,New]09:46
asettleI'm not convinced of this one, let's put it that way09:47
asettleBut, my nova deep dive konwledge is bad :(09:47
cdentmine too!09:48
* cdent looks09:48
*** salv-orl_ has joined #openstack-nova09:48
cdentasettle: heh, interesting. their solution works but is undesirable :)09:49
* cdent leaves some note09:49
cdents09:49
asettlecdent: I guess my real concern is whether or not what we have is going to work or not.09:50
*** dixiaoli has joined #openstack-nova09:50
*** afazekas has joined #openstack-nova09:50
cdentasettle: while the apache configuration is incorrect things will not work and the bugs that cascade from that will be various09:51
asettle-.-09:51
cdentthe original cause of this person's problem is that their apache config is wrong and they have worked around it by not using apache at all for the placement service09:51
*** salv-orlando has quit IRC09:51
asettleWell, that's info I can work with.09:52
asettleOkay.09:52
asettleThanks cdent. I can reply to the reporter with that :)09:52
asettleUnless you've already said something?09:52
cdentI've started something, yeah, but haven't finished it yet09:52
asettleOkay :) tahnks cdent I appreciate this09:52
*** psachin has quit IRC09:54
*** kylek3h has joined #openstack-nova09:56
cdentasettle: I left a comment but more might be needed09:56
asettlecdent: lgtm.09:59
* asettle clicks *invalid*09:59
*** dixiaoli has quit IRC09:59
asettleThanks again :)09:59
*** kylek3h has quit IRC10:00
cdentasettle: you're very welcome10:00
asettleI owe you and bauzas a drink10:00
*** cNilesh has quit IRC10:01
*** Guest86170 has quit IRC10:02
*** satyar has quit IRC10:03
*** cNilesh has joined #openstack-nova10:04
*** cNilesh has quit IRC10:05
*** cNilesh has joined #openstack-nova10:05
*** amotoki has quit IRC10:05
*** damien_r has quit IRC10:06
*** kevinz has quit IRC10:07
*** brault has quit IRC10:10
*** thorst has joined #openstack-nova10:11
*** Guest86170 has joined #openstack-nova10:14
*** baoli has joined #openstack-nova10:15
*** nicolasbock has joined #openstack-nova10:15
*** bhagyashris has quit IRC10:16
*** thorst has quit IRC10:16
*** baoli has quit IRC10:19
*** psachin has joined #openstack-nova10:21
*** ralonsoh has quit IRC10:23
*** kaisers has joined #openstack-nova10:23
*** yamamoto has quit IRC10:25
*** Shashi has quit IRC10:26
*** slaweq_ has quit IRC10:34
*** brault has joined #openstack-nova10:34
openstackgerritjichenjc proposed openstack/nova master: Use plain routes list for limits endpoint instead of stevedore  https://review.openstack.org/45880510:34
*** slaweq has joined #openstack-nova10:34
openstackgerritBalazs Gibizer proposed openstack/nova master: Add keypairs field to InstancePayload  https://review.openstack.org/41973010:37
openstackgerritBalazs Gibizer proposed openstack/nova master: Adding auto_disk_config field to InstancePayload  https://review.openstack.org/41918510:37
openstackgerritBalazs Gibizer proposed openstack/nova master: Adding tags field to InstancePayload  https://review.openstack.org/40722810:37
*** slaweq has quit IRC10:39
*** brault has quit IRC10:39
*** ralonsoh has joined #openstack-nova10:42
*** cNilesh has quit IRC10:43
*** smatzek has joined #openstack-nova10:44
*** cdent has quit IRC10:45
*** shaner has quit IRC10:52
*** shaner has joined #openstack-nova10:53
*** udesale has quit IRC10:53
*** phuongnh has joined #openstack-nova10:56
*** kylek3h has joined #openstack-nova10:56
*** djohnsto has quit IRC10:58
openstackgerritBalazs Gibizer proposed openstack/nova master: Add keypairs field to InstancePayload  https://review.openstack.org/41973010:59
openstackgerritBalazs Gibizer proposed openstack/nova master: Adding auto_disk_config field to InstancePayload  https://review.openstack.org/41918510:59
openstackgerritBalazs Gibizer proposed openstack/nova master: add tags field to instance.update notification  https://review.openstack.org/40722810:59
*** trinaths has joined #openstack-nova11:00
*** yamahata has quit IRC11:00
*** kylek3h has quit IRC11:01
*** phuongnh has quit IRC11:10
openstackgerritLee Yarwood proposed openstack/nova master: libvirt: Always disconnect_volume after rebase failures  https://review.openstack.org/45880711:11
*** vks1 has quit IRC11:12
*** markvoelker has quit IRC11:14
*** baoli has joined #openstack-nova11:15
*** cdent has joined #openstack-nova11:16
*** zenoway has joined #openstack-nova11:17
*** Shunli has joined #openstack-nova11:18
*** Shunli has quit IRC11:18
*** phuongnh has joined #openstack-nova11:19
*** baoli has quit IRC11:20
*** phuongnh has quit IRC11:21
*** thorst has joined #openstack-nova11:25
*** lucasagomes is now known as lucas-afk11:25
ralonsohsfinucan: hi11:26
*** slaweq has joined #openstack-nova11:26
openstackgerritLee Yarwood proposed openstack/nova master: libvirt: Always disconnect_volume after rebase failures  https://review.openstack.org/45880711:29
*** vladikr has joined #openstack-nova11:31
*** yamamoto has joined #openstack-nova11:33
lyarwoodkashyap, mdbooth ; ^ hopefully a straight forward bugfix for review if you have anytime this afternoon11:33
kashyaplyarwood: Yeah, will look after lunch11:35
*** yamamoto has quit IRC11:35
*** yamamoto has joined #openstack-nova11:39
*** dillaman has joined #openstack-nova11:40
*** salv-orl_ has quit IRC11:40
*** ratailor has quit IRC11:45
*** sree has joined #openstack-nova11:45
*** slaweq has quit IRC11:45
*** slaweq has joined #openstack-nova11:46
*** slaweq has quit IRC11:51
*** lyan has joined #openstack-nova11:51
*** yamamoto has quit IRC11:52
*** prateek has quit IRC11:52
*** satyar has joined #openstack-nova11:54
*** sdague has joined #openstack-nova11:54
*** rmart04 has quit IRC11:54
*** lpetrut has joined #openstack-nova11:55
*** jpena is now known as jpena|lunch11:55
*** lyan has quit IRC11:56
*** ebbex has joined #openstack-nova11:57
*** kaisers has quit IRC11:57
*** kylek3h has joined #openstack-nova11:57
openstackgerritAndy McCrae proposed openstack/nova master: Allow CONTENT_LENGTH to be present but empty  https://review.openstack.org/45571011:57
openstackgerritBalazs Gibizer proposed openstack/nova master: explain payload inheritance in notification devref  https://review.openstack.org/45366711:59
*** baoli has joined #openstack-nova11:59
*** brault has joined #openstack-nova12:01
*** kylek3h has quit IRC12:02
*** neilsun has quit IRC12:02
*** baoli has quit IRC12:03
*** jaypipes has joined #openstack-nova12:04
*** jaypipes is now known as leakypipes12:04
*** litao has quit IRC12:09
sfinucanralonsoh: Hey12:10
sfinucanSorry - just back from lunch12:10
*** baoli has joined #openstack-nova12:11
*** baoli has quit IRC12:12
*** jaosorior is now known as jaosorior_away12:12
*** markvoelker has joined #openstack-nova12:15
ralonsohsfinucan, me too12:17
ralonsohsfinucan, it's about https://review.openstack.org/#/c/427145/12:17
*** salv-orlando has joined #openstack-nova12:17
ralonsohsfinucan: don't you think optimizing this function (and adding a tool for future optimizations) worth the effort?12:18
*** markvoelker has quit IRC12:20
*** damien_r has joined #openstack-nova12:20
*** ayogi has quit IRC12:21
sfinucanralonsoh: not really, no12:23
sfinucanI mean, we're saving a fraction of a fraction of a second per instance boot12:23
*** markmc` has joined #openstack-nova12:23
sfinucanand that's a not insignificant chunk of code to do so12:24
ralonsohsfinucan: I know, but the point is this function should have been done like this12:24
sfinucanralonsoh: Would there be any real world improvements by doing that?12:24
ralonsohsfinucan: and the biggest part of this code is a function useful for other possible optimizations12:25
*** markmc has quit IRC12:25
*** ltomasbo has quit IRC12:25
*** jpena|lunch has quit IRC12:25
*** dmellado has quit IRC12:26
*** lucas-afk is now known as lucasagomes12:26
sfinucanand if they yield more significant results, I'd be happy to reassess that :)12:27
openstackgerritBalazs Gibizer proposed openstack/nova master: Add keypairs field to InstancePayload  https://review.openstack.org/41973012:27
*** zenoway has quit IRC12:27
*** zenoway has joined #openstack-nova12:27
openstackgerritMatthew Booth proposed openstack/nova master: libvirt: Fix races with nfs volume mount/umount  https://review.openstack.org/38385912:28
openstackgerritMatthew Booth proposed openstack/nova master: libvirt: Pass instance to connect_volume and disconnect_volume  https://review.openstack.org/45038312:28
mdboothsfinucan johnthetubaguy: ^^^ also rebases those 2 commits, btw, but the only change is an additional comment in test_mount.py.12:28
sfinucanralonsoh: That whole section of the code could do with being examined closer for larger optimizations, particularly wrt integration with resource providers12:30
*** diga has quit IRC12:30
*** lyan has joined #openstack-nova12:31
sfinucanjaypipes would be able to provide more info, but iirc the PCI tracker model doesn't integrate into the resource providers model very well. Lots of opportunities for larger optimizations there12:31
sfinucanmdbooth: Cool. Looking now12:32
ralonsohsfinucan: I'll talk to jaypipes12:33
ralonsohsfinucan: I'll see if we can optimize the code related to resource providers12:34
ralonsohsfinucan, thank you!12:34
sfinucanralonsoh: Definitely. I'm sure Jay would be ecstatic to have someone working on that :)12:35
*** sree has quit IRC12:35
*** zenoway has quit IRC12:36
*** zenoway has joined #openstack-nova12:37
*** david_1 has joined #openstack-nova12:37
efriedsdague Thanks for watching the PowerVM changes :)12:37
*** brault has quit IRC12:38
*** jpena has joined #openstack-nova12:38
openstackgerritEric Fried proposed openstack/nova master: PowerVM Driver: spawn/destroy #3: TaskFlow  https://review.openstack.org/43872912:38
openstackgerritEric Fried proposed openstack/nova master: PowerVM Driver: spawn/destroy #4: full flavor  https://review.openstack.org/39128812:39
sfinucanmdbooth: done and done. Thanks for addressing that small comment12:39
*** markvoelker has joined #openstack-nova12:40
openstackgerritEric Fried proposed openstack/nova master: PowerVM Driver: console  https://review.openstack.org/40940212:40
openstackgerritEric Fried proposed openstack/nova master: PowerVM Driver: SSP emphemeral disk support  https://review.openstack.org/44318912:41
*** markmc` has quit IRC12:41
openstackgerritTakashi NATSUME proposed openstack/nova master: WIP: Specify keymap on server boot (1/2)  https://review.openstack.org/45875212:41
efriedsdague ^^ Rebased up through "SSP ephemeral disk support".12:41
leakypipesralonsoh: hey, I'm here :)12:41
*** zenoway has quit IRC12:42
sfinucanoops12:42
* sfinucan wishes IRC did nick aliasing12:42
ralonsohleakypipes: I was talking to Stephen about a patch I submitted https://review.openstack.org/#/c/427145/12:42
ralonsohleakypipes: it's an small optimization. The point is if the memoize function could be useful to store in cache and optimize some parts of resourde providers12:43
sdagueefried: ok, cool, I'll back through them in a minute12:43
efriedsdague Awesome.12:43
ralonsohleakypipes: let me know if you know any interesting place to use it12:43
*** edleafe is now known as figleaf12:44
johnthetubaguysfinucan: +112:44
*** rmart04 has joined #openstack-nova12:44
leakypipesralonsoh: will do. :)12:45
*** gcb has quit IRC12:45
zioprotodansmith: I have been in meetings the all day... later I hope to find time to clean that broken database we have seen yesterday, I will keep you updated12:45
ralonsohleakypipes: thanks!12:45
*** markmc has joined #openstack-nova12:46
*** kylek3h has joined #openstack-nova12:46
*** zenoway has joined #openstack-nova12:47
*** slaweq has joined #openstack-nova12:47
*** yingwei has quit IRC12:47
*** dmellado has joined #openstack-nova12:47
*** ltomasbo has joined #openstack-nova12:49
*** adisky_ has quit IRC12:49
*** zenoway has quit IRC12:50
*** zenoway has joined #openstack-nova12:50
openstackgerritsahid proposed openstack/nova master: libvirt: configure trust mode for vfs  https://review.openstack.org/45851412:52
openstackgerritsahid proposed openstack/nova master: network: add command to configure trusted mode for VFs  https://review.openstack.org/45851312:52
openstackgerritsahid proposed openstack/nova master: network: update pci request spec to handle trusted tags  https://review.openstack.org/45882012:52
*** kaisers has joined #openstack-nova12:52
openstackgerritLee Yarwood proposed openstack/nova master: libvirt: Always disconnect_volume after rebase failures  https://review.openstack.org/45880712:53
lyarwoodmdbooth: posted some comments in the change, basically I was going to follow up with another change for resize failures as we can't just disconnect the new volume at that point.12:54
sdagueefried: there is an oslo_utils method for something in patch #412:56
*** efried has quit IRC12:57
*** yamamoto has joined #openstack-nova12:57
*** yamamoto has quit IRC12:58
*** slaweq has quit IRC12:58
mdboothlyarwood: That's an excellent point.12:58
*** yamamoto has joined #openstack-nova12:58
*** yongjiexu has joined #openstack-nova12:59
openstackgerritAndy McCrae proposed openstack/nova master: Allow CONTENT_LENGTH to be present but empty  https://review.openstack.org/45571013:00
*** awaugama has joined #openstack-nova13:00
*** mdrabe has joined #openstack-nova13:04
*** iceyao has joined #openstack-nova13:04
*** sridharg has quit IRC13:05
*** psachin has quit IRC13:07
*** efried has joined #openstack-nova13:09
*** iceyao has quit IRC13:09
*** slaweq has joined #openstack-nova13:11
openstackgerritOpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements  https://review.openstack.org/45883413:12
efriedandymccr For the love of all that is holy, at some point you gotta tell us to bugger off and merge your patch already.13:13
*** pchavva has joined #openstack-nova13:14
*** edmondsw has joined #openstack-nova13:15
*** yamamoto has quit IRC13:15
*** baoli has joined #openstack-nova13:16
*** baoli has quit IRC13:16
*** yamamoto has joined #openstack-nova13:16
*** mriedem has joined #openstack-nova13:16
*** yamamoto has quit IRC13:16
mriedemo/13:16
*** yamamoto has joined #openstack-nova13:16
*** jamesdenton has joined #openstack-nova13:17
*** cleong has joined #openstack-nova13:17
rpodolyakamriedem: hey! could you please take a look at https://review.openstack.org/#/c/458837/? Am I missing something or "?h=stable/newton" part was just missed in the original change?13:18
*** esberglu has joined #openstack-nova13:19
mriedemwas probably just missed, and i bet newton was master when that was added to novaclient13:19
rpodolyakaack, thanks!13:20
mriedemcdent: johnthetubaguy: congrats on your TC glory13:23
mriedemas PTL i will promise to fight your TC decisions at every turn13:23
johnthetubaguymriedem: I wouldn't want anything less13:23
*** yamamoto has quit IRC13:25
cdentmriedem: from the fires of conflict truth will rise13:25
*** yamamoto has joined #openstack-nova13:26
mriedemit'll be like those looney toons characters that clock in each day to fight each other13:26
mriedembut are buddies before and after13:26
dansmithzioproto: cool13:26
*** baoli has joined #openstack-nova13:26
mriedemclarkb: i don't suppose we ever backported your nova fix for the live migration job setup to stable/ocata13:27
cdentmriedem: perfect13:27
*** dave-mccowan has joined #openstack-nova13:28
mriedemclarkb: here we go https://review.openstack.org/#/c/458843/13:28
cdenthttps://www.youtube.com/watch?v=kerUbfOQTW013:28
mriedemone of you can be the weird hairy english sheep dog,13:29
mriedemand i can be the american coyote13:29
mriedemwho gets his ass handed to him daily13:29
*** gszasz has quit IRC13:30
*** yamamoto has quit IRC13:30
*** baoli has quit IRC13:31
mriedemjohnthetubaguy: dansmith: leakypipes: has anyone proposed the concept of dedicated hosts in nova before? i have to assume it's come up, but i don't remember13:31
*** liverpooler has joined #openstack-nova13:31
johnthetubaguyyeah, HP folks did13:31
mriedemdo you remember a spec for it?13:32
johnthetubaguyit was all aggregate wrangling if I remember, it might be pre-specs?13:32
mriedemhttps://blueprints.launchpad.net/nova/+spec/multi-tenancy-isolation-only-aggregates13:32
mriedem^ was cern13:32
mriedemhttps://blueprints.launchpad.net/nova/+spec/whole-host-allocation13:32
mriedem^ was HP13:32
johnthetubaguyah, the second one is what I thought you meant13:33
mriedemhttps://blueprints.launchpad.net/nova/+spec/multi-tenant-exclusion-filter13:33
johnthetubaguyyeah, I think it was phil talking about that13:33
mriedemhttps://blueprints.launchpad.net/nova/+spec/hide-exclusive-availability-zone13:33
mriedemha13:33
mriedemthe list goes on13:33
johnthetubaguywe did something like the cern and last one downstream13:34
mriedemhttps://blueprints.launchpad.net/nova/+spec/support-dedicate-hosts-when-boot13:34
*** baoli has joined #openstack-nova13:34
johnthetubaguyyeah, thats the whole-host-allocation one13:34
johnthetubaguythere are two separate issues mixed in there13:34
mriedemi figured this could be done with dedicated aggregates/AZs and filters13:34
johnthetubaguy"I want only my VMs on each hypervisor", "assign some hosts to a sub-set of tenants"13:35
*** tuan_luong has joined #openstack-nova13:35
*** rmart04_ has joined #openstack-nova13:35
johnthetubaguydepends how dynamic you want it13:35
cdentandymccr, efried: that code is going to be the shiniest thing ever13:35
johnthetubaguythe HP plan (memory is fuzzy) was that you pick the host by the first instance that lands there "owns" that box13:35
*** rmart04 has quit IRC13:36
*** rmart04_ is now known as rmart0413:36
mriedemjohnthetubaguy: interesting, but what if the box isn't big enough for all of the instances the tenant wants to take over on that box? delete and find a new one? or create server groups to do this?13:36
cdentjohnthetubaguy, mriedem : ironic wants a similar kind of thing for baremetal13:37
cdenti linked the spec in the latest rp update13:37
*** Dinesh_Bhor has quit IRC13:37
johnthetubaguymriedem: it was simpler than that13:37
johnthetubaguycdent: but when you get an ironic host, you get all the resources regardless, or do you mean reserving some for a particular tenant?13:37
mriedemcdent: not seeing it13:38
johnthetubaguymriedem: well, by simpler, I mean, you cheat, if it doesn't fit on the host, you then get another host to pay for13:38
mriedemjohnthetubaguy: oh i see13:38
cdentmriedem: I'll find the real link13:38
openstackgerritTakashi NATSUME proposed openstack/nova master: WIP: Specify keymap on server boot (1/2)  https://review.openstack.org/45875213:38
johnthetubaguymriedem: there was talk of per project flavors being allowed, so the divide the hosts they pay for up however they want... got super messy really fast13:39
mriedemso apparently phil's proposal was accepted at one point13:39
mriedemHP public cloud wanted it, rax public cloud had it, and huawei public cloud has something too downstream, which is why i'm asking about it13:39
cdentmriedem, johnthetubaguy https://review.openstack.org/#/c/415512/13:39
cdentfigleaf and I had some fairly meandering comments and then leakypipes came along and set everyone straight13:40
leakypipessaw ah?13:40
*** eglynn has joined #openstack-nova13:40
leakypipessay wha?13:40
johnthetubaguycdent: ah... right13:40
johnthetubaguycdent: thats similar to the host assignment case13:41
*** brault has joined #openstack-nova13:41
johnthetubaguymriedem: I am missing the business context on some of this, it sounds like better quotas would fix the ironic case13:41
mriedemi think it could be solved with tenant isolation filters and image meta,13:42
mriedemi.e. your tenant has access to these images which are configured to only work on certain host aggregates13:42
mriedemthereby you can only boot servers in those hosts13:43
mriedemphil says similar in https://review.openstack.org/#/c/38156/13:43
mriedemit puts a burden on the operator13:43
*** slaweq has quit IRC13:43
*** burt has joined #openstack-nova13:43
johnthetubaguymriedem: the problem is to automate that, you need to filer all create server requests, to make sure you just in time provision the extra hosts they might need, but maybe thats not really how it works, people probably have to buy the hosts via some other system.13:44
*** vks1 has joined #openstack-nova13:44
*** eharney has joined #openstack-nova13:49
* johnthetubaguy way too many internet company vans outside my house, I hope thats for next door...13:51
stvnoyesmriedem: johnthetubaguy: re: https://review.openstack.org/#/c/438750 - did you guys come to an agreement on whether something needs to done about the concern on begin_detaching? I looked thru the flows and i *think* it's ok for both the new flow and old flow.13:51
johnthetubaguystvnoyes: I thought the previous consensus was its not allowed in the new flow, as it doesn't work for multi-attach, etc13:52
mriedemjohnthetubaguy: ildikov was supposed to talk to jgriffith about that13:53
johnthetubaguyah, right, that was the action13:53
mriedembut we did seem to get two answers on whether or not it would work in the new API model during the meeting yesterday13:53
stvnoyeswould that mean that detaching would no longer ever be a valid status?13:54
mriedemi'd think it could be at least for a single attachment13:54
mriedemi.e. not multiattach13:54
stvnoyesok got it13:54
johnthetubaguymriedem: maybe that... not sure13:54
mriedemmaybe the concern is that with multiattach you could go from in-use > detaching > in-use again13:54
johnthetubaguybut we need a solution that works for multi-attach13:54
mriedemif yo'ure going from 2 to 1 attachments13:54
mriedemif you have one attachment, you go in-use > detaching > available13:54
johnthetubaguywell the detaching status would have to be per attachment, I believe13:55
mriedemi'm looking up their data model13:55
johnthetubaguywell, its on the volume today, which I guess is the problem13:55
johnthetubaguybut well worth a check13:55
ildikovjohnthetubaguy: I think begin_detaching is on another layer than the attachment calls TBH, therefore keeping it for that state change should be fine13:55
mriedemhaving said this, when ildikov did multiattach before, begin_detaching worked, but it did in-use > detaching > in-use13:55
ildikovjohnthetubaguy: couldn't catch jgriffith yesterday, but I will try next week, he's out today13:55
openstackgerritsahid proposed openstack/nova master: numa: fix an uninitialized local variable  https://review.openstack.org/45884813:55
*** ratailor has joined #openstack-nova13:56
ildikovmriedem: yep, we can say we don't want two detach happen at the same time, by which that state machine makes sense13:56
johnthetubaguymriedem: that works if we only allow people to detach one attachment at once, thats not terrible13:56
mriedemdoes hemna know?13:57
*** andreas_s has quit IRC13:57
*** prateek has joined #openstack-nova13:57
stvnoyesthe new  VolumeAttachmentNotFound exception in that change will be needed in other work. I may just put add that exception as a new review to remove the dependency so I can move forward13:58
mriedemthere is an attach_status on the volume_attachment table in cinder13:58
mriedemstvnoyes: hold up for now13:58
*** prateek has quit IRC13:58
johnthetubaguyoh...13:58
stvnoyesmriedem: ok13:58
mriedemjohnthetubaguy: given this is an open question and begin_detaching is in the api, and what this patch is doing is in the compute side, i don't think we need to hold it up13:59
*** catintheroof has joined #openstack-nova13:59
mriedemjohnthetubaguy: this patch is at the bottom of the call chain and has to assume the api has done whatever it needed to do, right?13:59
johnthetubaguymriedem: yeah, I am not against leaving this as an open question, we do need to keep moving here13:59
mriedemwe also get the attach status back when showing details about a volume attachment14:00
ildikovmriedem: I agree, I don't think we decided how to deprecate exactly what, begin_detaching can still fit as it does today14:00
johnthetubaguybut we don't pass the attachment_id in begin_detaching?14:00
johnthetubaguyits just the volume_id?14:00
mriedemi think regardless of what happens, cinder api deals with the multiattach case if begin_detaching is called14:01
openstackgerritEric Fried proposed openstack/nova master: PowerVM Driver: spawn/destroy #4: full flavor  https://review.openstack.org/39128814:01
stvnoyesjust the volume is passed in14:01
mriedemjohnthetubaguy: volume id14:01
*** kaisers has quit IRC14:01
johnthetubaguymriedem: you are right though, this is the API, its not our problem14:01
johnthetubaguymriedem: so didn't see your comment in the patch till now14:02
ildikovvolume_id should be fine for begin_detaching IMHO14:02
ildikovat least from overall behavior perspective14:02
*** claudiub|3 has joined #openstack-nova14:03
*** mlavalle has joined #openstack-nova14:03
johnthetubaguywell, it does disallow multiple detatch of the same volume, because we can't no which one it is14:03
johnthetubaguyI mean, I am OK with that14:03
johnthetubaguyits just a thing14:03
mriedemwe'd know which attachment to drop based on volume_id + instance_uuid14:04
*** claudiub|4 has joined #openstack-nova14:04
johnthetubaguydo we pass instance_uuid?14:04
mriedemno14:04
mriedemi'm talking future speak14:05
johnthetubaguyoh right14:05
mriedemhi, it's matt, from the future14:05
ildikovjohnthetubaguy: until we have multi-attach it's a valid behavior and while working towards multi-attach we can figure it out whether it's the level of lock we want or not14:05
johnthetubaguymriedem: you in australia?14:05
johnthetubaguyildikov: yep, agreed with that14:05
mriedemjohnthetubaguy: antarctica, it's warm and tropical now14:05
mriedemin the future14:05
*** jaosorior_away is now known as jaosorior_mtg14:05
ildikovmriedem: there are multiple ways to sort that out if that's what we want, like the one you mentioned14:05
ildikovmriedem: how's the future? :)14:06
johnthetubaguymriedem: true, true.14:06
mriedembleak14:06
mriedemvery bleak14:06
johnthetubaguysomething tells me mriedem likes the snow14:06
*** claudiub has quit IRC14:06
mriedemif we needed later on, we could hit a begin_detaching api on the attachments api in cinder, to change the status on a single attachment, which rolls up a status change in the volume itself, idk14:06
openstackgerritLee Yarwood proposed openstack/nova master: libvirt: Always disconnect_volume after rebase failures  https://review.openstack.org/45880714:06
openstackgerritLee Yarwood proposed openstack/nova master: libvirt: Remove is_job_complete polling after pivot  https://review.openstack.org/45885414:06
mriedembut that seems to be the same as what we have now essentially14:06
*** felipemonteiro has joined #openstack-nova14:07
mriedemi guess you wouldn't aggregate the status14:07
johnthetubaguymriedem: its just the multi detach in parallel thing14:07
mriedemthe volume would be in-use, one attachment would be 'attached' and the other would be 'detaching'14:07
mriedemso you could detach the other attachment,14:07
*** claudiub|2 has quit IRC14:07
mriedembut not the one that's 'detaching'14:07
mriedemi think that's probably the answer14:07
johnthetubaguymriedem: I think that was in one proposal, the begin_detaching on the attachment, I don't remember why we dropped that now14:07
*** claudiub has joined #openstack-nova14:07
ildikovI think we only have volume state right now14:07
mriedemonce both attachments are deleted, the volume status is 'available'14:07
*** claudiub|2 has joined #openstack-nova14:07
johnthetubaguymriedem: yeah, overall its "in-use" until the last one is detaching, I gues...14:07
mriedemildikov: there is an attach_status column on the volume_attachment table in cinder14:08
mriedemjohnthetubaguy: yeah that sounds right, in-use until ==1 attachment is 'detaching', then the volume itself is 'detaching'14:08
mriedemonce all attachments are deleted, the volume is 'available'14:08
johnthetubaguyanyways, I am +W on the detach patch, lets punt this, seems like its safe for now, appreciate stvnoyes for checking all that.14:08
mriedemso yeah, probably long-term we need a begin_detaching action on the attachments API14:08
*** yongjiexu has quit IRC14:08
ildikovmriedem: right, I remember that one, I just don't think we played that much with that state machine yet14:08
johnthetubaguymriedem: yeah, same for attaching I guess14:08
mriedemuntil then you can only detach one attachment at a time14:09
ildikovjohnthetubaguy: sounds good, thanks14:09
johnthetubaguymriedem: +114:09
*** djohnsto has joined #openstack-nova14:09
mriedemwhich today is all you can do anyway b/c we don't support multiattac14:09
ildikovmriedem: +114:09
*** cdent has quit IRC14:09
mriedemmaybe we should write this down somewhere :)14:09
mriedemb/c you know in 3 weeks we'll have forgotten14:09
johnthetubaguymriedem: you read my mind14:09
stvnoyesthanks! moving on to the next one...14:10
*** catintheroof has quit IRC14:10
ildikovmriedem: johnthetubaguy: wiki page, devref, etherpad, love letter?14:10
*** claudiub|3 has quit IRC14:10
*** catintheroof has joined #openstack-nova14:10
mriedemi haven't written a love letter since high school14:10
*** claudiub|4 has quit IRC14:10
mriedemwhen we didn't have cell phones14:10
gibimriedem: hi! thanks for the reviews and fixes on the https://review.openstack.org/#/q/topic:bp/additional-notification-fields-for-searchlight+status:open series.14:11
mriedemgibi: np14:11
johnthetubaguyI wrote a poem for my wedding, I am not doing that again14:11
gibimriedem: I rebased the keypair patch as well and I'm working on the BDM patch14:11
mriedemi believe we picked poems and had others read them14:11
ildikov:)14:11
* ildikov feels nostalgic now :)14:12
johnthetubaguymriedem: yeah, I couldn't think of how to finish my speach... and didn't think to use google because I was too nervous, lol14:12
mriedemjohnthetubaguy: was it pre-dinner or post-dinner?14:12
mriedemor mid-dinner?14:12
johnthetubaguysort of mid I really14:12
sballe_morning14:12
mriedemsame for my forced impromptu speech14:13
johnthetubaguyheh14:13
mriedemi should have done jimmy from south park14:13
mriedem"wow what a great audience!"14:13
sballe_I am looking for some documentation on how nova can schedule VMs with FPGAs as well as how FPGAs are represented in nove14:13
sballe_s/nova14:13
sballe_Any help is appreciated14:14
johnthetubaguymriedem: ildikov: maybe update the existing spec with a note about all that?14:14
*** dixiaoli has joined #openstack-nova14:15
ildikovjohnthetubaguy: that can work too14:15
*** rmart04_ has joined #openstack-nova14:15
johnthetubaguysballe_: we don't really support FPGA passthrough for VMs as such, although I think you could use ironic to give you the whole box including the FPGA14:15
mriedemsballe_: they aren't14:16
sballe_couls I use nova to schedule flavors with accelerators?14:16
*** tbachman has joined #openstack-nova14:16
*** rmart04 has quit IRC14:16
*** rmart04_ is now known as rmart0414:16
sballe_I see a lot of post with gpus14:16
*** pjm6 has joined #openstack-nova14:16
johnthetubaguysballe_: so you can pass through a generic PCI device, maybe that would work?14:17
mriedemsballe_: there is a project called 'cyborg' which you should probably start with14:17
mriedemwhich is all about acceleration14:17
sballe_ok cool! thx for the help14:17
mriedemsballe_: https://wiki.openstack.org/wiki/Cyborg14:17
mriedemlook for email threads in the openstack-dev mailing list tagged with [acceleration]14:18
johnthetubaguyso I forgot about that thing, my email filters are a bit strong these days14:18
mriedemsballe_: also https://review.openstack.org/#/c/318047/14:18
mriedemleakypipes: dansmith: johnthetubaguy: https://review.openstack.org/#/c/419185/ on down for bp/additional-notification-fields-for-searchlight is ready to go, has my +214:19
*** dixiaoli has quit IRC14:19
mriedemjohnthetubaguy: yeah we could amend the spec,14:20
mriedemjohnthetubaguy: you going to do that or want me to?14:20
mriedemi'm happy to update it14:20
johnthetubaguymriedem: if you could, that would be great14:20
mriedemwill do14:20
sballe_mriedem: thx14:20
*** bnemec is now known as beekneemech14:20
bauzasmriedem: hola, quick q, when are you planning a stable/newton release ? :)14:20
bauzasand oh snap, TGIF14:21
mriedembauzas: when you merge the regression fixes proposed to newton14:21
* bauzas bauwser14:21
*** yamahata has joined #openstack-nova14:21
* bauzas facepalms14:21
bauzasmriedem: heh, roger.14:21
*** bauzas is now known as bauwser14:21
* bauwser is just refueling with coffee14:21
smcginnismriedem: Missed your question yesterday while travelling.14:21
smcginnismriedem: That session is to discuss the track chair process and issues.14:22
openstackgerritsahid proposed openstack/nova master: libvirt: configure trust mode for vfs  https://review.openstack.org/45851414:22
openstackgerritsahid proposed openstack/nova master: network: update pci request spec to handle trusted tags  https://review.openstack.org/45882014:22
openstackgerritsahid proposed openstack/nova master: network: add command to configure trusted mode for VFs  https://review.openstack.org/45851314:22
mriedemsmcginnis: what's a track chair?14:24
mriedemthose setting up the summit?14:24
mriedemor those running a session?14:24
openstackgerritAlex Xu proposed openstack/python-novaclient master: Add `instance-uuid` flag to the migration-list  https://review.openstack.org/45872814:24
*** rcernin has quit IRC14:24
johnthetubaguypick the sessions14:24
mriedemalex_xu: you beat me to it14:25
smcginnismriedem: Decising which sessions to accept for the official schedule.14:25
*** brault has quit IRC14:25
johnthetubaguymriedem: done it twice, its a pain14:25
mriedemoh, i don't care about that session then :)14:25
smcginnisjohnthetubaguy: Yep. :)14:25
alex_xumriedem: hope you didn't start that14:25
mriedemalex_xu: no i didn't, thanks for doing it14:25
alex_xumriedem: np14:25
*** rfolco has joined #openstack-nova14:26
*** yamamoto has joined #openstack-nova14:27
*** baoli has quit IRC14:28
*** brault has joined #openstack-nova14:28
*** salv-orlando has quit IRC14:28
*** baoli has joined #openstack-nova14:29
mriedemalex_xu: comments inline :)14:29
mriedemotherwise looks good14:29
*** zz_dimtruck is now known as dimtruck14:29
openstackgerritLee Yarwood proposed openstack/nova master: libvirt: Always disconnect_volume after rebase failures  https://review.openstack.org/45880714:30
*** rfolco has quit IRC14:30
mriedembauwser: these https://review.openstack.org/#/c/457353/ https://review.openstack.org/#/c/448235/ https://review.openstack.org/#/c/458668/ https://review.openstack.org/#/c/456770/ https://review.openstack.org/#/c/448253/14:31
bauwsermriedem: reviewy reviewy14:31
mriedemask and ye shall receieve14:32
mriedem*receive14:32
bauwsermriedem: FWIW, I haven't touched the scheduler claims spec since I need time to think about14:32
mriedemi haven't either14:32
bauwserabout the super extra cool problem you showed to the world with overhead values14:32
mriedemdon't thank me, thank some performance tester internal to huawei14:33
*** dikonoor has quit IRC14:33
*** amotoki has joined #openstack-nova14:33
bauwsermriedem: FWIW, my honest first opinion is that problem it's something that we should leave out of placement14:33
mriedemi didn't know the overhead stuff existed before that14:33
bauwsermriedem: that looks something not really useful for placement and very related to the hypervisor14:33
*** baoli has quit IRC14:34
mriedemyou have to solve it with placement one way or the other, either by tracking overhead in allocations, or forcing extra reserved inventory to make up for the overhead14:34
bauwserso, say we leave in a world where we're not trying to eat all the resources but still have reserved room for that, then it's not a problem for placement14:34
mriedemright?14:34
mriedemi don't think we can punt on this14:34
*** baoli has joined #openstack-nova14:34
*** baoli has quit IRC14:35
*** mriedem has left #openstack-nova14:35
*** mriedem has joined #openstack-nova14:35
bauwsermriedem: if we have rescheduling, would it be a problem ?14:35
*** amotoki has quit IRC14:36
bauwserwe already don't place instances by reviewing that value14:36
mriedemwe reschedule based on it though14:36
bauwserof course14:36
mriedembut we don't have reschedules with super conductor14:36
bauwserbut how much ?14:36
mriedemidk how much14:36
bauwserso, it's rather a problem about how to reschedule14:36
mriedemwell,14:36
mriedemthe point of claims in the scheduler is you don't need to reschedule14:36
bauwserhonestly, I think claiming in the scheduler couldn't remove the compute node verifying the resources too14:37
bauwserbecause sometimes, things can be wrong14:37
bauwserso, having claims in the scheduler is cool but like Pareto (or more) fixing 95% of the number of problems we have14:37
bauwsershould we fix 5% of the current problems by adding more ?14:38
bauwserif we still reschedule14:38
mriedemif you can't reschedule from the compute, then what? NoValidHost and put the instance into ERROR state?14:38
mriedem^ was one of the options i proposed in the spec14:38
bauwseranyway, since not all the resources are yet set in the placement API (like NUMA), we would still need to reschedule, right ?14:38
mriedemi said account for the overhead by updating the allocations once on the compute, but people didn't like that b/c of quotas14:38
bauwserbecause we use allocations for quotas, and I agree with the majority14:39
bauwserso, either we say we add that for inventories *and not allocations*, or we say it's not a problem14:39
*** amotoki has joined #openstack-nova14:39
bauwserand we leave reschedules fix that self-healing14:39
mriedemwe don't have reschedules14:40
mriedemi thought the consensus the other day was pad the RP inventory reserved amount14:40
bauwserthat's what I'm not sure we can just say it won't exist in a cellsv2 world14:40
mriedemvia the get_inventory() method on drivers that calculate overhead14:40
bauwsermriedem: I think the consensus looks good by me14:40
mriedemreschedules are possible in a single-cell deployment14:40
bauwserthat's my "either" possibiltyu14:40
mriedembut i don't think we should rely on them14:41
bauwserokay14:41
mriedemwhen designing things14:41
*** gongysh has joined #openstack-nova14:41
mriedemdan proposed adding a config option to disable reschedules so you never have upcalls, regardless of deployment14:41
*** yongjiexu has joined #openstack-nova14:41
bauwserso it leaves the idea to modify inventories to add more "something" for decrementing the "left" value14:41
bauwseramending 'reserved' could be that "something" which wouldn't need to add a new DB fiedl14:42
mriedemcorrect, that's what most people wanted the other day14:42
*** slagle has quit IRC14:42
bauwsermriedem: yup, and I +2d that change for the instance scheduler RPC call14:42
mriedemit sucks for the operator because they have to configure reserved amounts,14:43
mriedemunless we can come up with a scheme to automate it14:43
bauwsermriedem: okay, if so, I think I can amend that spec14:43
*** pjm6 has quit IRC14:43
bauwsermriedem: I was rather thinking to have the inventory be modified by the RT to augment it by the sum of overhead for each instance14:43
openstackgerritMikhail Feoktistov proposed openstack/nova master: Remove fstype param from ploop init  https://review.openstack.org/44497014:43
bauwsersnap14:43
bauwserto have the inventory.reserved value14:44
cfriesenquestion...has nova ever considered setting the virtual disk logical/physical block size based on the host disk block size?  currently the guest sees 512 even for disks with 4K block size, which potentially leads to extra read-modify-write overhead14:44
*** rnoriega has quit IRC14:44
leakypipesmriedem: k, on it.14:44
bauwserleakypipes: mriedem: okay, I think then I have enough to amend the spec14:46
*** armax has joined #openstack-nova14:46
bauwserI'll try to provide a new rev' by today EOB or Monday14:46
leakypipesbauwser: coolio.14:46
mriedembauwser: so rather than add overheads to allocations, you want to add overhead to inventory.reserved during each build?14:46
mriedemthat could still get you in a 409 situation where we have to fail the build14:47
bauwserleakypipes: do you agree with my idea to augment in the RT the reserved value given by the driver.get_inventory() method by the number of instance.overhead we have ?14:47
*** jschlueter has joined #openstack-nova14:47
*** marst has joined #openstack-nova14:47
mriedemwe had talked about just a configurable value that get_inventory() would provide and isn't per-instance14:48
*** slaweq has joined #openstack-nova14:48
*** nkorabli has joined #openstack-nova14:48
figleafI don't like treating reserved like an allocation - it should be set when the RP is created, and that's it14:48
leakypipesbauwser: hmm, I must have missed that. lemme have another look at the spec14:48
bauwserleakypipes: that's not yet in the spec14:48
mriedemleakypipes: it's new as of bauwser today14:48
leakypipesoh14:49
mriedemlast 5 minutes14:49
figleafit's sort of in my last comment on the spec14:49
leakypipesno wonder I missed it then :)14:49
bauwserI'm trying to explain that we find nodes based on what we ask vs. what we have as free14:49
bauwserso, what we ask is the flavor14:49
bauwserwhat we have is the inventory minus the allocations14:49
leakypipesbauwser: sorry, lemme read back up. I just got back from breakfast :)14:49
bauwserI'm trying to explain it another way14:50
bauwsergiven we ask for the flavor size14:50
mriedemreserved to me means static reserved, via config from the operator, something that nova doesn't mess with automatically14:50
bauwserand we compare it to each node by doing (total - reserved - sum(allocations))14:50
figleafmriedem: exactly14:51
bauwserI'm seeing some way to say (total - reserved - sum(allocations) - sum(overhead))14:51
figleaffor a hypervisor, it's the "cost of doing business"14:51
mriedemworst case scenario is you don't modify reserved at all and run the risk of over-consuming your resources on the host14:51
bauwsermy proposal being "reserved" and sum(overhead) is purely related to the hypervisor14:51
mriedemfor ram and disk it could be a small overhead14:51
mriedemthat you didn't account for in capacity planning14:51
figleafthe amount of resource that a provider cannot offer14:52
*** kiwi_rot has quit IRC14:52
bauwserI think we all know why we have that "reserved "field14:52
bauwserI'm just trying to see how we can consider overheads to be part of something sent to placement14:52
bauwserbecause the more I think, the more I'm -1 to amending allocations if we consider allocations as the basement for quotas14:53
figleafif we do, then we should use it accordingly. "Overhead" is nothing except resources that the HV needs to do its job14:53
*** yamamoto has quit IRC14:53
mriedemalex_xu: since we print "Instance UUID" in the nova migration-list output, i guess --instance-uuid is ok14:53
bauwserthe other way would require a new 'overhead' table that would be per consumer id14:53
mriedembauwser: i think we already shot own the idea of updating allocations to account for overhead14:54
bauwserexactly like allocations is14:54
bauwsermriedem: \o/ glad to hear14:54
bauwsermriedem: so, if we say it's not allocations14:54
mriedemit's rp.inventory.reserved14:54
bauwserand if we don't want to touch 'reserved', then how could we send that amount to placement ?14:54
mriedemit is via reserved14:54
bauwsermriedem: right14:54
mriedemthe question is, is it static via config, or do you adjust it dynamically14:55
figleafConfigure when creating the RP, and be done with it14:55
mriedemwhich is what i thought you were talking about doing, the latter14:55
bauwserso, why are people arguing with my idea to automatically augment that rp.inventory.reserved by the sum(overhead) ?14:55
mriedemthe simplest solution is config like figleaf says14:55
bauwsermriedem: remember the libvirt overheads14:55
bauwserand see how it is linear per instances14:55
mriedemi realize that the overhead is per instance14:56
*** ratailor has quit IRC14:56
bauwserFWIW, my Red Hat infrastructure gladly crashed so I'm really 100% committed to upstream :p14:56
figleafbauwser: so figure out what the max number of instances that will cover 90% of the hosts, and use that14:56
*** markus_z has quit IRC14:56
leakypipesmriedem, bauwser, figleaf (and anyone else who wants to settle the overheads discussion): https://hangouts.google.com/hangouts/_/ejhj37l6u5fkhonhnn23in2vome14:56
lyarwoodbauwser: who needs DNS anyway?14:56
bauwserfigleaf: how could you be ? it's depending on the number of flavors the users ask ?14:56
mriedemand yes we could technically adjust the inventory.reserved based on the sum of all instance overheads, but i think that would be a surprise to operators that nova is automatically adjusting and increasing the reserved amount of inventory even though they set a static config value for it14:56
alex_xumriedem: ok, got it14:56
bauwserlyarwood: you're right, it's totally useless14:56
* bauwser lives in a cave with no signals 14:57
*** kaisers has joined #openstack-nova14:57
bauwsermriedem: if we allow them to see the values thru the REST API, I agree14:57
figleafleakypipes: gimme a minute14:57
mriedembauwser: which we do14:57
bauwsermriedem: but for the moment, we never intended to do so14:57
mriedemhuh/14:58
mriedem?14:58
*** markmc has quit IRC14:58
bauwsermriedem: I thought we said the REST API is not yet consumable by end-users ?14:58
*** jaosorior_mtg is now known as jaosorior14:58
mriedembauwser: jump on the hangout if you can14:58
openstackgerritAndy McCrae proposed openstack/nova master: Allow CONTENT_LENGTH to be present but empty  https://review.openstack.org/45571014:59
*** jaosorior has quit IRC14:59
bauwsermriedem: "I live for obeying orders" (again, French comics named 'Leonard')14:59
*** markmc has joined #openstack-nova15:01
*** mdrabe has quit IRC15:02
*** slaweq has quit IRC15:02
openstackgerritMonty Taylor proposed openstack/python-novaclient master: Remove direct dependency on requests  https://review.openstack.org/45886815:02
*** yamahata has quit IRC15:03
*** yamahata_ has joined #openstack-nova15:03
*** cdent has joined #openstack-nova15:03
lyarwoodildikov / stvnoyes ; just getting around to the cinderv3 patches now, am I okay to work on the swap_volume change? https://review.openstack.org/#/c/456971/15:04
*** nkorabli has quit IRC15:05
*** voelzmo has quit IRC15:05
ildikovlyarwood: it should be ok, stvnoyes took https://review.openstack.org/#/c/456877/ yesterday15:05
*** brault has quit IRC15:05
*** voelzmo has joined #openstack-nova15:05
lyarwoodildikov: kk thanks15:06
ildikovlyarwood: this one is on its way to get merged: https://review.openstack.org/438750 , so I should rebase the chain though15:06
*** ijw has joined #openstack-nova15:07
*** annegentle has joined #openstack-nova15:07
*** brault has joined #openstack-nova15:07
*** slagle has joined #openstack-nova15:07
ildikovlyarwood: also this one is not in the chain and needs some love too if you don't want to deal with the patch in the middle of the chain: https://review.openstack.org/#/c/456851/15:08
*** MasterOfBugs has joined #openstack-nova15:09
*** amotoki has quit IRC15:09
*** mdrabe has joined #openstack-nova15:10
*** voelzmo has quit IRC15:10
*** MasterOfBugs has quit IRC15:10
*** BlackDex has joined #openstack-nova15:11
*** MasterOfBugs has joined #openstack-nova15:11
*** Oku_OS is now known as Oku_OS-away15:11
*** aarefiev is now known as aarefiev_afk15:11
*** brault has quit IRC15:12
*** markmc has quit IRC15:12
*** nkorabli has joined #openstack-nova15:12
*** MasterOfBugs has quit IRC15:12
*** migi has quit IRC15:13
*** nkorabli has quit IRC15:14
*** migi has joined #openstack-nova15:14
bauwserleakypipes: mriedem: figleaf: thanks for helping me, always appreciated. :)15:16
bauwseryou just missed my new co-worker's face15:16
mriedemdogs psh15:16
*** markmc has joined #openstack-nova15:17
mriedemnow what did i say i was going to do an hour ago...15:17
bauwsermriedem: dansmith: soooo we can assume to modify a DB migration script like this https://review.openstack.org/#/c/458668/1 ?15:18
*** MasterOfBugs has joined #openstack-nova15:18
bauwsermriedem: are you then planning to do a .y release for ^ ?15:18
mriedembauwser: x15:18
mriedemmajor version bump15:18
bauwsermriedem: or would it still be a .z given it's a mitaka>newton migration script15:18
mriedemto f over red hat15:18
mriedemif there was a w, i'd use that15:19
mriedemepoch15:19
mriedemit's a bug fix15:19
mriedemnot a new migration15:19
mriedemso it's a patch release15:19
mriedem.z15:19
dansmithbauwser: can we assume what now?15:19
dansmithbauwser: you're asking if it's okay to make that change?15:20
mriedemwe don't have to worry about people with the bug getting past that migration,15:20
mriedembecause they'd be blocked on it15:20
mriedemhence the fix15:20
dansmith....right15:20
mriedemi.e. swebster_'s migration to newton was blocked on that migration15:21
*** kashyap has quit IRC15:21
dansmithyeah it's totally fine to make that change, I'm not sure what the concern is15:21
openstackgerritAndy McCrae proposed openstack/nova master: Allow CONTENT_LENGTH to be present but empty  https://review.openstack.org/45571015:21
mriedemi released a stable version as a patch release that had a db migration in it awhile back and red hat freaked out, so bauwser is touchy to backports on db migrations ever since15:22
bauwseryeah that15:22
dansmithokay but this is a blocker15:22
bauwser(sorry otp)15:22
mriedemi wasn't aware of red hat's internal stable release processes15:22
mriedemfor which i'll always be regretful15:22
dansmithyeah, I remember that, but.. this is... again, a blocker migration15:23
lyarwoodbauwser: which db migration was that?15:23
mriedemlyarwood: i think https://github.com/openstack/nova/commit/ee086460db947ea0dcd2cb27fd2aecf738b47c2015:24
*** efoley__ has quit IRC15:24
*** zenoway has quit IRC15:24
*** vladikr has quit IRC15:25
mriedemor https://github.com/openstack/nova/commit/608105a7c508ed48055dca6e2d327c944ecb18ea15:25
*** manjaro has quit IRC15:25
*** zenoway has joined #openstack-nova15:25
*** kashyap has joined #openstack-nova15:26
*** amotoki has joined #openstack-nova15:26
mriedemlyarwood: this is what you want for the brick encryptors change https://review.openstack.org/#/c/458834/15:26
lyarwoodmriedem: yup thanks I'll update the depends on with that now15:26
cdentandymccr, efried : you done yet, I've been holding off until you both bless that shiny code15:27
*** rmart04 has quit IRC15:27
efriedFer heaven's sake, bless it.  We could keep tweaking it for years.15:28
*** vks1 has quit IRC15:28
efriedUnless pep8 complains about those redundant parens, I say ship it!15:28
efriedoh, andymccr fixed...15:28
openstackgerritLee Yarwood proposed openstack/nova master: encryptors: Switch to os-brick encryptor classes  https://review.openstack.org/39159715:28
cdentefried: unfortunatley I can't +2 it, so...15:28
efriedcdent It looks JUST PERFECT now.  Please, please approve it!  ( sfinucan )15:29
andymccrhahahahahaha15:29
*** amotoki has quit IRC15:30
bauwserdansmith: mriedem: so this https://review.openstack.org/#/c/458668/1 is just for a mitaka>newton migration right?15:31
bauwserdansmith: mriedem: I mean, since we say to use the latest .z version, we're fine15:31
openstackgerritLee Yarwood proposed openstack/nova master: encryptors: Switch to os-brick encryptor classes  https://review.openstack.org/39159715:31
mriedembauwser: who is we?15:32
mriedemred hat?15:32
bauwserjust wanted to make sure it wasn't needing a new db sync if you already applied a newton install15:32
mriedembauwser: it's for an upgrade15:32
mriedemnot a new install15:32
*** amotoki has joined #openstack-nova15:32
mriedemselect([func.count()]).select_from(pci_devices)15:32
bauwserok, so no db sync for updating to that new package if already newton ?15:32
mriedemif you don't have pci devices (new install), then it's not a bug15:32
bauwserno db sync *required*15:33
*** gongysh has quit IRC15:33
bauwserif the answer is yes, then +W15:33
mriedemif you already got to newton you don't have this issue15:33
*** migi has quit IRC15:33
*** migi has joined #openstack-nova15:33
bauwserokay, that's what I thought, just double-checked15:33
mriedembecause 330 was in newton15:34
mriedemhttps://github.com/openstack/nova/blob/stable/newton/nova/db/sqlalchemy/migrate_repo/versions/330_enforce_mitaka_online_migrations.py15:34
*** amotoki has quit IRC15:35
*** ssurana has joined #openstack-nova15:35
*** MasterOfBugs has quit IRC15:36
*** baoli has joined #openstack-nova15:37
*** MasterOfBugs has joined #openstack-nova15:37
lyarwoodmriedem: ah sorry didn't see your check experimental15:38
*** zenoway has quit IRC15:38
lyarwoodmriedem: any idea why the encrypted volume tests were moved there?15:38
mriedemlyarwood: a bunch of scenario tests were marked slow to take them out of the main gate runs,15:41
mriedembecause the scenario tests were taking up a ton of time, and randomly failing and causing resets, which takes more time15:41
*** baoli has quit IRC15:41
mriedemit was a big QA effort around the time of the PTG15:41
lyarwoodmriedem: understood, me-- for not checking that the tests were still present in the gate in the recent CI runs.15:43
*** chyka has joined #openstack-nova15:43
*** lpetrut has quit IRC15:44
*** ildikov is now known as coffee_cat15:45
*** MasterOfBugs has quit IRC15:45
mriedemme-- :)15:46
mriedemnever seen that before15:46
*** jpena has quit IRC15:46
mriedemthis isn't c lee15:46
mriedemif you're going to decrement yourself, me -= me, please15:47
*** zenoway has joined #openstack-nova15:47
*** dikonoor has joined #openstack-nova15:48
*** amotoki has joined #openstack-nova15:48
lyarwoodmriedem: always reviewing ;)15:49
*** MasterOfBugs has joined #openstack-nova15:50
openstackgerritBalazs Gibizer proposed openstack/nova master: Add BDM to InstancePayload  https://review.openstack.org/44877915:50
*** yamamoto has joined #openstack-nova15:51
*** jpena has joined #openstack-nova15:52
dansmithmriedem: me -= me = 0, not me-1 right?15:53
mriedemdansmith: you've got me there15:55
mriedemsuperdan15:55
*** dansmith is now known as superdan15:55
*** Guest86170 has quit IRC15:56
bauwserif me = -1, is me a square root of myself ?15:56
*** lyarwood is now known as me15:56
mealways wanted a friday nick15:56
*** me is now known as Guest4138315:57
Guest41383dude15:57
bauwserheh, registered15:57
mdboothHaha15:57
Guest41383aaaaaaaaaand that's not going to be it15:57
*** MasterOfBugs has quit IRC15:57
bauwserI did registered both my casual nick *and* my friday one :)15:57
*** Guest41383 is now known as lyarwood15:57
*** Guest86170 has joined #openstack-nova15:58
openstackgerritEric Fried proposed openstack/nova master: PowerVM Driver: spawn/destroy #3: TaskFlow  https://review.openstack.org/43872915:58
*** david-lyle has joined #openstack-nova15:58
bauwseranyway, let's call it a week-end15:59
*** slaweq has joined #openstack-nova15:59
*** salv-orlando has joined #openstack-nova16:00
*** dikonoo has joined #openstack-nova16:02
*** yongjiexu has quit IRC16:03
*** salv-orlando has quit IRC16:04
*** slaweq has quit IRC16:04
*** salv-orlando has joined #openstack-nova16:05
*** dikonoor has quit IRC16:05
*** damien_r has quit IRC16:05
*** kaisers has quit IRC16:06
*** kaisers has joined #openstack-nova16:06
* cdent agrees with bauwser 16:09
* cdent waves16:09
*** cdent has quit IRC16:09
*** mlavalle has quit IRC16:11
*** zenoway has quit IRC16:14
*** slaweq has joined #openstack-nova16:17
*** yongjiexu has joined #openstack-nova16:17
*** slaweq has quit IRC16:18
*** zenoway has joined #openstack-nova16:19
openstackgerritMatt Riedemann proposed openstack/nova master: api-ref: move createBackup to server-actions  https://review.openstack.org/45297116:19
openstackgerritMatt Riedemann proposed openstack/nova master: 2.43: Remove Location header from createImage and createBackup responses  https://review.openstack.org/45544316:19
*** nic has joined #openstack-nova16:21
openstackgerritOpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements  https://review.openstack.org/45883416:21
*** rmart04 has joined #openstack-nova16:21
*** rmart04 has quit IRC16:22
*** zenoway has quit IRC16:23
*** annegentle has quit IRC16:26
*** voelzmo has joined #openstack-nova16:27
*** annegentle has joined #openstack-nova16:27
*** john51 has quit IRC16:27
*** john51_ has joined #openstack-nova16:27
*** dikonoo has quit IRC16:28
*** beekneemech has quit IRC16:30
*** esberglu has quit IRC16:30
*** nic1 has joined #openstack-nova16:31
*** dtp has joined #openstack-nova16:31
*** yongjiexu has quit IRC16:33
*** voelzmo has quit IRC16:33
*** nic has quit IRC16:34
*** gyee has joined #openstack-nova16:36
*** lucasagomes is now known as lucas-afk16:36
*** nic1 has quit IRC16:36
*** dikonoo has joined #openstack-nova16:38
*** baoli has joined #openstack-nova16:38
*** amotoki has quit IRC16:39
*** ltomasbo is now known as ltomasbo|away16:40
*** pchavva has quit IRC16:40
*** baoli has quit IRC16:43
*** bnemec has joined #openstack-nova16:44
*** bnemec is now known as beekneemech16:45
*** wasmum has joined #openstack-nova16:46
openstackgerritDan Smith proposed openstack/nova master: Tell people that the nova-cells man page is for cells v1  https://review.openstack.org/45692516:46
openstackgerritDan Smith proposed openstack/nova master: Add release note and update cell install guide for multi-cell limitations  https://review.openstack.org/45692316:46
*** mlavalle has joined #openstack-nova16:47
*** dmellado has quit IRC16:52
*** kashyap has quit IRC16:52
*** ltomasbo|away has quit IRC16:52
*** markmc has quit IRC16:53
*** nkorabli has joined #openstack-nova16:53
*** jpena has quit IRC16:54
*** weshay has quit IRC16:54
*** migi has quit IRC16:54
*** ijw has quit IRC16:54
*** ijw has joined #openstack-nova16:55
*** yamamoto has quit IRC16:55
*** Apoorva has joined #openstack-nova16:55
*** ijw has quit IRC17:00
*** derekh has quit IRC17:00
*** salv-orlando has quit IRC17:00
*** kashyap has joined #openstack-nova17:00
*** jpena|off has joined #openstack-nova17:00
*** migi has joined #openstack-nova17:00
*** markmc has joined #openstack-nova17:01
*** weshay has joined #openstack-nova17:01
coffee_catlyarwood: I had that thought rushing through my head as well re swap volume and reserve the new one17:01
*** ltomasbo|away has joined #openstack-nova17:02
coffee_catcoffee_cat: it was my laziness at this point that I didn't think it through, I just wanted to get something up what we can argue over :)17:02
*** jpena|off is now known as jpena17:04
*** dmellado has joined #openstack-nova17:06
*** jpena is now known as jpena|off17:07
*** eglynn has quit IRC17:07
*** arunman has joined #openstack-nova17:08
*** arunman has quit IRC17:08
*** marst has quit IRC17:09
*** marst_ has joined #openstack-nova17:09
*** brault has joined #openstack-nova17:10
*** nic has joined #openstack-nova17:15
cfriesendoes it make sense to allow a rebuild of a boot-from-volume to a different image, given that we don't write the new image to the volume?17:16
*** brault has quit IRC17:18
*** tesseract has quit IRC17:19
*** slaweq has joined #openstack-nova17:21
*** ig0r_ has quit IRC17:24
*** ralonsoh has quit IRC17:25
*** gjayavelu has joined #openstack-nova17:28
*** ig0r_ has joined #openstack-nova17:28
*** annegentle has quit IRC17:30
*** tuan_luong has quit IRC17:34
*** salv-orlando has joined #openstack-nova17:34
*** baoli has joined #openstack-nova17:39
*** esberglu has joined #openstack-nova17:40
*** esberglu_ has joined #openstack-nova17:41
*** esberglu has quit IRC17:41
*** baoli has quit IRC17:43
*** imacdonn has quit IRC17:46
*** zenoway has joined #openstack-nova17:47
*** zenoway has quit IRC17:51
*** mnestratov has joined #openstack-nova18:00
mnestratovsdague: hi, around?18:02
sdaguemnestratov: yeh, what's up?18:02
mnestratovcan you take  a look at https://review.openstack.org/#/c/458912/18:02
*** jdurgin has quit IRC18:04
*** yamahata_ has quit IRC18:04
*** owalsh_ has joined #openstack-nova18:06
sdaguemnestratov: my only concern with that is that we're going to need to add it back in as soon as we roll to packages18:08
sdagueand we're going to fail some upgrades in the process18:09
*** owalsh has quit IRC18:10
mnestratovsdague: hmm, and when do we plan this? as soon as packages are ready?18:10
*** zenoway has joined #openstack-nova18:11
sdaguemnestratov: yeh, centos already has new enough packages in epel, it might switch back over if epel comes back on18:14
sdagueubuntu has packages, but the socket interface isn't stable yet in them18:14
*** sambetts is now known as sambetts|afk18:15
*** jdurgin has joined #openstack-nova18:15
mnestratovI see, well, looks we shouldn't merge this at all then18:15
*** zenoway has quit IRC18:15
*** yamahata_ has joined #openstack-nova18:22
*** rnoriega has joined #openstack-nova18:25
*** slagle_ has joined #openstack-nova18:29
*** salv-orlando has quit IRC18:29
openstackgerritMatt Riedemann proposed openstack/nova master: encryptors: Switch to os-brick encryptor classes  https://review.openstack.org/39159718:31
*** winston-d_ has quit IRC18:33
mriedemi don't know how to debug this https://bugs.launchpad.net/nova/+bug/168533318:33
openstackLaunchpad bug 1685333 in OpenStack Compute (nova) "Fatal Python error: Cannot recover from stack overflow. - in py35 unit test job" [High,Confirmed]18:33
*** baoli has joined #openstack-nova18:39
*** amotoki has joined #openstack-nova18:39
*** jerrygb has quit IRC18:40
*** mnestratov has quit IRC18:41
mriedeminteresting18:43
mriedemlive migration job failed because the destination said the guest wasn't found18:43
mriedembut on the source side, the logs say "You may see the error "libvirt: QEMU error: Domain not found: no domain with matching name." This error can be safely ignored."18:43
*** amotoki has quit IRC18:44
*** Sukhdev has joined #openstack-nova18:46
mriedemoh fun that info message is in the compute manager18:47
mriedemwhere i might not be using libvirt at all18:47
*** ijw has joined #openstack-nova18:48
*** jerrygb has joined #openstack-nova18:49
*** imacdonn has joined #openstack-nova18:50
*** ijw has quit IRC18:52
*** mfisch has quit IRC18:54
*** med_ has quit IRC18:54
*** med_ has joined #openstack-nova18:54
*** mfisch has joined #openstack-nova18:54
mriedemoh no wonder this goes back to diablo in a commit with no explanation18:54
*** mfisch has quit IRC18:55
*** mfisch has joined #openstack-nova18:55
*** med_ is now known as Guest7674618:55
openstackgerritMatt Riedemann proposed openstack/nova master: Remove archaic reference to QEMU errors during post live migration  https://review.openstack.org/45893518:56
mriedemalso18:57
mriedemPost live migration at destination ubuntu-xenial-2-node-osic-cloud1-s3500-8527282 failed18:57
mriedemMigrating instance to ubuntu-xenial-2-node-osic-cloud1-s3500-8527282 finished successfully.18:57
mriedemwtf18:58
kashyapmriedem: Oops - that error message, specific to driver18:58
mriedemkashyap: well, it's probably from when libvirt was the only driver18:59
kashyapHmm.  Are other drivers, besides Xen, are well-maintained?18:59
* kashyap should probably duck...18:59
mriedemhypev19:00
mriedem*hyperv19:01
*** voelzmo has joined #openstack-nova19:01
kashyapYeah.19:01
*** fragatina has quit IRC19:01
kashyapSo, will Nova support Moby Containers? :P19:01
* kashyap stops trolling now19:02
*** pcaruana has quit IRC19:02
kashyapWas debugging a "fun" issue where exposing a CPU "L3" cache (via QEMU's "-cpu host,l3-cache=on") to a guest will improve performance by 10% or so for some SAP workloads!19:03
*** fragatina has joined #openstack-nova19:03
mriedemkashyap: you should talk to cfriesen then19:04
mriedemhe's been looking for someone that loves qemu and libvirt for the last 3 days19:04
kashyapmriedem: Found out the root cause, actually19:04
kashyapBut luckily, no action item needed for upstream Nova, Because:19:04
kashyapWe "get it for free", with QEMU 2.8 and above.19:04
kashyapAs it is part of the _default_ machine type19:04
*** tbachman has quit IRC19:05
kashyapSo, if anyone is hitting it with Nova, using an older QEMU, still "no problem", we could use the always-handy (but voids support warranty) workaround:19:05
kashyapLibvirt's XML namespace <qemu:commandline> [...] </qemu:commandline>19:05
kashyapWhile upstream libvirt is trying to wire it into its QEMU command-line generator.  So all good.  And I can wind up for the night19:06
mriedemis that like injecting stuff into rabbit at runtime using erlang?19:06
kashyapHehe19:07
kashyapcfriesen: You might be interested in this -- https://www.redhat.com/archives/libvir-list/2017-April/msg00815.html19:07
kashyapUnfortunately, the link won't work :-(19:07
kashyapAs there's a major outage in one of the critical datacenters19:07
kashyapBut rest assured, somewhere some tired admin is sweating to hell and back trying to fix the outage ...19:08
kashyapmriedem: But more seriously, that namespace is very handy -- we (Nova) could test interesting features and can decide: "Okay, this and that combination of QEMU command-line gives Nova users some advantage -- so let's file an RFE to get that wired up into official libvirt APIs"19:09
mriedemkashyap: maybe it's down b/c he was injecting stuff via qemu command line to the infra running the server19:09
kashyapmriedem: Yeah, that workaround should be a one-off hack only.19:09
kashyapBecause, when using that workaroud, in logs, you'd see the instances to be marked as "tainted" (rightfully)19:10
kashyapWarning the opertors that: "Look, your libvirt / QEMU upgrade might break your existing guests"19:10
kashyapAnd of course, to help support people identify if someone is using unofficial command-line19:10
mriedemi'm much more interested in making sure the features we've already landed actually work19:10
kashyapmriedem: I'm all with you19:10
mriedemlike when live migration fails and we tell you it was ok19:10
kashyap"Stability" over "yeah, let's bake that half-assed feature in, and let it rot after initial enthusiasm wanes"19:11
superdanmriedem: lol, I was trying to help with your doc patches, sorry if that was not that helpful19:11
mriedemsuperdan: you ruined EVERYTHING!19:12
mriedemsuperdan: you just have to realize the sfinucan-isms19:12
mriedemwith .rst files19:12
*** tbachman has joined #openstack-nova19:12
* superdan hangs his head in shame19:12
superdanmriedem: the one thing I know about sfinucanisms is that he gives a shit about the formatting and I do not19:12
superdanI read it in text format19:12
mriedemi also care about format19:12
mriedemit's why sfinucan and i butt heads19:12
superdanwell, sorry, you gonna change it?19:12
mriedemno, i don't really care19:13
superdanack19:13
mriedemi'm fixing this live migration logging turd19:13
superdannever again shall I do that19:13
mriedemwhilst live migration job is broken in ocata and blocking all changes19:13
mriedemand kashyap wants nova injecting qemu command line stuff in production, it's insane :P19:13
kashyapmriedem: No, no!19:13
kashyapYou're too eager to misunderstand, aren't you?19:13
mriedemkashyap: i know all too well my friend19:14
kashyap:P19:14
kashyapmriedem: What is the failure?  Actually Dave Gilbert from QEMU is also up and awake at this our19:14
kashyapI see the failure you link above is due to a bogus error message19:14
kashyapIs there anything more other than that?19:14
*** mlavalle has quit IRC19:14
*** brault has joined #openstack-nova19:14
kashyap(s/our/hour/)19:15
kashyapJeez - "logging turd"19:15
openstackgerritSamantha Blanco proposed openstack/nova master: Make flavor-rxtx policy more granular flavor-rxtx currently only has one policy it checks against, which is not restrictive enough when used in conjunction with other policies (e.g., flavor-manage). This allows users a greater degree of customization.  https://review.openstack.org/44403619:16
kashyapmriedem: It can be fast-approved, I think?19:16
openstackgerritSamantha Blanco proposed openstack/nova master: Make flavor-rxtx policy more granular flavor-rxtx currently only has one policy it checks against, which is not restrictive enough when used in conjunction with other policies (e.g., flavor-manage). This allows users a greater degree of customization.  https://review.openstack.org/44403619:17
*** brault has quit IRC19:18
mriedemkashyap: i don't actually need someone from qemu19:21
mriedemi mean, i don't know why the guest wasn't found that caused this actual failure19:21
mriedembut that's not what i'm fixing atm19:21
kashyapmriedem: Thought, you were also looking at another bug which involves QEMU itself19:22
*** fragatina has quit IRC19:22
*** mlavalle has joined #openstack-nova19:22
mriedemwell, this live migration job failed19:22
mriedembecause during post live migration, when source calls dest to complete the migration on that side, the guest domain wasn't found19:23
kashyapmriedem: Got a link to a log, if you don't mind?19:23
mriedemeven though we were in post live migration19:23
kashyapI think I should find one from here: logs.openstack.org/43/458843/1/check/gate-tempest-dsvm-multinode-live-migration-ubuntu-xenial/697a501/19:23
mriedemyes19:23
* kashyap now remembers by memory: "subnode2" == source logs19:24
kashyapThe root dir (gate-tempest-dsvm-multinode-live-migration-ubuntu-xenial/697a501/logs/) has destination logs19:25
mriedemhttp://logs.openstack.org/43/458843/1/check/gate-tempest-dsvm-multinode-live-migration-ubuntu-xenial/697a501/logs/screen-n-cpu.txt.gz#_2017-04-21_13_54_10_15019:25
mriedemyes ^ is the dest logs19:25
* kashyap nods19:27
mriedemhttp://logs.openstack.org/43/458843/1/check/gate-tempest-dsvm-multinode-live-migration-ubuntu-xenial/697a501/logs/libvirt/qemu/instance-00000001.txt.gz19:28
mriedem/build/qemu-5OJ39u/qemu-2.8+dfsg/nbd/server.c:nbd_receive_request():L710: read failed 2017-04-21 13:54:08.792+0000: shutting down, reason=failed19:28
*** dikonoo has quit IRC19:28
*** cleong has quit IRC19:28
kashyapFor future note: Incidentally, we're going to get finer-grained details about shutdown reasons19:29
kashyapWhether it is guest-triggered, or host-triggerred19:29
kashyapAnd what precisely caused it, etc19:29
kashyap(There's a long thread on qemu-devel upstream, to iron out the details.)19:30
mriedemwell, /build/qemu-5OJ39u/qemu-2.8+dfsg/nbd/server.c:nbd_receive_request():L710: read failed19:31
mriedemcaused it19:31
mriedemi guess19:31
*** haplo37 has quit IRC19:31
*** nkorabli_ has joined #openstack-nova19:31
kashyapYes, I recall seeing that19:31
* kashyap looks for detaiils19:31
mriedem/build/qemu-5OJ39u/qemu-2.8+dfsg/nbd/server.c:nbd_receive_request():L710: read failed19:32
mriedemoops19:32
kashyapmriedem: Yep, I recall it19:33
mriedemhttp://logs.openstack.org/43/458843/1/check/gate-tempest-dsvm-multinode-live-migration-ubuntu-xenial/697a501/logs/libvirt/libvirtd.txt.gz#_2017-04-21_13_54_08_79219:33
kashyapI even reported it recently here: http://lists.nongnu.org/archive/html/qemu-devel/2017-04/msg01086.html19:33
kashyapQuoting myself:19:33
kashyapJust writing for completeness' sake, if you try to stop the NBD server19:33
kashyapon the destination, _without_ gracefully completing or cancelling the19:33
kashyap`drive-mirror` job on the source, you see the below:19:33
kashyap[...]19:33
kashyap{"execute":"nbd-server-stop"}19:33
kashyap{"return": {}}19:33
kashyap/home/stack/src/qemu/nbd/server.c:nbd_receive_request():L706: read failed19:33
kashyap[...]19:33
*** nkorabli has quit IRC19:34
mriedemkashyap: so this is a known bug in qemu?19:35
kashyapmriedem: It's actually benign19:35
kashyapBecause:19:35
kashyapIt means the source has gone away unexpectedly or that you stopped the NBD server before the source was disconnected19:35
kashyapI know Nova shouldn't care this level of detail.19:36
*** haplo37 has joined #openstack-nova19:36
kashyapI'm checking if my discussion resulted in another patch19:36
*** cdent has joined #openstack-nova19:36
mriedemaround that same time in syslog http://logs.openstack.org/43/458843/1/check/gate-tempest-dsvm-multinode-live-migration-ubuntu-xenial/697a501/logs/syslog.txt.gz#_Apr_21_13_54_0819:37
kashyapmriedem: What were you trying to quote in the previous libvirtd log?  Your link seems broken here19:37
*** voelzmo has quit IRC19:38
mriedemthat's where it failed19:38
mriedem2017-04-21 13:54:08.792+0000: 12165: debug : qemuProcessStop:5941 : Shutting down vm=0x7f918c009d40 name=instance-00000001 id=2 pid=5792, reason=failed, asyncJob=migration in, flags=119:38
mriedemthen around that time in syslog19:39
mriedemApr 21 13:54:08ubuntu-xenial-2-node-osic-cloud1-s3500-8527282 virtlogd[12188]: End of file while reading data: Input/output error19:39
kashyapBut _what_ caused the guest shutdown...19:40
mriedemno idea19:40
kashyapmriedem: Checking with Eric Blake & Max, both should know this code in libvirt / QEMU respectively19:42
-openstackstatus- NOTICE: Gerrit will be offline briefly starting at 20:00 for scheduled maintenance http://lists.openstack.org/pipermail/openstack-dev/2017-April/115702.html19:42
*** rdo has quit IRC19:48
*** rnoriega has quit IRC19:49
*** Apoorva has quit IRC19:49
*** rdo has joined #openstack-nova19:49
*** fragatina has joined #openstack-nova19:50
cdentthank you mriedem, someone had to respond to leakypipes19:52
kashyapmriedem: Is this mig. failure blocking Gate?19:53
*** baoli has quit IRC19:54
*** ig0r_ has quit IRC19:55
kashyapAt least, I found out (w/ help from Max) the commit that introduced it.19:55
mriedemcdent: ha19:56
mriedemkashyap: i think this is probably random failure19:56
kashyapmriedem: Ah, okay, good.19:57
kashyapThe actual culprit failure is on the source host:19:57
kashyaphttp://logs.openstack.org/43/458843/1/check/gate-tempest-dsvm-multinode-live-migration-ubuntu-xenial/697a501/logs/subnode-2/libvirt/qemu/instance-00000001.txt.gz19:57
mriedemstable/ocata is blocked b/c of the live migration job, and to fix that i need to get this other change in, but i think this is just an intermittent failure19:57
mriedemoh fun19:57
mriedemqemu-system-x86_64: /build/qemu-5OJ39u/qemu-2.8+dfsg/block/io.c:1514: bdrv_co_pwritev: Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed.19:57
kashyapYep19:57
mriedemi have no idea what that means19:57
*** felipemonteiro has quit IRC19:58
*** ericyoung has joined #openstack-nova19:59
*** awaugama has quit IRC19:59
*** smatzek has quit IRC20:02
kashyapmriedem: It means (according to the QEMU commit that introduced it):20:02
kashyapSomething tried to write to the image file on the source, _while_ it is being migrated20:03
-openstackstatus- NOTICE: Gerrit is offline briefly for scheduled maintenance http://lists.openstack.org/pipermail/openstack-dev/2017-April/115702.html20:03
kashyapAnyway, it's unreasonably late here, I'll get to this on Monday20:03
*** ChanServ changes topic to "Gerrit is offline briefly for scheduled maintenance http://lists.openstack.org/pipermail/openstack-dev/2017-April/115702.html"20:03
kashyapCool; Gerrit is also offline on time.  Everything is in harmony, and the earth keeps spinning20:04
mriedemkashyap: ack, thanks for taking a look20:05
openstackgerritMatt Riedemann proposed openstack/nova master: Do not log live migration success when it actually failed  https://review.openstack.org/45895820:06
mriedemsuperdan: dig this ^20:06
mriedemsdague: ^ you too20:06
mriedemclassic terrible20:06
*** Sukhdev has quit IRC20:07
superdanmriedem: does that cleanup flags thing tell us not to destroy disks, etc in the case of failure?20:08
superdanlike, I'm surprised that falling through is the right thing to do20:08
openstackgerritSteve Noyes proposed openstack/nova master: Add Cinder v3 detach to shutdown_instance  https://review.openstack.org/45687720:09
superdanmriedem: doesn't look like it does to me20:09
*** xyang1 has quit IRC20:10
superdanmriedem: so if we fail, have not shared path, we'll do_cleanup=True and tell the driver to run cleanup right?20:10
*** jerrygb has quit IRC20:10
mriedemlooks that way20:11
superdanand libvirt goes right into deleting stuff20:11
mriedemeven though you should be rolling back20:11
mriedembut this isn't where rollback is called from20:11
*** nic has quit IRC20:12
superdanright, this is if post-at-destination fails, which presumably could fail for some mundane reason and then we eff things up by doing the cleanup20:12
*** Apoorva has joined #openstack-nova20:12
*** slagle_ has quit IRC20:12
mriedemis live_migration started from the source or dest host?20:12
superdansource20:13
mriedemoh right it has the dest parameter20:13
mriedemi lose track of the musical chairs game that is live migration20:13
superdanyeah it's confusing20:13
mriedemso the source side though it was done, and calls _post_live_migration (source compute stiffl)20:14
mriedem*still20:14
mriedemwhich does an rpc call to post_live_migration_at_destination on the dest host20:15
superdanoh, we don't get here unless it actually migrated20:15
mriedemthat fails becuase the guest isn't found on the dest host20:15
superdanand then we just failed in the post call, but whatever, we don't own it anymore20:15
mriedemyeah post_live_migration_at_destination fails and returns the failure back through rpc20:16
mriedemwe get the failure, log the trace "Post live migration at destination %s failed"20:17
superdanright, so I guess it's okay20:17
mriedemthen drop through and start cleaning up the source20:17
superdanwe don't get to this post method unless libvirt said it worked20:17
superdanso we can clean up regardless20:17
mriedemmeanwhile, the guest is not on the dest either20:17
mriedemyeah20:17
superdanyeah, but nothing we can do about it20:17
mriedemso basically,20:17
mriedemyour sh is f'ed20:17
mriedemand you instance is gone20:17
mriedem*your20:17
superdanyeah, I just wanted to make sure we didn't delete the thing if migration failed20:17
superdanthat's a double kick in the pands20:17
mriedemmeanwhile we've deleted your disks20:18
mriedemthis is really like, well, it's all busted, oh and btw we deleted your instance20:18
mriedemyou're welcome20:18
superdanwhatever, libvirt told us to :)20:18
mriedemwow20:18
mriedemremind me to never run live migration if i'm in ops20:18
superdanif libvirt told us it was done, then there should be disks on the other side too20:18
mriedemyeah hopefully20:19
superdanit's scary how many people depend on live migration20:19
coffee_catlyarwood: are you around?20:24
*** jerrygb has joined #openstack-nova20:25
*** felipemonteiro has joined #openstack-nova20:26
*** felipemonteiro has quit IRC20:26
coffee_cator anyone who could/would answer stupid BDM questions20:27
mriedemi can answer stupid questions20:27
mriedemcoffee_cat: are you in budapest right now?20:27
mriedemor the US?20:27
openstackgerritEric Fried proposed openstack/nova master: PowerVM Driver: spawn/destroy #4: full flavor  https://review.openstack.org/39128820:27
coffee_catmriedem: in the US until tomorrow evening20:28
mriedemoh, lee is in the UK20:28
mriedemso he's in a pub somewhere20:28
coffee_catmriedem: will fly back next Sunday though...20:28
*** felipemonteiro has joined #openstack-nova20:28
coffee_catmriedem: ah, I forgot20:28
coffee_catmriedem: anyhow, I'm sure you can help me out here to understand what's going on :)20:29
coffee_catmriedem: so his comments are here: https://review.openstack.org/#/c/456971/2/nova/compute/manager.py20:29
coffee_catmriedem: and I started to wonder whether the BDM is host or instance specific? if this question even makes sense...20:30
mriedemthe bdm is instance + volume specific20:31
mriedemso we get the bdm for the instance and existing (old) volume on L501120:31
mriedemthe connector is specific to the host20:33
mriedemwell, host + instance20:33
mriedemso in the old way, after we swap the volume, we terminate the connection for the old volume,20:35
*** satyar has quit IRC20:35
mriedemand then update the bdm with the new connection_info for the new volume20:36
*** ChanServ changes topic to "This channel is for Nova development. For support of Nova deployments, please use #openstack. Please see: https://wiki.openstack.org/wiki/Nova/Ocata_Release_Schedule"20:36
-openstackstatus- NOTICE: Gerrit is back in service and generally usable, though remote Git replicas (git.openstack.org and github.com) will be stale for the next few hours until online reindexing completes20:36
*** amotoki has joined #openstack-nova20:40
mriedemcoffee_cat: left comments inline20:41
mriedemcoffee_cat: this was also called out in john's spec i believe20:41
mriedemhttps://specs.openstack.org/openstack/nova-specs/specs/pike/approved/cinder-new-attach-apis.html#swap-volume20:41
coffee_catmriedem: ok, cool, makes sense, so basically need to create a new attachment for the new volume20:42
coffee_catand we might not be able to consolidate the workflow that much, but oh well20:42
mriedemyes20:42
mriedemwhere we used to call initialize_connection for the new volume, now we'll need to create a new attachment20:43
mriedemfor the new volume20:43
coffee_catok, that sounds easily doable20:43
mriedemif everything is ok, we delete the old attachment for the old volume and update the bdm with the new attachment_id20:43
mriedemjohn's spec is talking about doing things in the api too, which i'm not really following20:44
mriedem(api) create new attachment for the volume uuid-new, fail API call if we can’t create that attachment20:44
mriedem^ is what i was saying we could do on the compute where initialize_connection is called for the new volume20:44
mriedemwe could create the attachment for the new volume in the api, but we don't have a bdm for that20:45
mriedemso not sure how we get that in the compute, unless we lookup the new volume details and get it's attachment list20:45
coffee_catyeah, BDM is problematic :/20:45
*** slaweq has quit IRC20:45
*** slaweq has joined #openstack-nova20:45
*** amotoki has quit IRC20:46
mriedemmaybe he just meant create the new attachment in the api so we can fail fast20:46
mriedembut,20:46
coffee_catprobably as that was a topic many times20:46
mriedemwe'd only do that if we knew the old attached volume was created with the new flow i htink20:46
mriedem*think20:47
*** ociuhandu has joined #openstack-nova20:47
mriedemi'm not sure if that matters or not20:47
mriedembut it probably does20:47
coffee_catso the volume is always created the same way20:47
mriedemthis is all new flow stuff20:47
mriedem"In this section, we talk about what happens should the volume being swapped have the attachment_id present in the BDM, and as such we follow the new flow."20:47
mriedemyeah, so if the bdm.attachment_id is set, we key off that for all of the swap volume goodies outlined in the spec20:48
*** openstackgerrit has quit IRC20:48
mriedemlike creating a new attachment for the new volume, etc20:48
coffee_catand for the new volume we can create that with the new flow20:48
coffee_catif the API is available20:49
mriedemwell i think the point is, you can't swap from a volume attachd the old way, to a volume attached the new way20:49
mriedemyou have to swap from attached new way to attached new way20:49
mriedemif that makes sense20:49
mriedemi don't know if technically it makes a difference on the cinder side20:49
coffee_catI don't really see why not, but as we go by attachment_id in the BDM anyhow it pretty much doesn't matter20:49
sdaguemriedem: it would be less terrible if you used the fixture that actually captures the log stream20:49
*** baoli has joined #openstack-nova20:49
mriedemcoffee_cat: the reason john and i said to do it this way in the spec is so nothing else in the code does anything using the new apis until we've plumbed in support for attaching volumes the new way20:50
smcginnismriedem: Should be OK on the Cinder side as long as each volume has its attachment info.20:50
mriedemsince everything keys off that20:50
coffee_catin the sense that we only detach --> attach with the new flow if the BDM.attachment_id is set20:50
smcginnismriedem: ie, we don't do some silly DB swap of some data to "make it easier"20:50
mriedemcoffee_cat: i think i'm agreeing with you20:51
mriedemthe thing i don't like about https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/cinder-new-attach-apis.html#swap-volume and creating the new attachment for the new volume in the API is, we'd have to do a service version check on that b/c we wouldn't know if the compute we're going to cast to is new enough to understand what we're doing20:51
coffee_catmriedem: ok, if we want to do this in the API, where we don't have the BDM that's another thing20:51
mriedemi don't think we want to do it in the api20:52
mriedemsince that logic relies on if the compute is new enough i think20:52
mriedemif we're casting to an ocata compute, it's not going to have any of this new bdm.attachment_id code20:52
coffee_catalthough there we need to check whether the new Cinder API is available, etc.20:52
mriedemwell, that's why we key off bdm.attachment_id,20:52
mriedemif that is set, we're using new api20:52
*** kiwi_rot has joined #openstack-nova20:52
mriedemthat's why new style attach comes at the very end20:53
mriedemsince everything else keys off that20:53
coffee_catmriedem: yeah, on the compute it's all fine and I think we're on the same page if we keep things there20:53
mriedemcoffee_cat: ok i can amend the spec for that20:53
mriedemwhen i add in the stuff we talked about this morning20:53
mriedemabout begin_detaching20:53
coffee_catmriedem: sounds good, thank you20:53
*** yamamoto has joined #openstack-nova20:54
*** baoli has quit IRC20:57
*** kiwi_rot has quit IRC20:57
*** tbachman has quit IRC20:57
*** felipemonteiro has quit IRC20:58
*** yamamoto has quit IRC20:58
*** thorst has quit IRC21:03
*** xyang1 has joined #openstack-nova21:10
mriedemmaybe john had us creating the new attachment in the api in place of calling reserve on the new volume21:12
mriedembut i thought with the new flow, we still called reserve when doing an attach?21:13
mriedemcoffee_cat: do you remember? ^21:13
mriedemthe spec doesn't talk about reserve21:14
mriedemhmm, the cinder spec talks about it http://specs.openstack.org/openstack/cinder-specs/specs/ocata/add-new-attach-apis.html#proposed-change21:15
mriedem"If the connector is not specified this call will only complete the volume reservation step and create an empty volume attachment. This can be used by Nova to call it from the API and start the volume attaching process by checking that the volume is available and creates the empty attachment."21:15
*** brault has joined #openstack-nova21:15
mriedemand in the nova spec21:16
mriedemhttps://specs.openstack.org/openstack/nova-specs/specs/pike/approved/cinder-new-attach-apis.html#proposed-change21:16
mriedem"In addition we should only use the new API when all of the nova-compute nodes have been upgraded."21:16
mriedemso if we only create a new attachment when cinder 3.27 is available and all computes are upgraded, then during swap_volume we can create the new attachment for the new volume based on bdm.attachment_id being set for the old volume21:17
mriedemwe could pass the new attachment_id over rpc to swap_volume on the compute21:17
coffee_catmriedem: we don't call reserve with the new flow21:18
mriedemcoffee_cat: yeah ok so then we need to create the new attachment in the api21:18
coffee_catmriedem: attachment_create without connector acts as reserve in the sense of putting the volume in 'reserved' state21:18
mriedemand pass the attachment id down to the compute over rpc, or the compute can look it up21:19
coffee_catI guess passing it to the compute should be fine if we don't want to call out to Cinder that much21:19
*** brault has quit IRC21:20
mriedemthe compute could lookup the attachments for the new volume...21:20
mriedemsince the cinder api isn't documented, i don't know what it looks like21:21
*** karimb has quit IRC21:21
coffee_catmriedem: also we need to figure out on the compute too how to finalize the attachment process21:21
coffee_catwe might do that by using receiving an attachment_id from the API as a trigger21:21
coffee_cator list the attachments with the call from the new flow too I guess21:22
*** tbachman has joined #openstack-nova21:23
mriedemwe update the attachment with the connector21:23
coffee_catI meant that we need to know on the compute that the API reserved the volume with the new flow21:24
coffee_catand we need to call attachment_update at some point21:24
coffee_catwith the connector21:25
*** nic has joined #openstack-nova21:25
mriedemif bdm.attachment_id is set, we know the api reserved the new volume with the new flow21:25
mriedemso i think https://review.openstack.org/#/c/456971/ gets more complicated than just updating the compute code21:25
mriedemit should also be the api code21:25
mriedemand the rpc api changes21:25
mriedemunless we just want to lookup the new attachment via rest api21:26
mriedemi just don't know if we have that support yet in cinderclient21:26
mriedemi could help work on this if you want21:26
mriedemi just can't do it today21:27
*** tjones has joined #openstack-nova21:27
*** thorst has joined #openstack-nova21:27
mriedemit would be great if you guys could get the v3.27 APIs documented in https://developer.openstack.org/api-ref/block-storage/v3/21:28
mriedemyou == all of cinder21:28
mriedemand by "guys" i mean guys and gals and those that don't identify as guys or gals, of course21:28
*** Sukhdev has joined #openstack-nova21:30
coffee_catmriedem: got it :)21:31
*** smatzek has joined #openstack-nova21:31
mriedemit looks like from the compute we could list attachments and filter on instance_uuid21:31
coffee_catand yeah, if the bdm.attachment_id is set then all computes should be on the high enough version, etc.21:31
coffee_catwe should definitely be able to do that if we want to skip the rpc changes, which I'm totally fine with21:32
mriedemwe could get attachments via cinderclient for a given volume and instance21:32
*** thorst has quit IRC21:32
mriedemusing filters it looks like21:32
jgriffithmriedem correct21:32
*** smatzek has quit IRC21:32
mriedemif we got more than one attachment back...idk21:33
*** smatzek has joined #openstack-nova21:33
mriedemwe shouldn't today since we don't support multiattach21:33
mriedembut it gets weird21:33
mriedemthat's probably why it's just better to pass the new attachment id over rpc21:33
jgriffithmriedem right, for today that’s our safety net21:33
mriedemto the compute21:33
mriedemrather than hae the compute guess21:33
*** ijw has joined #openstack-nova21:33
jgriffithBUT, there’s a get-attachment21:33
coffee_catmriedem: although for live migrate etc we should be able to have multiple attachments for the same volume21:33
coffee_catwhich should not make a mess for swap volume, but still21:33
mriedemi think passing over rpc is safest21:33
mriedemthen compute doesn't need to decide21:34
mriedemagain, i can help with this later, but i'm getting in trouble for hiding in the office when it's a nice day out21:34
coffee_catagreed21:34
mriedemso i'm forcefully detaching from this computer, ttyl21:34
*** jamesdenton has quit IRC21:34
*** bauwser is now known as bauzas21:34
coffee_catmriedem: have a good weekend :)21:34
*** salv-orlando has joined #openstack-nova21:38
*** fragatin_ has joined #openstack-nova21:42
*** amotoki has joined #openstack-nova21:42
*** fragatina has quit IRC21:45
*** amotoki has quit IRC21:47
*** dimtruck is now known as zz_dimtruck21:47
*** salv-orl_ has joined #openstack-nova21:49
*** salv-orlando has quit IRC21:52
*** nic has quit IRC21:55
*** smatzek has quit IRC21:55
*** marst_ has quit IRC21:56
*** burt has quit IRC21:56
*** baoli has joined #openstack-nova21:57
*** mdrabe has quit IRC22:00
*** baoli has quit IRC22:02
*** Apoorva_ has joined #openstack-nova22:03
*** Apoorva has quit IRC22:06
*** fragatin_ has quit IRC22:08
*** fragatina has joined #openstack-nova22:09
*** openstackgerrit has joined #openstack-nova22:14
openstackgerritEric Fried proposed openstack/nova master: WIP/PoC: nova.utils.get_service_url(group)  https://review.openstack.org/45825722:14
efriedmriedem johnthetubaguy mordred If possible I'd like y'all to start looking at ^^ - let me know if the approach is remotely sane, and maybe answer some of the open questions in the comments.22:15
efriedWait, was it johnthetubaguy or jaypipes?  Well, jaypipes isn't here, so...22:15
mordredit was jay - I have it open in my browser - I'm heads down on a different patch at the moment, but I'll come back and give you some feedback RSN22:17
mordredleakypipes: ^^22:18
efriedmordred Thanks.  No hurry, think I'm gonna bounce for the night.22:22
*** thorst has joined #openstack-nova22:22
*** jdurgin has quit IRC22:29
*** slaweq has quit IRC22:33
*** slaweq has joined #openstack-nova22:34
*** thorst has quit IRC22:37
*** slaweq has quit IRC22:38
*** slaweq has joined #openstack-nova22:44
*** Sukhdev has quit IRC22:45
*** lyan has quit IRC22:45
*** catintheroof has quit IRC22:46
*** zz_dimtruck is now known as dimtruck22:47
*** cdent has quit IRC22:47
*** baoli has joined #openstack-nova22:47
*** salv-orl_ has quit IRC22:48
*** dtp has quit IRC22:51
*** gjayavelu has quit IRC23:01
*** masber has quit IRC23:02
*** masber has joined #openstack-nova23:04
*** gjayavelu has joined #openstack-nova23:05
*** Apoorva_ has quit IRC23:07
*** Apoorva has joined #openstack-nova23:07
*** thorst has joined #openstack-nova23:08
*** edmondsw has quit IRC23:09
*** edmondsw has joined #openstack-nova23:09
*** abalutoiu_ has joined #openstack-nova23:10
*** erhudy has quit IRC23:10
*** thorst has quit IRC23:12
*** abalutoiu__ has joined #openstack-nova23:13
*** owalsh_ is now known as owalsh23:13
*** abalutoiu has quit IRC23:14
*** edmondsw has quit IRC23:14
*** nkorabli_ has quit IRC23:16
*** chyka has quit IRC23:16
*** brault has joined #openstack-nova23:16
leakypipesmriedem: oh, you didn't appreciate my playground rock-paper-scissors humour? boo.23:16
*** abalutoiu_ has quit IRC23:16
*** nkorabli has joined #openstack-nova23:17
*** abalutoiu has joined #openstack-nova23:17
*** esberglu_ has quit IRC23:17
*** abalutoiu__ has quit IRC23:18
*** owalsh_ has joined #openstack-nova23:19
*** Eugene has joined #openstack-nova23:19
*** Eugene has left #openstack-nova23:19
*** baoli has quit IRC23:20
*** brault has quit IRC23:20
*** nkorabli has quit IRC23:21
*** owalsh has quit IRC23:22
*** sdague has quit IRC23:24
*** baoli has joined #openstack-nova23:25
*** baoli has quit IRC23:26
*** dixiaoli has joined #openstack-nova23:30
*** gjayavelu has quit IRC23:31
*** dixiaoli has quit IRC23:35
*** thorst has joined #openstack-nova23:38
*** gouthamr has joined #openstack-nova23:39
*** yamahata_ has quit IRC23:40
*** gouthamr has quit IRC23:44
*** owalsh has joined #openstack-nova23:44
*** owalsh_ has quit IRC23:44
*** tuan_luong has joined #openstack-nova23:49
*** tuan_luong has quit IRC23:54
*** yamamoto has joined #openstack-nova23:56
*** gouthamr has joined #openstack-nova23:57
*** thorst has quit IRC23:58

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!