Re: [Openstack] [User-committee] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

2017-06-29 Thread Melvin Hillsman
+1

Did not have a chance to draft a message but thanks for ops mention.

On Jun 29, 2017 3:02 PM, "Amy Marrich"  wrote:

> First off it looks really sleek and I love the look! A few thoughts though
> and I do realize it's just a mock up:
>
> 1) We have Sponsor just to pick one but don't have
> Operators/Administrators and their feedback is a major contribution so
> please don't leave them out.
> 2) I would list the contributor types in alphabetical order that way no
> group feels slighted, you can't help it if Use Cases are last it's just
> that they start with a U vs Code which is a C.
> 3) What if you would like to contribute in multiple ways?
>
> Resources are definitely still underdevelopment there but are they meant
> to be broad applicable to all resources with more specialized one's visible
> when you click on how you'd like to contribute?
>
> Amy (spotz)
>
> On Thu, Jun 29, 2017 at 2:03 PM, Mike Perez  wrote:
>
>> Hello all,
>>
>> Wes has just took my ugly mock up of the contributor portal idea and
>> came up with this [1].
>>
>> Here’s what he said:
>>
>> "The idea is to help get potential contributors to the right place,
>> using the outline Mike put together. Rather than sending people to a
>> different page for each contribution type, users would be able to see
>> what options are available all on this page. We’d send them to any
>> necessary page(s) once they’ve gone through this quasi-wizard. Is this
>> along the lines of what you were thinking? page 2 shows the view once
>> you’ve clicked “Code” on page 1 (just in case that wasn’t super
>> obvious) Thanks!”
>>
>> What do you all think? This does change things a bit of instead of the
>> landing page being more obvious of a resource of links, it’s both for
>> new and current contributors. Current contributors would hopefully be
>> able to see the resource links below.
>>
>> Keep in mind that we will be working in the “Top 5 requested help” and
>> as suggested by Clark, an option of “I don’t know where I want to
>> start, but I want to help” kind of option. This would direct people to
>> resources such as Upstream University, mentor program, low hanging
>> fruit, that release priority idea I talked about earlier, etc.
>>
>> Personally I like it!
>>
>>
>> [1] - https://www.dropbox.com/s/3q172qwfkik1ysd/contributor-port
>> al.pdf?dl=0
>>
>> —
>> Mike Perez
>>
>> On June 27, 2017 at 13:48:36, Mike Perez (thin...@gmail.com) wrote:
>> > Hello all,
>> >
>> > Every month we have people asking on IRC or the dev mailing list having
>> interest in working
>> > on OpenStack, and sometimes they're given different answers from
>> people, or worse,
>> > no answer at all.
>> >
>> > Suggestion: lets work our efforts together to create some common
>> documentation so that
>> > all teams in OpenStack can benefit.
>> >
>> > First it’s important to note that we’re not just talking about code
>> projects here. OpenStack
>> > contributions come in many forms such as running meet ups, identifying
>> use cases (product
>> > working group), documentation, testing, etc. We want to make sure those
>> potential contributors
>> > feel welcomed too!
>> >
>> > What is common documentation? Things like setting up Git, the many
>> accounts you need
>> > to setup to contribute (gerrit, launchpad, OpenStack foundation
>> account). Not all
>> > teams will use some common documentation, but the point is one or more
>> projects will use
>> > them. Having the common documentation worked on by various projects
>> will better help
>> > prevent duplicated efforts, inconsistent documentation, and hopefully
>> just more
>> > accurate information.
>> >
>> > A team might use special tools to do their work. These can also be
>> integrated in this idea
>> > as well.
>> >
>> > Once we have common documentation we can have something like:
>> > 1. Choose your own adventure: I want to contribute by code
>> > 2. What service type are you interested in? (Database, Block storage,
>> compute)
>> > 3. Here’s step-by-step common documentation to setting up Git, IRC,
>> Mailing Lists,
>> > Accounts, etc.
>> > 4. A service type project might choose to also include additional
>> documentation in that
>> > flow for special tools, etc.
>> >
>> > Important things to note in this flow:
>> > * How do you want to contribute?
>> > * Here are **clear** names that identify the team. Not code names like
>> Cloud Kitty, Cinder,
>> > etc.
>> > * The documentation should really aim to not be daunting:
>> > * Someone should be able to glance at it and feel like they can finish
>> things in five minutes.
>> > Not be yet another tab left in their browser that they’ll eventually
>> forget about
>> > * No wall of text!
>> > * Use screen shots
>> > * Avoid covering every issue you could hit along the way.
>> >
>> > ## Examples of More Simple Documentation
>> > I worked on some documentation for the Upstream University preparation
>> that has received
>> > excellent feedback meet close to these suggestions:
>> > * IRC [1]

