20:03:14 <jbryce> #startmeeting
20:03:15 <openstack> Meeting started Tue Jun 14 20:03:14 2011 UTC.  The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:03:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:03:27 <jbryce> http://wiki.openstack.org/Governance/PPB - agenda
20:03:37 <termie> k, well i'll lurk, say my name (!!) if you get to githubbery
20:03:49 <jbryce> termie: ok
20:03:56 <jbryce> #topic previous action items
20:04:23 <jbryce> looking back through the meeting logs, i think we're caught up on almost everything. one outstanding issue was a q&a system
20:04:34 <jbryce> does anyone know where we stand on that?
20:04:42 <ttx> o/
20:04:52 <devcamcar> o/
20:04:59 <johnpur> we have deferred it until the new tcm comes on board
20:05:10 <notmyname> what's a tcm?
20:05:14 <johnpur> since he/she will own it
20:05:16 <jbryce> technical community manager
20:05:22 <johnpur> technical community manager
20:05:31 <johnpur> jinx!
20:05:35 <jbryce> #info deferred implementation of q&a software, waiting for technical community manager
20:05:58 <jbryce> sebastianstadil: you around sebastian?
20:06:03 <sebastianstadil> jbryce: I am
20:06:05 * soren is here now, sorry, was distracted.
20:06:16 <jbryce> #topic Scalr incubation application
20:06:27 <jbryce> http://wiki.openstack.org/Scalr - incubation application for scalr
20:06:27 <sebastianstadil> *Rooting*
20:07:00 <ttx> who starts ? :)
20:07:02 <jbryce> did everyone get a chance to review the application? anyone have questions?
20:07:15 <jbryce> i know one issue that's already been brought up is language choice
20:07:22 <ttx> I have a few...
20:07:22 <sebastianstadil> indeed
20:07:22 <soren> I've not actually had a chance to read it. :(
20:07:27 * soren does so real quick.
20:07:40 <sebastianstadil> It's succint.
20:07:52 <johnpur> i would like to know the state of the scalr dev community, contributors, activity outside of the core, etc.
20:08:15 <johnpur> how it might mesh witht he current OS community
20:08:29 <ttx> johnpur: yes, I find the source code repository to be a bit scary in that respect
20:08:59 <mtaylor> google code --
20:08:59 <ttx> http://code.google.com/p/scalr/source/list shows no work since April 16, and code drops that show that the development is done behind closed doors and thrown over the wall in the open repo every once in a while
20:09:16 <ttx> which clearly does not match our way of doing things
20:09:21 <sebastianstadil> Agreed
20:09:33 <sebastianstadil> Reason is that the Google code repo is super slow
20:09:57 <ttx> sebastianstadil: does that mean you plan to change that in the incubation is accepted ?
20:10:03 <ttx> if*
20:10:11 <sebastianstadil> ttx: We plan on changing that regardless
20:10:16 <notmyname> to what?
20:10:31 <sebastianstadil> Github has our preference so far
20:11:00 <johnpur> sebastianstadil: i assume that there is little to no outside community then?
20:11:31 <sebastianstadil> About half a dozen community patches over the lifetime of the project
20:11:37 <jaypipes> My question is really about whether Scalr should be *part* of OpenStack or simply *consume/use* OpenStack as a cloud compute infrastructure... I'm thinking it's more a user of OpenStack than part of OpenStack itself.
20:11:43 <sebastianstadil> Minor fixes
20:11:44 <dendrobates> sebastianstadil: what happens to the scalr name if scalr becomes part of openstack and you change your mind and want to leave?
20:11:50 <ttx> jaypipes: +1
20:12:04 <ttx> as much as I find Scalr interesting as a project, I'm struggling to see how it fits with OpenStack, especially since it connects to multiple things
20:12:28 <ttx> I mean, I see how it fits with OpenStack... but not as a core project withing OpenStack
20:12:42 <ttx> and incubating projects are candidates for core in the end.
20:13:21 <sebastianstadil> ttx: I believe that at the end of the day we want people to use this stuff. That's what Scalr helps with
20:13:25 <johnpur> it gets to a point i brought up before, where are we drawing the line (IaaS, PaaS, etc.) Are there currently different rukes for "incubation" vs "core"?
20:13:40 <johnpur> s/rules/rukes
20:14:38 <sebastianstadil> ttx: We want people to be able to build complex applications, manage them, and gain all the agility that comes with the cloud
20:14:57 <jaypipes> I very much likes the idea of Scalr as one choice for deployment of app stacks on top of OpenStack infrastructure. Just not sure it belongs as an "incubated" project...
20:14:59 <soren> To be fair, Glance also interfaces with S3.
20:15:01 <sebastianstadil> ttx: Right now it's still easier to use dedicated hardware and scale up then use the cloud
20:15:14 <johnpur> it is clear that with the success of RightScale and projects like Scalr that folks that deploy on clouds benefit from these sorts of systems
20:15:17 <soren> ...so there's certainly prior art to core projects being able to interact with stuff that isn't OpenStack.
20:15:32 <sebastianstadil> johnpur: Precisely.
20:16:04 <sebastianstadil> There's no way a Zynga would not use a RightScale / Scalr / other management suite
20:16:20 <johnpur> jaypipes: can you elaborate? why not incubate?
20:16:21 <jaypipes> soren: yes, but Nova uses Glance as its image store. I don't think you could say the same about Scalr, no? How would other OpenStack projects *use* Scalr? The answer is they wouldn't...Scalr would use other OpenStack projects, but not the other way around, right?
20:16:28 <jaypipes> johnpur: ^^
20:16:36 <sebastianstadil> Just too hard to manage hundreds or thousands of servers and not go mad with the complexity
20:16:54 <soren> jaypipes: That will always be the case in the beginning when you add stuff at the top of the dependency chain.
20:17:13 <soren> jaypipes: ...and it's only true until the next thing comes along that builds on top of it. That's how stacks are built :)
20:17:19 <sebastianstadil> jaypipes: In the beginning, it would indeed be one-way
20:18:01 <sebastianstadil> jaypipes: but I think we should focus on users of OpenStack as well
20:18:02 <jaypipes> soren: AFAICT, Scalr is kind of like a conglomeration of a whole bunch of things... load balancing, compute, config management, database replication management, application management... I'm finding it tough to see where Scalr's "niche" is.
20:18:16 <sebastianstadil> jaypipes: auto-scaling
20:18:34 <sebastianstadil> jaypipes: which requires a lot of different elements
20:18:49 <jaypipes> sebastianstadil: right. But I don't see auto-scaling as a core OpenStack project. I see it as a consumer/manager of OpenStack core projects.
20:19:29 <soren> jaypipes: I think the situation where new projects build upon existing one is ideal.
20:19:35 <soren> s/one/ones/
20:19:42 <jbryce> i think soren's point is very good. these things expand and stacks build over time. i would expect there to be some sort of open source management/automation system that makes sense to have tied very closely to all openstack components. it does leave the question of when something like that should be brought in especially when the other core pieces (auth, networking, volume storage) are still forming
20:19:50 <soren> In the sense that they consume their API's and provide more value that way.
20:20:08 <johnpur> jbryce: hence incubation vs core
20:20:10 <jaypipes> soren: then what is "core"?
20:20:16 <dendrobates> jbryce: that is in fact the very idea of Donabe
20:20:18 <sebastianstadil> Very much agree with soren
20:20:24 <soren> jaypipes: Fantastic question.
20:20:32 <soren> jaypipes: ..with many answers, clearly :)
20:20:41 <jaypipes> sebastianstadil: I'm not disagreeing with you or soren :) just wondering where the "core" line is...
20:21:00 <jaypipes> sebastianstadil: since incubated projects are intended to become core, that's the question we're trying to answer here ;)
20:21:00 <sebastianstadil> jaypipes: Help us define it then!
20:21:16 <jaypipes> sebastianstadil: OK, I'll give it a shot...
20:21:21 <soren> jaypipes: I have some answers to what it doesn't mean :)
20:21:37 <johnpur> jaypipes: core projects will have significant community interest and involvement
20:21:37 <jaypipes> I think that core projects are the "building blocks" that other services and projects use to create an entire platform.
20:22:02 <jaypipes> I can't see Scalr as a building block. I see it as a platform.
20:22:04 <dendrobates> core projects require tight integration with the other core projects
20:22:09 <johnpur> and be the "best" solution to a set of defined problems
20:22:18 <jaypipes> sebastianstadil: that make sense?
20:22:19 <ttx> sebastianstadil: I think it's a bit early for incubation... as in, the project needs to live as an open development project for a bit, potentially grow a community, for us to see where that community pushes it
20:22:34 <johnpur> jaypipes: do you object to having a "PaaS" project in incubation?
20:22:41 <soren> jaypipes: I think what we're seeing with Scalr is simply that they have a massive head start.
20:22:42 <jaypipes> johnpur: yes.
20:22:51 <johnpur> ttx: +1
20:23:02 <ttx> sebastianstadil: going straight from "company owning development behind closed doors" to "openstack core candidate" is a bit quick
20:23:15 <soren> jaypipes: What would have happened with a more organic evolution is layers and layers and layers on top of the current core projects.
20:23:29 <sebastianstadil> jaypipes: You should spend some time and use it, you'll see that the different components can and are often used to build higher level concepts that fit every particular application
20:23:33 <ttx> Once you open it on github and as an openstack ecosystem project, you might realize people want to take it in other directions
20:23:40 <soren> jaypipes: ...and eventually something like Scalr would turn up, combining it all into something really useful.
20:24:02 <jaypipes> soren: sorry, I'm losing you. are you suggesting that that eventual solution would be a "core" project?
20:24:03 <soren> jaypipes: ...it just so happens that Scalr has existed for years and so have managed to get to that final point already.
20:24:21 <soren> jaypipes: Yes.
20:24:21 <johnpur> sebastianstadil: you mentioned that you will be altering your community engagement processes. Can you make these changes, model after OpenStack, get more community involvement... and then come back with an incubation request
20:24:34 <jaypipes> sebastianstadil: again, it's not that I don't see the value. I definitely do. I'm saying I don't consider PaaS stuff core OpenStack projects.
20:24:46 <johnpur> jaypipes: for now
20:24:52 <soren> jaypipes: I don't have a problem accepting a project into OpenStack as a core project on the grounds that it build on top of and is a heavy consumer of the existing core projects.
20:25:01 <sebastianstadil> ttx: Isn't that what incubation is for? To determine if all the processes can be established to guarantee a successful Core project?
20:25:03 <soren> "core" doesn't imply self-containedness to me.
20:25:11 <jaypipes> johnpur: are you saying "for now" as in "jay will change his mind later"?
20:25:30 <jaypipes> soren: ok, I hear you. but it does to me. :)
20:25:32 <soren> It's more along the lines of "this is the component that solves problem X that we as a project stand behind".
20:25:48 <ttx> sebastianstadil: incubation is more to get in line with openstack processes than to "become open"
20:25:48 <johnpur> i am saying that OpenStack will likely evolve and mature, evidence is that Cloud systems go "up the stack"
20:25:55 <soren> I tend to build my stacks upwards, not sideways :)
20:26:01 <eday> sebastianstadil: I've not used scalr before, but is it mainly config files and daemons running tasks, or is it tightly integrated into a UI as well?
20:26:04 <sebastianstadil> ttx: People do want to take it in other directions, a company recently wanted to make the IaaS-interface modules OCCI compatible
20:26:08 <ttx> we need to judge if the project fits, but going more open will chnage your project significantly
20:26:23 <jbryce> soren: ++
20:26:33 <ttx> so I fear that what we judge today might not be what it becomes
20:27:04 <soren> jaypipes: I can see how the term "core" suggests a sort of self-containedness.
20:27:07 <ttx> sebastianstadil: saw dendrobates question above ? I think it's a good one too
20:27:21 <jaypipes> soren: think of it this way: you don't consider Ubuntu to be a "core" Linux project do you?
20:27:29 <ttx> <dendrobates> sebastianstadil: what happens to the scalr name if scalr becomes part of openstack and you change your mind and want to leave?
20:27:52 <soren> jaypipes: I don't, no. I don't see the analogy, though.
20:27:54 <ttx> would we use the name "scalr" as the name of the project ?
20:27:57 <sebastianstadil> eday: sign up at scalr.net to get a quick idea of the interface
20:28:19 <joshuamckenty_> dendrobates: Presumably the same thing as the nova or OpenStack names.
20:28:21 <ttx> it's more than just a codename like the others, it's a brand, and a company name :)
20:28:28 <jaypipes> soren: or, even more inline with this discussion, you don't consider Ubuntu Enterprise Cloud to be a core linux project. I view Scalr in much the same way: a platform that uses core projects to deliver extended value
20:28:41 <jbryce> ttx: i would guess we'd probably come up with an openstack generic name
20:28:43 <johnpur> ttx: probably not, as Scalr will want to retain rights
20:28:44 <joshuamckenty_> sebastianstadil: I think eday was asking about tight coupling with the ui
20:28:52 <soren> jaypipes: I don't think "core linux" makes any sense.
20:28:53 <dendrobates> joshuamckenty_: except that scalr is also a company and all the core devs could leave.
20:29:09 <joshuamckenty_> Openstack is also a company
20:29:14 <joshuamckenty_> And a brand
20:29:18 <dendrobates> joshuamckenty_: I just want to make sure that sebastianstadil understands the implications
20:29:20 <soren> jaypipes: I think of this more like Gecko being a core part of the Mozilla project, but so is Firefox.
20:29:22 <eday> sebastianstadil: I'm asking because if it is heavily UI driven (which I assume it is), it seems like the ideal outcome would be to have the Scalr features added to OpenStack Dashboard (which is Python based) so we don't have competing UIs with an overlap of functionality
20:29:23 <joshuamckenty_> So the parallel standa
20:29:39 <jbryce> jaypipes: nova is a collection of functionality provided by iptables, kvm/xen/etc, filesystems....every piece of software aggregates functionality from others at some level
20:29:45 <sebastianstadil> ttx: OpenStack Manager / Scalr / UI, I don't have any preference on the name to use
20:29:46 <soren> jaypipes: ...even though it builds heavily upon another core project of Mozilla.
20:29:48 <joshuamckenty_> eday: +1
20:30:18 <sebastianstadil> dendrobates: We can sign a document giving you use of the Scalr name if that's what you are concerned about
20:30:21 <johnpur> eday: you are suggesting that scalr could be decomposed into sets of services that can be driven by the UI?
20:30:33 <jaypipes> soren: sorry, I still don't agree that a PaaS management interface should be a core project in OpenStack...
20:30:39 <soren> jaypipes: It's less of a technical term (which would suggest self-containedness), and more of a "socially and bureaucratically accepted part of OpenStack" sort of thing to me.
20:30:56 <jaypipes> soren: that is "related" projects in my mind.
20:31:00 <joshuamckenty_> johnpur: I think the scalr guest agent could be considered separately
20:31:31 <sebastianstadil> joshuamckenty_:  UI used to be tightly coupled, now it's just passing json to a js app on the client side
20:31:32 <soren> jaypipes: Anyone can say they're related. Only one project solving problem X can be core.
20:31:35 <johnpur> hmmm, sebastian, what do you think of that?
20:31:39 <soren> jaypipes: -ish.
20:31:51 <ttx> eday: I agree we should avoid overlap in core projects, so we have an issue with Dashboard
20:32:02 <eday> johnpur: I'm not sure, I don't know the Scalr architecture well enough to suggest anything. I'm just looking at it from an end-user. If we did have both scalr and openstack dashboard, it seems a bit confusing on the UI front. Or perhaps we want multiple official UIs (which I can't say I would want to support)
20:32:03 <joshuamckenty_> jaypipes: I think of elasticity mgmt as iaas, modulo UI
20:32:04 <soren> Ah! Dashboard!
20:32:10 <soren> jaypipes: Do you thing the dashboard should be core?
20:32:18 <ttx> soren: next topic :)
20:32:22 <jaypipes> soren: no.
20:32:24 <jbryce> ha
20:32:29 <soren> ttx: I know :)
20:32:33 <soren> jaypipes: Ok.
20:32:38 <soren> jaypipes: Well, at least you're consistent. :)
20:32:46 <joshuamckenty_> Flights taking off, you have my votes.
20:32:51 <jaypipes> soren: for the next ten minutes, sure ;)
20:32:56 <jbryce> joshuamckenty_: thanks. good flight
20:33:00 <soren> jaypipes: :)
20:33:03 <jbryce> ok...can we pause for a minute to summarize the questions
20:33:11 <jbryce> i'll take a stab at it
20:33:36 <jaypipes> sebastianstadil: does Scalr expose a REST API that completely controls Scalr's components?
20:33:45 <jbryce> #info has scalr built an open development process and community? does it need one before becoming incubated
20:33:47 <sebastianstadil> http://wiki/scalr.net/API
20:34:17 <jbryce> #info is the scalr architecture built in a way that it will provide reusable and recomposable functionality that may be used by other projects
20:34:21 <sebastianstadil> The problem we're tackling is that building applications on Cloud resources is hard
20:34:22 <johnpur> i think the issue of proving that the code can be opened and attract a viable community effort is key to accepting a project into incubation.
20:34:47 <sebastianstadil> That's why OpenStack should have a Core project that addresses it
20:34:50 <jbryce> #info should something that is primarily focused as a consumer and aggregator of other projects be in core
20:35:23 <jaypipes> sebastianstadil: OK, so not a REST API. Would you be open to developing a REST API instead of a SOAP-y API?
20:35:25 <jbryce> #info does being partially in php conflict with the existing openstack community, present potential problems around dev/testing/support of a new project
20:35:25 <notmyname> johnpur: isn't one of the purposes of incubation to help grow the community around a project?
20:35:31 <ttx> johnpur: so it should do "open development" and "open community" before applying ?
20:35:36 <sebastianstadil> jbryce: Thanks, I'm still lagging behind on some questions
20:36:29 <sebastianstadil> Doesn't the biological term incubation apply some sort of growth?
20:36:34 <sebastianstadil> *imply
20:36:55 <sebastianstadil> It's not really a test
20:36:56 <johnpur> my rationale is that "incubated" projects will take up time and resources form the folks managing releases, packaging, CI, QA, etc.
20:37:01 <jbryce> #info what issues does the scalr brand present if the company withdraws from involvement in openstack (on this i think we would probably have some other openstack name for the project)
20:37:26 <sebastianstadil> Regarding the dashboard, that's how Scalr started out: as an open source, web-based ElasticFox
20:37:56 <jbryce> those seem to be the main ones that i've picked out...did i miss any?
20:38:43 <sebastianstadil> But as people started using it, we found that a dashboard is in no way sufficient to manage an application. You need to be able to identify resources, commands to groups of them, orchestrate changes, etc.
20:39:21 <jaypipes> sebastianstadil: looking at the API, there seems to be a lot of overlap between Scalr's API and the OpenStack Compute API 1.1 (but looking more like EC2's API than Rackspace API)
20:39:33 <sebastianstadil> jbryce: Scalr is python for the guest agent, php for the controller, and js for the gui
20:40:04 <ttx> sebastianstadil: I also have a question, why would *you* want ScalR to be an OpenStack core project someday ?
20:40:07 <sebastianstadil> jaypipes: Correct, at the last summit I had a few discussions on how to address that
20:40:18 <sebastianstadil> ttx: OpenStack is awesome, want to be part of it.
20:40:27 <ttx> sebastianstadil: good :)
20:40:31 <jbryce> = )
20:40:37 <johnpur> nice answer
20:40:38 <jaypipes> sebastianstadil: nice bribe :)
20:40:46 <jbryce> 20 minutes before team meeting
20:40:54 <sebastianstadil> ttx: No technical reason, just a cool bunch that I like hanging out with
20:41:00 <ttx> sebastianstadil: because that implies a lot of constraints on what was your company and your code
20:41:02 <jaypipes> sebastianstadil: even better :)
20:41:17 <sebastianstadil> the company is in service of the code
20:41:25 <ttx> sebastianstadil: so it's not just a badge of honor or a club :)
20:41:43 <sebastianstadil> had we been venture funded, the company would have been in service of the shareholders
20:41:55 <sebastianstadil> ttx: I know :-)
20:42:03 <ttx> (it's the first "established" project we consider for openstack incubation, hence the strange questions)
20:42:11 <jbryce> do people want more discussion or should we call a vote and see where we stand?
20:42:20 <johnpur> vote
20:42:33 <sebastianstadil> ttx: Yeah, and we had to write a lot of code that solved problems from yesterday
20:43:03 <sebastianstadil> ttx: Like how to manage failover on a db that doesn't use network block storage
20:43:40 <soren> The answer to that being: "carefully"
20:43:48 <sebastianstadil> soren: haha!
20:43:52 <jaypipes> jbryce: to be sure, we are voting whether to accept Scalr into incubation -- which means that we will owe sebastianstadil a detailed map of what things need to change (code, community, process, etc) in order to be considered for core?
20:43:58 <jbryce> time for the vote. should scalr be added as an incubated openstack project?
20:44:11 <jbryce> jaypipes: correct.
20:44:28 <johnpur> my vote is +1. i think this is the sort of existing project that can add a lot of value to the oepnstack ecosystem. going forward we should look at how the scalr functionality is merged into the openstack user experience.
20:44:30 <soren> I'd actally like to talk aobut technical stuff.
20:44:38 <soren> ..before voting.
20:44:42 <soren> Mostly the PHP thing.
20:44:47 <ttx> soren: like, could we rewrite it in Python ?
20:45:11 <soren> ttx: I'd have phrased it differently, but yes :)
20:45:12 <jbryce> jaypipes: no guarantee of core, and i wouldn't be surprised if others in the community would like to see more merging between dashboard ui components and scalr automation components as well as the general aversion to php that we've already seen
20:46:10 <ttx> jbryce: aversion comes from the packaging burden that PHP carries. Is ScalR shipped in any distribution ?
20:46:22 <soren> ttx: I'm 97% done packaging it for Ubuntu.
20:46:29 <soren> Sorry, 87%.
20:46:38 <johnpur> ttx: how "bad" is it? java scale?
20:46:39 <soren> Just saying.
20:46:49 <ttx> johnpur: of course not
20:46:50 <soren> Nowhere near Java scale.
20:46:53 <johnpur> lol
20:46:59 <johnpur> just saying
20:47:10 <sandywalsh> does scalr conflict with the direction dashboard wants to go?
20:47:12 <soren> It's unpleasant, but certainly doable.
20:47:14 <sebastianstadil> actual laughter was produced
20:47:29 <ttx> johnpur: though security-wise, PHP is a bit of a nightmare, I'm giving Sebastian the benefit of doubt over his PHP code :)
20:48:24 <ttx> jbryce: unfortunately it's difficult to vote without considering Dashboard in parallel
20:48:42 <ttx> jbryce: If they overlap, we'll have to choose between the two ?
20:48:48 <sebastianstadil> ttx: I think a successful Dashboard project will turn into a Scalr in 2-3 years
20:48:58 <jbryce> ttx: choose or find ways to combine
20:49:11 <soren> I don't enjoy php, but my primary concern at this point is really the divergence.
20:49:14 <sebastianstadil> I've seen it with Scalarium, RightScale, and a few other projects
20:49:19 <ttx> jbryce: so it seems unfair to vote on ScalR without giving Dashboard a chance ;)
20:49:32 <soren> I think sharing something as core as programming language between all core projects is really, really useful.
20:49:33 <johnpur> we should look at the opportunity to enhance the user experience by merging the two efforts where it makes sense
20:49:59 <jbryce> ttx: so defer vote for discussion of dashboard?
20:50:05 <sebastianstadil> Anyone used thrift here?
20:50:16 <soren> Not directly, no.
20:50:17 <ttx> sebastianstadil: aaaaaah
20:50:25 <jbryce> sebastianstadil: unfortunately yes
20:50:31 <soren> I talked to a Cassandra instance once, so sort of. :)
20:50:32 <notmyname> soren: "In order to ensure that there is ubiquitous distribution of the core OpenStack projects the development languages/environments and libraries must be widely and freely available. (Specific languages/runtimes that are ubiquitously available can be proposed and will be considered by the PPB)."
20:50:34 <sebastianstadil> jbryce: Doesn't work as intended?
20:51:13 <jbryce> sebastianstadil: to be fair, this was 12+ months ago...but scars can last a long time
20:51:19 <sebastianstadil> This doesn't go for the short term, but longer term the proportion of python to php will increase
20:51:20 <devcamcar> sebastiansadil: are you more concerned about scalr's ui being a standard, or the interface to the orchestration layer being standard?
20:51:47 <sebastianstadil> devcamcar: Not sure I understand
20:51:56 <ttx> jbryce: maybe let devcamcar and sebastianstadil talk for a week and see if they can come up with something awesome ?
20:52:19 <sandywalsh> Would there be sufficient community adoption if it's in a different language compared to what we would get by sharing code directly?
20:52:29 <sebastianstadil> I'm more concerned about making an awesome product for people to build awesome applications
20:52:33 <soren> I'm not a big fan of the actual look of the scalr UI (I've seen much, much worse though!), but the fact that it's all Javascript and just interacts with Scalr over HTTP+JSON is pretty nifty in my view.
20:52:38 <johnpur> ttx: i like that
20:52:39 <ttx> jbryce: like a django UI with autoscaling featurse.
20:52:45 <jbryce> ttx: yep
20:53:14 <ttx> otherwise I have to think about which one I should give my +1 too, and that involves hearing Dashboard side of the story.
20:53:18 <sebastianstadil> ttx: It's actually more like Gmail
20:53:20 <devcamcar> seabastiansadil: what about using just the python pieces?
20:53:48 <sebastianstadil> devcamcar: Wouldn't help the end-users
20:53:49 <jbryce> ttxdevcamcar, sebastianstadil: are you two opposed to talking about something like that? dashboard ui driving scalr automation? this is similar to what josh mckenty mentioned as well
20:54:08 <devcamcar> i'm open to it but sebastian hasn't ever expressed interest  in that when we've discussed it
20:54:50 <devcamcar> anyway you guys just spent an hour talking about scalr so there's not much for me to say today
20:54:54 <sebastianstadil> I think a fully js engine >> mvc
20:55:03 <notmyname> wouldn't that imply that one of them will be incubated? isn't it possible that neither get accepted?
20:55:25 <jbryce> devcamcar: sorry about that!
20:55:44 <soren> i think this has been a very useful discussion, though. I'd hate to have cut it short.
20:56:21 <jbryce> i agree
20:56:43 <jbryce> sebastianstadil, devcamcar: you two are kind of are guinea pigs as this is are first pass at this
20:56:43 <johnpur> jbryce: next steps?
20:56:48 <sebastianstadil> Some brave enough to summarize the discussion?
20:56:56 <jbryce> sure
20:56:57 <ttx> notmyname: I would like to see one of them. Your opinion may differ. Jay's opinion differs.
20:57:27 <jbryce> not everyone feels ready to have a firm vote on scalr without giving dashboard a full hearing
20:57:48 <notmyname> ttx: ha! if you and I didn't differ, one of us is wrong ;-)
20:58:04 <ttx> notmyname: my.. head... hurts...
20:58:47 <jbryce> i think there are some concerns about overlap between the two and incubating 2 of the same thing, splitting efforts, language differences and a desire to see if there is a chance for collaboration that would result in an automation/scaling project with a ui where more of the code is in python
20:59:12 <jaypipes> jbryce: nice summary.
20:59:26 <johnpur> i really like the idea of extending the dashboard functionality with scalr automation, can we have an action to have these discussions?
20:59:28 <jbryce> next steps are to break for the day because we're out of time, see if devcamcar and sebastianstadil want to talk about combined efforts or not, and in any case come back again next week to discuss dashboard if devcamcar is available again
20:59:35 <sandywalsh> is the scalr architecture intended to only operate at the public API level, or will it attempt to access the AMQP layer for faster decision making?
20:59:39 <devcamcar> i'm available
21:00:53 <soren> sandywalsh: If there's any sort of motivation to speak AMQP to anything, we're doing something wrong :)
21:01:04 <ttx> jbryce: #endmeeting ?
21:01:07 <jbryce> devcamcar: sorry again for making you sit this one out. we will definitely give you your day in the hot seat
21:01:09 <jbryce> thanks guys
21:01:12 <jbryce> #endmeeting