<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">John,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks for the corrections. Please join us as we discuss these topics.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.” <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Rob<o:p></o:p></p>
<p style="margin-bottom:12.0pt">> -----Original Message-----<br>
> From: John Dickinson [mailto:me@not.mn]<br>
> Sent: Monday, July 28, 2014 3:15 PM<br>
> To: Hirschfeld, Rob<br>
> Cc: Defcore-committee@lists.openstack.org<br>
> Subject: Re: [OpenStack-DefCore] Update from Board Meeting, more <br>
> meetings to schedule > please vote on doodles!<br>
> <br>
> Thanks for the update. I'd like to address one paragraph in particular <br>
> from your attached PDF:<br>
> <br>
> "DefCore believes that Swift has required capabilities; however, we <br>
> also recognize that 1) it is not modular code in Havana and 2) there <br>
> are several commercial implementations of OpenStack that use <br>
> alternatives to Swift but could/would pass the capabilities test."<br>
> <br>
> Specifically, the first point mentioned is incorrect. Swift is indeed <br>
> "modular code", and it was so in the Havana release. One of the <br>
> primary design goals in Swift is and always has been to abstract away <br>
> storage volumes. The protocol Swift uses to speak to storage volumes <br>
> is POSIX, and this capability has been in Swift since day one. It is <br>
> and always has been possible for deployers to "swap out" the thing <br>
> that Swift abstracts (namely, storage volumes). We've seen this demonstrated by deployers since day one.<br>
> <br>
> During the OpenStack Havana development cycle, the Swift community <br>
> cleaned up some of this volume abstraction code. That refactoring <br>
> cleaned up existing capabilities. Importantly, it did not add <br>
> functionality but rather made existing functionality better. In fact, <br>
> the refactoring that was written was to make an existing third-party <br>
> implementations simpler (Swift on GlusterFS volumes and Seagate's Kinetic platform).<br>
> <br>
> <br>
> The second point in the DefCore paragraph above seems to be <br>
> immaterial. One of the founding principles of OpenStack is that the <br>
> code is developed in the OpenStack community. From the perspective of <br>
> "what is OpenStack?", it doesn't really matter if there are <br>
> alternative implementations that are not managed and developed under <br>
> the OpenStack governance umbrella--those things are not "OpenStack". <br>
> This is echoing what Jonathan Bryce has said about OpenStack for quite some time. The "open" of OpenStack is what's important.<br>
> <br>
> --John<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> On Jul 28, 2014, at 11:56 AM, Rob_Hirschfeld@Dell.com wrote:<br>
> <br>
> > All,<br>
> ><br>
> > I’m pleased to report that the board approved the advisory Havana<br>
> capabilities<br>
> (https://wiki.openstack.org/wiki/File:DefCore_Capabilities_Scoring.pdf <br>
> ). Note that I added the TC feedback and set all remaining 0.5 scores <br>
> to a conservative 0.<br>
> ><br>
> > I’m including the committee report we presented at the board <br>
> > meeting. We<br>
> spent some time prepping the board for the Designated Sections work <br>
> and expect it to offered for approval at the September meeting.<br>
> ><br>
> > I’d like to post Doodles to get some meeting times over the next few <br>
> > weeks including potential face to face meetings. First we need to <br>
> > discuss/review the principles for selection (review)<br>
> ><br>
> > 1) Principles, This Week: (Thurs or Friday)<br>
> http://doodle.com/75afaha3aypkybia<br>
> > 2) Draft DS on Low Hanging Fruit, Next Week (have have to slide)<br>
> http://doodle.com/zncaidywetn9qici<br>
> > 3) Finish DS for review, Face to Face, 8/14 and/or 8/17<br>
> http://doodle.com/giqhyd85mvtbick2<br>
> ><br>
> > Rob<br>
> > ______________________________<br>
> > Rob Hirschfeld<br>
> > Sr. Distinguished Cloud Solution Architect Dell | Cloud Edge, Data <br>
> > Center Solutions cell +1 512 909-7219 blog robhirschfeld.com, <br>
> > twitter @zehicle Please note, I am based in the CENTRAL (-6) time <br>
> > zone<br>
> ><br>
> ><br>
> ____________________________<br>
> ____<br>
> > _______________<br>
> > Defcore-committee mailing list<br>
> > Defcore-committee@lists.openstack.org<br>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committe<br>
> > e<o:p></o:p></p>
</div>
</body>
</html>