openstack-clients-dev team mailing list archive

[Sebastian Stadil <sebastian@xxxxxxxxx>]

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.
>