Re: [Openstack] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

2017-06-29 Thread Mike Perez
+ OpenStack dev list

On June 29, 2017 at 13:01:09, Amy Marrich (a...@demarco.com) wrote:
> First off it looks really sleek and I love the look! A few thoughts though
> and I do realize it's just a mock up:
>
> 1) We have Sponsor just to pick one but don't have Operators/Administrators
> and their feedback is a major contribution so please don't leave them out.

Ah yes, I should’ve mentioned earlier that this is totally a POC.
There are lots missing, don’t worry! :)

> 2) I would list the contributor types in alphabetical order that way no
> group feels slighted, you can't help it if Use Cases are last it's just
> that they start with a U vs Code which is a C.

Sure!

> 3) What if you would like to contribute in multiple ways?

You would come back to the main contributor portal and click on a
different contribution. How about at the end of each lesson it gives
them the option to go back to main contributor portal to pick another
way to contribute?

>
> Resources are definitely still underdevelopment there but are they meant to
> be broad applicable to all resources with more specialized one's visible
> when you click on how you'd like to contribute?

That’s a good question. I think it should probably on top contain the
more general stuff, then in alphabetical order we can list resources
for all contribution types? It can be like the “I want to contribute
to OpenStack by…” top piece, but instead lists resource links to pick
through based on your contribution type(s). Maybe we keep them as
separate pages as originally given in the mock up so it’s not overly
crowded?

Thanks for the help Amy!

—
Mike Perez

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


Re: [Openstack] [User-committee] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

2017-06-29 Thread Mike Perez
On June 29, 2017 at 13:01:09, Amy Marrich (a...@demarco.com) wrote:
> First off it looks really sleek and I love the look! A few thoughts though
> and I do realize it's just a mock up:
>
> 1) We have Sponsor just to pick one but don't have Operators/Administrators
> and their feedback is a major contribution so please don't leave them out.

Ah yes, I should’ve mentioned earlier that this is totally a POC.
There are lots missing, don’t worry! :)

> 2) I would list the contributor types in alphabetical order that way no
> group feels slighted, you can't help it if Use Cases are last it's just
> that they start with a U vs Code which is a C.

Sure!

> 3) What if you would like to contribute in multiple ways?

You would come back to the main contributor portal and click on a
different contribution. How about at the end of each lesson it gives
them the option to go back to main contributor portal to pick another
way to contribute?

>
> Resources are definitely still underdevelopment there but are they meant to
> be broad applicable to all resources with more specialized one's visible
> when you click on how you'd like to contribute?

That’s a good question. I think it should probably on top contain the
more general stuff, then in alphabetical order we can list resources
for all contribution types? It can be like the “I want to contribute
to OpenStack by…” top piece, but instead lists resource links to pick
through based on your contribution type(s). Maybe we keep them as
separate pages as originally given in the mock up so it’s not overly
crowded?

Thanks for the help Amy!

—
Mike Perez

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


Re: [Openstack] [User-committee] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

2017-06-29 Thread Amy Marrich
On Thu, Jun 29, 2017 at 3:12 PM, Mike Perez  wrote:

