| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-12 | |||
| 08:04:54 | vivsoni_ | any suggestion to get 'ccdec515-4a96-4927-b05c-fecbed1a5515' from u'zN7FFUqWSSewXP7L7RpVFQ== | |
| 08:40:15 | ameeda | vivsoni_: did you try base64.decode_as_text(u'zN7FFUqWSSewXP7L7RpVFQ==') ? | |
| 08:41:12 | vivsoni_ | ameeda: yes | |
| 08:41:16 | vivsoni_ | it gives UnicodeDecodeError: 'utf8' codec can't decode byte 0xcc in position 0: invalid continuation byte | |
| 08:41:35 | openstackgerrit | Huang Rui proposed openstack/nova master: z/VM Driver: Spawn and destroy function of z/VM driver https://review.openstack.org/527658 | |
| 08:41:35 | openstackgerrit | Huang Rui proposed openstack/nova master: z/VM Driver: Initial change set of z/VM driver https://review.openstack.org/523387 | |
| 08:41:36 | openstackgerrit | Huang Rui proposed openstack/nova master: z/VM Driver: add power actions https://review.openstack.org/543340 | |
| 08:41:36 | openstackgerrit | Huang Rui proposed openstack/nova master: z/VM Driver: add snapshot function https://review.openstack.org/534240 | |
| 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 | hello, how can I get python2-mistralclient version ? | |
| 10:31:41 | ameeda | morning | |
| 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 | cdent | gibi: awesome thanks. I'm going through all the stuff from last week's rp update, looking for easy wins... | |
| 11:25:44 | bauzas | cdent: ack | |
| 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: WIP: Isolate placement database config https://review.openstack.org/541435 | |
| 14:51:37 | openstackgerrit | Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766 | |
| 14:51:41 | jroll | mriedem: what have I done | |
| 14:51:58 | bauzas | gibi: mriedem: for the image.id being mandatory, I think I understand the point | |
| 14:51:58 | jroll | this really wasn't something I intended to tilt that hard at | |
| 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 | |