20:00:10 <r1chardj0n3s> #startmeeting horizon
20:00:11 <openstack> Meeting started Wed Nov 16 20:00:10 2016 UTC and is due to finish in 60 minutes.  The chair is r1chardj0n3s. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:14 <openstack> The meeting name has been set to 'horizon'
20:00:16 <hurgleburgler> (◠‿◠✿)ノ
20:00:19 <r1chardj0n3s> o/
20:00:22 <rdopiera> o/
20:00:23 <robcresswell> o/
20:00:28 <david-lyle> o/
20:00:30 <ducttape_> o/
20:00:30 <tqtran> [=_=]/
20:00:33 <rhagarty_> o/
20:00:41 <clu_> o/
20:00:53 <rdopiera> .oO( was tqtran replaced by a bot? )
20:01:01 <r1chardj0n3s> heh
20:01:35 <tqtran> thats my face each morning, it gets rounder as the day progresses
20:01:41 <robcresswell> woah so many people
20:01:50 * r1chardj0n3s wasn't going to jinx it
20:01:54 <tsufiev> who's there :)?
20:02:00 <robcresswell> \o/
20:02:04 <r1chardj0n3s> I'll start off with the usual stuff
20:02:04 <rdopiera> knock knock
20:02:09 <r1chardj0n3s> #topic Priority patches for review
20:02:13 <hurgleburgler> hehe
20:02:21 <hurgleburgler> is a full party today!
20:02:23 <r1chardj0n3s> #link https://review.openstack.org/#/q/starredby:r1chardj0n3s%20AND%20status:open lists the patches we need to get reviewed ASAP
20:02:27 <hurgleburgler> ♪└|∵|┐♪└|∵|┘♪┌|∵|┘♪ ♪└|∵┌|└| ∵ |┘|┐∵|┘
20:02:51 <r1chardj0n3s> though since I'll be tagging O-1 tomorrow (or maybe Saturday if we're optimistic about any of those patches) they probably won't be making it in
20:03:01 <rdopiera> I have a question about the priority reviews -- should we also reviews the ones that are marked as work in progress?
20:03:06 <r1chardj0n3s> I've got a busy Saturday morning though.
20:03:12 * tsufiev on his way to address the latest comments in profiler patch
20:03:14 <robcresswell> << guilty of WIP
20:03:43 <robcresswell> That tox patch keeps growing. Because we thought it would be fun to put all our translation infra for babel inside run_tests :(
20:03:46 <r1chardj0n3s> robcresswell: I think maybe the tox one might not make it this week, but I'm also not sure that's a huge problem
20:04:00 <robcresswell> No, its progressing fine, its just turned out to be a bigger job than I thought.
20:04:10 <robcresswell> story of openstack I suppose.
20:04:16 <r1chardj0n3s> since it doesn't really have any knock-on effects to others like frameworks would
20:04:31 <r1chardj0n3s> but it would be super nice for everyone to stop using run_tests as soon as possible this release
20:04:38 <r1chardj0n3s> so, you know, get on with it
20:04:39 <r1chardj0n3s> :-)
20:04:59 <rdopiera> fortunately I didn't setup ci for 11 yet
20:05:04 * tsufiev expects a lot of complaints once it's finally done
20:05:25 <ducttape_> r1chardj0n3s / robcresswell - should / could we add a quick patch to bark at people and say "use this instead please" ?
20:05:35 <ducttape_> for tox that is
20:05:52 <robcresswell> Already done that. If you use run_tests it has a big warning for every command
20:06:00 <robcresswell> Something about it being removed.
20:06:04 <robcresswell> Clearly it was very noticeable.
20:06:05 <r1chardj0n3s> yeah. maybe it could USE SOME BOLD ? :-)
20:06:29 <ducttape_> how does the blink tag work in the cli ?
20:06:40 <ducttape_> ;)
20:06:55 <r1chardj0n3s> Once O-1 is tagged I'll start loading the various next priority patches into the starred list. If you have favourites you'd like to encourage me to list there, please let me know.
20:07:08 <tsufiev> BIG BOLD RED BLINK :D
20:07:33 <hurgleburgler> +2
20:07:40 <r1chardj0n3s> ducttape_: ANSI code 5 or 6
20:07:54 <r1chardj0n3s> you're welcome
20:08:13 * ducttape_ did not expect this wealth of info
20:08:18 <r1chardj0n3s> ok, moving on
20:08:25 <r1chardj0n3s> #topic Priority bugs
20:08:29 <david-lyle> robcresswell: https://github.com/openstack-infra/project-config/blob/ad92dd20289c1861c2d0d68eeebd21fa1629a597/jenkins/jobs/horizon.yaml#L79 BTW
20:08:58 <r1chardj0n3s> I only have one priority bug listed at the moment
20:09:02 <r1chardj0n3s> https://bugs.launchpad.net/horizon/+bug/1624743
20:09:02 <openstack> Launchpad bug 1624743 in OpenStack Dashboard (Horizon) "Project image table: admin user sees images which are not shared with me" [High,In progress] - Assigned to Brad Pokorny (bpokorny)
20:10:13 <r1chardj0n3s> It'd be super nice if someone had some spare time they could look into that one.
20:10:16 <ediardo> o/
20:11:16 <r1chardj0n3s> #topic Nova changing simple tenant usage API
20:11:23 <tsufiev> so the patch is https://review.openstack.org/#/c/375170/ r1chardj0n3s?
20:11:25 <r1chardj0n3s> #link https://review.openstack.org/#/c/386771/ is a spec for changing the API
20:11:34 <tsufiev> perhaps add it to priority patches?
20:11:58 <r1chardj0n3s> tsufiev: thanks, I had missed that patch! I'll star it and review it today
20:12:27 <tsufiev> :)
20:12:38 <bpokorny> Let me know if you guys have any questions on the patch.
20:12:48 <r1chardj0n3s> So the nova folks want to fix the horrible performance of the os-simple-tenant-usage API call, which has been an issue for us in the past.
20:13:06 <bpokorny> I'm not confident it's been done in the most efficient way, but it's at least a bandaid for the problem :/
20:13:25 <r1chardj0n3s> thanks bpokorny
20:13:29 <bpokorny> np
20:14:24 <robcresswell> starred it too
20:14:35 <ducttape_> would be good to improve that, but we would likely need some graceful fall back option too (once it is available)
20:15:54 <r1chardj0n3s> yep
20:16:08 <r1chardj0n3s> robcresswell: could you please update us on where our xstatic packages are?
20:16:40 <robcresswell> \o/ Sure. So, we've updated and released several packages now, I've got a patch to the Horizon relnotes that lists them
20:17:06 <robcresswell> https://review.openstack.org/#/c/398302
20:17:34 <robcresswell> We're working on ui-bootstrap, d3 4.x, jquery 3.x... they all have breaking changes
20:17:35 <rdopiera> r1chardj0n3s: betherly couldn't come today, but she's working on the pagination patch
20:18:12 <robcresswell> But overall, making good progress.
20:18:35 <r1chardj0n3s> we're still waiting on the patch to limit Mitaka's use of bootstrap so it doesn't break
20:18:36 <r1chardj0n3s> https://review.openstack.org/#/c/396447/
20:18:49 <r1chardj0n3s> I'll nudge the requirements folks about that again today
20:19:39 <r1chardj0n3s> And of course all the poor plugins will need to be updated too
20:19:40 <robcresswell> sounds good
20:19:49 <rdopiera> #link https://blueprints.launchpad.net/horizon/+spec/simple-tenant-usage-pagination
20:19:55 <rdopiera> we have a blueprint for it too
20:20:35 <r1chardj0n3s> rdopiera: thanks!
20:22:16 <r1chardj0n3s> robcresswell: so should I also put in requirements limits for Mitaka for d3 and jquery?
20:23:17 <robcresswell> r1chardj0n3s: Yes, I suppose so
20:23:59 <r1chardj0n3s> Maybe I can get that shoe-horned into the current patch that's not yet merged, though it'd help to know the versions of d3 and jqeury that compatibility was broken in
20:24:18 <r1chardj0n3s> I'll take that on today
20:24:28 <r1chardj0n3s> ok, moving on
20:24:32 <r1chardj0n3s> #topic Cookiecutter template for an OpenStack Dashboard UI plugin project
20:24:37 <r1chardj0n3s> #link https://blueprints.launchpad.net/horizon/+spec/ui-cookiecutter
20:24:55 <r1chardj0n3s> tqtran, I think you are championing this one?
20:24:55 <tqtran> so shuu isnt here probably
20:24:59 <r1chardj0n3s> yeah
20:25:06 * ducttape_ ❤ cookies
20:25:17 <tqtran> hes created a cookie cutter for horizon plugins some time ago
20:25:39 <tqtran> i think we can potentially reuse this for our own startdash cmd (which doesnt really work)
20:25:51 <tqtran> we have one for python but none for angular panels
20:25:54 <r1chardj0n3s> ooh, I like removing code
20:26:18 <david-lyle> the command works, just doesn't stub out angular
20:26:24 <tqtran> so i think we can potentially reuse this for startdash and make it an official horizon repo
20:26:38 <tqtran> it works, but i think cindy and i found a few bug with it
20:26:45 <tqtran> this was some time ago, so i cant be sure now
20:26:51 <david-lyle> it doesn't get much love
20:27:10 <tqtran> right, there were recent changes that did not get incorporated
20:27:28 <tqtran> anyway, point is, this cookie cutter should be an official horizon repo that we support
20:27:37 <tqtran> and the side benefit is that we can also use it in our own start dash
20:27:39 <david-lyle> raise your hand if you know startdash and startpanel exist o/
20:27:43 <robcresswell> So... the only downside is more code to support, right?
20:27:46 <robcresswell> o/
20:28:02 <robcresswell> I mean, if we already ignore start*, do we want to add more?
20:28:07 <tqtran> right, the downside is we (horizon drivers) are now in charge of maintaining that repo
20:28:09 <tqtran> instead of shuu
20:28:32 <tqtran> yes i think we do since new projects can use it to jump start their own project
20:28:45 <tqtran> it will make life a bit easier
20:29:43 <tqtran> or we can just point people to shuu's repo, but down side is that if we make changes in the future, shuu's repo is going to be out of touch
20:30:18 <tqtran> so whats the verdict? should we vote?
20:30:39 <ducttape_> if shuu's repo is not getting love, I'd say move it into someplace that will look after it, and keep it running
20:30:54 <r1chardj0n3s> I personally need to think about it some before making a decision.
20:31:10 <tqtran> ok, we can revisit after everyone mulls over it
20:31:12 <robcresswell> My feeling is that we dont even maintain the existing ones, who's going to maintain the new one?
20:31:18 <ducttape_> even if it is not working 100% of the time, at least try to use common locations / tooling / etc
20:31:22 <robcresswell> Its a cool idea, no doubt
20:31:36 <robcresswell> I just dont want to be the one debugging it on IRC with someone in 3 months time.
20:31:39 <robcresswell> :)
20:31:39 <david-lyle> my point would be we had startdash and startpanel and they didn't get love and that's in the horizon tree, another repo is going to languish unless it's actively used
20:32:29 <ducttape_> can this tool be invoked from ./run_tests.sh ?     ;)
20:32:40 <robcresswell> wait are you saying bring it into Horizon, david-lyle, so it gets more attention?
20:32:40 <hurgleburgler> lol
20:32:41 <david-lyle> but it's a good idea and useful tool for sure
20:32:54 <david-lyle> robcresswell: I'm not sure, TBH
20:32:59 <tqtran> but whats the alternative? we are pushing everyone toward plugins, isnt it part of our responsibility to make it easier for them?
20:33:18 <david-lyle> I just am suspicious how up-to-date it will remain in our care
20:33:21 <robcresswell> tqtran: Yes, but a broken tool isnt easier for anyone :)
20:33:28 <tqtran> right now, you have to manually recreate those files, its a bit of a pain
20:33:51 <david-lyle> is it something we should do? absolutely. Is it something we will do effectively, not sure
20:33:58 <tqtran> hahaha
20:34:04 <r1chardj0n3s> So could we instread update start* in Horizon to be correct?
20:34:05 <ducttape_> bringing the tool back in, and then deciding to remove it (if it gets no love) - this is an option too
20:34:06 <robcresswell> david-lyle: +1
20:34:31 <robcresswell> ducttape_: Have you ever tried taking a feature away from horizon operators before? :)
20:34:42 <ducttape_> no way, those guys are jerks
20:34:46 <robcresswell> lol
20:34:48 <david-lyle> LOL
20:34:52 <tqtran> r1chardj0n3s: even if we update start dash, we still dont have one for angular
20:35:11 <r1chardj0n3s> (fwiw I'm not sure we can embed ui-cookiecutter in the Horizon repos and have it still work with the cookiecutter tool)
20:35:24 <tqtran> so the cookie cutter will still need to come in at some point
20:35:41 <david-lyle> I guess our poor oversight is better than a complete orphan
20:36:19 <tqtran> i think so too. some oversight is better than throwing people out in the cold
20:36:29 <ducttape_> less bad is the phrase david-lyle
20:36:34 <r1chardj0n3s> (oh, no, my concern about pulling it in is incorrect)
20:37:24 <robcresswell> Well, propose a patch
20:37:26 <tqtran> we're not the only project to use cookie cutter, tempest is also doing the same thing
20:37:27 <robcresswell> We'll see how it goes
20:37:39 <r1chardj0n3s> so, we have three options, I think? 1) Ignore it and "fix" start* in Horizon, 2) Add ui-cookiecutter as an openstack project under the Horizon tree or 3) pull ui-cookiecutter into Horizon to replace start*
20:38:09 <tqtran> its just a documentation patch that says, heres is the official horizon-plugin-cookie-cutter, and heres how to use it
20:38:11 <r1chardj0n3s> Both 2 and 3 mean shuu can't actively maintain the project any longer without becoming a Horizon core, correct?
20:38:42 <robcresswell> r1chardj0n3s: You can just give it its own core team that inherits from horizon-core too
20:39:00 <r1chardj0n3s> robcresswell: ok, good
20:39:14 <ducttape_> would the horizon cores not just implicitly shuu for many of these patches ?
20:39:20 <ducttape_> trust ^
20:39:48 <david-lyle> separate core works
20:40:01 <david-lyle> looks the same to everyone otherwise
20:40:18 <tqtran> honestly, theres not much code in there. shouldnt be too hard to maintain it. we can just fork over shuu's work and take over
20:40:19 <robcresswell> Yeah, manila already do that, they have their own core team but horizon are cores in it too. I think searchlight ui does it too.
20:40:31 <tqtran> we dont have to make him a core to maintain that project
20:40:45 <david-lyle> just if he wanted
20:40:50 <tqtran> right, if he wanted
20:40:55 <r1chardj0n3s> yep, having shuu (and potentially others, along with Horizon cores) be core of the project ameliorates the main concern about it being kept up to date I think.
20:40:58 <david-lyle> if he's dumping and running, yes, there's no pont
20:41:09 <david-lyle> *point
20:41:22 <tqtran> im sure he will be happy to maintain it
20:41:38 <r1chardj0n3s> I don't see any evidence that this is a dump-and-run
20:43:16 <r1chardj0n3s> So, the BP also proposes that startdash use ui-cookiecutter instead of the current code.
20:43:26 <david-lyle> wasn't making an accusation, just didn't know the full story
20:43:35 <r1chardj0n3s> That would presumably mean Horizon pulling in the cookiecutter tool and invoking it.
20:44:00 <r1chardj0n3s> And removing the existing startdash/startpanel.
20:44:31 <tqtran> i think that requires a bit more investigation. i have to look into how we can actually hook it up.
20:44:41 <tqtran> the part about us taking over the repo is what im proposing.
20:44:50 <tqtran> the other part, i think we should investigate first
20:45:44 <david-lyle> I'm fine in or out
20:46:26 <r1chardj0n3s> I think it makes sense for us to take over the repo with a separate set of cores specific to the project (even if that set is just shuu)
20:46:51 <r1chardj0n3s> That reduces the inherited burden for the current Horizon team.
20:47:17 <tqtran> worse case, no one maintains it. we're back to square one, didnt lose anything.
20:47:18 <david-lyle> the easiest first step for sure
20:47:38 <david-lyle> and if gets dusty we just drop repo support
20:47:49 <tqtran> and if someone needs plugin setup, we have a doc that points them to the repo and how to use it. easy peasy
20:47:53 <clu_> i think it's a plus, a good starting pt for newcomers
20:48:35 <robcresswell> To be clear; does this actually *work* right now? and how?
20:49:24 <robcresswell> ah, via https://github.com/audreyr/cookiecutter
20:49:54 <r1chardj0n3s> yep
20:49:57 <tqtran> http://docs.openstack.org/developer/tempest/plugin.html#plugin-cookiecutter
20:50:04 <tqtran> heres what tempest does for their test plugin
20:50:21 <tqtran> essentially, they have a patch for docs that guide users on how to use it
20:50:32 <r1chardj0n3s> tqtran: would you like to be the approver-shepherd for the ui-cookiecutter BP?
20:50:42 <tqtran> yes please
20:50:48 <robcresswell> Cool, sounds good
20:51:26 <r1chardj0n3s> go for it, with the understanding that it's currently approved for being a project with the proviso I've noted in the BP, and that further investigation is needed regarding Horizon integration :-)
20:51:43 <tqtran> i dont think the plugin shuu has is complete, its probably missing a few things like translation but we can add to that
20:51:59 <tqtran> ok, i'll start the process
20:52:03 <r1chardj0n3s> cool
20:52:15 <robcresswell> \o/
20:52:24 <r1chardj0n3s> ok, we have a few minutes - do we have anything else anyone would like to bring up?
20:52:55 <r1chardj0n3s> Just to note that the weekly Keystone-Horizon meeting will be tomorrow, at the same time as this meeting (2000 UTC) in #openstack-cp
20:53:05 <robcresswell> r1chardj0n3s: I had an item on there
20:53:11 <robcresswell> might need to refresh the page
20:53:27 <r1chardj0n3s> #link https://etherpad.openstack.org/p/ocata-keystone-horizon the etherpad for the keystone/horizon meeting
20:53:39 <r1chardj0n3s> robcresswell: ack! you snuck it in! go for it :-)
20:53:48 <r1chardj0n3s> #topic gettext in JS - angular gettext? global gettext? text-shim.js?
20:54:04 <r1chardj0n3s> I think the answer is "yes?" :-)
20:54:07 <tsufiev> r1chardj0n3s, I have kind of status update on 'fixing integration tests' - the one I already mentioned to you
20:54:12 <robcresswell> So, in sorting out tox/run_tests, I kinda realised how much of our i18n infra is fractured
20:54:57 <robcresswell> we seem to have this test-shim(?) that allows global gettext, we have angular-gettext which is used in half a dozen places, and then all our commands are just bash scripts, which are hardcoded to o_d and horizon so plugin code cant use them
20:55:09 <robcresswell> So I've mostly fixed the hard coded extraction etc.
20:55:28 <robcresswell> But I'm really confused by the direction with test-shim and angular-gettext; I was hoping someone could explain.
20:55:49 <r1chardj0n3s> robcresswell: angular-gettext provides the angular templating translation mechanisms
20:55:58 <robcresswell> Are we ever going to remove that shim?
20:56:02 <tqtran> so theres two part to i18n, the message extraction and message substitution
20:56:14 <robcresswell> Maybe Im confusing it with the gettext angular module, which some parts include.
20:56:15 <tqtran> angular-gettext is the substituion part
20:56:20 <robcresswell> some use gettext globally
20:56:27 <r1chardj0n3s> I'm not familiar with the test-shim
20:56:48 <r1chardj0n3s> gettext global is used by JS code
20:56:52 <tqtran> right, django embeds a catalog object containing the gettext function
20:56:57 <tqtran> which is globally available
20:57:13 <tqtran> but within anguar modules, we have a wrapper gettext that we encourage people to use
20:57:30 <tqtran> both have to exist (since we still have legacy js code)
20:57:39 <robcresswell> So, how does that wrapper work? And why dont we actually use it?
20:57:56 <tqtran> the wrapper uses the global gettext underneath it all
20:57:56 <robcresswell> And why does it have to imported as 'gettext'? Because that prevents use of ngettext etc.
20:58:10 <tqtran> we do use it, all of the angular code injects it
20:58:26 <tqtran> it has to be 'gettext' because of the message extraction part
20:58:35 <robcresswell> most of the modules are using the global one :/
20:58:38 <tqtran> we are using babel, and babel looks specifically for gettext
20:58:56 <tqtran> if they are, then it is incorrect and should be using the injected gettext
20:59:04 <robcresswell> okay, got that part
20:59:25 <robcresswell> Ill continue this in #horizon
20:59:32 <r1chardj0n3s> sorry folks, we are out of time :-(
20:59:50 <tsufiev> np
20:59:51 <r1chardj0n3s> thanks everyone for coming, and let's continue the gettext discussion in #horizon
20:59:54 <tqtran> the test-shim is there so we can use gettext in our tests (its just a mocked version) - though its been a while and i might be totally wrong here
21:00:04 <r1chardj0n3s> #endmeeting