> On June 29, 2017 at 13:01:09, Amy Marrich (a...@demarco.com) wrote:
> > First off it looks really sleek and I love the look! A few thoughts
> though
> > and I do realize it's just a mock up:
> >
> > 1) We have Sponsor just to pick one but don't have
> Operators/Administrators
> > and their feedback is a major contribution so please don't leave them
> out.
>
> Ah yes, I should’ve mentioned earlier that this is totally a POC.
> There are lots missing, don’t worry! :)
>
> > 2) I would list the contributor types in alphabetical order that way no
> > group feels slighted, you can't help it if Use Cases are last it's just
> > that they start with a U vs Code which is a C.
>
> Sure!
>
> > 3) What if you would like to contribute in multiple ways?
>
> You would come back to the main contributor portal and click on a
> different contribution. How about at the end of each lesson it gives
> them the option to go back to main contributor portal to pick another
> way to contribute?
>
> What if on the bottom it could list out the other ways and they could just
proceed from there?


> >
> > Resources are definitely still underdevelopment there but are they meant
> to
> > be broad applicable to all resources with more specialized one's visible
> > when you click on how you'd like to contribute?
>
> That’s a good question. I think it should probably on top contain the
> more general stuff, then in alphabetical order we can list resources
> for all contribution types? It can be like the “I want to contribute
> to OpenStack by…” top piece, but instead lists resource links to pick
> through based on your contribution type(s). Maybe we keep them as
> separate pages as originally given in the mock up so it’s not overly
> crowded?
>
> Thanks for the help Amy!
>
> —
> Mike Perez
>

Amy (spotz)
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


Re: [Openstack] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

2017-06-29 Thread Mike Perez
+ OpenStack dev list

Hello all,

Wes has just took my ugly mock up of the contributor portal idea and
came up with this [1].

Here’s what he said:

"The idea is to help get potential contributors to the right place,
using the outline Mike put together. Rather than sending people to a
different page for each contribution type, users would be able to see
what options are available all on this page. We’d send them to any
necessary page(s) once they’ve gone through this quasi-wizard. Is this
along the lines of what you were thinking? page 2 shows the view once
you’ve clicked “Code” on page 1 (just in case that wasn’t super
obvious) Thanks!”

What do you all think? This does change things a bit of instead of the
landing page being more obvious of a resource of links, it’s both for
new and current contributors. Current contributors would hopefully be
able to see the resource links below.

Keep in mind that we will be working in the “Top 5 requested help” and
as suggested by Clark, an option of “I don’t know where I want to
start, but I want to help” kind of option. This would direct people to
resources such as Upstream University, mentor program, low hanging
fruit, that release priority idea I talked about earlier, etc.

Personally I like it!


[1] - https://www.dropbox.com/s/3q172qwfkik1ysd/contributor-portal.pdf?dl=0

—
Mike Perez

> On June 27, 2017 at 13:48:36, Mike Perez (thin...@gmail.com) wrote:
> > Hello all,
> >
> > Every month we have people asking on IRC or the dev mailing list having 
> > interest in working
> > on OpenStack, and sometimes they're given different answers from people, or 
> > worse,
> > no answer at all.
> >
> > Suggestion: lets work our efforts together to create some common 
> > documentation so
> that
> > all teams in OpenStack can benefit.
> >
> > First it’s important to note that we’re not just talking about code 
> > projects here. OpenStack
> > contributions come in many forms such as running meet ups, identifying use 
> > cases (product
> > working group), documentation, testing, etc. We want to make sure those 
> > potential
> contributors
> > feel welcomed too!
> >
> > What is common documentation? Things like setting up Git, the many accounts 
> > you need
> > to setup to contribute (gerrit, launchpad, OpenStack foundation account). 
> > Not all
> > teams will use some common documentation, but the point is one or more 
> > projects will
> use
> > them. Having the common documentation worked on by various projects will 
> > better help
> > prevent duplicated efforts, inconsistent documentation, and hopefully just 
> > more
> > accurate information.
> >
> > A team might use special tools to do their work. These can also be 
> > integrated in this idea
> > as well.
> >
> > Once we have common documentation we can have something like:
> > 1. Choose your own adventure: I want to contribute by code
> > 2. What service type are you interested in? (Database, Block storage, 
> > compute)
> > 3. Here’s step-by-step common documentation to setting up Git, IRC, Mailing 
> > Lists,
> > Accounts, etc.
> > 4. A service type project might choose to also include additional 
> > documentation in
> that
> > flow for special tools, etc.
> >
> > Important things to note in this flow:
> > * How do you want to contribute?
> > * Here are **clear** names that identify the team. Not code names like 
> > Cloud Kitty, Cinder,
> > etc.
> > * The documentation should really aim to not be daunting:
> > * Someone should be able to glance at it and feel like they can finish 
> > things in five minutes.
> > Not be yet another tab left in their browser that they’ll eventually forget 
> > about
> > * No wall of text!
> > * Use screen shots
> > * Avoid covering every issue you could hit along the way.
> >
> > ## Examples of More Simple Documentation
> > I worked on some documentation for the Upstream University preparation that 
> > has received
> > excellent feedback meet close to these suggestions:
> > * IRC [1]
> > * Git [2]
> > * Account Setup [3]
> >
> > ## 500 Feet Birds Eye view
> > There will be a Contributor landing page on the openstack.org website. 
> > Existing contributors
> > will find reference links to quickly jump to things. New contributors will 
> > find a banner
> > at the top of the page to direct them to the choose your own adventure to 
> > contributing
> to
> > OpenStack, with ordered documentation flow that reuses existing 
> > documentation when
> > necessary. Picture also a progress bar somewhere to show how close you are 
> > to being ready
> > to contribute to whatever team. Of course there are a lot of other fancy 
> > things we can
> come
> > up with, but I think getting something up as an initial pass would be 
> > better than what
> we
> > have today.
> >
> > Here's an example of what the sections/chapters could look like:
> >
> > - Code
> > * Volumes (Cinder)
> > * IRC
> > * Git
> > * Account Setup
> > * Generating Configs
> > * Compute (Nova)
> > * IRC
> > * Git
> > * Accou

