21:05:17 <ttx> #startmeeting project
21:05:17 <dhellmann> mikal, ttx : yeah, I didn't even know I was supposed to ask
21:05:18 <openstack> Meeting started Tue Jun 24 21:05:17 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:05:18 <mikal> I am not here. I am in a cloud of annoyed.
21:05:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:05:20 <jgriffith> o/
21:05:22 <openstack> The meeting name has been set to 'project'
21:05:23 <ttx> Sorry for the lateness
21:05:32 <mikal> Ok fine, I'm here
21:05:38 <ttx> damn TC cahir can't keep meeting on rails
21:05:41 <ttx> chair*
21:05:43 <SlickNik> lol
21:05:44 <ttx> Agenda for today is available at:
21:05:47 <ttx> #link http://wiki.openstack.org/Meetings/ProjectMeeting
21:05:48 <mikal> ttx: yeah, _that_guy_
21:05:59 <ttx> #topic News from the 1:1 sync points
21:06:03 <ttx> See log at:
21:06:07 <ttx> #link http://eavesdrop.openstack.org/meetings/ptl_sync/2014/ptl_sync.2014-06-24-08.01.html
21:06:13 <therve> o/
21:06:27 <ttx> Juno-2 plans look relatively good, thanks to autokick.py invaluable contribution to clarity
21:06:34 <mikal> ttx: I feel like we should tell people to hold off on proposing dedicated sections for their things until the TC is finished arguing
21:06:51 <ttx> mikal: we can parallelize
21:07:06 <ttx> #topic Other program news
21:07:11 <ttx> Infra, QA, Docs... anything you'd like to mention ?
21:07:45 <mtreinish> ttx: we started running some tempest jobs on trusty today
21:08:02 <mtreinish> seems to be working well so far
21:08:02 <eglynn> mtreinish: as an experiment?
21:08:05 <mestery> mtreinish: Yay!
21:08:08 <eglynn> mtreinish: ... or in anger?
21:08:09 <ttx> mikal: we just need to have 1:1 discussions over those topics over the week, not just all at once in a one-hour slot
21:08:12 <SlickNik> mtreinish: nice!
21:08:34 <mtreinish> eglynn: as the first step in migrating over. I think they're in the check queue
21:08:42 <eglynn> mtreinish: "in anger" == voting?
21:08:44 <eglynn> mtreinish: cool
21:08:45 <mtreinish> clarkb has been doing all the work
21:08:49 <mtreinish> eglynn: yeah they're voting
21:08:54 <eglynn> clarkb: kudos!
21:09:16 * eglynn looks forward to the happy day when ceilo gates against mongodb :)
21:09:39 <clarkb> eglynn: well it does gate against mongodb on cetnos6 right?
21:09:50 <clarkb> eglynn: also pecan is guinea pigging for you and will run ceilometer tests on trusty
21:09:51 <eglynn> clarkb: not py27 or tempest
21:10:00 <eglynn> clarkb: but yeah, jut py26 units
21:10:04 <eglynn> *just
21:10:11 <clarkb> that should happen real soon now then we can expand to the rest of ceilometer
21:10:19 <eglynn> clarkb: excellent! :)
21:11:00 <ttx> ok, anything else ?
21:11:25 <mtreinish> nothing from me
21:11:44 <ttx> #topic Common spec proposal/approval deadlines
21:11:54 <ttx> As was predicted, -specs review represents a lot of work
21:11:56 <dhellmann> I'm anticipating markmc releasing a new version of oslo.messaging soon, so heads-up on that
21:12:11 <ttx> nova wins with a specs backlog of 154
21:12:17 <ttx> I still think design up-front will ultimately result in less wasted effort
21:12:28 <ttx> But as we get closer to feature freeze (juno-3) there will be a point in time where stuff under spec review can't possibly make it into Juno
21:12:35 <ttx> And reviewing specs after that point will be a distraction from Juno work
21:12:39 <mikal> We're going to try a specs review day tomorrow to see if that helps
21:12:44 <ttx> So we discussed today the idea of a Juno spec proposal deadline
21:12:51 <ttx> It would come a few weeks before a Juno spec approval deadline
21:12:59 <mikal> ttx: did you see my email to openstack-dev with nova's proposed dates for such a thing?
21:13:00 <ttx> which would come before the Feature proposal Freeze (the deadline for proposing implementation code for review)
21:13:03 <ttx> mikal: yes
21:13:07 <ttx> which in itself comes before Feature freeze (September 4)
21:13:15 <ttx> The question is, which projects are interested in following that, and is there convergence on dates (or is each project using different dates)
21:13:18 <therve> ttx, Sounds like a lot of process...
21:13:27 <ttx> Personally I think SpecApprovalDeadline (SAD) should be at least 3 weeks before FPF, so before July 31
21:13:34 <ttx> And SpecProposalDeadline (SPD) at least two weeks before that, so before July 17
21:13:37 <ttx> mikal proposed for Nova: July 3 for SPD, July 10 for SAD
21:13:51 <ttx> therve: it might not make sense for smaller projects
21:13:51 <mikal> We had a bit of a balancing act
21:14:00 <ttx> mikal: One week between the two might not be long enough to give them a chance
21:14:00 <mikal> We wanted to have those earlier, but have left it too late
21:14:06 <eglynn> I was think July 11th as SAD for ceilo, so similar
21:14:07 <ttx> mikal: Also you could use the meetup for a quick approval round
21:14:17 <ttx> therve: I like the SAD acronym though
21:14:20 <mikal> Yeah, we can use the exceptions process to handle some of the fail here
21:14:20 <mestery> I'm good with the same dates as mikal has selected.
21:14:24 <mikal> And learn from the experience
21:14:29 <mestery> mikal: +1
21:14:44 <markwash> mikal: +1
21:14:49 <mikal> The only contentious point seems to be when we open K specs
21:14:51 <therve> ttx, Smelling a great slogan :)
21:15:06 <mikal> Which is somethign I'm a little uncomfortable with dictating too closesly given I might not be the K PTL
21:15:12 <ttx> mestery: do you think one week between proposal and approval will let you review/approve stuff proposed before SPD?
21:15:18 <mestery> For K specs, the neutron drivers team is going to start putting -2 on specs we know won't land in Juno.
21:15:37 <mestery> ttx: It's a bit tight, but I like the shorter gap, it forces the issue in some cases.
21:15:37 <dhellmann> For oslo, we're going to hold off on setting firm deadlines and judge submissions when they come. We aren't seeing a lot of specs now, and if something good comes in we might just approve it for K. We try to be in sync, but tend to run ahead of the other projects to allow syncing or adoption, so if we cut things off too early we're going to have huge bits of unused time in the schedule.
21:15:44 <mikal> mestery: for ones previously approved, or those in flight, or both?
21:16:11 <ttx> so maybe it only makes sense for neutron and nova
21:16:13 <mestery> mikal: In flight which are proposed but not approved, and new submissions after the SAD.
21:16:16 <jgriffith> mikal: honestly my policy on that is when K opens up
21:16:18 <ttx> they are the only ones with a huge backlog
21:16:21 <therve> The spec deadline makes for a short calendar. That's like half of the year where you can't land specs
21:16:31 <dolphm> mestery: like, -2 pending re-proposal against a k* directory?
21:16:38 <mestery> dolphm: Correct.
21:16:47 <mikal> therve: well, for nova its about not distracting cores from reviewing patches at certain points in the cycle
21:16:56 <mikal> We want to set the expectation that we're busy elsewhere
21:17:06 <mestery> At the start of K, we'll wipe the specs repo clean and start fresh, at least that was my thinking. Things which were not approved need to be re-proposed.
21:17:15 <eglynn> why the -2 if there's a separate k* directory in the specs repo?
21:17:18 <mikal> mestery: we talked about that too, we're also going to unmerge approved things which never had code proposed
21:17:18 <jgriffith> mestery: _1
21:17:23 <dolphm> mestery: as long as things can land in the K dir during juno development, that sounds totally reasonable ++
21:17:24 <jgriffith> err.. +1
21:17:46 <therve> mikal, I understand. It'd be nice to be able to say "your spec looks good, but you can only propose the patch in release+1"
21:17:50 <therve> which blueprints allowed
21:17:51 <jgriffith> dolphm: I think trying to plan out to K right now is sort of a waste of my time
21:17:53 <mestery> eglynn: That's another way of doing it, but I'd like to hold off on adding hte K directory as long as possible, I tend to agree with mikal's reasoning on the distraction thing.
21:17:59 <jgriffith> in terms of a spec at least
21:18:05 <eglynn> mestery: fair enough
21:18:17 <mikal> People can always be writing their rst file in their homedir for a week or two
21:18:22 <mikal> I don't think its a super big deal
21:18:28 <mestery> mikal: Agreed
21:18:35 <dolphm> therve: s/propose/have considered for merging/
21:18:57 <ttx> jgriffith: what's cinder take on this ? You're hit with a lot of specs too
21:19:00 <dolphm> therve: or seriously consider as a release blocker
21:19:15 <jgriffith> ttx: I liked the two weeks out from submission freeze
21:19:36 <jgriffith> ttx: and like I said, I'm inclined to ignore anything K related until midway through J3
21:19:43 <therve> dolphm, I guess my question is if we could distinguish specs merged into master with specs approved
21:19:49 <therve> Maybe that defeats the purpose
21:19:54 <jgriffith> ttx: I alredy know there will be exceptions
21:20:08 <jgriffith> so I'd rather plan on it and make it "harder" after mid July
21:20:36 <jgriffith> therve: merged are approved... I'm confused?
21:20:51 <jgriffith> therve: you want a long term db to look at?
21:21:05 <eglynn> jgriffith: merged in juno dir == approved, or?
21:21:21 <jgriffith> eglynn: that just puts us backin the mess of LP IMO
21:21:31 <therve> jgriffith, Yeah that's my point, we used to have more states with blueprints.
21:21:41 <jgriffith> the beauty of the specs for me is tracking and organization as well as detail
21:21:46 <ttx> OK, so it looks like only a few projects would use that
21:21:50 <jgriffith> therve: and I think that was *bad*
21:21:51 <ttx> I hear nova and neutron
21:21:58 <eglynn> jgriffith: fair point, though the overhead of proposing/landing a specs patch sets the bar significantly higher?
21:22:05 <jgriffith> therve: chaos... look at al the "zombie" BP's out there
21:22:14 <jgriffith> eglynn: true
21:22:15 <eglynn> (as opposed to a drive-by filing on LP)
21:22:22 <therve> jgriffith, Well nova spec backlog doesn't look great to me :)
21:22:25 <ttx> so i propose each project announces its own date and deadlines
21:22:36 <jgriffith> eglynn: but I'm not convinced with rapid pace of change etc it's worth my time to deal with things that are 3+ months out
21:22:39 <mestery> ttx: +1
21:22:48 <eglynn> ttx: subsidiarity, me likee! :)
21:22:52 <jgriffith> ttx: sigh
21:22:53 <mikal> therve: I think its great
21:22:57 <ttx> and we'll look at it at the end of the cycle and see if we try to make it converged next time or not
21:22:59 <jgriffith> ttx: probably the right answer
21:23:00 <eglynn> jgriffith: that's fair
21:23:02 <therve> ttx, °1
21:23:02 <mikal> therve: we're being more honest about how much we think we can get done
21:23:05 <jgriffith> but means I'll be taking some flack again :)
21:23:15 <mikal> therve: and we're designing things before we argue in code reviews for the implementation or roll it back
21:23:23 <ttx> jgriffith: blame nova for it ?
21:23:27 <mikal> therve: _and_ we're finally letting operators have a say
21:23:32 <jgriffith> ttx: my new motto ;)
21:23:32 <mikal> I don't think its slower at all
21:23:41 <therve> mikal, Fair enough. Heat clearly doesn't have that problem, so it's hard to imagine being in your shoes
21:23:42 <mikal> It just feels that way because we're setting people's expectations better
21:23:49 <jgriffith> eglynn: yeah.. part of this is I want to se how specs works out for a full ccle
21:23:52 <jgriffith> cycle
21:24:12 <ttx> I don't think it's slower. We are building a longer pipeline, so it takes time before things are aligned to it properly
21:24:18 <dolphm> ttx: as long as we keep all the dates in a single wiki page / etherpad or something, so projects that want to settle on a single date can do so? if projects have a reason to deviate, that seems fair... but less than ideal
21:24:23 <jgriffith> ttx: +1
21:24:31 <ttx> but then I'd expect things will flow better IN the new pipeline
21:24:31 <eglynn> jgriffith: yep, exactly, it's a learning process for all
21:24:35 <jgriffith> the good thing I'm seeing is that specs actually lead to implemented code
21:24:37 <ttx> with less wated effort overall
21:24:41 <ttx> wasted*
21:24:51 <jgriffith> as opposed to willy-nilly bp's that never get acted on
21:25:18 <ttx> dolphm: hmm, would you be interested in it ?
21:25:23 <jgriffith> therve: eglynn actually... that's an interesting point maybe
21:25:38 <jgriffith> therve: eglynn still submit a bp.... submit spec during window
21:25:38 <eglynn> the devs have to start to see the pay-off from the process as well /methinks
21:25:41 <ttx> I can document them all in the juno release schedule
21:25:48 <jgriffith> spec controls targetting so I'm happy that way
21:25:52 <eglynn> (before they *fully* buy into it)
21:25:58 <ttx> if you keep me in the lop
21:26:01 <ttx> loop*
21:26:22 <jgriffith> ttx: "lop" isn't that the sound I hear when my head falls off
21:26:42 <ttx> no, that's "bop"
21:26:46 <jgriffith> ha
21:26:49 <dolphm> ttx: interested in deviating?
21:27:05 <ttx> dolphm: no, interested in SPD/SAD in the first place
21:27:09 <dolphm> ttx: oh, yes.
21:27:23 <ttx> oh ok. It felt like it was a nova-neutron discussion here
21:27:36 <eglynn> so I thinking part of the documentation of this process should emphasize the *direct* benefits to devs
21:27:58 <ttx> +cinder although I have difficulty to parse "I liked the two weeks out from submission freeze"
21:28:08 <eglynn> otherwise it appears as a Kafkaesque maze to some ;)
21:28:15 <ttx> eglynn: ok, will document them all
21:28:22 * ttx needs to docuemtn RequirementsFreeze anyway
21:28:26 <eglynn> ttx: thank you sir!
21:28:28 <ttx> so i'll go on a wiki rampage
21:28:44 <ttx> once they are all documented i'll ML thread the thing
21:28:46 * mestery gest out of ttx's way.
21:28:46 <eglynn> LOL :)
21:29:00 <eglynn> excellent!
21:29:04 <ttx> #action ttx to document SPD/SAD as optyional steps
21:29:31 <jgriffith> ttx: sorry... to clarify freeze spec submit/approve 1-2 weeks out from feature freeze
21:29:31 <ttx> #action ttx to then start a ML thread about proposed dates and potential convergence
21:29:47 <ttx> #action ttx to document resultig dates to the Juno release schedule page
21:29:53 <jgriffith> to ease confusion I'm going to "blame" nova and do whatever mikal does :)
21:30:08 <ttx> sounds like a plan
21:30:15 <ttx> famous last words on this topic ?
21:30:30 <dolphm> actually, we talked about a SAD for each *milestone* for keystone
21:30:30 <mikal> LOL
21:31:00 <mestery> dolphm: That's a lot of SADness. :)
21:31:13 <ttx> mestery: you said it
21:31:17 <ttx> #topic sahara-to-horizon merge
21:31:21 <ttx> SergeyLukjanov: around?
21:31:21 <dolphm> yeah, but making the pipeline longer means that i'm starting to think we should have shorter milestones, to facilitate smaller changes
21:31:26 <ttx> david-lyle: around?
21:31:32 <david-lyle> yup
21:31:32 <annegent_> there needs to be a blame mikal song like blame canada
21:31:32 <SergeyLukjanov> ttx, yup, I'm here
21:31:33 * ttx sets up the boxing cage
21:31:40 <eglynn> SAD is already taken as a TLA == "seasonal affective disorder" ;)
21:31:46 * mestery makes some popcorn.
21:31:52 <ttx> eglynn: awesome.
21:32:08 <mikal> Heh
21:32:08 <dolphm> #link https://blueprints.launchpad.net/sahara/+spec/merge-sahara-dashboard-to-horizon
21:32:11 <ttx> SergeyLukjanov: i'll let you introduce the topic
21:32:36 <SergeyLukjanov> ttx, okay
21:32:53 <SergeyLukjanov> so, the topic is to merge sahara-dashboard to the horizon
21:33:12 <SergeyLukjanov> I believe we have a bp for horizon too
21:33:39 * ttx resists a Launchpad blame
21:33:49 <SergeyLukjanov> #link https://blueprints.launchpad.net/horizon/+spec/merge-sahara-dashboard
21:34:40 <ttx> SergeyLukjanov: is that the list of proposed patches ? https://review.openstack.org/#/q/topic:bp/merge-sahara-dashboard,n,z
21:34:50 <SergeyLukjanov> so, the current state is that all (or 90%) needed patches are under reviewf
21:35:02 <SergeyLukjanov> ttx, yup, I think it's a complete list
21:35:16 <ttx> Was there progress on this since the last episode ? Like more patches posted, or some patches merged ?
21:35:32 <SergeyLukjanov> https://review.openstack.org/#/q/horizon+comment:%22Sahara%22,n,z works good too
21:35:58 <SergeyLukjanov> ttx, one patch merged IIRC - client bindings
21:36:33 <ttx> david-lyle: so the main issue on your side is the size of the patch ?
21:36:47 <david-lyle> ttx: getting core focus on it
21:36:48 <annegent_> I want to raise a slight concern about how to document
21:36:55 <annegent_> horizon is core, sahara is not
21:37:03 <SergeyLukjanov> there were a number of reviews for other patches and comments are resolved now, but the size of patches is very big, so, needs more iterations
21:37:05 <david-lyle> I think that has been addressed
21:37:15 <ttx> david-lyle: ok
21:37:27 <ttx> annegent_: "core" ?
21:37:41 <annegent_> ttx: the docs mission scope is only for core
21:37:45 <david-lyle> sahara is integrated
21:37:48 <annegent_> ttx: we try to get to integrated but don't promise
21:37:56 <david-lyle> ah
21:38:01 <ttx> annegent_: what definition of "core" are you using for that ?
21:38:03 <annegent_> just saying it makes for a bit of doc difficulty across "how do I install OpenStack"
21:38:22 <annegent_> ttx: the one in effect when we made our mission statement in july 2013
21:38:44 <annegent_> it's a known difficulty; just noting it here for others to note as a concern
21:38:47 <ttx> annegent_: hmm, not sure what that would include :)
21:39:00 <ttx> anyway, I see your point
21:39:25 <therve> david-lyle, Sorry if I say something dumb, but would it be possible for horizon to have integration points (plugins) so that sahara is in horizon the service but not horizon the code base?
21:39:25 <ttx> how does that influence the discussion here ?
21:39:33 <ttx> integrated projects must be.. well.... integrated
21:39:53 <jogo_> Heat is not core either
21:39:57 <annegent_> they can be integrated but we're not promising docs
21:40:09 <ttx> so sahara dashboard must be in horizon
21:40:13 <eglynn> therve: yeah out-of-tree dashboards, that's what I was thinking also
21:40:21 <annegent_> and by we I mean the doc team itself -- the horizon and sahara team are welcome to figure it out
21:40:31 <david-lyle> therve, we have a plugin mechanism and that's how the sahara dashboard was created, but if it's not in Horizon it becomes more difficult to maintain in the long run
21:40:39 <ttx> eglynn: that already exists, there is a sahara-dashboard
21:40:40 <therve> That problem is meant to happen again, with solum for example
21:40:49 <SergeyLukjanov> therve, it's already done as sahara-dashboard project and we're moving now it into the horizon
21:40:55 <annegent_> jogo_: sure but we (docs team) are working with them on integration in the user guide this cycle, it's just a few cycles later than their first integrated release
21:41:05 <ttx> it's supposed to be integrated within horizon now that sahara is integrated
21:41:06 <eglynn> ttx: I guess the question is, why doesn't that suffice?
21:41:22 <eglynn> ttx: (... to meet the integartion requirements?)
21:41:40 <ttx> eglynn: because horizon ships with dashboard integration for all the other integrated buts
21:41:43 <ttx> bits*
21:41:55 <therve> david-lyle, SergeyLukjanov: Okay. I feel that if we could keep things smaller we should, but I understand maintenance would be easier this way
21:42:05 <ttx> so it's a "first cycle requirement" to get your dashboard plugin into horizon mainline
21:42:28 <ttx> it neevr was an issue before
21:42:30 <jogo_> annegent_: ahh so core first
21:42:34 <david-lyle> There shouldn't be a reason we can't merge Sahara, it just takes time to integrate an 8k loc dashboard even if already existant
21:42:34 <annegent_> jogo_: right
21:43:06 <ttx> SergeyLukjanov: you feel like it's not going fast enough for a merge in Juno ?
21:43:08 <annegent_> ttx: david-lyle: any reason sahara can't be in a separate repo with separate reviewers under the Dashboard program?
21:43:22 <annegent_> I might not understand the technical limits
21:43:35 <eglynn> k, so it seems that evolving the dashboard for incubating proects *within* horizon somehow would avoid the need for a mega-merge post-integration?
21:43:44 <therve> annegent_, From what we're talking, it's mostly a maintenance problem
21:43:46 <ttx> annegent_: all the other integrated bits are in horizon repo, so why would we specialcase sahara ?
21:43:51 <eglynn> incubating *projects
21:43:54 <david-lyle> annegent_: we could take that approach, integration testing becomes more involved
21:44:09 <annegent_> ttx: because it's the biggest so far?
21:44:13 <SergeyLukjanov> ttx, it's difficult to say now - all patches are on review, but /me and david-lyle think that it could be done in time for juno
21:44:29 <dhellmann> yeah, making changes to the APIs the dashboards use is harder if they're in separate repos, because you have to figure out how to stage the changes and make all of them continue to work instead of doing it all in one patch
21:44:34 <SergeyLukjanov> ttx, there is already a huge work done on adjusting some parts for the whole chain of changes
21:44:38 <annegent_> dhellmann: ouch yeah then
21:44:49 <david-lyle> we could do that with all service panels, but as soon as they become interdependent we get into troubled waters
21:44:58 <devananda> this discussion sounds similar to ironic's nova virt driver "prepare to merge during incubation" discussion.
21:45:16 <devananda> also worth noting that horizon will face the same intergration for an ironic dashboard soon
21:45:17 <eglynn> big-bang merge of pre-existing out-of-tree dashboard post-integration inevitably leads to a 8 KLOC set of patches festering on gerrit
21:45:34 <ttx> SergeyLukjanov: OK, not sure we can do to help you guys sort it out. Anything you need from us?
21:45:43 <eglynn> what if horizon had an incubation sandbox?
21:46:05 <therve> dhellmann, I guess one question would be if horizon shouldn't provide stable APIs for allowing custom integration
21:46:10 <david-lyle> we've pulled in the tuskar-ui repo because of the scope and size of that
21:46:11 <dhellmann> yeah, the policy in oslo has shifted to taking the first version of something like that as-is and then interating
21:46:14 <ttx> eglynn: it's a bit of the same problem with nova ironic driver
21:46:19 <eglynn> in-tree, then post-intregation could be just a matter of promoting out of a contrib area
21:46:27 <SergeyLukjanov> ttx, I think nope, I've added this point to agenda as we agreed with you to raise this topic every several weeks to monitor status
21:46:30 <eglynn> ttx: fair point
21:46:31 <ttx> you basically want to review in the original repo and just merge it all
21:46:34 <dhellmann> therve: I'd love it if they did, since I want to add some dashboards for Dreamhost, but if they don't now we can't block sahara on that
21:46:34 <david-lyle> so Horizon program has horizon and tuskar-ui repos
21:46:47 <devananda> ttx: review code in antoher repo has not worked for the nova.virt.ironic driver at all
21:46:51 <devananda> ttx: for that that's worth
21:46:53 <therve> eglynn, We somewhat do that in Heat for resources
21:47:08 <eglynn> therve: interesting ... does the approach work?
21:47:24 <ttx> devananda: yes, "you want" wasn't meant as a recommendation :)
21:47:30 <ttx> SergeyLukjanov: ok
21:47:42 <therve> eglynn, I think so? We run the tests as part of everything else, but don't install the contrib resources by default. Obviously the amount of code is smaller.
21:48:05 <ttx> SergeyLukjanov: From a release management perspective, i can only reiterate that having dashboard functionality for integrated projects is high on the release priority list
21:48:06 <eglynn> therve: smaller and also perhaps most "testable"?
21:48:25 <therve> eglynn, Possibly yeah
21:48:27 <ttx> SergeyLukjanov: so yes, we can follow up regularly
21:48:35 <SergeyLukjanov> ttx, ack
21:48:37 <david-lyle> ttx: I think Horizon will be able to integrate the dashboard in J-2
21:49:09 <ttx> david-lyle: I thin k that's a good target. We have some room for overflowing to early J3 that way
21:49:22 <SergeyLukjanov> david-lyle, it'll be awesome - we'll have some time to implement dashboard features
21:49:45 <SergeyLukjanov> ttx, ++
21:49:46 <ttx> #topic Open discussion
21:50:10 <ttx> We can continue discussing better options to integrate 8K lines of code in one shot, or discuss anything else
21:50:21 <lifeless> gulp
21:50:39 <ttx> well, not one shot :)
21:50:54 <ttx> but it's true that it will bite us again
21:50:56 * dhellmann puts down his shot of whiskey
21:51:38 <david-lyle> ideally what I think would help is better inclusion of the Horizon team as part of UI development in incubated projects, the problem of course being resource constraint, pay me now or pay me later I suppose
21:51:39 <eglynn> any opinions on the usefulness or otherwise of the PTL webinars?
21:51:39 <SergeyLukjanov> ttx, yeah, it'll happens again ~ each cycle
21:51:53 * eglynn was disappointed not a single question from the floor at the cinder/ceilo webinar earlier today
21:52:02 <ttx> david-lyle: sahara had dashboards already developed -- did that actually help or hurt ? I can see that development goes faster but review goes slower ?
21:52:10 <dhellmann> eglynn: how many people were listening live? I haven't done mine yet.
21:52:16 <mikal> eglynn: do we have numbers on if people actually attend them?
21:52:32 <ttx> eglynn: dunno, that will be my first. Not sure what to expect
21:52:40 <eglynn> dhellmann: dunno, I wasn't on the meetingburner (just phone + slides on a tablet)
21:53:04 <eglynn> mikal: apparently more traffic on the youtube recording after the fact
21:53:04 <david-lyle> ttx: it certainly helps, but now horizon core is looking at this thing cold and not watching it come together. quick ramp up and try to make sure it's consistent with the rest of Horizon
21:53:22 <mestery> eglynn: How long did you get to present? I
21:53:23 <eglynn> mikal: ... otherwise relatively small attendence (10s as opposed to 100s)
21:53:27 <mestery> eglynn: I'm up Thursday :)
21:53:28 <david-lyle> so far it looks like it was done well, but I haven't gotten to the end yet
21:53:36 <david-lyle> don't ruin it for me
21:53:38 <SergeyLukjanov> ttx, david-lyle, for example, in sahara, we've started dev. of both server side and dashboard in one day and the first version of dashboard has been released right after the first working version of server side
21:53:38 <eglynn> mestery: 20 mins, I went overtime tho'
21:53:43 <mestery> eglynn: :)
21:54:39 <david-lyle> ttx: there's now way we would have been able to reproduce in Juno the same degree of API coverage starting from scratch
21:55:08 <ttx> david-lyle: yeah. Ican see benefits to both approaches
21:55:35 <ttx> Anything else, anyone ?
21:55:36 <devananda> david-lyle: given this context, any thoughts or suggestions w.r.t. tuskar / ironic UI integration next cycle?
21:56:47 <david-lyle> devananda: getting Horizon core looking at the patches now or designs at least would aid the adoption process
21:57:31 <devananda> david-lyle: ack
21:59:02 <ttx> ok, looks like that clsoes it
21:59:04 <ttx> #endmeeting