Earlier  
Posted Nick Remark
#openstack-nova - 2018-02-12
08:41:37 openstackgerrit Huang Rui proposed openstack/nova master: z/VM Driver: add get console output https://review.openstack.org/543344
08:42:01 vivsoni_ ameeda: this base64.decode_as_bytes(u'zN7FFUqWSSewXP7L7RpVFQ==')
08:42:13 vivsoni_ gives a closer results
08:43:06 bauzas good morning stackers
08:43:40 ameeda morning :)
08:43:57 ameeda vivsoni_: I am not sure, I will check that soon
08:54:39 vivsoni_ ameeda: Thanks :)
09:12:58 gryf vivsoni_, you can get your uuid by creating uuid object, like uuid.UUID(bytes=base64.decode_as_bytes(u'zN7FFUqWSSewXP7L7RpVFQ=='))
09:16:25 vivsoni_ gryf: this worked
09:16:27 vivsoni_ :)
09:18:53 vivsoni_ gryf: how you proceed to solve this ?
09:19:02 vivsoni_ gryf: please let me know
09:19:34 gryf vivsoni_, I just looked at documentation for uuid object ;)
09:32:35 vivsoni_ gryf: Ok... Thanks :)
10:19:02 hrw morning
10:31:41 ameeda morning
10:31:41 ameeda hello, how can I get python2-mistralclient version ?
10:32:26 openstackgerrit Chris Dent proposed openstack/nova master: WIP: Use nova.db.api directly https://review.openstack.org/543262
11:06:50 cdent bauzas, giblet: if you're around this is a fairly trivial related-bug fix and followup to some earlier stuff that merged: https://review.openstack.org/#/c/526691/
11:15:43 cdent bauzas, giblet: this one is also fairly trivial: https://review.openstack.org/#/c/536784/
11:20:09 openstackgerrit Chris Dent proposed openstack/nova master: Avoid inventory DELETE API (no conflict detection) https://review.openstack.org/539712
11:20:18 cdent efried: fixed the merge conflict on ^
11:25:04 gibi cdent: will look at them soon
11:25:44 bauzas cdent: ack
11:25:44 cdent gibi: awesome thanks. I'm going through all the stuff from last week's rp update, looking for easy wins...
11:30:43 cdent thanks bauzas
11:37:39 gibi cdent: just on more small clarification request in https://review.openstack.org/#/c/526691/2/nova/api/openstack/placement/deploy.py@97
11:38:03 hrw bauzas: can you help get https://review.openstack.org/#/c/541728/ (aarch64 status matrix) merged? mriedem already gave +2 so you can finish merge process :D
11:40:37 cdent gibi: yeah, good point. will fix
11:43:26 openstackgerrit Chris Dent proposed openstack/nova master: [placement] annotate loadapp as public interface https://review.openstack.org/526691
11:43:32 cdent bauzas, gibi: ^ please and thank you
12:26:42 gibi cdent: thanks, +2d
12:27:42 AJaeger novaclient team, please review https://review.openstack.org/543115 , https://review.openstack.org/#/c/543114, https://review.openstack.org/#/c/541370/ - the first two are needed to fix building, the third is needed for Zuul v3
12:38:34 ameeda gibi: could you please check https://review.openstack.org/#/c/526900/, it doesn't has any activity from awhile
13:08:11 bauzas hrw: https://review.openstack.org/#/c/541728/ will be merged in master, which is now for Rocky
13:08:59 bauzas hrw: let's discuss with mriedem if we should cherry-pick to Queens
13:41:43 hrw bauzas: thanks
13:42:16 hrw bauzas: I think that status-matrix part can be merged
13:49:14 efried cdent: Thank you sir.
13:49:37 efried cdent: Was it because of global_id?
13:50:32 cdent efried: I _think_ so. The method that you had deleted was different from when you had deleted if before, so I just deleted it again
13:50:44 efried right
13:54:07 efried leakypipes: Yet another +2-after-rebase please: https://review.openstack.org/#/c/539712/
13:55:38 efried cdent: here's that spec on resource class affinity for NUMA: https://review.openstack.org/543062
13:56:39 leakypipes efried: done
13:56:44 efried leakypipes: Thanks
13:56:52 cdent efried: yeah, already noted it because of the spying you suggested i might do
13:57:06 efried cdent: Turns out the "aggregate distance" business isn't actually suited for NUMA. I'll still send out a link to the eavesdrop/etherpad, but I'm going to kinda push it out of main memory to keep room for other stuff.
13:57:44 efried cdent: eh, spying?
13:58:04 cdent efried: I haven't digested it yet. glanced over the weekend and was all "ugh, not another table" and decided to come back later
13:58:37 cdent efried: spying: p!spy in https://anticdent.org/purple-irc-bot.html
13:58:52 efried cdent: Another table - you're talking about agg distance, not rc affinity, right?
13:59:20 cdent efried: right, I haven't looked at rc affinity yet, but its in the queue
13:59:21 efried cdent: Ah :)
13:59:26 efried okay, cool.
14:00:30 edleafe Scheduler subteam meeting running now in #openstack-meeting-alt
14:01:35 mriedem bauzas: i don't think https://review.openstack.org/#/c/541728/ needs to go to queens
14:01:46 bauzas sure, np
14:02:27 efried p!spy
14:17:53 openstackgerrit Chris Dent proposed openstack/nova master: Move db MAX constants to own file https://review.openstack.org/543469
14:21:04 AJaeger mriedem, who's reviewing python-novaclient nowadays? I have some reviews: review https://review.openstack.org/543115 , https://review.openstack.org/#/c/543114, https://review.openstack.org/#/c/541370/ - the first two are needed to fix building, the third is needed for Zuul v3.
14:21:44 efried AJaeger: I hear takashin might be a good candidate :)
14:25:22 AJaeger takashin: ^ please ping me in case of questions. Without the first two changes, the stable branches are broken.
14:30:31 mriedem AJaeger: i can look after the scheduler meeting
14:30:49 AJaeger mriedem: thanks
14:33:39 takashin AJaeger: I'm not a core reviewer for python-novaclient project...
14:36:02 openstackgerrit Merged openstack/nova master: Provide basic data for AArch64 support matrix/functionality https://review.openstack.org/541728
14:42:09 hrw mriedem, bauzas: thanks for helping with getting this stuff merged
14:44:28 gibi mriedem, bauzas: when I mentioned that a volume used in BFV case might not have any image associated to it I thought about someting like this: http://paste.openstack.org/show/670002/
14:44:59 gibi mriedem, bauzas: In this case nova cannot do anyithing to have the image reference, as there was never an image associated to the volume
14:46:02 gibi mriedem, bauzas: I don't think we can enforce to have image_id in the request spec
14:46:08 mriedem gibi: that vm is worthless though right?
14:46:31 gibi mriedem: yeah, I oversimplified it, but I could attach my-vol to a vm, populate it, detach it, then boot from it
14:47:48 mriedem sure, i wasn't saying we should 'require' an id in the requestspec.image field,
14:48:04 mriedem just that in certain cases (presumably the more normal cases), it's available via the volume_image_metadata
14:48:19 mriedem and furthermore, we can use that information later if a cell is down
14:48:30 mriedem and we use the request spec to represent the instance in the GET /servers/{id}/detail response
14:48:39 mriedem *if we use
14:49:28 gibi mriedem, bauzas: OK, it is clearer now. I had the feeling that we want to make image_id mandatory in the request spec
14:50:10 mriedem jroll: added the healthcheck middleware to both https://etherpad.openstack.org/p/self-healing-queens-ptg and https://etherpad.openstack.org/p/api-sig-ptg-rocky
14:50:21 mriedem we probably need a few more SIGs for this
14:51:18 bauzas mriedem: heh for "more SIGs"
14:51:30 bauzas that can become a very discussed and argued thing
14:51:36 openstackgerrit Chris Dent proposed openstack/nova master: WIP: Move resource provider objects into placement hierarchy https://review.openstack.org/540049
14:51:37 openstackgerrit Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766
14:51:37 openstackgerrit Chris Dent proposed openstack/nova master: WIP: Isolate placement database config https://review.openstack.org/541435
14:51:41 jroll mriedem: what have I done
14:51:58 jroll this really wasn't something I intended to tilt that hard at
14:51:58 bauzas gibi: mriedem: for the image.id being mandatory, I think I understand the point
14:52:19 bauzas gibi: mriedem: the problem is that AFAICS we assert in a lot of places about having an instance with an image
14:52:33 mriedem jroll: i just wanted to see it socialized more before it's adopted across a few projects,
14:52:53 mriedem because i'm projecting it on the community wide goals process
14:52:54 bauzas so we can 'fix' that, but that won't solve the design issue that we accepted in the past a different paradigm
14:52:59 jroll mriedem: also, I wasn't aware of the "new" thing until today, so adding the new thing you linked wasn't my intention at all
14:53:19 mriedem jroll: so your ironic patch and graham's spec aren't the same thing?
14:53:21 jroll mriedem: the new thing sounds like it'll take a year just to get through committee and have code written
14:53:23 jroll correct
14:53:27 bauzas jroll: from a very practical standpoint, do you feel blocked ?
14:53:29 jroll mine is the "old" one
14:53:38 mriedem bauzas: jim just wants to upstream it, but meh

Earlier   Later