Re: [Openstack] [User-committee] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

2017-06-29 Thread Amy Marrich
First off it looks really sleek and I love the look! A few thoughts though
and I do realize it's just a mock up:

1) We have Sponsor just to pick one but don't have Operators/Administrators
and their feedback is a major contribution so please don't leave them out.
2) I would list the contributor types in alphabetical order that way no
group feels slighted, you can't help it if Use Cases are last it's just
that they start with a U vs Code which is a C.
3) What if you would like to contribute in multiple ways?

Resources are definitely still underdevelopment there but are they meant to
be broad applicable to all resources with more specialized one's visible
when you click on how you'd like to contribute?

Amy (spotz)

On Thu, Jun 29, 2017 at 2:03 PM, Mike Perez  wrote:

> Hello all,
>
> Wes has just took my ugly mock up of the contributor portal idea and
> came up with this [1].
>
> Here’s what he said:
>
> "The idea is to help get potential contributors to the right place,
> using the outline Mike put together. Rather than sending people to a
> different page for each contribution type, users would be able to see
> what options are available all on this page. We’d send them to any
> necessary page(s) once they’ve gone through this quasi-wizard. Is this
> along the lines of what you were thinking? page 2 shows the view once
> you’ve clicked “Code” on page 1 (just in case that wasn’t super
> obvious) Thanks!”
>
> What do you all think? This does change things a bit of instead of the
> landing page being more obvious of a resource of links, it’s both for
> new and current contributors. Current contributors would hopefully be
> able to see the resource links below.
>
> Keep in mind that we will be working in the “Top 5 requested help” and
> as suggested by Clark, an option of “I don’t know where I want to
> start, but I want to help” kind of option. This would direct people to
> resources such as Upstream University, mentor program, low hanging
> fruit, that release priority idea I talked about earlier, etc.
>
> Personally I like it!
>
>
> [1] - https://www.dropbox.com/s/3q172qwfkik1ysd/contributor-
> portal.pdf?dl=0
>
> —
> Mike Perez
>
> On June 27, 2017 at 13:48:36, Mike Perez (thin...@gmail.com) wrote:
> > Hello all,
> >
> > Every month we have people asking on IRC or the dev mailing list having
> interest in working
> > on OpenStack, and sometimes they're given different answers from people,
> or worse,
> > no answer at all.
> >
> > Suggestion: lets work our efforts together to create some common
> documentation so that
> > all teams in OpenStack can benefit.
> >
> > First it’s important to note that we’re not just talking about code
> projects here. OpenStack
> > contributions come in many forms such as running meet ups, identifying
> use cases (product
> > working group), documentation, testing, etc. We want to make sure those
> potential contributors
> > feel welcomed too!
> >
> > What is common documentation? Things like setting up Git, the many
> accounts you need
> > to setup to contribute (gerrit, launchpad, OpenStack foundation
> account). Not all
> > teams will use some common documentation, but the point is one or more
> projects will use
> > them. Having the common documentation worked on by various projects will
> better help
> > prevent duplicated efforts, inconsistent documentation, and hopefully
> just more
> > accurate information.
> >
> > A team might use special tools to do their work. These can also be
> integrated in this idea
> > as well.
> >
> > Once we have common documentation we can have something like:
> > 1. Choose your own adventure: I want to contribute by code
> > 2. What service type are you interested in? (Database, Block storage,
> compute)
> > 3. Here’s step-by-step common documentation to setting up Git, IRC,
> Mailing Lists,
> > Accounts, etc.
> > 4. A service type project might choose to also include additional
> documentation in that
> > flow for special tools, etc.
> >
> > Important things to note in this flow:
> > * How do you want to contribute?
> > * Here are **clear** names that identify the team. Not code names like
> Cloud Kitty, Cinder,
> > etc.
> > * The documentation should really aim to not be daunting:
> > * Someone should be able to glance at it and feel like they can finish
> things in five minutes.
> > Not be yet another tab left in their browser that they’ll eventually
> forget about
> > * No wall of text!
> > * Use screen shots
> > * Avoid covering every issue you could hit along the way.
> >
> > ## Examples of More Simple Documentation
> > I worked on some documentation for the Upstream University preparation
> that has received
> > excellent feedback meet close to these suggestions:
> > * IRC [1]
> > * Git [2]
> > * Account Setup [3]
> >
> > ## 500 Feet Birds Eye view
> > There will be a Contributor landing page on the openstack.org website.
> Existing contributors
> > will find reference links to quickly jump to things. New contributors
> will find 

