Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-07-10
17:53:05 openstackgerrit Dan Smith proposed openstack/nova master: Microversion 2.64 - Use new format policy in server group https://review.openstack.org/567534
18:00:43 mriedem1 i assume bauzas is in his futbol chamber
18:10:11 mriedem dansmith: ok i'm +2 up that stack to the point of the rest api change, reviewing that during this game
18:11:16 dansmith mriedem: okay we might want to find someone else to do that policy one since it's like half mine now
18:11:21 dansmith but I'll hit the rest
18:13:58 dansmith mriedem: hmm, so I wonder if that notification one should have been squashed into the main servergrouppayload like the objects were?
18:14:23 dansmith I was just mechanically updating it but hadn't really thought about it
18:14:24 mriedem i thought about that yesterday
18:14:46 mriedem and thought the separate payload isn't bad since it's the singular policy and the rules,
18:14:56 mriedem which in the rest api you just get a singular policy and (eventually) rules
18:15:01 mriedem so if we squashed,
18:15:10 mriedem the notification payload would have policies (deprecated list), policy and rules
18:15:20 mriedem so the nested object for the payload seems ok to me
18:15:27 dansmith so this mirrors more of what the api does?
18:15:28 mriedem doesn't matter to me much either way
18:15:38 mriedem the api will be flat
18:15:52 mriedem well, sorry, it's not flat
18:15:53 mriedem https://review.openstack.org/#/c/567534/28/doc/api_samples/os-server-groups/v2.64/server-groups-get-resp.json
18:16:00 mriedem yes it mirrors the rest api
18:16:12 dansmith hmm
18:17:21 mriedem we don't have to model it that way in the notification or api of course
18:17:27 mriedem could all be flat
18:18:04 mriedem gibi wanted both the old policies field and new policy payload in the notification for compat since notification consumers can't request a specific versoin of the notification payload
18:18:08 mriedem but that's not the same in the rest api
18:18:19 dansmith yeah, I dunno
18:18:37 dansmith just not sure I see the point of the nesting in either the api or the notification object
18:18:43 dansmith it's not bad, it just seems unnecessary
18:18:50 dansmith just another object and hash to track
18:19:29 dansmith anyway, if you want to just steam on I'll play along
18:26:02 mriedem i'm ok with making them flat if we want
18:26:37 mriedem thinking about stuff we nest in the rest api for servers, those are things like security groups, volumes, ports, etc - things that have their own resources in the api
18:26:50 mriedem server group policies wouldn't count like that since they aren't separate resources
18:26:55 dansmith yeah
18:27:26 mriedem gibi is probably the only other person that would have an opinion and he's probably gone by now
18:28:14 mriedem should we just wait and ask yikun what he thinks? if he doesn't care, then we can flatify tomorrow
18:28:28 dansmith if you're cool with that
18:28:33 mriedem yeah i'm fine with it
18:28:49 mriedem need to review Kevin_Zheng's abort queued live migration stuff today anyway
18:29:06 mriedem i'll drop my +2 on yikun's notification patch
18:30:27 dansmith aight
18:30:32 dansmith I'll comment
18:31:54 openstackgerrit Eric Fried proposed openstack/nova master: Tighten up ReportClient use of generation https://review.openstack.org/556669
18:33:35 mriedem me too
18:33:35 mriedem https://review.openstack.org/#/c/563401/28/nova/notifications/objects/server_group.py@41
18:33:42 mriedem gibi: fyi ^
18:46:05 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Use ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa in tree https://review.openstack.org/581444
18:48:37 openstackgerrit Matt Riedemann proposed openstack/nova stable/ocata: Use ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa in tree https://review.openstack.org/581445
18:53:02 melwitt looking for a +W on this ironic driver change needed to solve a race during instance creates https://review.openstack.org/563722
18:55:45 efried Looks like jaypipes, dansmith, and johnthetubaguy have reviewed ^ in the past, so I'll stay away for now.
18:56:11 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: unquiesce instance after quiesce failure https://review.openstack.org/581451
19:04:14 openstackgerrit Eric Fried proposed openstack/nova master: Delete orphan nodes before updating resources https://review.openstack.org/579922
19:04:20 openstackgerrit Ken'ichi Ohmichi proposed openstack/nova master: Avoid BadRequest error log on volume attachment https://review.openstack.org/581453
19:09:34 openstackgerrit Eric Fried proposed openstack/nova master: Address nits from consumer generation https://review.openstack.org/577227
19:09:38 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: unquiesce instance after quiesce failure https://review.openstack.org/581454
19:11:41 mriedem 7 days left to submit talks for berlin....
19:14:16 melwitt I just swapped the runways (a day late, apologies) https://etherpad.openstack.org/p/nova-runways-rocky if anyone would like to add log notes for the removed ones and if dansmith could please update the channel topic
19:18:06 dansmith the first one doesn't have the blueprint slug in it
19:18:18 melwitt argh, sorry
19:19:53 melwitt thanks
19:21:40 melwitt vdrok, jroll, TheJulia: is this patch needed for https://blueprints.launchpad.net/openstack/?searchtext=allow-reserved-equal-total-inventory ? it's in merge conflict https://review.openstack.org/565841
19:22:28 melwitt link correction https://blueprints.launchpad.net/nova/+spec/allow-reserved-equal-total-inventory
19:26:57 TheJulia melwitt: I think jroll is the only person who can know for sure, it looks like it just ought to be abandoned based upon the discussion. I know jroll has been super busy as of recent.
19:27:24 melwitt TheJulia: ack, thanks
19:28:25 jroll melwitt: I'll look post-meeting, been meaning to get back to that
19:28:46 melwitt jroll: thx
19:28:54 jroll I'd say it's needed but not for that BP
19:31:19 melwitt jroll: thanks for confirming. I'll update https://etherpad.openstack.org/p/nova-rocky-blueprint-status to call out just the one patch as needing review
19:31:29 jroll ++
19:31:34 melwitt (this one https://review.openstack.org/517921)
19:34:26 jroll right
19:34:33 melwitt ty
19:34:34 jroll thanks for checking on that :)
19:40:51 openstackgerrit Artom Lifshitz proposed openstack/nova master: WIP: Nova objects for Libvirt NUMA config https://review.openstack.org/581456
19:46:02 melwitt does anyone know what's the deal with vgpu work this cycle? is it blocked on reshaper work or is some of it okay to merge at the moment? https://review.openstack.org/#/q/topic:bp/vgpu-rocky+(status:open+OR+status:merged)
19:47:25 dansmith the numa-ness is blocked on reshaper AFAIK
19:48:15 dansmith which would be the NRP ones up there I guess, and some libvirt ones that don't appear to be in the list (and maybe aren't written yet)
19:48:41 melwitt hm, ok
19:49:28 melwitt efried: should we -W this one if we need to hold it behind reshaper? https://review.openstack.org/520313
19:50:50 dansmith man that's a lot of rechecks
19:51:11 efried melwitt: I had previously -2'd https://review.openstack.org/#/c/521041/ which is the patch that actually puts the code in the way of the compute manager. But perhaps we want to move that -2 to the bottom as you say, since the first two patches don't do anything without the top one.
19:52:25 melwitt efried: k. at a glance, it looked like things we could merge as progress so it would help to -W or -2 to show that it needs to wait
19:52:53 efried melwitt: Yes, we could merge the bottom two without hurting anything.
19:53:26 efried melwitt: I think some people might object to merging what's essentially "dead code".
19:53:51 efried melwitt: Me, I'd rather see it merged so we've got a shorter path when we're ready to pull the trigger.
19:54:09 efried But no strong feelings either way.
19:54:21 dansmith I think we should wait
19:54:46 dansmith merging refactors early in a set or something are useful, but if it's really dead code, we might as well wait, IMHO
19:55:48 melwitt I don't have a strong feeling about it. I think it'd be okay to merge some progress but waiting is also fine
19:56:59 melwitt mriedem: we have a proof-of-concept patch for the rbd erasure coding config option as of today, fyi https://review.openstack.org/581055
19:57:23 melwitt jmlowe: is this something we can see working in the ceph job results? using the erasure coding? http://logs.openstack.org/55/581055/2/check/legacy-tempest-dsvm-full-devstack-plugin-ceph/d6331b3/
19:58:54 jmlowe you're thinking functional test?
19:59:44 melwitt jmlowe: no, I mean I was wondering if there's anything ceph would log (in the ceph job I linked) that shows passing the data_pool did something. just curious if it's something we could see
20:01:18 jmlowe I don't think so, let me poke around a little more, you can check the data pool of a rbd device with the ceph api but it's supposed to be relatively transparent aside from disk usage increasing in some other pool
20:02:01 jmlowe or is that what you are thinking, write a gig and check the disk usage of the pools?
20:02:57 melwitt okay, that's cool. no, I wasn't thinking ahead that complex, just thought it'd be handy if something got reflected in the ceph job run for free
20:04:55 melwitt for one thing, I doubt the job is running luminous so it wouldn't do anything anyway
20:07:26 melwitt oh, it actually is. cool. http://logs.openstack.org/55/581055/2/check/legacy-tempest-dsvm-full-devstack-plugin-ceph/d6331b3/logs/ceph/ceph-mgr.x.txt.gz#_2018-07-10_01_16_55_913130
20:08:12 jmlowe yeah, it is running luminous so it doesn't blow up
20:08:57 melwitt jmlowe: what do you mean, what would make it blow up if not luminous?
20:09:29 dansmith passing the flag that turns it on right?

Earlier   Later