<html>
<head>
</head>
<body>
<div style="font-family: arial, sans-serif;">
<p
style="color: black; font-family: Arial, sans-serif; margin: 0 0 1em 0;">+1</p>
<div style="font-family: arial, sans-serif;">
<p
style="color: black; font-size: 10pt; font-family: Arial, sans-serif; margin: 10pt 0;">On
September 12, 2014 3:34:42 PM Doug Hellmann <doug@doughellmann.com>
wrote:</p>
<blockquote type="cite" class="gmail_quote"
style="margin: 0 0 0 0.75ex; border-left: 1px solid #808080; padding-left: 0.75ex;"><br><div><div>On
Sep 12, 2014, at 9:55 AM, Mark Collier <<a
href="mailto:mark@openstack.org">mark@openstack.org</a>> wrote:</div><br
class="Apple-interchange-newline"><blockquote type="cite">
<div>
<div style="font-family: arial, sans-serif;"><p
style="font-family: Arial, sans-serif; margin: 0px 0px 1em;">I
think your reasoning is sound, provided we don't make it harder to follow
through on "phase 2" of your proposal in icehouse by conceding the removal
of a requirement that is intended to be quickly re-added.
</p></div></div></blockquote><div>That’s a fair point. I understood the
intent of the DefCore process to be to start small and slowly add to the
set of capabilities for subsequent releases, and adding object storage
capabilities and Swift designated sections seems to fit within that
process.</div><br><blockquote type="cite"><div><div
style="font-family: arial, sans-serif;"><p
style="font-family: Arial, sans-serif; margin: 0px 0px 1em;">Inertia
being a thing that can cause such unintended
consequences.</p></div></div></blockquote><div>Indeed, if we think there
will be a problem adding Swift later, either to a single core trademark or
using a separate “OpenStack Object Storage” trademark, or in some other way
that the developer community, distros, deployers, and other parties can all
stand behind, then I would have to revert to my original stance and support
the TC assertion that we should not have designated sections and should be
including everything from the beginning. I don’t think that’s the
situation, though, and I appreciate the desire to start from a small core
and iterate precisely to reduce the unintended consequences of making big
decisions quickly.</div><br><blockquote type="cite"><div><div
style="font-family: arial, sans-serif;"><p
style="font-family: Arial, sans-serif; margin: 0px 0px 1em;">Openstack
is software, which we as a community create (though heroic efforts which I
can't claim credit for myself! But admire, encourage, and support all that
much more as a beneficiary of those efforts). </p><p
style="font-family: Arial, sans-serif; margin: 0px 0px 1em;">OpenStack
is an OpenSource Cloud Computing platform that meets the needs of public
and private clouds regardless of size, by being simple to implement and
massively scalable.</p><p
style="font-family: Arial, sans-serif; margin: 0px 0px 1em;">Our
mission to produce it. </p><p
style="font-family: Arial, sans-serif; margin: 0px 0px 1em;"> I
always find out mission statement a handy reminder when trying to make such
weighty decisions. <br>
<a
href="https://wiki.openstack.org/wiki/Main_Page">https://wiki.openstack.org/wiki/Main_Page</a></p><p
style="font-family: Arial, sans-serif; margin: 0px 0px 1em;">(Note
I took the poetic license to change "will meet" to "meets" now that we are
4 years in and the largest banks in the world run it. Whether we've
yet achieved 'simple to implement' or 'massively scalable' is an exercise
left to the reader.)<br><br><br><br><br><br><br><br><br><br></p>
<div style="font-family: arial, sans-serif;"><p
style="font-size: 10pt; font-family: Arial, sans-serif; margin: 10pt 0px;">On
September 12, 2014 2:38:44 PM Doug Hellmann <<a
href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>>
wrote:</p>
<blockquote type="cite" class="gmail_quote"
style="margin: 0 0 0 0.75ex; border-left: 1px solid #808080; padding-left: 0.75ex;"><div>The
point I have been trying to make is that because our community creates code
and not standards, we should not simply trademark an API without including
the implementation. For Swift, that means leaving the capabilities out
entirely for Havana because we are, for better or worse, leaving the code
out entirely. The net effect would be to say that your OpenStack cloud or
distribution does not need to include object storage at all, or you can
include an object storage system other than Swift without applying the
OpenStack trademark to it. That seems to be what at least some of the
distributors and deployers want, and seems like a reasonable compromise
until we can decide on whether multiple trademark designations solve the
problem in a different way.</div><div><br></div><div>If we take this route,
we will need to look at the non-designated sections of code for all of the
projects to ensure they do not represent the entire implementation of any
of the capabilities (I think probably not, but I haven’t audited the list
myself).</div><div><br></div><div>I hope we can re-evaluate Swift when we
look at the Icehouse version of DefCore, because I would prefer to see all
of our integrated projects included in core, but moving ahead without
object storage is a better solution than requiring an API and essentially
allowing someone to use our name on their
code.</div><div><br></div><div>Doug</div><br><div><div>On Sep 11, 2014, at
5:44 PM, Joshua McKenty <<a
href="mailto:joshua@pistoncloud.com">joshua@pistoncloud.com</a>>
wrote:</div><br class="Apple-interchange-newline"><blockquote
type="cite"><meta http-equiv="content-type"
content="text/html; charset=utf-8"><div dir="auto"><div>I don't see that
symmetry, but I'm still +1 for the discussion with the
board. <br><br>Sent from my iPhone</div><div><br>On Sep 11, 2014, at
2:23 PM, "Rochelle.RochelleGrober" <<a
href="mailto:rochelle.grober@huawei.com">rochelle.grober@huawei.com</a>>
wrote:<br><br></div><blockquote type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"Trebuchet MS";
panose-1:2 11 6 3 2 2 2 2 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.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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]-->
<div class="WordSection1"><p class="MsoNormal"><span
style="color:#1F497D">+1<o:p></o:p></span></p><div><span
style="color:#1F497D"> </span><br
class="webkit-block-placeholder"></div><p class="MsoNormal"><span
style="color:#1F497D">It makes so much sense once the symmetry was pointed
out:<o:p></o:p></span></p><p class="MsoNormal"><span
style="color:#1F497D">If there are no required capabilities, then there is
no designated code.<o:p></o:p></span></p><p class="MsoNormal"><span
style="color:#1F497D">If there is no designated code, then there are no
required capabilities.<o:p></o:p></span></p><div><span
style="color:#1F497D"> </span><br
class="webkit-block-placeholder"></div><p class="MsoNormal"><span
style="color:#1F497D">--Rocky<o:p></o:p></span></p><div><span
style="color:#1F497D"> </span><br class="webkit-block-placeholder"></div>
<div>
<div
style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"><p
class="MsoNormal" style="margin-left:.5in"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
Auld, Will [<a
href="mailto:will.auld@intel.com">mailto:will.auld@intel.com</a>]
<br>
<b>Sent:</b> Thursday, September 11, 2014 1:49 PM<br>
<b>To:</b> <a
href="mailto:Rob_Hirschfeld@Dell.com">Rob_Hirschfeld@Dell.com</a>; <a
href="mailto:Defcore-committee@lists.openstack.org">Defcore-committee@lists.openstack.org</a><br>
<b>Subject:</b> Re: [OpenStack-DefCore] Results from Community Meetings
> discussion/+1 about reconsidering Havana Swift as a core
capability<o:p></o:p></span></p>
</div>
</div><p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p><p
class="MsoNormal" style="margin-left:.5in"><span style="color:#1F497D">+1 <o:p>
</o:p></span></p><div style="margin-left: 0.5in;"><span
style="color:#1F497D"> </span><br class="webkit-block-placeholder"></div>
<div
style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div
style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"><p
class="MsoNormal" style="margin-left:.5in"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a href="mailto:Rob_Hirschfeld@Dell.com">Rob_Hirschfeld@Dell.com</a> [<a
href="mailto:Rob_Hirschfeld@Dell.com">mailto:Rob_Hirschfeld@Dell.com</a>]
<br>
<b>Sent:</b> Thursday, September 11, 2014 1:35 PM<br>
<b>To:</b> <a
href="mailto:Defcore-committee@lists.openstack.org">Defcore-committee@lists.openstack.org</a><br>
<b>Subject:</b> [OpenStack-DefCore] Results from Community Meetings >
discussion/+1 about reconsidering Havana Swift as a core
capability<o:p></o:p></span></p>
</div>
</div><p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p><p
class="MsoNormal" style="margin-left:.5in">DefCore,<o:p></o:p></p><p
class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p><p
class="MsoNormal" style="margin-left:.5in">We just completed our two
community meetings. Community attendance was light but the dialogs
where good.<o:p></o:p></p><p class="MsoNormal"
style="margin-left:.5in"><o:p> </o:p></p><p class="MsoNormal"
style="margin-left:.5in">I am still working to get input from the PTLs
against the designated sections; however, I do not think that we are
blocked at this point with the following consideration:
<b>Swift capabilities should not be considered core for
Havana</b>.<o:p></o:p></p><p class="MsoNormal"
style="margin-left:.5in"><o:p> </o:p></p><p class="MsoNormal"
style="margin-left:.5in">I have gotten significant and consistent feedback
that the two Swift capabilities should not be included in Havana
Core. This has come from multiple sources, a variety of interests,
and different reasons were given.
<o:p></o:p></p><p class="MsoNormal"
style="margin-left:.5in"><o:p> </o:p></p><p class="MsoNormal"
style="margin-left:.5in">The final straw came today during community review
of Swift when the point was made (by Doug Hellman) that if there are no
designated sections that having required capabilities does not make
sense.<o:p></o:p></p><p class="MsoNormal"
style="margin-left:.5in"><o:p> </o:p></p><p class="MsoNormal"
style="margin-left:.5in">While people arrive at this conclusion in
different ways, I am confident in saying that community consensus is to
reconsider Swift core capabilities.<o:p></o:p></p><p class="MsoNormal"
style="margin-left:.5in"><o:p> </o:p></p><p class="MsoNormal"
style="margin-left:.5in">I’d like your opinion (and/or +1) on presenting
this to the board on Thursday _<i>before</i>_ discussing the details of
designated sections and process flow. I believe this change will
greatly simplify the discussion
and allow us to proceed with the DefCore process and
results.<o:p></o:p></p><p class="MsoNormal"
style="margin-left:.5in"><o:p> </o:p></p><p class="MsoNormal"
style="margin-left:.5in">Thanks,<o:p></o:p></p><p class="MsoNormal"
style="margin-left:.5in"><o:p> </o:p></p><p class="MsoNormal"
style="margin-left:.5in"><span
style="font-size:10.0pt;font-family:"Trebuchet MS","sans-serif";color:#444444">Rob<o:p></o:p></span></p><p
class="MsoNormal" style="margin-left:.5in"><b><span
style="font-size:10.0pt;font-family:"Trebuchet MS","sans-serif";color:#444444">______________________________<o:p></o:p></span></b></p><p
class="MsoNormal" style="margin-left:.5in"><b><span
style="font-size:10.0pt;font-family:"Trebuchet MS","sans-serif";color:#444444">Rob
Hirschfeld<o:p></o:p></span></b></p><p class="MsoNormal"
style="margin-left:.5in"><span
style="font-size:8.0pt;font-family:"Trebuchet MS","sans-serif";color:#444444">Dell,
Sr. Distinguished Cloud Solution Architect<o:p></o:p></span></p><p
class="MsoNormal" style="margin-left:.5in"><b><span
style="font-size:8.0pt;font-family:"Trebuchet MS","sans-serif";color:#444444">cell</span></b><span
style="font-size:8.0pt;font-family:"Trebuchet MS","sans-serif";color:#AAAAAA">
</span><span
style="font-size:8.0pt;font-family:"Trebuchet MS","sans-serif";color:#444444">+1
512 909-7219
<b>blog</b> <a href="http://robhirschfeld.com/">robhirschfeld.com</a>,
<b>twitter</b> @zehicle<o:p></o:p></span></p><p class="MsoNormal"
style="margin-left:.5in"><span
style="font-size:8.0pt;font-family:"Trebuchet MS","sans-serif";color:#444444">Please
note, I am based in the CENTRAL (-6) time zone
<o:p></o:p></span></p><p class="MsoNormal"
style="margin-left:.5in"><o:p> </o:p></p>
</div>
</div>
</blockquote><blockquote
type="cite"><span>_______________________________________________</span><br><span>Defcore-committee
mailing list</span><br><span><a
href="mailto:Defcore-committee@lists.openstack.org">Defcore-committee@lists.openstack.org</a></span><br><span><a
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee">http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee</a></span><br></blockquote></div>_______________________________________________<br>Defcore-committee
mailing list<br><a
href="mailto:Defcore-committee@lists.openstack.org">Defcore-committee@lists.openstack.org</a><br><a
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee">http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee</a><br></blockquote></div><br>
_______________________________________________<br>
Defcore-committee mailing list<br>
<a
href="mailto:Defcore-committee@lists.openstack.org">Defcore-committee@lists.openstack.org</a><br>
<a class="aqm-autolink aqm-autowrap"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee">http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee</a><br>
<br></blockquote>
</div>
</div>
</div>
</blockquote></div><br></blockquote>
</div>
</div>
</body>
</html>