Re: [Openstack] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

2017-06-29 Thread Mike Perez
Hello all,

Wes has just took my ugly mock up of the contributor portal idea and
came up with this [1].

Here’s what he said:

"The idea is to help get potential contributors to the right place,
using the outline Mike put together. Rather than sending people to a
different page for each contribution type, users would be able to see
what options are available all on this page. We’d send them to any
necessary page(s) once they’ve gone through this quasi-wizard. Is this
along the lines of what you were thinking? page 2 shows the view once
you’ve clicked “Code” on page 1 (just in case that wasn’t super
obvious) Thanks!”

What do you all think? This does change things a bit of instead of the
landing page being more obvious of a resource of links, it’s both for
new and current contributors. Current contributors would hopefully be
able to see the resource links below.

Keep in mind that we will be working in the “Top 5 requested help” and
as suggested by Clark, an option of “I don’t know where I want to
start, but I want to help” kind of option. This would direct people to
resources such as Upstream University, mentor program, low hanging
fruit, that release priority idea I talked about earlier, etc.

Personally I like it!


[1] - https://www.dropbox.com/s/3q172qwfkik1ysd/contributor-portal.pdf?dl=0

—
Mike Perez

On June 27, 2017 at 13:48:36, Mike Perez (thin...@gmail.com) wrote:
> Hello all,
>
> Every month we have people asking on IRC or the dev mailing list having 
> interest in working
> on OpenStack, and sometimes they're given different answers from people, or 
> worse,
> no answer at all.
>
> Suggestion: lets work our efforts together to create some common 
> documentation so that
> all teams in OpenStack can benefit.
>
> First it’s important to note that we’re not just talking about code projects 
> here. OpenStack
> contributions come in many forms such as running meet ups, identifying use 
> cases (product
> working group), documentation, testing, etc. We want to make sure those 
> potential contributors
> feel welcomed too!
>
> What is common documentation? Things like setting up Git, the many accounts 
> you need
> to setup to contribute (gerrit, launchpad, OpenStack foundation account). Not 
> all
> teams will use some common documentation, but the point is one or more 
> projects will use
> them. Having the common documentation worked on by various projects will 
> better help
> prevent duplicated efforts, inconsistent documentation, and hopefully just 
> more
> accurate information.
>
> A team might use special tools to do their work. These can also be integrated 
> in this idea
> as well.
>
> Once we have common documentation we can have something like:
> 1. Choose your own adventure: I want to contribute by code
> 2. What service type are you interested in? (Database, Block storage, compute)
> 3. Here’s step-by-step common documentation to setting up Git, IRC, Mailing 
> Lists,
> Accounts, etc.
> 4. A service type project might choose to also include additional 
> documentation in that
> flow for special tools, etc.
>
> Important things to note in this flow:
> * How do you want to contribute?
> * Here are **clear** names that identify the team. Not code names like Cloud 
> Kitty, Cinder,
> etc.
> * The documentation should really aim to not be daunting:
> * Someone should be able to glance at it and feel like they can finish things 
> in five minutes.
> Not be yet another tab left in their browser that they’ll eventually forget 
> about
> * No wall of text!
> * Use screen shots
> * Avoid covering every issue you could hit along the way.
>
> ## Examples of More Simple Documentation
> I worked on some documentation for the Upstream University preparation that 
> has received
> excellent feedback meet close to these suggestions:
> * IRC [1]
> * Git [2]
> * Account Setup [3]
>
> ## 500 Feet Birds Eye view
> There will be a Contributor landing page on the openstack.org website. 
> Existing contributors
> will find reference links to quickly jump to things. New contributors will 
> find a banner
> at the top of the page to direct them to the choose your own adventure to 
> contributing to
> OpenStack, with ordered documentation flow that reuses existing documentation 
> when
> necessary. Picture also a progress bar somewhere to show how close you are to 
> being ready
> to contribute to whatever team. Of course there are a lot of other fancy 
> things we can come
> up with, but I think getting something up as an initial pass would be better 
> than what we
> have today.
>
> Here's an example of what the sections/chapters could look like:
>
> - Code
> * Volumes (Cinder)
> * IRC
> * Git
> * Account Setup
> * Generating Configs
> * Compute (Nova)
> * IRC
> * Git
> * Account Setup
> * Something about hypervisors (matrix?)
> - Use Cases
> * Products (Product working group)
> * IRC
> * Git
> * Use Case format
>
> There are some rough mock up ideas [4]. Probably Sphinx will be fine for 
> this. Potentially
>

