Open Stack

Hi Rob,

Thank you for the reply.  The project usage data from the last user survey
(e.g. here
<http://a2.res.cloudinary.com/hqq9ey1mh/image/upload/c_limit,w_793/v1414983197/c4ctuijd67tmq4yfqtdc.png>)
only shows services (and not API sets) being used by the respondents.  If
we were to compare the 70% adoption (and I know it was just a number you
threw out) against survey data then Nova, Glance, Keystone, Horizon, and
Cinder would be the only projects.  I agree that the data from test reports
will be needed before we can discuss further, i'll reinitiate the
conversation at a later date.

Thanks,
Shamail Tahir
Cloud Architect, EMC
t: @ShamailXD
tz: Eastern

On Sun, Mar 1, 2015 at 1:40 PM, Rob Hirschfeld <rob at rackn.com> wrote:

>  Shamail,
>
> I think that needs to be a subject of discussion once we start getting
> some data.
>
> My gut is that we'd want to see at least 70% penetration of a API set.
> That means that in 70% of the reports, we see 100% passing of the tests in
> the capability.  Said another way, 7 out of 10 OpenStack implementations
> (reporting results) would have that capability in a fully functioning way.
>
> I don't know if that's the right cut off - the only way to know is to
> compare it against other capabilities.  I am very confident that we'll see
> a clear in/out range once we start collecting data.  I just don't know the
> actual %.
>
> I hope that helps.
>
> Rob
>
>
> On 02/27/2015 12:43 PM, Shamail wrote:
>
> How do we define "broad adoption"?  Should we state some threshold or
> criteria or will it be subjective for now?
>
>  Thanks,
> Shamail
>
>
>
> On Feb 27, 2015, at 12:03 PM, Rob Hirschfeld <rob at zehicle.com> wrote:
>
>   YES!  very very well said.
>
> On 02/27/2015 10:38 AM, Barrett, Carol L wrote:
>
>  Thanks Rob – so when capabilities become accepted in the market Defcore
> ensures support for them moving forward, until it’s no longer appropriate.
>
>
>
> I’ll take up my branding concerns with the marketing side of the house.
>
> Carol
>
>
>
> *From:* Rob Hirschfeld [mailto:rob at zehicle.com <rob at zehicle.com>]
> *Sent:* Friday, February 27, 2015 8:36 AM
> *To:* Barrett, Carol L; Rob Hirschfeld; Shamail
> *Cc:* defcore-committee at lists.openstack.org
> *Subject:* Re: [OpenStack-DefCore] Trying to explain Guidelines... here's
> what I'm thinking [feedback welcome]
>
>
>
> Carol,
>
> DefCore can't.  IMHO, it one of Vendors' roles to select, validate and
> support new capabilities.  DefCore comes along after those capabilities are
> broadly adopted.  It would be an anti-pattern if we selected capabilities
> that were only in one or two products/distros.
>
> The reason to move away from releases was to decouple this exact
> discussion.  DefCore is not about features in releases but long term
> capabilities of the platform.
>
> Rob
>
> On 02/27/2015 10:00 AM, Barrett, Carol L wrote:
>
> Rob – With my Branding hat on, it’s less about API uptake and more about
> the connotation of the Brand on a release. If the OpenStack Brand on a
> distro means a promise of quality, interoperability and backward
> compatibility how can we deliver on that for new capabilities without
> having evaluated them and ensure there’s appropriate testing?
>
>
>
> Carol
>
>
>
> *From:* Rob Hirschfeld [mailto:rob at zehicle.com <rob at zehicle.com>]
> *Sent:* Thursday, February 26, 2015 4:41 PM
> *To:* Barrett, Carol L; Rob Hirschfeld; Shamail
> *Cc:* defcore-committee at lists.openstack.org
> *Subject:* Re: [OpenStack-DefCore] Trying to explain Guidelines... here's
> what I'm thinking [feedback welcome]
>
>
>
> Carol,
>
> Let me turn that around.  If a project released new capabilities out of
> cycle, how quickly would you expect them to surface into the DefCore
> guidelines?
>
> By design, we select for widely-used APIs.  So, how fast should we expect
> a new feature to get wide adoption.
>
> Rob
>
> On 02/26/2015 03:48 PM, Barrett, Carol L wrote:
>
> I expect that the unpredictability of project releases will create
> challenges in many ways. Branding is one of them – if a project releases
> new capabilities out of cycle to the core-projects release of the Defcore
> definition update, those new features will not be covered by the Brand
> (which means they haven’t been validated to a certain level nor is there
> any backward API compatibility promise). How will an end-user know that?
> If the Brand doesn’t simplify the purchasing process for the end-user, then
> we’re not on the right track..imho.
>
>
>
> *From:* Rob Hirschfeld [mailto:rob at rackn.com <rob at rackn.com>]
> *Sent:* Thursday, February 26, 2015 1:42 PM
> *To:* Shamail
> *Cc:* Barrett, Carol L; defcore-committee at lists.openstack.org
> *Subject:* Re: [OpenStack-DefCore] Trying to explain Guidelines... here's
> what I'm thinking [feedback welcome]
>
>
>
> Good questions.  We're including which releases are covered in each
> guideline so, for example, you can track DefCore 2015.07 to the I,J & K
> releases.  You can't use that guideline against H or L
>
>
>
> On Thu, Feb 26, 2015 at 3:38 PM, Shamail <itzshamail at gmail.com> wrote:
>
> Hi Carol,
>
> I agree with the concern but I think (I didn't attend the F2F) some of
> this may be driven by the fact that we don't necessarily have a concrete
> definition of what a release may look like in the future.
>
> If the releases (due to project structure reform) end up having a cadence
> with a usual group of components then I could see aligning with releases
> but I think some of that is TBD at this point, therefore this seems like a
> safe bet.
>
> Thanks,
> Shamail
>
>
>
> > On Feb 26, 2015, at 3:52 PM, Barrett, Carol L <carol.l.barrett at intel.com>
> wrote:
> >
> > I am concerned about achieving the Brand goal,  using a month/year
> approach rather than a release approach. Is the expectation that a vendor
> will pull the upstream  for the month/year Defcore test and ship a
> product?  If a vendor release cycle is offset by 2 months, what would use
> to validate their Brand compliance? My thought is by that time new things
> will be included in a variety of projects that will be included in the
> Vendor release but not comprehended in the 2 month old Defcore definition.
> >
> > Carol
> >
> > -----Original Message-----
> > From: Rob Hirschfeld [mailto:rob at zehicle.com]
> > Sent: Thursday, February 26, 2015 11:37 AM
> > To: defcore-committee at lists.openstack.org
> > Subject: Re: [OpenStack-DefCore] Trying to explain Guidelines... here's
> what I'm thinking [feedback welcome]
> >
> > Chris Lee pinged me about missing a note Component & Platform levels.
> > We need to include that in the Guidelines.
> >
> > Good catch Chris!
> >
> >> On 02/26/2015 12:46 PM, Rob Hirschfeld wrote:
> >> DefCore... does this explain Guidelines?
> >>
> >> Last week, the OpenStack DefCore committee rolled up our collective
> >> sleeves and got to work in a serious way.  We had a in-person meeting
> >> with great turn out with 5 board members, Foundation executives/staff
> >> and good community engagement.
> >>
> >> TL;DR > We think DefCore should dated milestone guidelines instead
> >> tightly coupled to release events (see graphic
> >> https://robhirschfeld.files.wordpress.com/2015/02/defcore-timeline1.png
> ).
> >>
> >> DefCore has a single goal expressed from two sides: 1) defining the
> >> "what is OpenStack" brand for Vendors and 2) driving interoperability
> >> between OpenStack installations.  From that perspective, it is not
> >> about releases, but about testable stable capabilities.  Over time,
> >> these changes should be incremental and, most importantly, trail
> >> behind new features that are added.
> >>
> >> For those reasons, it was becoming confusing for DefCore to focus on
> >> an "Icehouse" definition when most of the capabilities listed are
> >> "Havana" ones.  We also created significant time pressure to get the
> >> "Kilo DefCore" out quickly after the release even though there were no
> >> "Kilo" specific additions covered.
> >>
> >> In the face-to-face, we settled on a more incremental approach.
> >> DefCore would regularly post a set of guidelines for approval by the
> >> Board.  These Guidelines would include the required, deprecated
> >> (leaving) and advisory (coming) capabilities required for Vendors to
> >> use the mark (see footnote*).  They would also include the relevant
> >> designated sections.  These Guidelines would use the open draft and
> >> discussion process that we are in the process of outlining for
> >> approval in Vancouver.
> >>
> >> Since DefCore Guidelines are simple time based lists of capabilities,
> >> the vendors and community can simply reference an approved Guideline
> >> using the date of approval (for example DefCore 2015.03) and know
> >> exactly what was included.  While each Guideline stands alone, it is
> >> easy to compare them for incremental changes.
> >>
> >> We've been getting positive feedback about this change; however, we
> >> are still discussing it appreciate your input and questions. It is
> >> very important for us to make DefCore simple and easy.  For that, your
> >> confused looks and WTF? comments are very helpful.
> >>
> >> * footnote: the Foundation manages that process the Vendors. DefCore
> >> Guidelines are just one part of the brand process.
> >
> > --
> >
> >
> > Rob
> > ____________________________
> > Rob Hirschfeld, 512-773-7522
> >
> > I am in CENTRAL (-6) time
> > http://robhirschfeld.com
> > twitter: @zehicle, github: cloudedge & ravolt
> >
> >
> > _______________________________________________
> > Defcore-committee mailing list
> > Defcore-committee at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
> >
> > _______________________________________________
> > Defcore-committee mailing list
> > Defcore-committee at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
>
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
>
>
>
>
>
> --
>
> Rob
> ____________________________
> Rob Hirschfeld, 512-773-7522
> RackN CEO/Founder (rob at rackn.com)
>
> I am in CENTRAL (-6) time
> http://robhirschfeld.com
> twitter: @zehicle, github: cloudedge & ravolt
>
>
>
>
>
>  _______________________________________________
>
> Defcore-committee mailing list
>
> Defcore-committee at lists.openstack.org
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
>
>
>
>
>  --
>
>
>
>
>
> Rob
>
> ____________________________
>
> Rob Hirschfeld, 512-773-7522
>
>
>
> I am in CENTRAL (-6) time
>
> http://robhirschfeld.com
>
> twitter: @zehicle, github: cloudedge & ravolt
>
>
>
>  --
>
>
>
>
>
> Rob
>
> ____________________________
>
> Rob Hirschfeld, 512-773-7522
>
>
>
> I am in CENTRAL (-6) time
>
> http://robhirschfeld.com
>
> twitter: @zehicle, github: cloudedge & ravolt
>
>
> --
>
>
> Rob
> ____________________________
> Rob Hirschfeld, 512-773-7522
>
> I am in CENTRAL (-6) timehttp://robhirschfeld.com
> twitter: @zehicle, github: cloudedge & ravolt
>
>
> --
>
>
> Rob
> ____________________________
> Rob Hirschfeld, 512-773-7522
>
> RackN CEO, Founder
>
> I am in CENTRAL (-6) timehttp://robhirschfeld.com
> twitter: @zehicle, github: cloudedge & ravolt
>
>


-- 
Thanks,
Shamail Tahir
Cloud Architect, EMC
t: @ShamailXD
tz: Eastern Time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20150303/44e268c1/attachment-0001.html>