22:07:32 #startmeeting horizon 22:07:33 Meeting started Tue Jun 18 22:07:32 2013 UTC. The chair is gabrielhurley. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:07:34 no worries 22:07:34 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:07:36 The meeting name has been set to 'horizon' 22:07:45 Hi folks 22:08:09 Hi 22:08:10 hey everybody 22:08:11 hello 22:08:15 hello 22:08:15 if you can't tell, I'm less on top of things today than I'd like, so I'm gonna mostly ask for status updates to try and get a grasp on it all 22:08:17 hey 22:08:31 #topic overview 22:08:50 overview-wise, we're about halfway through H2, and the blueprints seem about half-done as far as I know, so that's reasonable. 22:09:28 Summit registration codes have started going out for any of you thinking of heading to Hong Kong in November 22:09:43 The hacking discussion and subsequent patches have been good. 22:09:50 I can't think of anything else meta-level. 22:10:01 #topic blueprints 22:10:16 Let's just go around and give an update on what we're working on and where it's at 22:10:36 (just start typing and post when you feel is appropriate)... 22:11:22 I'm a little new here but I'm working on a Heat Resource Topology that is dependent on the Heat UI blueprint currently in Code Review 22:11:22 as for me: I spent the time I had the last two weeks playing with Heat, and I have a very good understanding of where it's at and how to do things with it. filed a number of bugs. still need to do a little more work on the Horizon code, but that's where that's at. 22:11:37 timductive: heh. see my post just before yours. 22:11:50 haha, yeah 22:12:35 as for my other two blueprints, the realtime-spec is in limbo 'cuz I haven't looked at the realtime proof-of-concept that was put together yet, and the RPC listener is high on my to-do list but I haven't started it yet. 22:12:38 gabrielhurley: is the plan to have the current heat ui review merged as is? apparently you plan to improve the workflow size of things? 22:12:47 *side 22:12:55 kspear: yeah, I'm hacking on it a little bit. 22:13:32 I'm curious what improvements to the Workflow system are being planned 22:13:57 mostly just around the flow for entering the parameters defined by the template 22:14:22 gabrielhurley: with the current review things aren't great from a UX perspective 22:14:25 making separate HTML forms per tab? 22:14:42 kspear: agreed. hence the plans to improve 22:15:01 timductive: it'll be more multi-step 22:15:16 si there any blueprint for it? 22:15:37 jcoufal: it's part of the bar for entry on the "heat UI for managing stacks" blueprint 22:15:47 https://blueprints.launchpad.net/horizon/+spec/heat-ui 22:16:12 I tried running the heat code today and it throws an exception on the index view 22:16:12 ok, so is it going to be real a workflow (sequence of step) instead of multiform? 22:16:18 the code needs some love 22:16:42 I'm just gonna say "yes" to both of you. ;-) 22:16:52 this is why I've picked up that code myself 22:17:08 Well let me know if there is room to help, I'm 100% on heat ui at the moment 22:17:11 gabrielhurley: great, do we have some UX proposals for that? 22:17:12 cool 22:17:41 jcoufal: not really. I have some ideas and intend to generally just prove it out. we can iterate on the specific UX in H3. 22:18:05 BrooklynChen, jpich, bradjone1|away: you were gonna sync up on on ceilometer stuff... any update there? 22:18:23 david-lyle, lcheng: how's the keystone stuff? 22:18:27 the refactoring of ceilometer code is almost done. I a question, where can I put the css file of bootstrap-datepicker.js? 22:18:34 https://blueprints.launchpad.net/horizon/+spec/domain-context is ready for r eview, https://blueprints.launchpad.net/horizon/+spec/multiple-service-endpo ints is ready for review for the high level region picking, subsequent indiv idual endpoint selection will build on that once it's in and I will start ht tps://blueprints.launchpad.net/horizon/+spec/rbac next week 22:18:34 For Domain login support - https://blueprints.launchpad.net/horizon/+spec/login-domain-support, it is still blocked by keystoneclient v3 auth support. 22:18:51 Keystone patch is getting close to be merge though: https://review.openstack.org/#/c/21942/ 22:19:12 BrooklynChen: I'd put it in horizon/static/lib 22:19:36 david-lyle: awesome. I'll look at those this week. 22:19:40 gabrielhurley: ok. I just think we need both - multiform as well as sequence of steps. I wanted to raise this question earlier, but I'm glad you are working on that 22:20:00 lcheng: anything I can do to help with pushing the v3 auth forward, or have you got it under control? 22:20:04 gabrielhurley: okay. another one, should I merge the summary table of ceilometer with the usage table? 22:20:29 BrooklynChen: without seeing it explicitly to know for sure my gut feeling is "yes" 22:20:54 gabrielhurley: I got under control. I already got a +2, it's pretty close. :-) 22:20:57 If that's on the overview page, it means it's going to be quite slow whenever someone logins since that's the landing page? 22:21:18 lcheng: great! 22:21:36 jpich: good point. maybe a better idea to make that an early target for the realtime/async stuff 22:22:02 either that or just make that a plain ol' ajax-based bit of code 22:22:15 let it load asynchronously without the fanciness... 22:22:30 I could go with any direction there 22:22:55 +1 on ajax-ing it in, if it affects performance noticeable 22:22:56 Sounds good 22:23:02 gabrielhurley: query the date with ajax. +1 22:23:09 +1 here too 22:23:09 cool 22:23:15 anybody want to speak for Quantum currently? What's happening with FWaaS and Security Groups? 22:23:31 (I'll email the quantum folks if nobody speaks up now) 22:23:39 anything to speed up the overview pages, or at least not slow them down further is appreciated 22:23:56 david-lyle: agreed. also they're prone to *not* loading if something goes down. 22:24:51 anybody else with blueprint updates in general? I hit most of the big ticket ones but all updates are welcome. 22:25:47 okay. we can come back to it if anybody speaks up later. 22:25:48 #topic bugs 22:25:55 I want to mention a couple items real quick 22:26:27 https://bugs.launchpad.net/horizon/+bug/1191050 and https://bugs.launchpad.net/horizon/+bug/1191051 got filed as vulnerabilities but are in fact just items we should better document since Django already solves them. 22:26:51 Figured I'd point them out here for any of you who are security-minded in your own deployments. 22:27:16 Also of note, most of the Keystone bugs that were plaguing us have been fixed now, so that's good. 22:27:45 #topic open discussion 22:27:53 That's what I've got... 22:28:08 I have a feeling jcoufal is hanging out to talk about the github vs. g+ UX forum topic? 22:28:18 gabrielhurley: right :) 22:28:23 go for it 22:28:33 I wanted to bring out question about right place for UX discussions 22:28:42 though it's nice to have you here representing UX concerns in general ;-) 22:28:52 currently there is community activity on Google+ 22:29:14 however the format is not the best for broader discussions 22:29:25 gabrielhurley: thanks, happy to be part of it :) 22:29:38 si the proposal is to move the discussionon GitHub 22:29:45 and also store documents related to UX there 22:29:55 whole idea is captured in mail here: https://lists.launchpad.net/openstack/msg24345.html 22:30:22 there are also listed some concerns and benefits in the replies on this thread 22:30:44 any reflection from others? 22:30:58 so ... I'll have to admit I'm not 100% sure why github is a better choice for this than other things 22:31:17 other than potientiall: 22:31:19 * Issues have quite good options for text formatting. 22:31:21 * You can past image directly to the post. 22:31:23 are those the key things? 22:31:58 mordred: part of them, but plays big role 22:31:58 those are mostly it. the ability to crossreference commits is a semi-potential plus 22:32:14 I also feel, that G+ is partly disconnected from the main development source 22:32:23 k. my biggest concerns is that it opens the door to completely unrelated set of tooling 22:32:35 well, yeah, I think g+ is also not great for the same reason 22:32:58 mordred: what do you see under "unrelated set of tooling"? 22:33:02 github 22:33:14 we don't use github currently 22:33:19 it would be a new set of tooling 22:33:25 we don't use github *directly* would be more accurate 22:33:35 outside of the workflow, tooling, scope and governance of anything we currently do 22:33:39 right 22:33:45 we replicate to github 22:34:03 mordred: nothing we currently use in our toolchain has even the remotest usefulness for UX/design dicussions 22:34:13 so adding a new tool is somewhat inevitable if we're gonna fill this gap at all 22:34:19 right 22:34:28 my thinking was 22:34:41 I hear that - and I'm mainly trying to engage on that subject to see in what way we can be helpful there 22:34:42 that all the projects of OS are stored in github repositories anyway 22:35:27 so having UX among that might be the closest possibility, and having the benefit with nicely organised discussions etc might be nice 22:35:35 Github is definitely more visible, for newcomers like me :) 22:35:47 it's one of those funny "unless you're a developer and have had to deal with launchpad/gerrit it sure *looks* like OpenStack uses GitHub..." ;-) 22:36:03 I think I'm actually more concerned that by using github, we confuse the issue for newcomers who do not grok that we don't use github. 22:36:07 gabrielhurley: yeah. I know. :) 22:36:21 gabrielhurley: I, for one, would not mind removing our github replicas for exactly that reason 22:36:26 but we might be diverging there 22:36:29 yep, but the thing we *do* use (launchpad) is dreadful for design discussions 22:36:34 ++ 22:36:39 image support and text formatting are non-existent 22:36:58 I see 22:37:03 just out of curiousity (because I really don't know the answer) 22:37:04 mordred: what, you'd go back to using bazaar? :-P 22:37:10 gabrielhurley: hah 22:37:21 gabrielhurley: no, I'd just turn off github replicas 22:37:46 BUT - my question is - are there other examples of good systems for this type of discussion? 22:37:54 I'd sort of like to learn about what's good and bad 22:38:24 there are a lot of paid tools for this sort of thing 22:38:29 because there are recurring conversations about how launchpad fits in to things - and even if we move forward short-term iwth a github thing 22:38:29 I've used a few 22:38:34 I'd like to understand a long-term plan 22:38:50 if possible 22:38:56 the main issue is that design conversations and prototyping have very different requirements than general issue tracking 22:39:09 so it almost 100% necessitates its own tool in my experience 22:39:18 well, even that is good to know then 22:39:21 I've mostly been just trying to let the community find something that they likd thus far 22:39:35 do you know of any open source systems that are good at this? 22:40:07 my other concern is also to get that tool as close to developers as possible and also make that easy to use for creative people 22:40:27 not offhand. in the "not-opensource" arena I've recently used Notable and Invision to some degree of success. 22:40:39 k. 22:41:03 I have concerns about hosting portions of openstack dev on non-opensource tools run by companies that have a history of not caring out us 22:41:16 but jcoufal makes a good point that finding and easily-accessible tool that's a halfway point for devs and designers is an interesting challenge. 22:41:22 obviously, though, I want you guys to have the tools you need 22:41:27 mordred: same. I'd rather avoid it. 22:42:08 forgive my ignorance of the needs but does something like our wiki not allow for formatting like github does? 22:42:17 GOD NO 22:42:17 can we perhaps take a little bit and see if there's an open source thign that might work? even if it's something like redmine that might seem like duplication of effort at first. I'll do what I can to dig up possibilities for folks to check out 22:42:34 clarkb: wikis are absolutely horrendous for discussion 22:42:47 oh I see the desire is discussion with mock ups 22:42:49 discussion/feedback/revving a concept 22:42:52 yeah ok 22:42:59 wiki would be bad for that 22:43:17 mordred: sounds reasonable. I have a bad history with redmine though. ;-) 22:43:23 mordred: I agree, we can do broader research 22:43:26 jcoufal: can you do a little research too? 22:43:38 gabrielhurley: oh yeah. I mean, I hate it - just saying 22:43:43 for sure :-) 22:43:44 mordred: would you mind writing your ideas to the thread in mailing list? 22:43:47 awesome 22:43:50 jcoufal: I'd be happy to 22:43:56 great! progress! 22:44:00 and I'll send you suggestions as I find them 22:44:14 and that way I'll learn more about what's good and what's bad 22:44:23 gabrielhurley: will do 22:44:23 perfect! thanks 22:44:33 whee! 22:45:24 okay. anybody else got topics before I wrap the meeting? 22:45:40 Yes, are there strong opinions about adding a 3rd party js library? 22:46:00 FYI: Django 1.4 testing coming to a (voting) gate near you soon -- https://review.openstack.org/#/c/32884/ (thank you infra folks!) 22:46:00 I know there are a few in Horizon already 22:46:02 yes. what library? ;-) 22:46:08 kineticjs 22:46:21 Using it for canvas objects for the Heat Topology 22:46:29 unless there is something already in Horizon 22:46:44 jpich: you're welcome1 22:46:50 hmmm... interesting. we've been aiming to use d3 generally 22:47:02 bradjone1|away has been leading that effort 22:47:10 ok 22:47:22 I'll take a look at it and see if it has the functionality that I need 22:47:23 there was talk about porting the existing network topology stuff to d3 and then making that reusable for visualizing stacks in heat 22:47:46 so I'd try to sync up with bradjone1|away and toshiyuki hayashi on all that 22:47:53 ok thanks 22:48:08 no problem. my main concern is I just don't want to end up with three ways to do the same thing. 22:48:20 yes, I agree 22:48:31 jpich: thanks for driving the testing stuff 22:48:47 do we have documentation about logging in horizon now? 22:49:01 gabrielhurley: np! 22:49:04 not really. it uses django's logging, which is really python's logging 22:50:15 for non-developers, i think it's necessary tell them how to improve logging level or related hints 22:50:49 gabrielhurley, jcoufal: quick question - is a mailing list set up for hte purposes of ui discussions a possibility? 22:50:57 maybe just tell them to see how django do this 22:51:04 BrooklynChen: feel free to open a bug to improve the docs around that 22:51:14 ok 22:51:32 mordred: not really. the threading gets really messy and image sharing is bad. 22:51:39 gabrielhurley: k. thanks 22:51:42 np 22:52:21 gabrielhurley: can you elaborate? 22:52:53 gabrielhurley: i mean nobody ever likes how anything does threading. or doesn't do threading. depending on the thing. 22:53:25 jeblair: click through http://www.invisionapp.com/tour 22:53:26 gabrielhurley: and what's bad about the image sharing? basically i see "we need a discussion tool that supports images" and mailing lists are a discussion tool that supports images. 22:53:35 that's the type of commenting fidelity that's ideal 22:54:37 inline images are a must, commenting should be in order and ideally should support comment sub-threads without the incredibly crufty "comments inline" with a thousand nested arrows 22:54:43 you're dealing with visually-oriented people here 22:56:08 gabrielhurley: thank you 22:56:14 yep yep 22:57:04 jeblair, mordred: the best analogy is that it's the visual equivalent of how github/gerrit let you have separate discussions on specific lines of code 22:57:30 gabrielhurley: so you want in-line code review comments - except for pictures 22:57:52 that's the ideal. see the not-free-and-not-open-source tools I mentioned ;-) 22:58:02 yeah. was just looking at that 22:58:16 something like github that allows inline images and organized, threaded discussion is a second-place 22:58:47 just addition - threaded discussion is still needed 22:59:14 okee doke. it's 4 PM, and I gotta run. feel free to continue discussing if you like, but I'm gonna close the meeting. 22:59:18 thanks everyone! 22:59:19 #endmeeting