openstack-clients-dev team mailing list archive

[Michael Mayo <mike@xxxxxxxxxxxxx>]

Oops, I didn't notice the question on Scalr using Python and PHP.  Ultimately, I'd just say use your best judgment :)  If there's any sort of problem with naming, we can hash it out here.  (After all, Devin's NASA client is Python, but I imagine it would end up named openstack-django)

As for a next step, I know we're all at different places in different projects, so if you're contributing to one that already exists, go with the usual branch/merge approach.  If you want to start a new project in launchpad under openstack-clients, send me an email with what it is and what you want it to be named, and then we can go from there!

Thanks!
Mike




On Dec 5, 2010, at 11:07 PM, Sebastian Stadil wrote:

> Looks like we have lazy consensus. What's the next step, Mike?
> 
> On Tue, Nov 30, 2010 at 5:36 PM, Sebastian Stadil <sebastian@xxxxxxxxx> wrote:
> Looks good.
> 
> Scalr uses Python and PHP, should we choose the language or framework used predominantly?
> 
> 
> On Tue, Nov 30, 2010 at 5:29 PM, Todd Willey <todd@xxxxxxxxxxxx> wrote:
> I like it.
> 
> On Tue, Nov 30, 2010 at 7:38 PM, Mike Mayo <mike@xxxxxxxxxxxxx> wrote:
> > I was thinking openstack-platform-(language/framework if necessary)
> > Examples:
> > openstack-android
> > openstack-ios
> > No language on those since it's implied by the platform.  More:
> > openstack-web-django
> > openstack-web-java
> > How's that?
> > Mike
> > 901-299-9306
> > @greenisus
> > On Nov 30, 2010, at 3:56 PM, Sebastian Stadil <sebastian@xxxxxxxxx> wrote:
> >
> > Any thoughts on the naming convention? OpenStack-ui-[python|php|ruby|java] ?
> >
> > On Tue, Nov 30, 2010 at 1:09 PM, Michael Mayo <mike@xxxxxxxxxxxxx> wrote:
> >>
> >> Yeah, that's exactly what I'm thinking.  But I don't want to commit to any
> >> of it :)
> >> For instance, I'm not going to write a Java version, so if one is going to
> >> exist, someone will need to step up and contribute it.
> >> And there actually *is* a Firefox extension for Rackspace Cloud, which
> >> could potentially be later adapted to the OpenStack API.
> >> On Nov 30, 2010, at 12:31 PM, Sebastian Stadil wrote:
> >>
> >> We've made similar decisions to use or not use software based on what it
> >> was written in (I'm looking at you, Chef!). So one client per language makes
> >> sense. How's one each for Ruby, Python, Java, PHP, and Javascript (meaning
> >> client side only). We can consider things like XUL (Firefox extensions) if
> >> they come up.
> >> Thanks for kicking off the discussion.
> >>
> >> On Tue, Nov 30, 2010 at 11:17 AM, Michael Mayo <mike@xxxxxxxxxxxxx> wrote:
> >>>
> >>> I think it's a great place for language bindings.  After all, a language
> >>> binding is a client.  Perhaps we name the projects something like
> >>> openstack-binding-python, etc?
> >>>
> >>> I don't think we can or should enforce feature parity.  After all, some
> >>> platforms will have features that simply aren't possible for others.  (For
> >>> instance, I'm including syncing files from iTunes to Object Storage.  That's
> >>> only possible with iOS.)  But maybe there should be some minimum feature
> >>> level required, such as, I don't know, being able to actually launch an
> >>> instance :)
> >>>
> >>> My mindset is more to encourage choice.  At a charity I used to work at,
> >>> we once chose an inferior shopping cart app strictly because it was written
> >>> in Java.  This charity would be a prime candidate for running OpenStack as a
> >>> private cloud, and I'd hate for a place like that to reject OpenStack simply
> >>> because their web developers don't want to customize a Python/Django app.
> >>>
> >>> That said, I don't think we should run off and build 15 different web
> >>> control panels.  As for me, I will either focus primarily on Devin's NASA
> >>> version or the Ruby/Cappuccino version (if the Cappuccino guys really step
> >>> up), but not try to get in the way if someone tries to submit a Perl (or
> >>> whatever) version.  However, if someone else came in with another Django
> >>> app, I would be more in favor of merging than having two Django control
> >>> panels.
> >>>
> >>> On the flip side, we should come up with some way to enforce that the
> >>> clients continue to be supported.  Nova and Swift change a lot, and quickly,
> >>> so the client projects should remain active, or get off of Launchpad and go
> >>> live on someone's Github page.
> >>>
> >>> Do you guys agree?  And if you think I'm completely crazy, let me know :)
> >>>  Either way, this party is just getting started, and I think we'll figure it
> >>> out as we go along.
> >>>
> >>>
> >>>
> >>> On Nov 30, 2010, at 10:54 AM, Todd Willey wrote:
> >>>
> >>> > Is the clients project a place for language bindings to live, or just
> >>> > full-blown apps?
> >>> >
> >>> > I think having multiple frontends is fine, but are we going to enforce
> >>> > feature parity?  Also, are we going to drive their creation, or just
> >>> > offer a good home to anyone who actually wants to go out and create
> >>> > them?
> >>> >
> >>> > Congrats on your nuptials.
> >>> >
> >>> > -todd[1]
> >>> >
> >>> > On Tue, Nov 30, 2010 at 1:24 PM, Michael Mayo <mike@xxxxxxxxxxxxx>
> >>> > wrote:
> >>> >> Hi everyone!
> >>> >>
> >>> >> I'll start with some apologies.
> >>> >>
> >>> >> First off, I'm sorry for all the Launchpad mailing list confusion.  I
> >>> >> talked with Rick Clark (dendrobates) and we're going with a similar
> >>> >> structure as the nova and swift teams.  I removed everyone from the
> >>> >> openstack-client-maintainers group because being a member lets you change
> >>> >> things in Launchpad.  Of course, I trust all of you, but it makes more sense
> >>> >> to separate the groups in case someone malicious tries to join us later.
> >>> >>  Also, this makes things a bit less confusing.  If you object to any of
> >>> >> that, let me know!
> >>> >>
> >>> >> Second, I'm sorry (but not really) that I had to leave the Design
> >>> >> Summit early to go get married and go on my honeymoon.  While it was
> >>> >> certainly a joyous occasion, the timing was pretty bad with all the momentum
> >>> >> built up from us getting together in San Antonio.
> >>> >>
> >>> >> Now, on to business!
> >>> >>
> >>> >> The iOS client is looking great, and I've had some good contributions
> >>> >> from Joe Heck (heckj).  Thanks dude!
> >>> >>
> >>> >> Android is on hold, which I think is okay.  If anyone wants to step up
> >>> >> there, let me know :)
> >>> >>
> >>> >> And... the web:
> >>> >>
> >>> >> We're seeing a lot of web control panels out there, and it may be a
> >>> >> good idea to accept many of them.  I love Devin's control panel for NASA,
> >>> >> Scalr does a lot of really neat stuff, and Nachi's SimCloud prototype is
> >>> >> very exciting.  Also, the creators of Cappuccino have expressed interest in
> >>> >> maintaining the original web control panel prototype I created for the
> >>> >> Design Summit in Austin.
> >>> >>
> >>> >> I was talking to Bret Piatt (bret-piatt) yesterday, and he suggested
> >>> >> that we have web control panels for all (or most) of the popular languages.
> >>> >>  Since we're expecting a lot of enterprises to adopt OpenStack for their
> >>> >> private clouds, it would be good to offer control panels in as many
> >>> >> languages as possible so that IT/dev teams can choose one to
> >>> >> use/deploy/customize based on what they're good at.  A company full of Java
> >>> >> developers can use the Java version.  A cool startup can use the Python or
> >>> >> Ruby version, etc.
> >>> >>
> >>> >> What do you guys think of that?
> >>> >>
> >>> >> Mike Mayo
> >>> >> 901-299-9306
> >>> >> @greenisus
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >> _______________________________________________
> >>> >> Mailing list: https://launchpad.net/~openstack-clients-dev
> >>> >> Post to     : openstack-clients-dev@xxxxxxxxxxxxxxxxxxx
> >>> >> Unsubscribe : https://launchpad.net/~openstack-clients-dev
> >>> >> More help   : https://help.launchpad.net/ListHelp
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > CONFIDENTIALITY NOTICE:  This email is for sole use of intended
> >>> > recipient(s).  Unauthorized use is prohibited.
> >>>
> >>> Mike Mayo
> >>> 901-299-9306
> >>> @greenisus
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Mailing list: https://launchpad.net/~openstack-clients-dev
> >>> Post to     : openstack-clients-dev@xxxxxxxxxxxxxxxxxxx
> >>> Unsubscribe : https://launchpad.net/~openstack-clients-dev
> >>> More help   : https://help.launchpad.net/ListHelp
> >>
> >>
> >> Mike Mayo
> >> 901-299-9306
> >> @greenisus
> >>
> >>
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~openstack-clients-dev
> >> Post to     : openstack-clients-dev@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~openstack-clients-dev
> >> More help   : https://help.launchpad.net/ListHelp
> >>
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack-clients-dev
> > Post to     : openstack-clients-dev@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~openstack-clients-dev
> > More help   : https://help.launchpad.net/ListHelp
> >
> >
> 
> 
> 
> --
> CONFIDENTIALITY NOTICE:  This email is for sole use of intended
> recipient(s).  Unauthorized use is prohibited.
> 
> 

Mike Mayo
901-299-9306
@greenisus