20:00:04 <robcresswell> #startmeeting horizon
20:00:06 <openstack> Meeting started Wed Aug 16 20:00:04 2017 UTC and is due to finish in 60 minutes.  The chair is robcresswell. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:09 <openstack> The meeting name has been set to 'horizon'
20:00:28 * robcresswell is on time!
20:00:43 <gary-smith> \o/
20:00:49 <makowals_> Good evening everyone !
20:00:54 <e0ne> hi
20:01:05 <dklyle> o/
20:01:12 <ying_zuo> hi everyone :)
20:01:15 <robcresswell> I'll give everyone a couple of minutes to wander in
20:01:36 <rdopiera_pto> \o\ \o/ /o/
20:01:47 <robcresswell> Haha
20:02:04 <robcresswell> rdopiera_pto dances in to the room
20:02:05 <ying_zuo> :)
20:02:21 <rdopiera_pto> _/o/~
20:02:26 <rdopiera_pto> walk like an egyptian
20:02:33 <robcresswell> Haha
20:02:39 <robcresswell> #topic Notices
20:02:51 <robcresswell> So, a couple of things
20:03:33 <robcresswell> #info RC2 tag soon. Need to sync with i18n on translations, and merge a couple of high priority bugs
20:04:09 <robcresswell> This will also the the last meeting I run, as ying_zuo will be stepping up :)
20:04:22 <e0ne> robcresswell: are these bugs already backported?
20:04:40 <robcresswell> e0ne: no
20:04:46 <e0ne> :(
20:05:13 <e0ne> just trying to understand what are priorities for stable/pike branch reviews
20:05:27 <robcresswell> Check the LP branch as usual
20:05:32 <e0ne> ok, thanks
20:05:44 <robcresswell> On phone atm, if anyone has a link handy...
20:06:31 <robcresswell> Anyway, backporting is trivial, it just adds to the gate time slightly
20:06:45 <rdopiera_pto> https://launchpad.net/horizon/12.0.0-pike/pike-3
20:06:53 <e0ne> #link https://launchpad.net/horizon/+milestone/pike-rc2
20:06:57 <robcresswell> But there are a couple patches at pike-rc2
20:07:06 <rdopiera_pto> no wait
20:07:10 <rdopiera_pto> sorry
20:07:20 <robcresswell> Boom, thanks e0ne
20:07:27 <robcresswell> .... And thanks for trying rdopiera_pto
20:07:32 <e0ne> robcresswell: np
20:07:32 <robcresswell> ;)
20:08:45 <robcresswell> As before, please test things out, check with product teams if possible, use horizon against staging / testing envs
20:09:12 <robcresswell> This is a good time to land any critical issues before the release goes out
20:10:02 <robcresswell> We aim to run against older clouds, so you don't need to test against pike clouds (could be N / O)
20:10:21 <e0ne> #link https://releases.openstack.org/pike/schedule.html
20:10:47 <e0ne> ^^ maybe someone was was looking for it too
20:11:02 <robcresswell> And finally, please take a look at the PTG planning etherpad; even if you're not attending, if you can describe an issue you think should be discussed, we can consider it
20:11:25 <robcresswell> #link https://etherpad.openstack.org/p/horizon-ptg-queens
20:11:32 <robcresswell> Thanks e0ne
20:11:42 <robcresswell> That's everything from me :)
20:11:50 <robcresswell> #topic Open Discussion
20:12:56 <makowals_> Hi again, two patches would be happy to get some comments/actions
20:12:57 * robcresswell just switched back to laptop
20:13:01 <makowals_> https://review.openstack.org/#/c/418246/
20:13:06 <makowals_> and https://review.openstack.org/#/c/426493/
20:13:27 <makowals_> The latter was tagged as rc1 by the way
20:13:58 <makowals_> Don't know if not too late for any of them, but anyway, even if just for master, still good
20:14:20 <robcresswell> hmm, that was me, I should've put that queen-1 though. Its feature work.
20:14:32 <robcresswell> The images bug could go in to Pike, however
20:15:42 <robcresswell> yeesh that images code
20:15:57 <robcresswell> Okay, I've starred it, thats going to take some time to get my head round
20:16:11 <robcresswell> Both are good patches though, thanks for the reminder
20:16:39 <makowals_> Thanks ! Also one question from a different branch
20:17:06 <makowals_> What I noticed -- or in fact users reported ;) -- when creating an instance, the panel does not validate name at all
20:17:47 <makowals_> This is consistent with nova which also does not validate it at all; however at least in some cases it would make sense to put some regex validation against the name (as ex. in networking stages we have some restrictions)
20:17:58 <robcresswell> :/
20:18:12 <robcresswell> Why would that "make sense"?
20:18:17 <makowals_> Thus the question, would it make sense to make a patch with optional config option to enable validation agains some RFC ?
20:18:46 <makowals_> If you try to create instance with the following name -- +1%&abc -- is it okay ?
20:18:59 <robcresswell> makowals_: Are your users regularly trying to launch instances with those names?
20:19:14 <dklyle> the create instance code will check what nova checks IIRC which is not much
20:19:28 <rdopiera_pto> what happens when horizon's validation doesn't match the service's requirements?
20:19:33 <robcresswell> I mean I get the "people will break things however possible" but fixing that in the UI is not the way to do it. We can't sanitise APIs.
20:19:35 <makowals_> Definitely not regularly, but we had few reports from users trying to use colon or semicolon
20:19:36 <rdopiera_pto> shouldn't that happen on the service side?
20:19:49 <dklyle> rdopiera_pto, we hope we are the more accepting of the two
20:20:08 <robcresswell> makowals_: What's the problem if they use a semicolon?
20:20:10 <rdopiera_pto> right, we would catch the error from the service and display it
20:20:30 <robcresswell> I mean, I think we should just match the API personally. And if they dont validate, we shouldnt.
20:20:54 <makowals_> Semicolon as a dns name, not really acceptable
20:20:59 <dklyle> nova bars very little, we had a bug capturing all that a couple of releases ago
20:21:34 <makowals_> The case now it's nova does not catch any of those, so we have an errors in the next stages (registering instance in the dns)
20:21:43 <makowals_> s/it's/is
20:21:45 <robcresswell> Right
20:21:46 <dklyle> then we can't create rules
20:21:49 <robcresswell> go yell at nova :)
20:21:53 <makowals_> :D
20:21:53 <dklyle> change should be made in nova
20:22:03 <dklyle> then we could reflect that
20:22:14 <robcresswell> +1
20:22:30 <makowals_> Yep, that's what I thought, nova first, horizon second
20:22:34 <dklyle> if you wanted to add a mechanism to validate names, you could, but that leaves a big hole via the CLI and APIs
20:22:44 <dklyle> just in horizon that is
20:24:18 <makowals_> Okay, I will try to push nova guys for this then; anyway local patch is ready so it won't be any trouble to put it in here afterwards
20:24:28 <robcresswell> Sure
20:24:51 <lucasxu> speaking of which, will horizon support a ceph backend swift, or just the openstack swift only  :)
20:25:08 <robcresswell> lucasxu: That depends if someone wants to implement it.
20:25:20 <dklyle> horizon shouldn't care
20:25:26 <dklyle> we only talk to the APIs
20:25:43 <lucasxu> robcresswell, hmm, interesting. Thanks
20:25:46 <robcresswell> dklyle: Yeah, I think we have some expectations that don't exist in Ceph
20:25:49 <e0ne> the problem is ceph ragos-gw doen't implement 100% of swift API
20:25:56 <dklyle> one header is all I recall
20:26:04 <lucasxu> dklyle, yeah, make sense
20:26:59 <robcresswell> lucasxu: The issue is really about us not knowing how its broken and how to recreate those issues
20:27:12 <robcresswell> But otherwise, we should just support what the API does.
20:27:14 <lucasxu> kk, i am not that familiar with rgw though. A co-worker asked me this today since he found a bug. Horizon logged out him when he was trying to create a container that has the same name as that of an existing one. So..
20:27:24 <e0ne> robcresswell: +1
20:27:28 <robcresswell> I imagine we are relying on some values existing that don't with a certain driver / plugin / backend, whatever.
20:27:56 <lucasxu> thanks and make sense to me
20:28:11 <robcresswell> lucasxu: Basically, yes, if support is broken, it is a bug. But realistically, that doesn't mean we can immediately support it. If you can work with us on it, we're happy to.
20:28:16 <robcresswell> you / your colleagues
20:28:32 <dklyle> if there are optional parts of the API we are requiring then it would make sense to treat those as optional in Horizon rather than required
20:28:45 <robcresswell> dklyle: ++
20:29:00 <robcresswell> I would imagine thats what we're doing
20:29:20 <robcresswell> expecting fields / validation / APIs that aren't reliably there.
20:29:21 <lucasxu> robcresswell, sounds good. I haven't looked further on that since to me, it is more like a ceph rgw bug since it returns a 401 and horizon receives that 401 then logs out the user. Which is the correct workflow.
20:29:49 <robcresswell> lucasxu: Okay, well, feel free to open bugs etc.
20:30:37 <lucasxu> robcresswell, sure, will look into that. I don't think it happens in the openstack swift. Will provide more details later.
20:30:44 <lucasxu> thanks guys.
20:30:52 <robcresswell> No problem
20:32:04 <robcresswell> Any other questions / bugs / patches etc?
20:35:06 <robcresswell> Alright, I think we can call it there
20:35:10 <robcresswell> Thanks everyone!
20:35:16 <robcresswell> #endmeeting