<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=iso-8859-1">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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:Consolas;
panose-1:2 11 6 9 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.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.5pt;
font-family:Consolas;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:Consolas;}
span.EmailStyle19
{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]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">One other thing I’d like to add on the Swift conundrum:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><i><span style="color:#1F497D">I went to the congress meetup and Martin Calado said something very interesting. Rough paraphrase: you can’t start to abstract the physical functions until you’ve virtualized them. For Nova, the virtualization
layer is the hypervisors. For Swift, it is the virtualization layer. So really, Swift is layer 0. Which makes it really important but not always necessary. But it also makes it valuable to people who don’t want the cloud abstraction but still want the
virtualization of its datacenter hardware.</span></i></b><span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">--rocky<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<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""> Rochelle.RochelleGrober [mailto:rochelle.grober@huawei.com]
<br>
<b>Sent:</b> Wednesday, September 24, 2014 5:55 PM<br>
<b>To:</b> John Dickinson<br>
<b>Cc:</b> Defcore-committee@lists.openstack.org<br>
<b>Subject:</b> Re: [OpenStack-DefCore] Suggestions on trademark changes, possible meeting 10/2 or earlier<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">-----Original Message-----<br>
From: John Dickinson [mailto:me@not.mn] <br>
Sent: Tuesday, September 23, 2014 8:41 PM<br>
To: Rochelle.RochelleGrober<br>
Cc: Rob_Hirschfeld@Dell.com; joshua@pistoncloud.com; simon@dreamhost.com; Defcore-committee@lists.openstack.org<br>
Subject: Re: [OpenStack-DefCore] Suggestions on trademark changes, possible meeting 10/2 or earlier<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">On Sep 23, 2014, at 12:06 PM, Rochelle.RochelleGrober <rochelle.grober@huawei.com> wrote:<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">> Taking up the gauntlet.<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">> <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">> What I heard from the board meeting was:<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">> <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">> DefCore did and is doing what it is supposed to do: Identify mature, critical widespread OpenStack functionality and corresponding code that represents the foundational pieces of the OpenStack contributions
for a specific release; identify tests which would certify these foundational components. No politics. All technical. What DefCore is really saying about these parts identified by DefCore is that they are community vetted, tested under fire, in the wild,
and represent the solid and mature parts of OpenStack; these identified parts can be trusted. Well, as well as they are tested. We might want to change bug priorities in the projects such anything affecting identified core functionality/code gets marked
critical and gets fixed first, but that’s another issue.<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">> <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">> <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">> Now, these foundational components are just that, components. As the tent expands, we’ll have a lot more components that meet the 12 aspects of foundational and yet will be able to operate exclusive of much
or all of the rest of the OpenStack integrated releases. So, we need to step forward with a plan that takes these realities into account. But what DefCore is really saying is that these parts identified by DefCore are community vetted, tested under fire,
in the wild and are important.<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">> <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">> We appear to be most of the way to a solution with the full distro and the standalone components (but not the names):<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">> · OpenStack distro (OpenStack full stack??? Certified OpenStack? Whole OpenStack?)<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">> · OpenStack component(powered by OpenStack XXX?)<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">> But the hard part is the mostly got it all parts or when other stuff is added to what would be considered an OpenStack product or distro.<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">I agree completely here. The first time I heard this idea was from Josh, and I think it's fantastic. Having one mark that calls the integrated release[1] "OpenStack" answers the main concern I've heard so far:
calling some subset of the integrated release "openstack" (or at least labeling a subset group as a thing above other subsets).<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">Naming is hard, and unfortunately in this case, the names matter more than normal. FWIW, I like both "distro" and "full stack".<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">I also think that the idea of a second "components" mark helps answer the concerns of people who are shipping products that include a subset of the integrated release. This mark allows products to be accurately
branded so as to promote interop (deployers and end-users know what's on the inside).<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">Importantly, the existing DefCore process work can be applied to these two proposed concepts. Basically, all of the capabilities and sections defined in the recent board proposal still apply. There are two high-level
parts to finish. First, define capabilities and sections for the other projects in the integrated release. Second, slightly tweak the final proposal to match the proposed marks. That is, instead of proposing "here is your OpenStack mark definition", it would
look something like "here's the buffet of capabilities and code--if you use everything, use mark A, otherwise mark B".<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">> <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">> So, how about we define the third mark as: it is built on the DefCore identified code and contains no extensions or new code that displaces any of the DefCore identified set of functionality/code. This would
allow for:<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">> · Powered by OpenStack<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">> · Built on OpenStack<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">> · OpenStack Solid<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">> · Etc<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">I'm a little unclear on what this third mark adds. My understanding of the other two proposed marks (as I stated above) is that they would use the DefCore process. So this proposed mark seems to be defining a
subset of the first mark as a thing. That was (my understanding of) the biggest roadblock to the board proposal, so I'd like to hear some more explanation of this.<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><span style="color:black">[Rocky Grober]
<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:1.0in"><span style="color:black">Let’s see if I can make this third point more clear. Defcore identifies capabilities *<b>and</b>* code that are mature and well used in the outside world. Right now, in Havana, capabilities
include nova and swift which is the crux of the definition issue as you can use either one without the other. But when you are not including the other, there could/should still be a more overarching mark than just the “OpenStack Swift” or “OpenStack Nova”
if you are using the OpenStack framework and not *<b>replacing</b>* OpenStack project(s) with proprietary or non-OpenStack projects.<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:1.0in"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:1.0in"><span style="color:black">So, here’s a couple of examples:<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:1.0in"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:1.0in"><span style="color:black">Nova/Glance/Swift
</span><span style="font-family:Wingdings;color:black">à</span><span style="color:black"> Powered by OpenStack<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:1.0in"><span style="color:black">Nova/Glance/Ceph (used as ObjectStore)
</span><span style="font-family:Wingdings;color:black">à</span><span style="color:black"> OpenStack Nova, OpenStack Glance – no general mark<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:1.0in"><span style="color:black">Nova/Glance/Swift/Cinder+Ceph
</span><span style="font-family:Wingdings;color:black">à</span><span style="color:black"> Powered by OpenStack – addition of Ceph does not replace an existing OpenStack integrated project<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:1.0in"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:1.0in"><span style="color:black">Swift/Keystone
</span><span style="font-family:Wingdings;color:black">à</span><span style="color:black"> Powered by OpenStack<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:1.0in"><span style="color:black">Swift/keystone/CloudStack
</span><span style="font-family:Wingdings;color:black">à</span><span style="color:black"> OpenStack Swift, OpenStack Keystone – no general mark<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:1.0in"><span style="color:black">Swift/keystone/trove/mongoDB
</span><span style="font-family:Wingdings;color:black">à</span><span style="color:black"> Powered by OpenStack – MongoDB doesn’t replace any OpenStack integrated project<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:1.0in"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:1.0in"><span style="color:black">Now these examples are a bit stilted, but you I think you can better get what I am trying to say. You can’t use a general OpenStack Mark if you use a replacement code set for any function
of an OpenStack “Core” capability set.<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:1.0in"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:1.0in"><span style="color:black">Any clearer?<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:1.0in"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:1.0in"><span style="color:black">--Rocky<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:1.0in"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:1.0in"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:1.0in"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:1.0in"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:.5in">--John<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">[1] I know that there are current discussions on the -dev mailing list and among the TC that may end up with getting away from something being called the "integrated release". I'm using the word "integrated release"
here because that's what it's been called so far and as a stand in for whatever the TC ends up with as the set of projects falling under OpenStack governance.<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p> </o:p></p>
</div>
</body>
</html>