19:00:30 <jeblair> #startmeeting infra
19:00:31 <openstack> Meeting started Tue May 27 19:00:30 2014 UTC and is due to finish in 60 minutes.  The chair is jeblair. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:34 <openstack> The meeting name has been set to 'infra'
19:00:39 <jeblair> #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting
19:00:40 <jeblair> agenda ^
19:00:40 <jeblair> #link http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-05-20-19.02.html
19:00:40 <jeblair> previous meeting ^
19:00:46 <jeblair> #topic Actions from last meeting
19:00:46 <jeblair> fungi add a wait for acl file creation on gerrit project initialization
19:00:59 <fungi> jeblair: lemme find the review and see if it merged
19:01:01 <jeblair> fungi: istr you put a patch up for that
19:01:11 <clarkb> o/
19:01:12 <anteaya> o/
19:01:12 <jeblair> but we didn't test it with the recent batch of creates
19:01:25 <ianw> o/
19:01:27 <fungi> #link https://review.openstack.org/#/c/94684/
19:01:30 <jeblair> i think SergeyLukjanov submitted a patch to create a specs repo
19:01:33 <fungi> looks like i wuo'd it
19:01:35 <fungi> wip'd
19:01:47 <jeblair> should we try to use it for that create?
19:01:53 <clarkb> yes, SergeyLukjanov has a change up for sahara-specs I have +2'd it looks good
19:02:09 <SergeyLukjanov> jeblair, i do
19:02:09 <fungi> need to rework it to jive with sdague's https://review.openstack.org/94196 error handling
19:02:25 <fungi> i'll do that right after the wrap up the meeting
19:02:31 <fungi> right after we
19:02:59 <jeblair> #topic  manage-projects status (fungi)
19:03:04 <jeblair> i think we kind of just did that
19:03:08 <fungi> yup
19:03:12 <jeblair> #topic  A home for Devstack within Infra (anteaya)
19:03:17 <anteaya> o/
19:03:27 <fungi> home is where you hang your devstack
19:03:35 <anteaya> so right now the devstack docs aren't under the infra umbrella
19:03:42 <anteaya> it would be helpful if they were
19:03:49 <anteaya> dtroyer is amenable to that
19:03:55 <anteaya> two things are needed
19:04:06 <clarkb> anteaya: you mean the stuff on devstack.org?
19:04:12 <anteaya> someone at the foundation willing for anotherjesse to transfer the devstack.org name to
19:04:14 <anteaya> yes
19:04:21 <anteaya> and an ip for the stuff
19:04:27 <anteaya> thoughts?
19:04:33 <jeblair> that would probably be jbryce; i believe he has handled most of the domain transfers
19:04:34 <fungi> was anyone able to get in touch with anotherjessee about it?
19:04:41 <anteaya> yes
19:04:45 <anteaya> dtroyer had that chat
19:04:50 <fungi> okay, great
19:04:55 <anteaya> anotherjessee is willing to make the transfer
19:05:04 <anteaya> we just need someone to catch
19:05:05 <jeblair> i believe that jbryce and sparkycollier would be happy for that to happen
19:05:11 <anteaya> yay
19:05:37 <anteaya> so I will track down jbryce and see if he can coordinate with anotherjesse
19:05:38 <jeblair> anteaya: Jonathan Bryce <jonathan@openstack.org>, Mark Collier <mark@openstack.org>
19:05:42 <anteaya> great
19:05:45 <clarkb> we should be able to start publishing the docs to a new location now too
19:05:48 <anteaya> which leaves the ip
19:05:51 <clarkb> they justwon't be available at devstack.org
19:05:59 <anteaya> so what server do we want them to live on
19:06:18 <anteaya> and if we have devstack.org, we can control where folks land when they use it
19:06:36 <fungi> i assume we just create another rackspace cloudsites site and use the same docs jobs we're using for docs.o.o, developer.o.o, et cetera
19:06:46 <jeblair> maybe docs.openstack.org/developer/devstack would be okay
19:06:55 <jeblair> that's where project docs usually live
19:07:01 <clarkb> jeblair: I like that
19:07:02 <fungi> or that, and a redirect at devstack.org
19:07:05 <fungi> me too
19:07:06 <clarkb> annegentle: ^ are you around?
19:07:18 <anteaya> dtroyer isn't here right now, but I would like his input on the path
19:07:47 <anteaya> but for now I can get the domain transfer underway
19:07:55 <anteaya> and hope to hear from dtroyer by next week
19:07:57 <jeblair> anteaya: ++ we can work out the rest later
19:08:08 <fungi> probably just worth noting that we can either host content at devstack.org or have it redirect to an existing docs site and get the interested parties to weigh in
19:08:16 <jeblair> fungi: yep
19:08:26 <SergeyLukjanov> ++ for docs.openstack.org/developer/devstack and redirect from devstack.org
19:08:45 <jeblair> anteaya: end of topic?
19:08:51 <anteaya> yes
19:08:52 <anteaya> thanks
19:08:53 <mordred> well
19:08:56 <jeblair> thank you!
19:08:58 <jeblair> mordred: oh?
19:08:59 <mordred> we should probably figure out the docs build
19:09:03 <mordred> they're in gh-pages right now
19:09:15 <mordred> shouldn't be hard - but that's not how we do other thigns
19:09:26 <anteaya> I'd like dtroyer here for this part
19:09:31 <fungi> yeah, that's a task to add to the list... get docs building so they can be uploaded in cooked format rather than raw
19:09:36 <anteaya> can we continue this next week?
19:09:37 <mordred> fungi: ++
19:09:39 <jeblair> mordred: well 'gh-pages' isn't so much a build thing as a publish thing
19:09:55 <jeblair> mordred: and i think the conversation so far has been about changing how we publish it
19:10:00 <mordred> jeblair: yes. except I think gh-page will auto-render md for you?
19:10:16 <mordred> jeblair: sure - just saying - the thing that puts things in gh-pages may need to be investigated - it's possible it's a human
19:10:29 <anteaya> dtroyer has some specific things he is looking for
19:10:34 <jeblair> mordred: yeah, i think it's static content
19:10:35 <fungi> right, presumably there are some additional transformations which will need to be applied to the current source to turn it into something we can put on a webserver
19:10:37 <anteaya> and it is best if I let him tell you
19:10:40 <mordred> kk
19:10:50 <fungi> or maybe it's just straight html in which case no need
19:10:56 <jeblair> mordred: once we have a publishing method for the content, then we have a known way to change the content.
19:11:06 <mordred> jeblair: ++
19:11:12 <jeblair> #topic  Third Party CI Gerrit Account name format (anteaya)
19:11:22 <anteaya> okay so on the linked etherpad
19:11:26 <jeblair> #link https://etherpad.openstack.org/p/juno-infra-improving-3rd-party-testing
19:11:31 <anteaya> thanks
19:11:51 <anteaya> there was a request for standardization of third party ci names
19:11:55 <anteaya> for email filtering
19:12:08 <anteaya> and it has also come up on the ml for filtering for gerrit js
19:12:21 <anteaya> how do we decide a new format?
19:12:25 <fungi> yeah, we didn't get time to discuss it at that summit session, but i stuck it on there just because i've been asked for it a few times as well (in regard to e-mail filtering)
19:12:37 <anteaya> then how to we get current accounts to comply with the new format?
19:12:37 <krtaylor_> That was me
19:12:45 <jeblair> something like "Foo CI" ?
19:12:47 <anteaya> yay krtaylor_
19:12:53 <clarkb> jeblair: I like Foo Bot
19:13:01 <fungi> krtaylor_: oh, perhaps you read my mind then ;) thanks!
19:13:03 <jeblair> anteaya: we're going to ask third party ci folks to make several changes; i think we should do it all at once...
19:13:04 <clarkb> because we may want bots to do other things
19:13:11 * anteaya nods
19:13:39 <anteaya> and there was a comment on the email list that there are more bots than just ci bots
19:13:40 <jeblair> anteaya: so that means getting the new wiki pages set up, and making sure we have each of the new reqs documented
19:13:44 <ianw> clarkb: bot seems like a common suffix, so you might have foobot bot?
19:13:45 <anteaya> so perhaps more than one filter
19:13:46 <fungi> right, the consensus so far had been that we should have a pattern which identifies clearly that the account is for an automated system and able to differentiate whether it's a third-party system or one run by infra
19:13:51 <jeblair> anteaya: then i think we ask them all to change once that is all in order
19:13:52 <anteaya> yes
19:13:57 <anteaya> sounds fair
19:14:01 <fungi> and i think the welcome message account should probably get exempted from that
19:14:14 <anteaya> yes
19:14:32 <anteaya> so there are bots
19:14:35 <anteaya> there is ci
19:14:42 <clarkb> and there is third party
19:14:45 <anteaya> there is the welcome message account
19:14:55 <anteaya> is third party the same set as ci?
19:15:02 <jeblair> there's the proposal bot -- are there any other bots that are not 3rd party ci or welcome message?
19:15:18 <fungi> "jenkins"
19:15:27 <anteaya> what is the project creator bot
19:15:38 <fungi> anteaya: that one doesn't comment
19:15:47 <Ajaeger> "OpenStack Proposal Bot" ;)
19:15:49 <mordred> I can't think of any others that leave comments righ tnow
19:15:52 <anteaya> so it sounds like we have to list all the accounts affected by this as a starting point
19:15:58 <Ajaeger> but that one does not comment
19:15:58 <anteaya> then decided on categories
19:16:04 <fungi> we did have "trivial rebase" commenting, but that's gone with gerrit 2.8
19:16:13 <anteaya> then select a keyword that a regex can isolate
19:16:44 <jeblair> i'm just not sure that we need to design a naming system that accomodates the proposal bot...  it does something very different than 3rd party ci and doesn't leave comments
19:16:47 <anteaya> I can start an etherpad listing everthing and then we can work on categorizeing them in a way we agree on
19:16:47 <mgagne> jeblair: I think you missed elastic recheck bot
19:16:49 <ianw> would some api-type service that returns some json describing current bot names work?  seems that could plug in easily to gerritjs
19:16:52 <jeblair> mgagne: thank you!
19:16:54 <mordred> I think we should have this on the full name and the username - so "SmokeStack CI" and "smokestack-ci" for instance?
19:17:01 <mordred> mgagne: ++
19:17:13 <krtaylor_> I am good with anything as long as it is standardized
19:17:41 <fungi> i think it's sufficient if we decide in the meeting that it should be done, what eth basic parameters are, and then leave the specifics to hash out in a spec/ml thread/code review
19:17:43 <mordred> ianw: I think people also want to be able to do email filters to not see emails of comments from ci bots
19:17:49 <mordred> fungi: ++
19:17:50 <clarkb> fungi: ++
19:18:03 <anteaya> it should be done
19:18:04 <jeblair> so how about "Foo CI" and "Bar Bot" depending on whether you are, well, a ci system or a bot....
19:18:05 <SergeyLukjanov> fungi ++
19:18:14 <clarkb> jeblair: wfm
19:18:16 <fungi> that seems sane enough
19:18:37 <fungi> whatever we settle on should be encoded in our third-party account documentation
19:18:45 <jeblair> yup
19:18:48 <anteaya> yes
19:19:05 <jeblair> #topic  Review Third Party wiki template (anteaya)
19:19:06 <fungi> we should start composing the visible names of the accounts ourselves at account creation based on info provided by the requesters
19:19:19 <anteaya> oh me again
19:19:20 <jeblair> #link https://wiki.openstack.org/wiki/Template:ThirdPartySystemInfoSubst
19:19:29 <anteaya> thanks
19:19:29 <jeblair> yup, i'm reordering
19:19:36 <anteaya> there is a template
19:20:00 <anteaya> #link https://etherpad.openstack.org/p/third-party-wiki-templating
19:20:13 <anteaya> this is the etherpad I am working from for the templating
19:20:20 <clarkb> the template looks good to me
19:20:29 <clarkb> it captures informantion that would allow me to udnerstand what is going on
19:20:36 <anteaya> great, thanks
19:20:51 <jeblair> #link https://wiki.openstack.org/wiki/ThirdPartySystems
19:20:57 <fungi> we do need to make sure it's fairly comprehensive before we ask the operators to start filling it out, since we don't want to have to keep going back to them all asking for new bits
19:20:57 <jeblair> that's also nice to see ^
19:20:59 <anteaya> Ajaeger put it together for me
19:21:20 <jeblair> i think that's illustrating how the page structure will come together; i like it
19:21:23 <anteaya> great
19:21:30 <Ajaeger> teamwork with anteaya and fungi!
19:21:38 <anteaya> I'll work on the other template for the openstack programs template
19:21:45 <anteaya> thanks
19:22:03 <anteaya> I just needed some initial feedback to ensure we were going in the right direction
19:22:17 <anteaya> I have what I need from this topic
19:22:21 <fungi> once we collect info on what projects the operators think they should be voting on, we can start rolling out tighter acls limiting them to that
19:22:29 <anteaya> yay
19:22:46 <clarkb> fungi: ya and/or just give tem the ability to manage them
19:22:53 <Ajaeger> anteaya: fifieldt started with this one for programs: https://wiki.openstack.org/wiki/Template:ProjectBox
19:23:00 <fungi> clarkb: right
19:23:16 <anteaya> Ajaeger: interesting
19:23:24 <jeblair> anteaya: maybe it's implied in structure, but maybe not...
19:23:35 <jeblair> anteaya: but a description of what is being tested and how would be useful for devs
19:23:38 <fungi> clarkb: we could set the neutron-tpt group owned by neutron-core for example
19:23:47 <anteaya> I will make it explict
19:23:59 <anteaya> I don't find implying anything works with this group
19:24:01 <jeblair> eg, "we test patches on our super-expensive network switch thingy in such and such configuration"
19:24:09 <anteaya> great
19:24:31 <anteaya> I will expand that section
19:24:57 <jeblair> #topic  How do we want to handle patches to openstack_project and openstack tooling that fix downstream issues.
19:25:01 <jeblair> clarkb: i think that's you?
19:25:06 <clarkb> yup
19:25:30 <clarkb> so on the agenda are links to a couple examples of changes that update openstack_project to make it useable by downstreams
19:25:33 <jeblair> sdague: ping
19:25:45 <clarkb> I don't want to chase people away when they do those things, but I think that we are misplacing effort
19:25:51 <clarkb> openstack_project is well the openstack project
19:26:17 <clarkb> we will do domain specific things tehre and IMO allowing for every use case is a bit overboard there
19:26:24 <mordred> I agree that it's the openstack project - but I think there is a bunch of stuff in it that doesn't need to be there
19:26:27 <clarkb> would be good to come up with a consistent way of addressing these things
19:26:33 <clarkb> mordred: yup agreed
19:26:39 <mordred> like, I don't think openstack_project needs to be very configurable
19:26:58 <mordred> but I _do_ think a bunch can get refactored out into things that are more re-usable
19:27:04 <mordred> s/very//
19:27:11 <clarkb> personally I would like to see refactors instead like jesusaur's jenkins reorg
19:27:16 <fungi> i definitely don't want to see us extracting all the variables out of o_p into the global site manifest, for example
19:27:17 <mordred> ++
19:27:25 <mordred> (to both)
19:27:51 <mordred> I think also AaronGr's heira-in-tree can help us to have _less_ parameters in openstack_project
19:27:58 <mordred> because many of them are there for passthrough needs
19:28:04 <mordred> and not because we need parameters
19:28:16 <fungi> yeah, that has led to a major spaghetti effect
19:28:28 <mordred> so - if the refactors actually make things cleaner and simpler, I think theyre awesome
19:28:44 <mordred> and I'd love to stop having to plumb variables through 6 layers of use
19:28:52 <rcarrillocruz> ++
19:29:03 <wenlock> clarkb we had the same battle when starting to consume config as upstream... it was natural for us to make our own <project>_project , but we also came back with a need for an instance specific module which held more of this config integration with parameters.
19:29:14 <jesusaur> I think that moving most of the puppet modules out into their own repos would help define the line: openstack-infra/config should be openstack_project and manifests/site.pp (which don't need to be configurable), other modules and projects should be more configurable and reusable
19:29:17 <wenlock> moving things to a hiera tree has been helping us alot
19:29:19 <fungi> distilled, if the change makes it easier for downstreams *and* us to modify, it's worthwhile
19:29:26 <mordred> fungi: ++
19:30:21 <jeblair> https://review.openstack.org/#/c/87384/ is instructive
19:30:48 <fungi> and yeah, like jesusaur mentions, we should continue to push for bits people want to reuse to go down into the individual modules when it can be done cleanly, rather than just accepting that everyone tried to reuse openstack_project directly
19:31:09 <mordred> jeblair: yeah. that's the other aspect of this question
19:31:10 <jeblair> it's not pupput; it's shell code that we use to build our images
19:31:10 <clarkb> jeblair: ya so that is the other type of change we see
19:31:30 <mordred> I think we should take those case-by-case - tbh
19:31:34 <jeblair> i mean, it's super easy for a downstream to replace it with their own scripts
19:31:42 <jeblair> but, otoh, apparently ours are 99.9% good enough
19:32:08 <mordred> in this case, I think the move to dib will obviate teh need for that patch - and a class of that type of patch
19:32:23 <clarkb> mordred: to a degree
19:32:32 <mordred> but it's still illustrative of a person who needs a feature that wants to go into ours, and it's not a feature we'll ever need
19:32:33 <clarkb> but the jenkins scripts fall under that category now too
19:32:39 <jeblair> so maybe that's a matter of just weighing the extra cost; if it's a few lines of "dead" (to us at least) code, sure.  but if it's more, then we say it's better to use new scripts
19:32:44 <mordred> but it facilitates them not forking a script they could otherwise consume
19:32:50 <mordred> jeblair: ++
19:32:53 <clarkb> mordred: well so you shouldn't have to fork right?
19:32:59 <clarkb> you just set the variable in your wrapper script and exec ours
19:33:15 <jeblair> clarkb: that's a good approach to this case
19:33:24 <mordred> clarkb: yes. except the actual mechanics there are hard
19:33:38 <clarkb> mordred: export FOO=bar ; exec script is hard?
19:33:40 <mordred> because the scripts are in openstack_project, which is not really a thing you're likely to be consuming directly
19:33:42 <jeblair> mordred: well, we essentially already do that ourselves
19:33:47 <fungi> what i would see as a "good" compromise there would be to refactor some of our scripts to make them better building blocks which can be more easily called from downstream scripts/tooling
19:34:14 <clarkb> fungi: ++
19:34:15 <jeblair> fungi: they already are somewhat blocky -- more specific ones call less specific ones
19:34:23 <mordred> fungi: ++ - but also what jeblair said above, which is that I think we should weight the costs as those come up
19:34:41 <mordred> and know that we don't want to add senseless complexity
19:34:48 <fungi> yep, i agree they're mostly that way already
19:34:53 <mordred> but oftentimes such refactors help us too
19:35:15 <mordred> kinda like the devstack-gate hook functions
19:35:24 <clarkb> yup
19:35:49 <jeblair> clarkb: (i think you should suggest the script callout on that patch, see what the authors think)
19:35:59 <clarkb> jeblair: will do
19:36:28 <mordred> clarkb: or, tell them to wait for the dib refactor, which already has a different way of dealing with proxies and local content injection
19:36:36 <clarkb> so I think we haev agreement that we should push towards proper refactoring for reconsumption
19:36:41 <mordred> clarkb: ++
19:36:44 <clarkb> if the change is minor then ok
19:36:50 <jeblair> i was hoping sdague would be around to talk about how this affects test-matrix
19:36:59 <clarkb> ya so test-matrix is the other thing
19:37:16 <clarkb> mordred: have you fermeted on that more?
19:37:27 <clarkb> *fermented
19:37:42 * jeblair is worried that he fomented
19:39:18 <clarkb> tl;dr on that is again we have instructiev code that determines how we test stuff
19:39:29 <clarkb> and others would like to make it instructive for not upstream openstack
19:39:49 <clarkb> which bothers me because it is clearly an openstack specific tool for upstream testing
19:39:49 <mordred> yeah - I mean
19:39:54 <clarkb> and we can't test the downstream use case at all
19:40:02 <mordred> I don't think it's a specific openstack tool
19:40:21 <mordred> I think we've spent a lot of time telling people to re-use the tools we've written for their internal testing and they've listended
19:40:22 <clarkb> mordred: it is used to deploy from source openstack clouds
19:40:29 <clarkb> so that they can be tested
19:40:32 <mordred> yes
19:40:47 <mordred> I believe we have tons of people now wanting to replicate this infrastructure that we've built to do exactly that thing
19:41:06 <clarkb> but they don't want to replicate the development model
19:41:34 <jesusaur> clarkb: what do you mean?
19:41:37 <mordred> what I'm saying is that I don't think test-matrix is necessarily or has to necessarily be "upstream only"
19:41:55 <clarkb> jesusaur: openstack is very particluar in its dev flow in order to handle 1k devs
19:41:55 <mordred> in fact, I think sean has done a good job of making it a thing which takes data to make decisions
19:42:02 <clarkb> jesusaur: other folks want to mix it up for their 1k folks
19:42:22 <clarkb> mordred: right so we discussed making those bits more properly config, but you didn't like that for some reason
19:42:29 <clarkb> (I forget what the actual concern was)
19:42:39 <jeblair> mordred: i don't see how we can keep putting test variations into test-matrix that we don't test; i don't think we can review them intelligently, and i think it will hurt what we're trying to do by making it more complex
19:42:52 <mordred> jeblair: I do not think we shoudl do that at all, so I agree
19:43:07 <jeblair> mordred: i think for downstream test configs, that has to live outside of d-g and test-matrix, but we can facilitate that with plugin/hook points, etc.
19:43:16 <fungi> yeah, i do worry that our current branch handling is already jenga-like to the point where we risk even impacting our own use cases (when a change ends up modifying a behavior we weren't testing well enough)
19:43:18 <jeblair> clarkb: a config file sounds ideal to me...
19:43:22 <mordred> yah. agreed
19:43:30 <mordred> I think the main concern I had ...
19:43:44 <jeblair> fungi: i think we should have a giant jenga thing at the next summit
19:43:54 <fungi> jeblair: it should be the THEME of the next summity
19:43:57 <mordred> is that we keep in mind that someone may want to wholesale consume our config for test-matrix as well, and simply to suppliment it
19:44:17 <jeblair> mordred: sounds reasonable
19:44:19 <mordred> but, I think we keep that in mind generally, so it shoudln't be a big departure
19:44:46 <jeblair> clarkb: end of topic?
19:44:49 <clarkb> jeblair: yes  Ithink so
19:44:55 <jeblair> cool
19:44:58 <jeblair> #topic  About splitting Horizon repo in two parts (rdopiera)
19:44:59 <clarkb> basically push to refactoring and config rather than instructive code changes
19:45:01 <mordred> clarkb: I believe our disagreement is that I wanted to add awareness of branch prefixing to our branch fallback algorithm
19:45:07 <sdague> jeblair: just back from CSA pickup, what's up?
19:45:16 <mordred> clarkb: but I think that's out of scope for now
19:45:29 <mordred> ooh! splitting horizon!
19:45:32 <rdopiera> so I came to ask for advice, because we are going to do some changes in the horizon's repos, and we want to know the best way to proceed
19:45:32 <jeblair> sdague: read previous topic fyi and possible further discussion, but we need to move on now i think
19:45:33 * mordred is excited
19:46:05 <jeblair> rdopiera: we're very excited!  splitting them should make a lot of things easier!
19:46:09 <rdopiera> basically what we plan to do is to have a separate repo for the library and the application parts of horizon, plus a bunch of packages for all the js libraries
19:46:41 <fungi> rdopiera: please clarify what you mean by "packages" in that sense
19:46:41 <rdopiera> the js libraries part I already started on, we are using xstatic to package them, and putting them on stackforge
19:46:51 <fungi> got it ;)
19:46:53 <krotscheck> This is the “use pip to package javascript things” discussion, yes?
19:47:02 <rdopiera> xstatic is basically a minimal python package with the js libraries as data files in it
19:47:03 <clarkb> krotscheck: partially yes
19:47:12 <rdopiera> and some metadata
19:47:25 <rdopiera> so it can be installed from pypi, etc.
19:47:45 <jeblair> rdopiera: have you put any in stackforge yet?
19:47:50 <fungi> this is as opposed to installing the js bits via npm and everything else via pip?
19:47:55 <clarkb> the change to add them all to stackforge is proposed
19:47:57 <rdopiera> jeblair: there is a patch
19:48:00 <clarkb> fungi: correct
19:48:12 <rdopiera> that part is the easy part
19:48:26 <rdopiera> what I would like to ask all of you about is tackling the horizon's code itself
19:48:41 <rdopiera> we were thinking about cloning the repo, and removing half the files in each of them
19:48:47 <fungi> that does make them somewhat less consumable to the broader js community/ecosystem, though if horizon's dashboard is the only consumer right now then i don't suppose it's much of a concern
19:48:52 <rdopiera> this way we retain the history and the patch queue on one of them
19:49:08 <rdopiera> fungi: MoinMoin 2 also uses the same system
19:49:11 <Ajaeger> rdopiera: this might need changes to the translation jobs, please add this to your todo list.
19:49:19 <jeblair> let's tackle the repo split first
19:49:19 <rdopiera> fungi: and we hope more apps will use it with time
19:49:45 <clarkb> rdopiera: typically the way we do this is by git filter branching the initial state of one repo
19:49:52 <clarkb> then in the other repo submit a change t odelete the excess
19:49:53 <SergeyLukjanov> honestly, I'm feeling some inconsistence when see pip handling js libs
19:49:56 <fungi> rdopiera: right, the git repo split can be fairly easily handled via git filter-branch *if* the files which go in each repo are fairly well separated already
19:50:11 <jeblair> rdopiera: which will be in the "horizon" repo?  the dashboard or library?
19:50:18 <rdopiera> fungi: they are separated
19:50:50 <rdopiera> jeblair: the openstack_dashboard will get renamed to horizon, and the horizon (library) will get renamed to django-horizon
19:51:20 <fungi> and also i'm curious to know what the release model will become for each (both still integrated releases? library switching to ad-hoc with no stable branches?)
19:51:24 <rdopiera> jeblair: so the patch queue will stay with dashboard, which I think is good, because most changes are there
19:51:28 <jeblair> rdopiera: cool, that makes sense.
19:51:49 <anteaya> would webui work in there at all for naming
19:51:55 <rdopiera> fungi: simultaneus release, from what I understand
19:52:00 <jeblair> rdopiera: so we can help with the filter branch when you're ready
19:52:01 <anteaya> isn't that what we are doing with storyboard and vinz?
19:52:11 <clarkb> anteaya: the architecture of the two is different
19:52:16 <anteaya> oh okay
19:52:35 <jeblair> rdopiera: or if you want to do it, you can just host the new repo somewhere
19:52:35 <rdopiera> django-horizon is mostly front-end stuff, like widgets and views
19:52:46 <jeblair> rdopiera: and when we create the project, import it from there
19:53:07 <rdopiera> jeblair: that sounds good, because I can test different approaches then
19:53:18 <jeblair> rdopiera: i think that the horizon repo will still have the history for both projects though
19:53:28 <clarkb> yup and I tink it should
19:53:28 <rdopiera> yes, that's fine
19:53:31 <jeblair> ok
19:53:38 <clarkb> because we need to track that they became two at some point
19:53:43 <fungi> right, most likely outcome is that the old library bits get deleted from the horizon repo in one mass commit
19:54:16 <rdopiera> that commit will probably invalidate a lot of patches in the queue, but the sooner we do it, the better
19:54:40 <jeblair> rdopiera: i think what you may want to do is to "freeze" the library inside of horizon, create the new project, then get it working in devstack-gate, then rm the lib from horizon
19:55:02 <rdopiera> jeblair: sorry, what is devstack-gate?
19:55:39 <jeblair> rdopiera: it's what we used to do integration testing of all the projects
19:55:51 <jeblair> rdopiera: it uses devstack to install everything and runs tempest
19:55:58 <rdopiera> I will look for it, thank you
19:56:00 <fungi> #link http://git.openstack.org/cgit/openstack-infra/git-review/tree/README.rst
19:56:13 <fungi> er, wrong link
19:56:20 <fungi> #link http://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/README.rst
19:56:21 <clarkb> close :)
19:56:26 <fungi> (silly clipboard!)
19:56:29 <jeblair> rdopiera: so i expect there to be some patches to devstack and devstack-gate after the new project is created
19:56:31 <rdopiera> ok, thank you everyone
19:56:46 <jeblair> rdopiera: sdague, dtroyer, and i can help out with those parts
19:56:56 <jeblair> rdopiera: thank you!
19:57:28 <jeblair> rdopiera: so we don't have a lot of time, and i'm not sure this is the best forum for the discussion anyway, but the other half of this, the xstatic part, interests some of the people here
19:57:45 <sdague> jeblair: sounds good
19:57:50 <jeblair> rdopiera: is there a mailing list thread about it?
19:58:28 <rdopiera> jeblair: we had a design session on that https://etherpad.openstack.org/p/juno-summit-horizon-static-files
19:58:38 <jeblair> rdopiera: so that people can learn about it or discuss?  particularly, i want to make sure that zigo weighs in on it
19:58:39 <rdopiera> jeblair: and there is an e-mail with some summary of progress here:
19:59:21 <jeblair> rdopiera: because i recall from the design session that there was a lot of talk about doing this to help debian, but zigo wasn't actually there
19:59:34 <clarkb> jeblair: yes and red hat iirc
19:59:46 <jeblair> red hat was there and seemed okay with xstatic
19:59:46 <mordred> yah - I also have an extreme view myself that it's not our job to make things easier on the distros
19:59:47 <rdopiera> http://lists.openstack.org/pipermail/openstack-dev/2014-May/035370.html
19:59:48 <clarkb> but fedora does have npm now so I don't know
19:59:52 <mordred> but rather to do the thigns that make sense for us
19:59:53 <fungi> pabelanger has also expressed a desire to be able to pip-install the django lib
20:00:10 <jeblair> rdopiera: also, mordred had an idea about using pbr and nodeenv to build things at tarball creation time
20:00:15 <mordred> yup
20:00:22 <rdopiera> mordred: xstatic is actually designed with easy packaging for distros in mind
20:00:24 <jeblair> so i want to make sure zigo and mordred have an opportunity to chime in
20:00:31 <mordred> rdopiera: right. I don't share that as a goal
20:00:34 <rdopiera> mordred: you can configure it to keep the actual files in any place
20:00:41 <mordred> I share participating in and with upstreams more in mind
20:01:02 <mordred> and if the distros can't figure out javascript, then they'll be replaced by distros that can figure out javascript
20:01:09 <mordred> but like I said, I'm an extremist
20:01:10 <jeblair> and i think we're out of time
20:01:13 <mordred> :)
20:01:17 <jeblair> rdopiera: thanks!
20:01:20 <mordred> rdopiera: ++
20:01:21 <jeblair> #endmeeting