Re: [openstack-dev] Barcelona Summit -- Monday -- openings in command-presence-workshop

[Paul Dardeau]

I attended this session in Austin and thought it was excellent. For anyone
who has uneasiness about getting up in front of others to defend their
point-of-view, I think it's time well spent.

-paul

On Fri, Oct 14, 2016 at 11:01 AM, Potter, Nathaniel <
nathaniel.pot...@intel.com> wrote:

> **Forwarding along a message from Malini Bhandaru**
>
>
>
> Hello Everyone!
>
>
>
> We have a few slots still available on Monday’s Command Presence workshop
> and are opening out to a broader audience. Please register if interested.
> Past attendees, despite their many skills and experience, vouched that they
> had learned a trick or two.
>
>
>
> https://www.openstack.org/summit/barcelona-2016/summit-
> schedule/events/16888/command-presence-workshop
>
>
>
> Regards,
>
> Malini
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Default the HA scenario to Ceph

[Paul Dardeau]

RGW does not use Swift. It’s an optional component of Ceph that can provide a 
Swift compliant API (and also S3). But it does not make use of openstack-swift. 
It’s a completely separate implementation written in c++ [1].

[1] https://github.com/ceph/ceph/blob/master/src/rgw/rgw_rest_swift.cc

> On Oct 13, 2016, at 5:36 AM, Shinobu Kinjo  wrote:
> 
> 
> 
> On Wed, Oct 12, 2016 at 9:59 PM, Giulio Fidente  > wrote:
> On 10/12/2016 02:29 PM, Thiago da Silva wrote:
> 
> 
> On 10/12/2016 07:10 AM, Giulio Fidente wrote:
> hi,
> 
> we introduced support for the deployment of Ceph in the liberty
> release so that it could optionally be used as backend for one or more
> of Cinder, Glance, Nova and more recently Gnocchi.
> 
> We used to deploy Ceph MONs on the controller nodes and Ceph OSDs on
> dedicated ceph-storage nodes so a deployment of OpenStack with Ceph
> would need at least 1 more additional node to host a Ceph OSD.
> 
> In our HA scenario the storage backends are configured as follows:
> 
> Glance -> Swift
> Nova (ephemeral) -> Local
> Cinder (persistent) -> LVM (on controllers)
> Gnocchi -> Swift
> 
> The downside of the above configuration is that Cinder volumes can not
> be replicated across the controller nodes and become unavailable if a
> controller fails, while production environments generally expect
> persistent storage to be highly available. Cinder volumes instead
> could even get lost completely in case of a permanent failure of a
> controller.
> 
> With the Newton release and the composable roles we can now deploy
> Ceph OSDs on the compute nodes, removing the requirement we had for an
> additional node to host a Ceph OSD.
> 
> I would like to ask for some feedback on the possibility of deploying
> Ceph by default in the HA scenario and use it as backend for Cinder.
> 
> Also using Swift as backend for Glance and Gnocchi is enough to cover
> the availability issue for the data, but it also means we're storing
> that data on the controller nodes which might or might not be wanted;
> I don't see a strong reason for defaulting them to Ceph, but it might
> make more sense when Ceph is available; feedback about this would be
> appreciated as well.
> I think it would be important to take into account the recently created
> guiding principles [0]:
> 
> "While the software that OpenStack produces has well defined and
> documented APIs, the primary output of OpenStack is software, not API
> definitions. We expect people who say they run “OpenStack” to run the
> software produced by and in the community, rather than alternative
> implementations of the API."
> 
> In the case of Cinder, I think the situation is a bit muddy as LVM is
> not openstack software, and my limited understanding is that LVM is used
> as a reference implementation, but in the case of Swift, I think RGW
> would be considered an 'alternative implementation of the API'.
> 
> Thiago
> 
> hi Thiago,
> 
> sorry if it wasn't clear in my original message but I did not suggest to 
> replace Swift with Ceph RGW.
> 
> Swift would continue to be deployed by default, not RGW.
> 
> RGW utilizes Swift. So Swift has to be there anyway -;
>  
> 
> The feedback I'm asking for is about storing (or not) the Cinder volumes in 
> Ceph for the HA scenario by default, and also store the Glance images and 
> Gnocchi metrics in Ceph or rather keep that data in Swift.
> -- 
> Giulio Fidente
> GPG KEY: 08D733BA
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> 
> 
> -- 
> Email:
> shin...@linux.com 
> shin...@redhat.com 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] governance proposal worth a visit: Write down OpenStack principles

[Paul Dardeau]

Re: "One OpenStack" product

Is vim, less, awk, sed, and emacs one product? Are the bolt and nut of same
size (and produced by same manufacturer) sitting in a hardware store a
single product? A vote or edict does not automatically make things one
product - it only conveys a desire. I would argue that OpenStack is closer
to being a single, very large toolkit (instead of a product) that can be
configured and used in many different ways. For those that do consider it a
single product -- have you tried watching someone brand new to OpenStack
try to roll it out (not devstack)? If you still consider it a product, what
are the competing products and how easy are they to use?

In my view, a 'product' has a certain level of integration and common-ness
about it (still vague, I know). Some may argue that a product is
indivisible (or not readily indivisible).

-paul

On Fri, Sep 9, 2016 at 5:22 AM, John Davidge 
wrote:

> Thierry Carrez wrote:
>
> >[...]
> >In the last years there were a lot of "questions" asked by random
> >contributors, especially around the "One OpenStack" principle (which
> >seems to fuel most of the reaction here). Remarks like "we should really
> >decide once and for all if OpenStack is a collection of independent
> >projects, or one thing".
> >
> >A lot of people actually ignore that this question was already asked,
> >pretty early on (by John Dickinson in June 2011). Back then it was
> >settled by the PPB (the ancestor to the TC). You can read it all
> >here[1]. It was never brought again as a proposed change to the TC, so
> >that decision from June 2011 is still defining how we should think about
> >OpenStack.
> >
> >Most of the TC members know the governance history and know those
> >principles. That is, after all, one of the reasons you elect them for.
> >But we realized that the people asking those questions again and again
> >were not at fault. It was our failure to *document* this history
> >properly which caused the issue. Took us some time to gather the courage
> >to write it, then finally Monty wrote a draft, and I turned it into a
> >change.
>
> To provide a counter point, I think the reason this question is asked so
> often is not because the TC has failed to *document* this policy, but that
> it has failed to *comply* with it.
>
> I¹m of course referring to the introduction of The Big Tent. This is the
> moment that OpenStack stopped being: ³A single product made of a lot of
> independent, but cooperating, components.² And became: ³A collection of
> independent projects that work together for some level of integration and
> releases.²
>
> This is in direct contradiction to the stated and collectively understood
> goal of the project, and has left many scratching their heads.
>
> The principles as written in the review do not accurately describe the
> current state of the project. To make it so that they do, we either need
> to change the principles or change the project. As I see it, our options
> are:
>
> 1. Adjust the project to reflect the principles by abolishing The Big Tent.
> 2. Adjust the principles to reflect the project by redefining it as: ³A
> collection of independent projects that work together for some level of
> integration and releases.²
>
> Personally, my vote is for option 1.
>
> John
>
>
> 
> Rackspace Limited is a company registered in England & Wales (company
> registered number 03897010) whose registered office is at 5 Millington
> Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy
> can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail
> message may contain confidential or privileged information intended for the
> recipient. Any dissemination, distribution or copying of the enclosed
> material is prohibited. If you receive this transmission in error, please
> notify us immediately by e-mail at ab...@rackspace.com and delete the
> original message. Your cooperation is appreciated.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev