16:00:31 <david-lyle> #startmeeting Horizon
16:00:31 <jrist> o/
16:00:32 <openstack> Meeting started Tue Jun 24 16:00:31 2014 UTC and is due to finish in 60 minutes.  The chair is david-lyle. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:36 <openstack> The meeting name has been set to 'horizon'
16:00:48 <jrist> wb, david-lyle
16:00:49 <akrivoka> hi everyone
16:00:53 <akrivoka> \o
16:00:54 <david-lyle> Hello everyone!
16:00:57 <santib> hi guys
16:00:58 <tmazur> o/
16:00:59 <jgravel> hi
16:01:08 <gary-smith> Hi and welcome back
16:01:17 <crobertsrh> hello
16:01:20 <Kadence> hello
16:01:22 <doug-fish> hi all
16:01:22 <jomara> ahoy
16:01:28 <rdopieralski> hi
16:01:28 <tzumainn> hiya
16:01:34 <lblanchard> hi all
16:01:37 <david-lyle> After a protracted absence I came back in time to break the openstack gate for the better part of the day on Sat, so I can literally say you were better off without me
16:01:53 <akrivoka> lol :)
16:01:56 <rdopieralski> we missed you :)
16:02:11 <david-lyle> On the plus side, you can now log into Horizon on devstack again
16:02:33 <jrist> vn
16:02:48 <david-lyle> not much on the formal agenda today
16:02:49 * doug-fish will picture jomara as a pirate from now on
16:02:56 <jomara> doug-fish: thank you, i am
16:03:01 <doug-fish> :-)
16:03:02 <david-lyle> #link https://wiki.openstack.org/wiki/Meetings/Horizon
16:03:22 <david-lyle> #topic Juno-2 status
16:03:34 <david-lyle> #link https://launchpad.net/horizon/+milestone/juno-2
16:04:07 <david-lyle> For having so many blueprints slated for J-2 we are actually in good shape
16:04:32 <david-lyle> there are a few items that have a status of Not Started, if that's not true please update
16:05:07 <david-lyle> also a couple of items without owners, if these are yours and you're working on them please assign yourself
16:05:23 <david-lyle> book-keeping makes me happy
16:05:23 <jpich> or ask a "driver" to assign you
16:05:27 <david-lyle> yes
16:06:20 <david-lyle> There are several bps that have been added that don't have a priority yet. I will look at those shortly, or any core is more than welcome to approve, prioritize bps
16:06:32 <jrist> rdopieralski: were you on this? https://blueprints.launchpad.net/horizon/+spec/configurable-plugin-config-location
16:06:51 <lsmola__> hello
16:07:30 <rdopieralski> jrist: nope
16:07:37 <jpich> david-lyle: There were some concerns/questions last week as to whether cores are allowed to approve BPs or if it's only under the remit of the PTL (I think the former, very strongly to avoid overloading the PTL role but better clarify now!)
16:07:52 <rdopieralski> jrist: but it will become irrelevant if we switch to ini files
16:07:57 <rdopieralski> jrist: or maybe not
16:08:07 <david-lyle> Reading back, that question came up when I was gone. My stance is that any core can prioritize/schedule/approve bps, just leave a note if you are moving it to a milestone other than the one it's currently assigned to
16:08:29 <david-lyle> same for bugs
16:08:48 <rdopieralski> is there a description of the blueprint workflow somewhere?
16:08:52 <david-lyle> if we wait on me, we may be waiting for some time
16:08:58 <rdopieralski> I'm not sure what the different statuses mean, for example
16:09:06 <david-lyle> rdopieralski: I think there may be a general one for openstack
16:09:22 <rdopieralski> What's the difference between status:approved and direction:approved?
16:09:32 <david-lyle> for Horizon the process I inherited, which we may revisit at a later date is fairly loose
16:10:07 <jpich> david-lyle: Makes sense to me, thanks
16:10:20 <jpich> rdopieralski: http://wiki.openstack.org/Blueprints
16:10:31 <david-lyle> fields we really care about: Status, Milestone-target, Series goal, Approver, Implementation and Assignee
16:10:32 <rdopieralski> jpich: awesome, thanks, now I feel silly
16:10:50 <jpich> :P
16:10:57 <david-lyle> if a bp is a point of discussion, the direction should be drafting or discussion
16:10:57 <jpich> Some of these fields we don't use much
16:12:03 <david-lyle> So the only concern with all cores prioritizing/scheduling bps, make sure we're not approving conflicting work :)
16:12:19 <jpich> yeah, it's difficult to keep track of bps
16:12:22 <nlahouti> how about definition:drafting
16:12:32 <david-lyle> so keep up with the scheduled bps
16:13:29 <david-lyle> oops, before when I said direction drafting, I meant definition: drafting
16:13:53 <david-lyle> nlahouti: your bp is approved but waiting on neutron changes
16:14:28 <david-lyle> consider it approved even if it doesn't indicate, I will update
16:15:01 <david-lyle> I think another question while I was gone re: bps was a specs repo
16:15:02 <nlahouti> david-lyle: thx david. I didn't see in the bp.
16:15:21 <david-lyle> nlahouti: may not be done yet, mentally done on my side :)
16:15:39 <jrist> david-lyle: yeah, I replied to akrivoka but wasn't sure how it'd work
16:15:43 <jrist> re: specs
16:15:46 <nlahouti> david-lyle: :) thx a lot.
16:16:11 <david-lyle> personally I think we could use one for ux designs, beyond that I'm not sure
16:16:18 <jpich> david-lyle: Indeed, your input on the thread would be appreciated  ( http://lists.openstack.org/pipermail/openstack-dev/2014-June/037290.html )
16:16:57 <jpich> It does seem heavyweight when we're often adding simple support for existing API
16:17:15 <jpich> I think the UX team are trying to determine what's the best place/tool/location for them to store designs at the moment
16:17:15 <david-lyle> we don't publish an API and for the majority of changes we don't have a formal design until the code is up for review
16:17:54 <jpich> I guess the question would be, should we change that and formally review blueprints earlier?
16:18:09 <david-lyle> I'm happy to revisit, and I get the feeling it may be a requirement for the K cycle for all of openstack
16:18:23 <jpich> Considering we're having difficulties keeping up with reviews
16:18:28 <akrivoka> I think some more complex features would benefit from a design discussion prior to putting the code up for review
16:18:56 <david-lyle> akrivoka: absolutely, and that's happened in various forums over time
16:18:57 <akrivoka> it certainly should not be mandatory for every bp, IMO
16:19:06 <david-lyle> a specs repo would make sense for that
16:20:09 <david-lyle> We would definitely benefit from a stricter bp process
16:20:38 <david-lyle> I think that's something we need to target for K
16:21:02 <akrivoka> david-lyle: makes sense
16:21:06 <david-lyle> at this point the list of bps is fairly set for J and we just need to follow through on them
16:22:56 <david-lyle> #action: david-lyle better formalize the bp process prior to K, be it specs or other
16:23:10 <david-lyle> #topic Sahara
16:23:22 <crobertsrh> :)
16:23:29 <crobertsrh> It looks like we gained some momentum on reviews last week with mrunge and Tatiana lending some core reviews.  This is 1 of 5 j2 high priority blueprints, so hopefully we will build on that this week.  Ideally, the merge can be completed soon since there is additional work that we would like to get in for the Juno release and we'd like to be able to give plenty of time for those reviews as well.
16:23:46 <crobertsrh> Also, I updated the Sahara patches to no longer require the "enabled/*" files.  As a part of that, I uncovered a couple bugs:  https://bugs.launchpad.net/horizon/+bug/1333739 and https://bugs.launchpad.net/horizon/+bug/1329050 .  I haven't really had a chance to look closely at them yet, so if anyone cares to jump in, please go for it.
16:24:26 <david-lyle> I'm currently setting up my devstack to work with Sahara so I can better exercise the patches
16:24:43 <david-lyle> we do really need to prioritize supporting Sahara in J
16:24:45 <crobertsrh> Awesome.  Let me know if you have issues.
16:25:19 <crobertsrh> or anyone in #openstack-sahara can likely help you out if I'm not around.
16:25:28 <david-lyle> crobertsrh: thanks for keeping on top of all your patches
16:25:55 <crobertsrh> I currently live [and die] for it :)
16:26:13 <david-lyle> #topic Mid-Cycle Meetup
16:26:40 <david-lyle> I believe this was brought up and killed, just wanted to make sure I'm caught up here
16:27:23 <akrivoka> yeah, pretty much
16:27:28 <jrist> boom
16:27:46 <david-lyle> I see value in a sprint at some point to develop a coherent architect for the client side work, but the timing of such a sprint??
16:28:16 <david-lyle> What I don't want to have is a bunch of ad-hoc work on the clientside code that leaves us in a worse state than we started
16:28:41 <david-lyle> we could benefit from getting a number of people in a room to work through the overall design and sticking points
16:28:49 <tqtran> agree
16:28:53 <jomara> +1, i am working on a heat feature that is going to require some decisions about that
16:29:07 <jpich> Was there discussions about a client sprint?
16:29:18 <jpich> for this cycle?
16:29:36 <david-lyle> jpich: that was my response to the mid-cycle meetup on the mailing list
16:29:37 * jpich lots of emails about sprints/mid-cycles going through the last couple of months
16:29:44 * david-lyle may have imagined responding
16:30:57 <david-lyle> at this point, such sprint would likely have to be in late July or early August
16:31:22 <jomara> i will have plenty of code by then you can all sprint over
16:31:23 <david-lyle> that's fairly late in the cycle but could set us up well for better progress in K
16:32:04 <jpich> If it's too close to feature freeze / milestone 3 lots of people we'd like to have present may ignore it though
16:32:14 <david-lyle> jomara, I think several people will/do, so that makes a little late to be of maximum benefit
16:32:15 <tzumainn> tripleo had some difficulty coordinating a midcycle over that same time frame
16:32:37 <jpich> I agree it'd be great to have either way though!
16:32:59 <tzumainn> so if it's desired, it probably should be planned reallllly soon
16:33:05 <jrist> for K
16:33:05 <david-lyle> I think August is a poor choice for most European folks? is that correct?
16:33:24 <jomara> is sprint === IRL meetup?
16:33:33 <tzumainn> oh, my bad
16:33:35 <tzumainn> I got confused
16:33:37 <david-lyle> jomara: yeah
16:33:41 <tzumainn> oh, nevermind
16:34:59 <tqtran> :O IRL not IRC, i didnt misread that?
16:35:27 <jpich> Summer time can be more difficult to coordinate around
16:35:38 <david-lyle> something to consider quickly, I think it's necessary and would greatly benefit K if it happened prior to K
16:35:44 <david-lyle> jpich: understood
16:36:16 <jpich> but till there's dates, who knows - maybe everyone is going on holidays in July this year
16:36:27 <jomara> jpich: i am going in august!
16:36:51 <jpich> jomara: If you're not European you're not allowed to :(
16:36:59 <david-lyle> I went in June to avoid such conflicts, yay planning
16:37:04 <tqtran> wow, is usually eu vacation month?
16:37:15 <tqtran> *August, eu
16:37:21 <tzumainn> what tripleo did was set up an etherpad with proposed dates and people signed up so that people could see if there was a growing consensus
16:37:56 <jpich> tzumainn: Sounds like a good idea to steal
16:37:58 <jpich> I mean
16:37:59 <jpich> borrow
16:38:01 <david-lyle> we'd need a host and dates
16:38:06 <tzumainn> sorry, you can't have our etherpad
16:38:11 <jrist> jpich: it's open source, just fork it
16:38:14 <tzumainn> lol
16:38:37 <david-lyle> anyone up for setting up the etherpad
16:38:57 <david-lyle> acceptable outcome is that we all have lives that don't allow for a sprint as well
16:39:21 <david-lyle> but you really went into the wrong field if that's already true
16:39:23 <david-lyle> :)
16:39:48 <jpich> Lives are ok, people should get them
16:39:55 <tzumainn> https://etherpad.openstack.org/p/juno-horizon-meetup ?
16:40:16 <david-lyle> thanks tzumainn
16:40:27 <david-lyle> #topic Open Discussion
16:41:04 <david-lyle> I want to give a big thanks to jpich and mrunge for picking up my slack while I was gone.
16:41:40 <jpich> haha, anytime! ...actually no not too often
16:41:44 <jpich> ;)
16:41:50 <tzumainn> lol
16:41:53 <tzumainn> they did a great job, I thought
16:42:15 <doug-fish> agreed, well done jpich and mrunge
16:42:24 <akrivoka> thanks jpich and mrunge !
16:42:32 <doug-fish> related to the client side discussion, I wanted to chat about this review:  https://review.openstack.org/#/c/86089/
16:42:43 <doug-fish> This is Maxime's work to reimplement the launch instance form in angular.  I'm concerned that its becoming so large (its 8k+ loc now) that it's going to be really hard to review.
16:42:52 <doug-fish> Do other reviewers think this is a problem?  Is there anything that can be done to make this more reviewable?
16:43:14 <doug-fish> (or maybe I have to wait for the meetup to have that discussion)?
16:43:16 <jrist> I +1 the problem. the sahara stuff has been tough to review
16:43:28 <jomara> doug-fish: FWIW, i am working on a a smaller, but identically architected patch that will be easier to review
16:43:44 <david-lyle> doug-fish: there is a todo in the commit message to split that up
16:43:48 <jpich> doug-fish: Definitely don't wait for a physical meetup to open a discussion
16:43:51 <doug-fish> oh great
16:43:53 <david-lyle> it's really several bps in one
16:44:10 <jpich> and yes 8K sounds a bit over the line... glad to hear it'll be split up :)
16:44:20 <doug-fish> I can't think about that much code at once!
16:44:23 <tzumainn> jomara, are you working with maxime to coordinate work?  or will there be two different implementations?
16:45:49 <david-lyle> my other concern moving forward with AngularJS is we don't have to convert everything just because we can, we should be looking to places where it provides immediate benefit, otherwise we are just destabilizing our code base
16:46:41 <jpich> Right
16:46:42 <crobertsrh> +1 to that thought, david-lyle.
16:47:30 <jpich> I think there are thoughts that because we have adopted AngularJS we should become more of a Angular project and get rid of most of the current django backend?
16:47:43 <jpich> while others would agree more with your sentiment
16:47:45 <jomara> tzumainn: i am
16:47:51 <jomara> tzumainn: its the same architecture, different code
16:48:11 <jpich> david-lyle: What you suggest makes sense to me
16:49:12 <tsufiev> jpich, is there a kind of plan to get rid of django eventually?
16:49:20 <jpich> I don't think so now
16:49:27 <jpich> s/now/no/
16:49:29 <tqtran> jpich: i think angular can work well with django, we are shifting some of the server responsibility to reduce load on server
16:49:34 <doug-fish> IMO we'd never get rid of django entirely
16:49:40 <tzumainn> jomara, your heat work required angular, right?
16:50:05 <jpich> Maybe it makes sense for new work that can benefit from angular, like jomara's work it sounds like?
16:50:10 <tqtran> tsufiev: i agree with doug, django is here to stay, its a matter of getting angular to work with django
16:50:20 <jomara> tzumainn: yes
16:50:35 <jpich> rather than rewriting the existing? though the launch instance form does need a lot of rework either way...
16:50:35 <david-lyle> one reason angular was chosen is because it wasn't all or none
16:50:44 <tsufiev> tqtran, django is fine to me, was just curious :)
16:51:12 <absubram> david-lyle: amotoki: This is regarding the UT change that we spoke about in the Atlanta summit.. I submitted review https://review.openstack.org/#/c/90093/ to address that.. I know amotoki had a couple comments about it (version 5).. and I have commented back.. could you please take a look and respond?.. I think version 5 should be the final solution.. I've posted more comments today
16:51:12 <jomara> the django/angular integration proposed at the juno summit seems like a really nice architecture
16:51:54 <tqtran> it is, but theres a few issues we have to get a consensus on
16:52:02 <david-lyle> launch instance is certainly an area for improvement and if angular aids in that, which I think it does, then that makes sense
16:52:14 <tqtran> such as how django translation can be handled in angular
16:52:44 <tzumainn> sounds like this architecture could have benefited from a spec : )
16:52:55 <tzumainn> but in the absence of that, would it make sense to have the proposed architecture on the mailing list
16:53:09 <tzumainn> or somewhere else where it could be discussed?
16:53:40 <doug-fish> tzumainn - I'm hoping that jomara's smaller scale patch will serve as a good platform for discussion
16:53:49 <david-lyle> absubram: I'll put it in my queue
16:54:03 <absubram> thanks much David!
16:54:08 <MAnspach> is there ux work happening on launch instance?
16:54:16 <tzumainn> doug-fish, fair enough - I could just imagine it being discouraging if issues come up that mean that the entire patch has to be reworked
16:54:47 <jpich> MAnspach: Yes! I think a lot of it is being tracked there: https://blueprints.launchpad.net/horizon/+spec/launch-instance-ux-enhancement
16:55:00 <MAnspach> cool, will have a look!
16:55:09 <lsmola__> doug-fish: btw. maxime has todo there for splitting up the patch
16:55:12 <doug-fish> tzumainn: sure, understood.
16:55:33 <doug-fish> lsmola__:  yeah, I didn't see the todo - I think getting it split up would help me a lot
16:56:00 <doug-fish> I wanted to chat about this review too https://review.openstack.org/#/c/91338/
16:56:10 <doug-fish> This is a translatability improvement that lets actions be translated as more complete fragments.
16:56:21 <doug-fish> It's a good fix by itself, but also an enablement fix so other tables can be fixed.
16:56:22 <david-lyle> doug-fish: to be fair 5k lines of that is javascript library includes which should go away with xstatic
16:56:53 <doug-fish> david-lyle:  fair enough.  Still 3k is enough to overflow my brain.
16:56:58 <doug-fish> maybe I'm due for an upgrade
16:57:26 <david-lyle> not arguing the need to break it up, but the 8k scared me off completely
16:57:55 <tqtran> lol
16:58:02 <doug-fish> I'd love to see the translation fix merge soon-ish so translations can begin, but it's not getting much attention.
16:58:47 <jpich> doug-fish: https://review.openstack.org/#/c/91338/ ?
16:58:57 <doug-fish> (checking my link)
16:59:08 <doug-fish> yeah that's it
16:59:15 <david-lyle> yeah BatchAction translation
16:59:50 <jpich> Yes, definitely one to get in soon or it'll miss J (or cause translators to hate us)
17:00:36 <doug-fish> yeah exactly
17:01:52 <jpich> Ok we're overtime
17:02:05 <david-lyle> Thanks everyone
17:02:05 <jpich> Thanks everyone!
17:02:07 <david-lyle> #endmetting
17:02:12 <david-lyle> #endmeeting