Re: [Openstack] Production openstack on 5 node

2017-06-29 Thread Satish Patel
I have implemented DVR in test environment but not sure how much it's popular 
in production in sense of complexity and management. 

Sent from my iPhone

> On Jun 25, 2017, at 4:30 PM, Remo Mattei  wrote:
> 
> Dvr is good option if you want to implement a way to have your vms always 
> available. It needs ovs. 
> 
> I still have not seen a doc details on implementation yet. 
> 
> :) 
> 
> Inviato da iPhone
> 
>> Il giorno 25 giu 2017, alle ore 12:38, Satish Patel  
>> ha scritto:
>> 
>> Thank you folks!
>> 
>> I have 5 node so following role i am planning to implement, I am
>> little confused related network component, should i use DVR
>> (distributed virtual router ) but problem is every single node need
>> public IP address in that case, first time building production style
>> openstack so don't know what would be the best option?
>> 
>> 1 controller + network
>> 4 compute node
>> 
>>> On Wed, Jun 21, 2017 at 10:22 PM, Mike Smith  wrote:
>>> Agree you should definitely check out what is already out there in community
>>> if you are starting from scratch.  In our specific case, we do our puppet
>>> configs manually because 1) we are still on puppet v3 for everything else
>>> and 2) we have been doing it this way since Folsom and it’s worked well.
>>> 
>>> We are about to build another new cluster on Ocata and I think for that one
>>> I will try and leverage more of the community puppet stuff if possible.
>>> 
>>> On Jun 21, 2017, at 1:49 PM, John van Ommen  wrote:
>>> 
>>> I couldn't agree more. OpenStack deployment is not a trivial task. Do not
>>> reinvent the wheel.
>>> 
>>> John
>>> 
>>> On Jun 21, 2017 12:04 PM, "Erik McCormick" 
>>> wrote:
 
 If you are a Puppet shop you should check out the Puppet community
 modules. You will get familiar with all the inner goo as you'll need your
 own composition layer (in my case a series of hiera files). There's no
 reason to reinvent the wheel unless you really want to.
 
 -Erik
 
