20:02:09 <ying_zuo> #startmeeting horizon
20:02:10 <openstack> Meeting started Wed Feb  7 20:02:09 2018 UTC and is due to finish in 60 minutes.  The chair is ying_zuo. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:13 <openstack> The meeting name has been set to 'horizon'
20:02:22 <ying_zuo> Hi everyone o/
20:02:24 <e0ne> hi
20:02:26 <david-lyle> o/
20:03:12 <ying_zuo> #topic Queens-rc1 milestone release
20:03:21 <ying_zuo> I will tag the release tonight
20:03:37 <ying_zuo> after that, will need to cherry pick the patches for them to be included in stable Queens
20:03:53 <ying_zuo> we will be in rc-2
20:03:58 <e0ne> ying_zuo: great! so master will be opened for Rocky
20:04:06 <ying_zuo> yes
20:04:21 <ying_zuo> rc-2 is for translation mainly
20:04:25 <ying_zuo> no string changes
20:05:33 <ying_zuo> I’d like to hold off the feature related patches just to be safe
20:06:00 <ying_zuo> because we will be cherry picking
20:07:03 <ying_zuo> #topic Open Discussion
20:07:18 <e0ne> when are you going to curt rc2?
20:08:35 <ying_zuo> we will have rc2 release if that's what you are asking
20:08:48 <ying_zuo> for translation
20:11:19 <e0ne> it means that we'll be allowed to merge only critical fixes and translations until release
20:12:05 <e0ne> ying_zuo: did you see this thread #link http://lists.openstack.org/pipermail/openstack-dev/2018-February/127070.html?
20:12:41 <e0ne> Matt is asking about horizon-cisco-ui and django_openstack_auth releases
20:13:05 <e0ne> we don't need django_openstack_auth for Queens but what is a status of Cisco plugin?
20:14:06 <ying_zuo> horizon-cisco-ui is not ours
20:14:25 <ying_zuo> we only have horizon and django_openstack_auth
20:14:32 <david-lyle> ying_zuo, it's under the project governance
20:14:40 <e0ne> ying_zuo: https://governance.openstack.org/tc/reference/projects/horizon.html#horizon-cisco-ui
20:15:09 <ying_zuo> I thought that's a separate project?
20:15:19 <ying_zuo> I don't think I have any permission for that
20:15:47 <amotoki> I asked about cisso-ui to rob a few days ago and he said it is dead and can be retired.
20:16:10 <e0ne> amotoki: morning
20:16:15 <amotoki> morning
20:16:33 <ying_zuo> amotoki: thanks for checking
20:16:46 <amotoki> so you can contact him and how you can move the retirement forward.
20:16:46 <david-lyle> I think we just need to retire retire the repo and remove it from the horizon project list
20:17:19 <e0ne> #link https://github.com/openstack/horizon-cisco-ui/commit/dfa791ac4b979052eb3498fae2c70aa21ed1c147
20:17:38 <amotoki> https://review.openstack.org/#/c/541803/
20:17:43 <amotoki> it has been merged.
20:18:02 <ying_zuo> great
20:18:09 <e0ne> amotoki: thanks for the link
20:18:12 <amotoki> https://review.openstack.org/#/c/541809/1
20:18:13 <david-lyle> perfect
20:18:17 <amotoki> it is a governance change
20:18:17 <rdopiera> I have a topic I would like to raise.
20:18:38 <amotoki> i think rob contacted the release team and Sean sent these patches
20:19:12 <ying_zuo> cool
20:19:43 <ying_zuo> rdopiera: sure
20:19:58 <rdopiera> so keystoe removed the _member_ role again
20:20:05 <rdopiera> keystone
20:20:19 <rdopiera> it's not created by default anymore, and there is no replacement
20:20:27 <rdopiera> I wonder how we should approach that
20:20:41 <amotoki> rdopiera: what is the expected role for a regular member then?
20:20:49 <ying_zuo> no default non-admin users?
20:20:52 <rdopiera> amotoki: I think there is none
20:21:20 <jpich> Apparently it's not needed at all in v3, looking at the commit message and release note for https://review.openstack.org/#/c/522461/
20:22:12 <david-lyle> the only place we use it is the default role when adding a user
20:22:18 <e0ne> jpich: according to that patch, it's deprecated, not removed
20:22:45 <david-lyle> just have to remove setting the default value
20:22:51 <amotoki> in my understanding, all roles need to be created
20:22:53 <jpich> e0ne: I think the bootstrap command is deprecated, but it is not run anymore so _member_ is no longer created by default
20:23:23 <amotoki> there is no pre-defined role, right?
20:24:04 <david-lyle> amotoki, I imagine there is lingering 'admin' role requirements
20:24:17 <jpich> maybe 'admin' is, yes. That's what I would gather from the release note
20:24:52 <david-lyle> theoretically you could create any role and treat it as admin, but I'm not sure that's universally supported across projects yet
20:25:14 <amotoki> actually devstack creates both 'admin' and 'member' roles explicitly even though 'admin' might be assumed to exist
20:25:33 <amotoki> that's same as what we do in our private cloud.
20:26:29 <jpich> yeah... Anyway, at the moment in a default deployment you end up with project management not working in horizon due to the good old '_member_' missing. Not sure if it there is another way to handle membership in the future, to avoid this forever
20:27:02 <david-lyle> jpich it's only the one use that needs to chage
20:27:05 <david-lyle> *change
20:27:10 <amotoki> i think OPENSTACK_KEYSTONE_DEFAULT_ROLE needs to be changed
20:27:13 <david-lyle> default role for user on project
20:27:18 <ying_zuo> yes
20:27:24 <ying_zuo> needs to be set manually
20:27:24 <david-lyle> just remove providing a default
20:27:38 <david-lyle> and force the user to pick one from the role list
20:28:03 <amotoki> david-lyle: exactly
20:28:08 <ying_zuo> maybe just comment out that setting?
20:28:14 <e0ne> david-lyle: +1
20:28:20 <david-lyle> ying_zuo, a little more complicate
20:28:21 <amotoki> devstack already configures OPENSTACK_KEYSTONE_DEFAULT_ROLE to 'Member'
20:28:34 <david-lyle> just because  the project workflow is trying to read it
20:28:35 <e0ne> does this affect horizon in Queens?
20:29:14 <david-lyle> I've had this on my never completed todo list for quite a while
20:29:18 <jpich> Yes, Keystone removed this in Queens
20:29:27 <amotoki> after dropping _member_ in keystone, operators need to specify OPENSTACK_KEYSTONE_DEFAULT_ROLE at least
20:29:38 <amotoki> so I think it affects horizon queens
20:29:47 <e0ne> :(
20:29:55 <amotoki> it is worth mentioned in the release note and the config guide
20:30:15 <amotoki> at least the default value does not work :(
20:30:28 <david-lyle> potential bug fix for rc1
20:30:40 <david-lyle> not that invasive or much risk
20:31:07 <jpich> I imagine the deployment tools may also work around it when they realise, we just added patches to create _member_ in TripleO Queens at least
20:31:39 <amotoki> jpich: is _member_ the default member role in TripleO?
20:32:20 <jpich> amotoki: As soon as the patches finish merging :) https://bugs.launchpad.net/tripleo/+bug/1741066
20:32:21 <openstack> Launchpad bug 1741066 in tripleo "Horizon project management and lack of _member_ role" [High,In progress] - Assigned to Emilien Macchi (emilienm)
20:32:40 <david-lyle> looks like domains and projects use the vaalue
20:32:57 <jpich> I also noticed puppet-horizon sets the defaut role to _member_ by default as well, fwiw
20:33:01 <amotoki> my question is what is the default expected member role by default (regardless of horizon is used or not)
20:33:20 <jpich> It may something to discuss with the keystone people
20:33:21 <david-lyle> amotoki, there isn't one
20:33:31 <david-lyle> that is implementation defined
20:33:41 <david-lyle> s/implementation/deployment/
20:34:02 <amotoki> david-lyle: yes, so why do we need OPENSTACK_KEYSTONE_DEFAULT_ROLE in horizon?
20:34:14 <david-lyle> amotoki, it was a convenience
20:34:33 <david-lyle> so we could provide a default role
20:34:50 <david-lyle> devstack supported that role as well
20:34:51 <amotoki> i see.
20:35:07 <amotoki> I wonder it is better to make OPENSTACK_KEYSTONE_DEFAULT_ROLE optional.
20:35:30 <david-lyle> that would be fine too
20:35:44 <david-lyle> more complicated workflow
20:35:57 <david-lyle> extra logic, but nothing terrible
20:37:51 <amotoki> from what we discussed so far, there seems two options:
20:38:04 <amotoki> (a) clear the default value of OPENSTACK_KEYSTONE_DEFAULT_ROLE and force operators to set OPENSTACK_KEYSTONE_DEFAULT_ROLE manually (if not set, we can emit errors)
20:38:25 <amotoki> (b) make OPENSTACK_KEYSTONE_DEFAULT_ROLE optional and if not set a user is forced to select a role
20:38:57 <amotoki> as the variation of (a), we can request it by a relnote or config guide.
20:39:04 <e0ne> "a" is safer for Q release but "b" is better in a long-term perspective
20:39:05 <david-lyle> in api/keystone.py if the default role is not defined and present in keystone, we raise an exception now
20:39:26 <david-lyle> I take that back
20:40:06 <amotoki> from the relmgt perspective, we need an owner of this topic. who can volunteer for it?
20:40:09 <david-lyle> we return None, no hint that it's not set
20:41:09 <david-lyle> depends on the approach :)
20:43:07 <e0ne> are we OK to force operators to set OPENSTACK_KEYSTONE_DEFAULT_ROLE on Queens?
20:43:19 <ying_zuo> a) seems reasonable
20:43:51 <ying_zuo> (b) seems like a more flexible way to do (a)
20:44:22 <amotoki> the difference between (a) and (b) is that (a) is mandatory but (b) is optional.
20:44:55 <ying_zuo> right
20:45:26 <amotoki> I am fine with (a)
20:45:38 <ying_zuo> I think a is good enough for rc-2
20:45:51 <e0ne> +1 for Queens. we can implement better approach in Rocky
20:46:11 <amotoki> we seem to have a consensus for (a)
20:46:11 <e0ne> ying_zuo: can we get it landed in rc1?
20:46:42 <amotoki> then what will we do for (a)?
20:47:03 <amotoki> document only or changing some code to emit warning?
20:47:04 <david-lyle> so not having OPENSTACK_KEYSTONE_DEFAULT_ROLE set is a terminal error?
20:47:09 <ying_zuo> e0ne: if the changes can be merged by tomorrow
20:47:30 <e0ne> david-lyle: yes
20:47:42 <david-lyle> that would seem like a failing on our part
20:47:52 <david-lyle> for a convenience value
20:48:03 <david-lyle> just saying
20:48:06 <amotoki> I prefer to logging rather than a terminal error..
20:48:23 <david-lyle> then I think we require code changes
20:48:28 <david-lyle> I'm looking now
20:50:41 <david-lyle> I think we fail out without the value set, or found in keystone
20:51:18 <david-lyle> openstack_dashboard/dashboards/identity/workflows.py Line 314ish
20:52:02 <david-lyle> domains has similar logic
20:52:10 <david-lyle> bah
20:52:31 <david-lyle> openstack_dashboard/dashboards/identity/project/workflows.py
20:53:31 <ying_zuo> so the checking is in place so we just need to comment it out and document it?
20:53:34 <amotoki> hi, about http://lists.openstack.org/pipermail/openstack-dev/2018-February/127070.html, do we need to cut a stable branch now?
20:53:40 <david-lyle> ying_zuo, sort of
20:53:44 <amotoki> wrong channel...:p
20:54:03 <david-lyle> we start setting defaults based on the default value without checks that it exists
20:54:08 <david-lyle> or is not None
20:54:13 <jpich> When I was testing, the impact was the "Create Project" modal not opening with a clear-enough error message, and same for Manage Members. The rest seemed fine though I didn't poke in details. At least it's limited
20:54:46 <david-lyle> the modal opened?
20:55:25 <david-lyle> if it opened I think you would get a missing attribute error
20:55:36 <david-lyle> or None has no attribute 'id'
20:55:57 <jpich> no, it didn't open - just the error notification
20:56:05 <david-lyle> yes, that's what I would think
20:56:21 <david-lyle> ok, so more extensive changes are necessary
20:56:44 <ying_zuo> is there a taker for the missing _member_ role issue?
20:57:33 <david-lyle> I can change the code, but I won't have time for the release notes, etc
20:57:43 <david-lyle> too many fires already
20:58:04 <david-lyle> I can post the code and a co-author could do the release notes
20:58:18 <ying_zuo> sounds good. thank you
20:58:20 <david-lyle> but are we just gracefully not having a default?
20:58:52 <david-lyle> or forcing a default?
20:59:02 <david-lyle> or removing the option of a default
20:59:12 <david-lyle> the first is hard
20:59:17 <david-lyle> *hhardest
20:59:19 <ying_zuo> force a default for now
20:59:46 <e0ne> +1 to force default value for role
21:00:09 <david-lyle> so just a better error message and log?
21:00:21 <ying_zuo> we are running out of time. please continue on #openstack-horizon
21:00:29 <ying_zuo> #endmeeting