20:00:13 <david-lyle> #startmeeting horizon
20:00:14 <openstack> Meeting started Wed Mar  9 20:00:13 2016 UTC and is due to finish in 60 minutes.  The chair is david-lyle. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:17 <openstack> The meeting name has been set to 'horizon'
20:00:41 <david-lyle> anyone here for Horizon?
20:00:51 <doug-fish> \o
20:00:55 <bpokorny> o/
20:01:12 <robcresswell> o/
20:01:13 <ducttape_> i'm here for the free snacks
20:01:14 <TravT> i appear to be
20:01:59 <david-lyle> ok, let's roll
20:02:24 <david-lyle> We tagged M-3 last week and are working toward an RC-1
20:02:39 <david-lyle> django_openstack_auth 2.2.0 was also released last week
20:02:48 <jpomeroy> did somebody say snacks?
20:03:19 <david-lyle> here is the list of things for RC-1 https://launchpad.net/horizon/+milestone/mitaka-rc1
20:03:23 <david-lyle> #link https://launchpad.net/horizon/+milestone/mitaka-rc1
20:03:54 <itxaka> o/
20:03:55 <david-lyle> only 1/5 has merged or made any substantial progress since M-3 was tagged
20:04:18 <david-lyle> substantial progress being patches landed
20:04:39 <david-lyle> we have a lot of people coding the things and less reviewing the things
20:05:17 <david-lyle> if we hope to land these items by next time we meet, the efforts in those columns will need to reverse
20:05:41 <itxaka> yes please, more reviews less code by the cores would be nice :)
20:05:54 <itxaka> everyone can add code but only cores can approve :O
20:05:54 <david-lyle> on the positive side, all the bugs targeted for RC-1 are actively being worked
20:06:17 <robcresswell> itxaka: Reviews from non-cores are extremely useful.
20:06:24 <david-lyle> the other exceptionally odd thing I've seen is patches around linting fixes
20:06:26 <r1chardj0n3s> o/
20:06:41 <r1chardj0n3s> oh, linting, yes
20:06:50 <david-lyle> the period between M-3 and the RC is for hardening, and bug fixing not code thrash
20:07:18 <TravT> the linting ones i'm all for at the beginning of next cycle, but right now they cause merge conflicts
20:07:27 <robcresswell> I'd vote for -2ing them.
20:07:31 <r1chardj0n3s> yes, linting can wait until next cycle
20:07:39 <doug-fish> robcresswell: turns out you can just do that!
20:07:51 <david-lyle> it's not that it's not valuable, just not now :)
20:07:55 <robcresswell> doug-fish: haha. Feels a little abrupt, thats all :)
20:07:56 <r1chardj0n3s> yep
20:08:07 <r1chardj0n3s> and also there's the whole thing about jsdoc :-)
20:08:09 <robcresswell> Agreed. I sent out an email to that effect. If I remembered to press send.
20:08:24 <david-lyle> ok so please spend some time reviewing the things
20:08:30 <david-lyle> yeah I think jsdoc can go
20:08:50 * r1chardj0n3s just woke up, sorry, need to get up to speed
20:10:14 <robcresswell> Basically, everyone should make the RC1 bug list their home screen for the next week :D
20:10:41 <robcresswell> LI fixes need to be iterated quickly and merged, or we will have to revert. There are blocking bugs iirc.
20:10:50 <david-lyle> #chair robcresswell
20:10:51 <openstack> Current chairs: david-lyle robcresswell
20:11:02 <david-lyle> my internet is acting up so adding robcresswell just in case
20:11:34 <robcresswell> I'm making my way through the RC1 list, so any patch on there *will* get reviewed.
20:12:24 <robcresswell> Think we lost dave :p
20:12:35 * matt-borland walks in late
20:12:38 <robcresswell> There are no agenda items for today it seems.
20:12:39 <david-lyle> I may still be here, just laggy
20:12:48 <david-lyle> I had one more general item
20:12:53 <robcresswell> Go ahead
20:12:58 <david-lyle> beyond getting the things out the door
20:13:11 <david-lyle> The PTL election cycle starts March 11
20:13:22 <david-lyle> at least the nomination period
20:13:30 <david-lyle> then one week later are the elections
20:14:07 <david-lyle> I'm not going to run
20:14:35 <ducttape_> david-lyle - thanks for all your work.  you are not the worst PTL out there, you should be proud   ;)
20:14:40 <TravT> it's been a good run, david-lyle
20:14:59 <matt-borland> many, many thanks :)
20:15:00 <doug-fish> david-lyle: yes, well done!
20:15:03 <r1chardj0n3s> thanks david-lyle!
20:15:19 <bpokorny> Nice job these years, david-lyle!
20:15:29 <david-lyle> so if you plan to run the info is posted
20:15:33 <tyr_> it looks like a really hard job. Nice work david-lyle
20:15:33 * david-lyle finds the link
20:15:59 <david-lyle> I think the community is ready for not me, and I'm ready for not me, so cheers :)
20:16:10 <david-lyle> and thanks
20:16:29 <TravT> please assure us that you'll still keep working on horizon, though?
20:16:36 <david-lyle> #link https://wiki.openstack.org/wiki/PTL_Elections_March_2016
20:16:50 <david-lyle> hori what?
20:16:55 <rhagarty> thanks for your leadership... have you "named" a successor?
20:17:07 <david-lyle> yeah, I'm not going anywhere
20:17:08 <ducttape_> we name the successor ;)
20:17:16 <david-lyle> rhagarty: that's up to horizon ATCs
20:17:16 <krotscheck> o/
20:17:22 <krotscheck> whoa, thanks!
20:17:38 <krotscheck> david-lyle++
20:17:53 <david-lyle> ok, moving on
20:18:13 <david-lyle> one last thing DST reminder in the US, next week meeting will be one hour later
20:18:33 * TravT looks forward to being early to something
20:18:53 <david-lyle> rest of the world I have no idea :)
20:19:25 <r1chardj0n3s> Australia changes back at the start of April so the meetings change to 10pm and 6am
20:19:31 <robcresswell> UK doesnt shift for a few weeks yet.
20:20:49 <david-lyle> As robcresswell mentioned before, there are no agenda items
20:20:49 <david-lyle> #topic Open Discussion
20:20:49 <david-lyle> my lag is back
20:20:49 <david-lyle> so trying again
20:21:17 <david-lyle> As robcresswell mentioned before, there are no agenda items
20:21:17 <david-lyle> nevermind
20:21:26 * david-lyle yells at his ISP
20:21:46 <krotscheck> I'm collecting feedback for any changes needed to eslint-config-openstack before cutting 2.0 as the newton version.
20:21:48 <r1chardj0n3s> I meant to add agenda items but I was bushed coming back from the bugsmash, sorry
20:22:30 <r1chardj0n3s> I have an eslint-related change I proposed on openstack-dev (and patch) that I'm happy to defer until N is open but I'd like us to think about
20:22:44 <r1chardj0n3s> and thankyou to those folks who have thought about it and contributed already
20:23:18 <r1chardj0n3s> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088759.html is the mail thread
20:23:38 <r1chardj0n3s> I have someone from docs helping look into tooling for this, we'll see where that goes
20:24:23 <r1chardj0n3s> ultimately I see value in us having published docs for the horizon.framework code we've created (at a minimum) which includes API docs and separate prose around that (tutorial, developer guide style)
20:24:38 <tsufiev> yes, that would be nice
20:24:40 <r1chardj0n3s> and it'd be great if that could be published as part of our existing docs
20:25:12 <robcresswell> Absolutely agreed on the framework documentation. Its good for plugins and any newcomers to Horizon.
20:25:43 <r1chardj0n3s> so I would just say that people might want to hold off "fixing" jsdoc until we settle on our doc syntax
20:26:05 <r1chardj0n3s> (noting that a lot of the jsdoc "fixes" are actually unnecessary in ngdoc, which is what most of the docs have been written for)
20:26:26 <r1chardj0n3s> so there's potentially a lot of wasted effort there, sorry
20:26:55 <itxaka> So we would leave the checking to the jsdoc generator then?
20:27:10 <r1chardj0n3s> that would be the plan, yes
20:27:25 <itxaka> but that is not in place and its something that we cant enfornce rigth now, having eslint check for that meanwhile gives us a way to enforce it _now_
20:27:27 <krotscheck> Do they have no value whatsoever in an ngdoc world?
20:28:03 <r1chardj0n3s> itxaka: but eslint is enforcing things that we don't even know we want enforced, which makes no sense to me :-)
20:28:24 <itxaka> ah, I cant talk about that becuase I have no idea about this
20:28:25 <r1chardj0n3s> krotscheck: *some* jsdoc constructs do, but ngdoc diverts (around things like @returns and others)
20:28:49 <itxaka> I know that when looking at the js code I get happy the more comments I see before a function/class/controller
20:28:52 <itxaka> :D
20:28:59 <krotscheck> r1chardj0n3s: This seems to disagree with that statement -> https://github.com/angular/angular.js/wiki/Writing-AngularJS-Documentation
20:28:59 <r1chardj0n3s> yes :-)
20:29:14 <krotscheck> (specifically with reference to @returns)
20:29:26 <r1chardj0n3s> krotscheck: don't even start with me on the "recommendations" from the angular world
20:29:42 <r1chardj0n3s> their recommended tool *does not work* ... let me rant about that in a non-meeting time :-)
20:29:46 <krotscheck> r1chardj0n3s: Uh-oh, I hear an opinion coming!
20:29:57 <robcresswell> We have enough of those around here
20:29:58 <r1chardj0n3s> I shan't take up valuable meeting time on that
20:30:02 <robcresswell> opinions I mean
20:30:05 <TravT> r1chardj0n3s opinions are more entertaining in person
20:30:20 <r1chardj0n3s> because way more importantly, I would very much like everyone to think on http://lists.openstack.org/pipermail/openstack-dev/2016-March/088641.html
20:30:23 <krotscheck> r1chardj0n3s: so... http://blog.codinghorror.com/the-works-on-my-machine-certification-program/
20:30:25 <krotscheck> ;)
20:30:45 <r1chardj0n3s> I know the xstatic packaging thing is a very hard problem
20:31:09 <r1chardj0n3s> but we need some solution for this or we're never going to update our JS/CSS/fonts ever again :/
20:31:27 <hurgleburgler> :'(
20:31:48 <david-lyle> the app-catalog threw a wrench into things
20:31:53 <r1chardj0n3s> something that changed that folks might not be aware of is the addition of upper-constraints recently
20:32:05 <david-lyle> now I'm fresh out of ideas
20:32:08 <r1chardj0n3s> that means that we can break the gate when we try to update xstatic
20:32:16 <r1chardj0n3s> hence that wall of text email trying to come up with a solution
20:32:25 <r1chardj0n3s> and as david-lyle says, then along came app-catalog
20:32:27 <krotscheck> r1chardj0n3s: Well, for what it's worth, I have an xstatic-packaging job for pure JS projects on my roadmap for newton.
20:32:40 <krotscheck> That only helps with packages that we control though, the repackaged ones become problematic.
20:32:52 <r1chardj0n3s> krotscheck: the *packaging* of xstatic is a solved problem - there are patches in play to solve that
20:33:01 <david-lyle> our xstatic is all repackaged
20:33:14 <r1chardj0n3s> it's the problem specifically mentioned in that email I reference that is not solved and is very difficult to solve
20:33:50 <krotscheck> r1chardj0n3s: I get that. Please don't patronize me.
20:34:05 <r1chardj0n3s> I should mention that: during the bugsmash this week myself and my team put forward patches to openstack-infra and to openstack-releases to enable automated release of xstatic through the proper channels again
20:34:27 <r1chardj0n3s> krotscheck: I wasn't patronizing you, I was making sure you were aware of which problem I was talking about
20:34:37 <david-lyle> r1chardj0n3s: even the 4 . versions ?
20:34:45 <r1chardj0n3s> and that you weren't duplicating effort
20:34:45 <david-lyle> err 3 .'s
20:34:47 <r1chardj0n3s> david-lyle: yes
20:35:37 <robcresswell> I need to catch up on the email thread.
20:36:19 <robcresswell> This sounds like something we should run through at the summit too, as long as people are willing to familiarise themselves beforehand. I don't know that I have the time to help figure this out in the middle of RC.
20:36:29 <robcresswell> But thats just me :)
20:36:56 <r1chardj0n3s> FWIW the patch to update our docs for *generating* xstatic packages is here https://review.openstack.org/#/c/289142/
20:37:09 <r1chardj0n3s> and that links to the proposed patch to jenkins for handling things on that side
20:37:10 <krotscheck> So much headache over xstatic.
20:37:32 <r1chardj0n3s> but not the patch on the openstack-releases side since that's not a depdendent change, but more of a follow on
20:38:33 <r1chardj0n3s> please feel free to ask questions about any aspects of the mail I mention that are confusing
20:38:51 <r1chardj0n3s> there's a bunch of confusion in openstack land about upper-constraints
20:39:03 <r1chardj0n3s> (which *should* be called "pinned-constraints" but that ship sailed)
20:39:27 <david-lyle> I don't think you need to qualify the confusion
20:39:37 <david-lyle> it's general
20:39:39 <r1chardj0n3s> :-)
20:39:45 <TravT> r1chardj0n3s: i've only read the first message of the thread
20:40:23 <TravT> but can't we just put up the upper constraints fix and the horizon fix, approve horizon fix, but put the Depends-On flag for cross repo merges
20:40:29 <TravT> it would minimize breakage time
20:41:11 <r1chardj0n3s> you can't merge the horizon fix before the upper constraints fix unless the horizon fix is backward compatible, which is solution 1
20:41:27 <r1chardj0n3s> because the horizon fix will be running against the old version
20:41:56 <TravT> http://lists.openstack.org/pipermail/openstack-dev/2015-February/056515.html
20:42:37 <r1chardj0n3s> so even with that, there will be that period of time between the horizon and constraints patches landing where things will break
20:42:40 <krotscheck> TravT: That breaks down with requirements, because a req has to merge, then the update-bot has to propose the fix to horizon.
20:42:42 <r1chardj0n3s> even with the depends-on
20:42:55 <TravT> the bot doesn't have to propose them
20:42:59 <TravT> we can propsoe them
20:43:01 <TravT> propose
20:43:13 <TravT> and approve them
20:43:21 <krotscheck> TravT: That'll cause the incompatible requirements job to fail, no?
20:43:25 <r1chardj0n3s> TravT: the issue is the upper-constraints change
20:43:27 <TravT> perhaps...
20:43:38 <TravT> all i'm saying is this might be a way to minimize breakage time
20:43:45 <r1chardj0n3s> upper-constraints specifies the *precise* version of xstatic-angular that Horizin uses in integrated tests
20:44:31 <r1chardj0n3s> so if Horizon and constraints land at different times (as in the diagram in the email) then horizon will break if it's not compatible with old and new versions in constraints
20:45:12 <r1chardj0n3s> note that I also have a patch up for using upper-constraints in our tox envs https://review.openstack.org/#/c/290203/
20:45:17 <krotscheck> ...just cheking real quick - the app catalog, aren't they a horizon plugin, and can therefore inherit their dependencies from horizon?
20:45:24 <david-lyle> krotscheck: no
20:45:25 <r1chardj0n3s> this would bring our other testing in line with the integrated testing
20:45:29 <david-lyle> not a plugin
20:45:41 <david-lyle> there is a plugin
20:45:44 <TravT> what are they?
20:45:56 <david-lyle> but there's also a community web site not running on horizon
20:46:02 <r1chardj0n3s> http://apps.openstack.org/
20:46:14 <r1chardj0n3s> TravT: ^
20:46:37 <TravT> thx, r1chardj0n3s i know about them... just don't know what david means
20:46:40 <r1chardj0n3s> ok
20:46:47 <TravT> i actually am wearing their t-shirt as we speak...
20:46:52 <TravT> from a summit or two ago
20:46:57 <r1chardj0n3s> yeah, they're very separate from Horizon
20:46:59 <david-lyle> they have 2 uis
20:47:02 <TravT> pretty comfy i must say
20:47:06 <david-lyle> one plugin and one not
20:47:14 <krotscheck> david-lyle: Ok, so, the plugin can inherit from horizon, and apps.openstack.org isn't part of the integrated release, so we don't need to worry about it?
20:47:15 <david-lyle> but they apparently want to share code
20:47:25 <krotscheck> Ah, that's the issue.
20:47:31 <david-lyle> and xstatic packages, IIUC
20:48:12 <david-lyle> but, they are a snowflake that should probably just manage it's own xstatic dependencies
20:48:22 <david-lyle> it's not as if we're removing releases
20:48:38 <TravT> well, i think all plugins should assert, even document, their horizon release compatibility level
20:48:43 <david-lyle> that probably requires further conversation
20:48:54 <krotscheck> Ok, so the "Along came app-catalog" point that supposedly threw a wrench into everything isn't actually an issue.
20:49:08 <krotscheck> (or is probably not an issue)
20:49:09 <david-lyle> plugins shouldn't be the issue
20:49:11 <robcresswell> Thats the point though right, one of their UIs isnt a plugin but still wants to use xstatic packages?
20:49:17 <TravT> horizon is just an aggregate library to them
20:49:24 <robcresswell> Plugins will always rely on Horizon so they are a non-issue as far as I can tell
20:49:36 <krotscheck> robcresswell: Yeah, but it's a UI that's not part of the integrated release. i.e. unlikely to ever be part of an ubuntu package.
20:49:41 <r1chardj0n3s> I think having them manage their own xstatic constraints is reasonable --- unless someone ever decided to install Horizon and app-catalog on the same debian/redhat system :-(
20:50:06 <r1chardj0n3s> global dependencies, ugh
20:50:13 <robcresswell> krotscheck: Ah. So a very lightweight spanner in the works.
20:50:20 <david-lyle> r1chardj0n3s: woe be to them
20:51:01 <r1chardj0n3s> personally, I think the option of Horizon specifying its own constraints is still the only workable one
20:51:11 <david-lyle> me too
20:51:12 <r1chardj0n3s> even though.... y'know... ATOMIC ZUUL
20:51:13 <r1chardj0n3s> heh
20:51:42 <r1chardj0n3s> lifeless was particularly fond of that solution ;-)
20:51:53 * krotscheck felt like he contributed!
20:51:53 <r1chardj0n3s> but also very supportive of the local constraints
20:51:56 <TravT> i think horizon should specify its constraints and plugins should be tagged or at least documented along with the releases of horizon.
20:52:07 <tsufiev> Lol, we cannot even reliably use depends-on for libs
20:52:25 <r1chardj0n3s> tsufiev: so that means a bug in depends-on that infra knows they should fix :-)
20:52:38 <r1chardj0n3s> they're aware of some gaps in that
20:52:42 <TravT> because horizon has APIs as well
20:52:52 <tsufiev> r1chardj0n3s: they said i'm welcomed to contribute :)
20:52:58 <TravT> every line of code is apparently an API in horizon
20:52:59 <r1chardj0n3s> I'm sure you are :-)
20:53:09 <krotscheck> TravT: I hear you can copyright those.
20:53:09 <hurgleburgler> LOL
20:53:49 <TravT> so this whole discussion on external library version dependencies is no different than a plugin being dependent on a version of horizon
20:54:00 <TravT> horizon is just an aggregate version
20:54:21 <r1chardj0n3s> TravT: with the big exception that plugins aren't in the integrated tests so won't break the gate when we release a new xstatic :-)
20:54:27 <TravT> either you work with it and all of its dependencies or you don't
20:55:07 <TravT> this is no different than the situation today if we change something in horizon
20:55:11 <TravT> we don't know who it affects
20:55:37 <r1chardj0n3s> TravT: don't we have most of the integrated tests in our test suite?
20:55:51 <r1chardj0n3s> grenade, tempest, horizon-integrated?
20:56:01 <TravT> do we test all of the horizon plugins in there?
20:56:10 <r1chardj0n3s> those are not in the integrated test suite
20:56:15 <TravT> my point
20:56:20 <r1chardj0n3s> yes, but
20:56:34 <r1chardj0n3s> the whole point of that email I wrote is that an xstatic release can break the gate
20:56:43 <r1chardj0n3s> a plugin might break, but it won't break the gate
20:56:45 <krotscheck> TravT: If someone downstream wants to notify the team that a change breaks their world, there's ways to spin up their own voting-or-non infra systems to provide that feedback.
20:56:52 <r1chardj0n3s> so it's ok if a plugin breaks for a while
20:56:57 <TravT> true point there r1chardj0n3s
20:57:02 <r1chardj0n3s> but we can't block all of OpenStack
20:57:24 <krotscheck> The only place where you should gate on plugins is if the plugin is part of the integrated release.
20:57:37 <r1chardj0n3s> and yes, we should increase coverage of plugin testing (david-lyle is on that, I believe ;-)
20:57:45 <TravT> so, in other words, if zuul could just have a commit group
20:57:56 <TravT> either all members of group pass or all don't
20:58:07 <david-lyle> r1chardj0n3s: from which view point?
20:58:15 <r1chardj0n3s> if zuul could do atomic commits across multiple repos, the problem would go away ATOMIC ZUUL
20:58:21 <david-lyle> plugins test up, us testing down doesn't really make sense
20:58:25 <r1chardj0n3s> david-lyle: wanting it? :-)
20:58:44 <tsufiev> david-lyle: +1
20:58:55 <krotscheck> +1
20:59:23 <david-lyle> we have the same problem with python-*client changes
20:59:41 <david-lyle> but requiring say keystone client to test all consumers per change won't work
20:59:53 <r1chardj0n3s> oh, on that
21:00:24 <r1chardj0n3s> so I also have on my TODO now to add some more of Horizon's tests to the jobs that test constraints changes
21:00:40 <r1chardj0n3s> so that constraints changes will have much better coverage of whether Horizon might break
21:00:51 <r1chardj0n3s> which would probably have picked up that heatclient snafu
21:01:06 <lhcheng> OSC pulls in all plugin and do a sanity check that the command namespaces are all unique, perhaps we can do something similar
21:01:26 <david-lyle> time's up. Thanks everyone and please review the RC-1 items
21:01:26 <david-lyle> #endmeeting