> On Jun 21, 2017 2:19 PM, "Satish Patel"  wrote:
> 
> Thank you all of you for your opinion, As mike suggested i am also
> planning to brew home grown puppet module to understand each and every
> component and their role instead of grabbing third party tool, I am
> sure OOO is best for 100 deploying 100 compute node but in my setup we
> have only 5 servers and its not worth it to manage undercloud server.
> 
> We are puppet shop so it would be easy to write own code and go from
> there.
> 
>> On Wed, Jun 21, 2017 at 1:25 AM, Remo Mattei  wrote:
>> I did a deployment with cs9 hp it was pretty bad. I hope the new one
>> does
>> better.
>> 
>> Nevertheless I do not see many using hp out there. Maybe different
>> regions
>> like emea do better with that.
>> 
>> Inviato da iPhone
>> 
>> Il giorno 20 giu 2017, alle ore 21:10, John van Ommen
>>  ha scritto:
>> 
>> At HPE we originally used TripleO but switched to a 'flat' model.
>> 
>> I personally didn't see any advantage to Triple O. In theory, it should
>> be
>> easier to manage and upgrade. In the real world, Helion 3.0 and 4.0 are
>> superior in every respect.
>> 
>> John
>> 
>>> On Jun 20, 2017 9:02 PM, "Remo Mattei"  wrote:
>>> 
>>> I worked for Red Hat and they really want to get ooo going because the
>>> installation tools did never work as everyone was hoping. Before Red
>>> Hat I
>>> was at Mirantis and the fuel installation was nice now dead. I know
>>> ooo will
>>> go into containers next couple of release but kolla–Ansible is one of
>>> the
>>> emerging solutions now to get it out fast.
>>> 
>>> I am doing a project now where I am working on deploying ooo just
>>> finished
>>> the doc for Ocata undercloud.
>>> 
>>> Just my two cents to concord with Mike’s statement.
>>> 
>>> Remo
>>> 
>>> Inviato da iPhone
>>> 
>>> Il giorno 20 giu 2017, alle ore 20:51, Mike Smith
>>> 
>>> ha scritto:
>>> 
>>> There are definitely 1,001 opinions on what is “best”.  We use RDO at
>>> Overstock and we use home-grown puppet modules because we do our own
>>> puppet
>>> modules for everything else we do here.  We based everything around
>>> the
>>> official Openstack install documents and we do it because we want to
>>> *fully*
>>> understand everything we can instead of treating it like a black box
>>> that
>>> knows how to do the magic.
>>> 
>>> However, there are lots of options out there - ansible, kolla, puppet
>>> plus
>>> vendor-specific options too like those provided by Mirantis.  If there
>>> are
>>> config management tools (ansible, puppet, etc) that you already use,
>>> you may
>>> want to check out the Openstack options for those.  You are correct
>>> that
>>> that packstack is more of a ‘all-

Re: [Openstack] Mirantis Openstack - Instances lose IP in certain nodes

2017-06-29 Thread Tomáš Vondra
Hi!

What kind of networking plugin have you deployed with Fuel?

Do you mean fixed IP or Floating IP?

Tomas

 

From: Raja T Nair [mailto:rtn...@gmail.com] 
Sent: Tuesday, June 27, 2017 8:54 PM
To: openstack@lists.openstack.org
Subject: [Openstack] Mirantis Openstack - Instances lose IP in certain nodes

 

Hello All,

In my Mirantis cluster, recently VMs in some nodes have started to lose IPs.

After a reboot of the node, none of the VMs there gets an IP.

Version details below:

[root@fuel ~]# cat /etc/fuel/version.yaml 
VERSION:
  feature_groups:
- mirantis
  production: "docker"
  release: "7.0"
  openstack_version: "2015.1.0-7.0"
  api: "1.0"
  build_number: "301"
  build_id: "301"

Any help to troubleshoot this situation is highly appreciated.

Regards,

Raja.



-- 

:^)

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack