Open Stack

John,

Thanks for the corrections.  Please join us as we discuss these topics.

It's important to restate that we're talking about commercial use of OpenStack and the ability to substitute is also a part of open source Apache 2 licensed products.  We're trying to give specific guidelines on how much instead of having the answer be "none" or "any."

Rob

> -----Original Message-----
> From: John Dickinson [mailto:me at not.mn]
> Sent: Monday, July 28, 2014 3:15 PM
> To: Hirschfeld, Rob
> Cc: Defcore-committee at lists.openstack.org
> Subject: Re: [OpenStack-DefCore] Update from Board Meeting, more
> meetings to schedule > please vote on doodles!
>
> Thanks for the update. I'd like to address one paragraph in particular
> from your attached PDF:
>
> "DefCore believes that Swift has required capabilities; however, we
> also recognize that 1) it is not modular code in Havana and 2) there
> are several commercial implementations of OpenStack that use
> alternatives to Swift but could/would pass the capabilities test."
>
> Specifically, the first point mentioned is incorrect. Swift is indeed
> "modular code", and it was so in the Havana release. One of the
> primary design goals in Swift is and always has been to abstract away
> storage volumes. The protocol Swift uses to speak to storage volumes
> is POSIX, and this capability has been in Swift since day one. It is
> and always has been possible for deployers to "swap out" the thing
> that Swift abstracts (namely, storage volumes). We've seen this demonstrated by deployers since day one.
>
> During the OpenStack Havana development cycle, the Swift community
> cleaned up some of this volume abstraction code. That refactoring
> cleaned up existing capabilities. Importantly, it did not add
> functionality but rather made existing functionality better. In fact,
> the refactoring that was written was to make an existing third-party
> implementations simpler (Swift on GlusterFS volumes and Seagate's Kinetic platform).
>
>
> The second point in the DefCore paragraph above seems to be
> immaterial. One of the founding principles of OpenStack is that the
> code is developed in the OpenStack community. From the perspective of
> "what is OpenStack?", it doesn't really matter if there are
> alternative implementations that are not managed and developed under
> the OpenStack governance umbrella--those things are not "OpenStack".
> This is echoing what Jonathan Bryce has said about OpenStack for quite some time. The "open" of OpenStack is what's important.
>
> --John
>
>
>
>
>
> On Jul 28, 2014, at 11:56 AM, Rob_Hirschfeld at Dell.com wrote:
>
> > All,
> >
> > I'm pleased to report that the board approved the advisory Havana
> capabilities
> (https://wiki.openstack.org/wiki/File:DefCore_Capabilities_Scoring.pdf
> ). Note that I added the TC feedback and set all remaining 0.5 scores
> to a conservative 0.
> >
> > I'm including the committee report we presented at the board
> > meeting. We
> spent some time prepping the board for the Designated Sections work
> and expect it to offered for approval at the September meeting.
> >
> > I'd like to post Doodles to get some meeting times over the next few
> > weeks including potential face to face meetings. First we need to
> > discuss/review the principles for selection (review)
> >
> > 1) Principles, This Week: (Thurs or Friday)
> http://doodle.com/75afaha3aypkybia
> > 2) Draft DS on Low Hanging Fruit, Next Week (have have to slide)
> http://doodle.com/zncaidywetn9qici
> > 3) Finish DS for review, Face to Face, 8/14 and/or 8/17
> http://doodle.com/giqhyd85mvtbick2
> >
> > Rob
> > ______________________________
> > Rob Hirschfeld
> > Sr. Distinguished Cloud Solution Architect Dell | Cloud Edge, Data
> > Center Solutions cell +1 512 909-7219 blog robhirschfeld.com,
> > twitter @zehicle Please note, I am based in the CENTRAL (-6) time
> > zone
> >
> >
> ____________________________
> ____
> > _______________
> > Defcore-committee mailing list
> > Defcore-committee at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committe
> > e
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140728/732f1b60/attachment.html>