Open Stack

Oops.  Forgot to include the WG

From: Rochelle Grober
Sent: Monday, January 19, 2015 5:40 PM
To: 'Shamail Tahir'
Subject: RE: [Product] Reference Architectures

Small Cloud Reference Architecture

Here’s the operators’ thread to follow:
http://lists.openstack.org/pipermail/openstack-operators/2014-December/005759.html
and it continued into the new year…
http://lists.openstack.org/pipermail/openstack-operators/2015-January/005833.html

As you can see on the first email, the discussion originally was around a minimal set of requirements to just have the cloud up and working, but then it morphs a bit into a small, functional cloud, and that’s what I think we want.  I think it has veered a little bit off topic for us, but it seems to me, this discussion is really about a “typical” small cloud installation, and I bet we could get the devs to focus on what would comprise a reference architecture for a “small cloud”.  Yeah, it won’t meet everyone’s needs, but it would get a person working.  Ops tend to work from an example then start tweaking.  What we want to provide is the example that  works and is tweakable for a good number of small cloud use cases.

And Shamal, I provided the thread references so you can start on your compilation.  I think collecting up what the Ops seem to agree on and asking them how they would tweak it for a general installation small cloud might be a good starting point in the discussion.    And cc the ETW group?  Maybe ask for the use cases this would solve or solve to a 80% or 90% point?

--Rocky

From: Shamail Tahir [mailto:itzshamail at gmail.com]
Sent: Monday, January 19, 2015 5:12 PM
To: Roland Chan
Cc: Rochelle Grober; product-wg at lists.openstack.org
Subject: Re: [Product] Reference Architectures

@Rocky:

I agree that we could look at what these initiatives are currently targeting and defining as reference architectures as a starting point.  I believe that even if these teams work on building out RAs, we should keep in touch with them since we could gleam insights that play into the "2-3 year architecture/use case" discussion that we may be having.  Unfortunately, I don't think either group is far enough along in the process to provide feedback during this mid-cycle meetup.  We should definitely consider going through their findings at our next meetup.

By the way, I would be happy to help compile the information if there is interest in covering what some of these other WGs are planning for 2015.

As a side-note, I have put my name on the list to help write some of the user reference architectures in WTE (although I don't know if I will be taken up on the offer yet) and I also recently joined the HA Guide Update team.

@Roland:
I agree that it will be a balancing act.  If the RA is defined as "ready to operate" (for a very specific combination) then the burden of delivering the necessary variants will probably be very significant.  These would be very meaningful to organization deploying the exact combination but relevance would be minimal to the large part of the market.

On the other hand, if we build something too "high-level" then it might be relegated to being a good read only for basic/introductory level of understanding.

I like the approach you mentioned about focusing on attributes needed for cloud consumption as the theme for a particular reference architecture might be the right "level" of broadness/specificity to target (e.g. HA OpenStack Clouds, Federated Clouds, Considerations for providing multiple service levels within a cloud, etc.)  We can discuss our definition of "RA" at some point and then see how it aligns with actual initiatives that are in-flight.

Thanks,
Shamail


On Mon, Jan 19, 2015 at 6:43 PM, Roland Chan <roland at aptira.com<mailto:roland at aptira.com>> wrote:
An architecture that is "ready to operate" could be one of a fairly large number of valid combinations of components, which I think dilutes the value of the reference architecture(s) significantly.

In my view the trick here will be to define the boundaries of the reference architecture such that it can plug into the various ancillary components required to make it operable. That definition should be based on capability, starting with the OpenStack core definition presumably, but then what should be included?

- HA
- Which of the integrated capabilities outside of defcore should go in? Perhaps none is the simplest answer, but not necessarily a useful one for consumers of the RA. Neutron? Horizon?
I would specifically exclude:

- deployment, beyond the simplest goal of getting the reference architecture running
- monitoring
- any other lifecycle management capabilities

on the grounds that there are too many types of solutions to fit within the concept of a reference architecture, and also to avoid descending into the rabbit-hole of individual preferences. The nascent "Operations Project" aims to provide options in the key areas, and I would prefer to leave it to them and anyone else tackling specific use cases.

​​
Roland



On 20 January 2015 at 08:51, Rochelle Grober <rochelle.grober at huawei.com<mailto:rochelle.grober at huawei.com>> wrote:
Shamail [mailto:itzshamail at gmail.com<mailto:itzshamail at gmail.com>], Monday, January 19, 2015 12:51 PM wrote:

Hi Rocky,

I changed the topic to separate the voting from the RA topic that you mentioned.  I think it's a good idea but I would be glad to share a "user reference architecture" initiative that the WTE (Win The Enterprise) WG is planning to work on ASAP.  This concept is slightly different from what you described below since these reference architectures will be driven by customer deployment examples versus prescribed architectures given scale or projects.  I'd be interested in determining whether the need for both exists or whether one (or the other) is a superset.

[Rockyg] I suspect that both the WTE and the operators will have architectures that dovetail, as the operators are often implementing the needs of their organizations.  I would think that we could up with good compromises that reflect both the WTE use cases and the Dev-Ops common implementations.  The cool and key thing here is that, the groups come up with a reference architecture which then makes it much easier to iterate to what the individual user wants/needs.

Sounds like the discussion could be fun and productive.
--Rocky



Happy to discuss further when we meet in person.

Thanks,
Shamail

> On Jan 19, 2015, at 3:39 PM, Rochelle Grober <rochelle.grober at huawei.com<mailto:rochelle.grober at huawei.com>> wrote:
>
> I believe Rob Hirschfeld will be in attendance so, Rob (and I if he wants me) can cover the DefCore and Refstack session.  Rob is certainly the expert on DefCore.
>
> I'd also like to propose a session on defining/finding a project manager to start creating some reference architectures with tested installs.  Right now there is a discussion on the Operators' list on a small installation, 3-5 nodes, with HA.  This could be a fine first reference architecture with all the code and docs to make it similar (or better) to install than devstack.  This is also a good architecture for prospective users for prototyping, testing, or small business installation.  Spec'ing this out during the summit, or at least getting a good start, along with a volunteer project manager, would be a very worthwhile endeavor for the meetup.
>
> --Rocky
>
> -----Original Message-----
> From: sean roberts [mailto:seanroberts66 at gmail.com<mailto:seanroberts66 at gmail.com>]
> Sent: Sunday, January 18, 2015 11:44 AM
> To: product-wg at lists.openstack.org<mailto:product-wg at lists.openstack.org>
> Subject: [Product] Time to Pick Topics
>
> It’s time to finalize the OpenStack Product Management topics for the Kilo
> midcycle meeting
> <http://sarob.com/2015/01/openstack-kilo-product-management-midcycle-coming-to-a-greater-understanding/>
> coming
> up. We will need speakers for each topic. I want to get the best authority
> possible for each talk, so locking down the topics is required. I will need
> to get their commitment as soon as possible.
>
> More details on this post
> http://sarob.com/2015/01/getting-ready-for-the-product-management-kilo-midcycle/
>
>
> --
> ~sean
> _______________________________________________
> Product-wg mailing list
> Product-wg at lists.openstack.org<mailto:Product-wg at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg
> _______________________________________________
> Product-wg mailing list
> Product-wg at lists.openstack.org<mailto:Product-wg at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg
_______________________________________________
Product-wg mailing list
Product-wg at lists.openstack.org<mailto:Product-wg at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg