Re: [openstack-dev] [ptg] Simplification in OpenStack

[Mike Perez]

On 10:45 Sep 12, Mike Perez wrote:
> Hey all,
> 
> Back in a joint meeting with the TC, UC, Foundation and The Board it was
> decided as an area of OpenStack to focus was Simplifying OpenStack. This
> intentionally was very broad so the community can kick start the conversation
> and help tackle some broad feedback we get.
> 
> Unfortunately yesterday there was a low turn out in the Simplification room.
> A group of people from the Swift team, Kevin Fox and Swimingly were nice
> enough to start the conversation and give some feedback. You can see our
> initial ether pad work here:
> 
> https://etherpad.openstack.org/p/simplifying-os
> 
> There are efforts happening everyday helping with this goal, and our team has
> made some documented improvements that can be found in our report to the
> board within the ether pad. I would like to take a step back with this
> opportunity to have in person discussions for us to identify what are the
> area of simplifying that are worthwhile. I’m taking a break from the room at
> the moment for lunch, but I encourage people at 13:30 local time to meet at
> the simplification room level b in the big thompson room. Thank you!

Sorry for the late reply all. Decompression from burning man and ptg :).

Thanks for the discussions everyone has brought to this thread. I think we did
a good job brainstorming and identifying what we have more information on.

I would like to move this discussion to a different thread that focuses on
those more identified areas, with relation to the recent user survey:

http://lists.openstack.org/pipermail/openstack-dev/2017-October/123086.html

Lets keep this momentum going!

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] [ptg] Simplification in OpenStack

[Fox, Kevin M]

Its easier to convince the developers employer to keep paying the developer 
when their users (operators) want to use their stuff. Its a longer term 
strategic investment. But a critical one. I think this has been one of the 
things holding OpenStack back of late. The developers continuously push off 
hard issues to operators that may have other, better solutions. I don't feel 
this is out of malice but more out of lack of understanding on what operators 
do. The operators are starting to push back and are looking at alternatives 
now. We need to break this trend before it accelerates and more developers can 
no longer afford to work on OpenStack. I'd be happy as an operator to work with 
developers to identify pain points so they can be resolved in more operator 
friendly ways.

Thanks,
Kevin

From: Ben Nemec [openst...@nemebean.com]
Sent: Friday, September 29, 2017 6:43 AM
To: OpenStack Development Mailing List (not for usage questions); Rochelle 
Grober
Subject: Re: [openstack-dev] [ptg] Simplification in OpenStack

On 09/26/2017 09:13 PM, Rochelle Grober wrote:
> Clint Byrum wrote:
>> Excerpts from Jonathan Proulx's message of 2017-09-26 16:01:26 -0400:
>>> On Tue, Sep 26, 2017 at 12:16:30PM -0700, Clint Byrum wrote:
>>>
>>> :OpenStack is big. Big enough that a user will likely be fine with
>>> learning :a new set of tools to manage it.
>>>
>>> New users in the startup sense of new, probably.
>>>
>>> People with entrenched environments, I doubt it.
>>>
>>
>> Sorry no, I mean everyone who doesn't have an OpenStack already.
>>
>> It's nice and all, if you're a Puppet shop, to get to use the puppet modules.
>> But it doesn't bring you any closer to the developers as a group. Maybe a few
>> use Puppet, but most don't. And that means you are going to feel like
>> OpenStack gets thrown over the wall at you once every
>> 6 months.
>>
>>> But OpenStack is big. Big enough I think all the major config systems
>>> are fairly well represented, so whether I'm right or wrong this
>>> doesn't seem like an issue to me :)
>>>
>>
>> They are. We've worked through it. But that doesn't mean potential users
>> are getting our best solution or feeling well integrated into the community.
>>
>>> Having common targets (constellations, reference architectures,
>>> whatever) so all the config systems build the same things (or a subset
>>> or superset of the same things) seems like it would have benefits all
>>> around.
>>>
>>
>> It will. It's a good first step. But I'd like to see a world where 
>> developers are
>> all well versed in how operators actually use OpenStack.
>
> Hear, hear!  +1000  Take a developer to work during peak operations.

Or anytime really.  One of the best experiences I had was going on-site
to some of our early TripleO users and helping them through the install
process.  It was eye-opening to see someone who wasn't already immersed
in the project try to use it.  In a relatively short time they pointed
out a number of easy opportunities for simplification (why is this two
steps instead of one?  Umm, no good reason actually.).

I've pushed for us to do more of that sort of thing, but unfortunately
it's a hard sell to take an already overworked developer away from their
day job for a week to focus on one specific user. :-/

>
> For Walmart, that would be Black Firday/Cyber Monday.
> For schools, usually a few days into the new session.
> For otherseach has a time when things break more.  Having a developer 
> experience what operators do to predict/avoid/recover/work around the normal 
> state of operations would help each to understand the macro work flows.  
> Those are important, too.  Full stack includes Ops.
>
> < Snark off />
>
> --Rocky
>
>>
>> __
>> 
>> 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
>

__
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] [ptg] Simplification in OpenStack

[Ben Nemec]

On 09/26/2017 09:13 PM, Rochelle Grober wrote:

Clint Byrum wrote:

Excerpts from Jonathan Proulx's message of 2017-09-26 16:01:26 -0400:

On Tue, Sep 26, 2017 at 12:16:30PM -0700, Clint Byrum wrote:

:OpenStack is big. Big enough that a user will likely be fine with
learning :a new set of tools to manage it.

New users in the startup sense of new, probably.

People with entrenched environments, I doubt it.



Sorry no, I mean everyone who doesn't have an OpenStack already.

It's nice and all, if you're a Puppet shop, to get to use the puppet modules.
But it doesn't bring you any closer to the developers as a group. Maybe a few
use Puppet, but most don't. And that means you are going to feel like
OpenStack gets thrown over the wall at you once every
6 months.


But OpenStack is big. Big enough I think all the major config systems
are fairly well represented, so whether I'm right or wrong this
doesn't seem like an issue to me :)



They are. We've worked through it. But that doesn't mean potential users
are getting our best solution or feeling well integrated into the community.


Having common targets (constellations, reference architectures,
whatever) so all the config systems build the same things (or a subset
or superset of the same things) seems like it would have benefits all
around.



It will. It's a good first step. But I'd like to see a world where developers 
are
all well versed in how operators actually use OpenStack.


Hear, hear!  +1000  Take a developer to work during peak operations.


Or anytime really.  One of the best experiences I had was going on-site 
to some of our early TripleO users and helping them through the install 
process.  It was eye-opening to see someone who wasn't already immersed 
in the project try to use it.  In a relatively short time they pointed 
out a number of easy opportunities for simplification (why is this two 
steps instead of one?  Umm, no good reason actually.).


I've pushed for us to do more of that sort of thing, but unfortunately 
it's a hard sell to take an already overworked developer away from their 
day job for a week to focus on one specific user. :-/




For Walmart, that would be Black Firday/Cyber Monday.
For schools, usually a few days into the new session.
For otherseach has a time when things break more.  Having a developer 
experience what operators do to predict/avoid/recover/work around the normal 
state of operations would help each to understand the macro work flows.  Those 
are important, too.  Full stack includes Ops.

< Snark off />

--Rocky



__

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



__
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] [ptg] Simplification in OpenStack

[Gyorgy Szombathelyi]

Hi,

> The install docs still suggest hand configuring machines in 2017. It’s only 
> after
> people fall down that snake pit that they find projects like
> TripleO/Ansible/Puppet/Chef, and wonder why everyone doesn’t use this
> stuff.

I just wondering, too, but about a different thing: the install doc writes 
nicely
how to install and configure OpenStack as an average Linux admin would do it.
Install packages/modify config files and you're ready. These steps are not 
necessary
to be hand-executed, they can be easily automated (Ansible comes to my mind 
first, as
the most user-friendly config management tool for me). Then the sysadmin looks
at the official deployment tools: they're doing their job with exta layers, 
extra things
which are not in the install docs, like creating containers, installing 
OpenStack from git,
installing an OpenStack before installing the real OpenStack, etc...
They're just overcomplicated, to be honest. 

As an operator myself, I want a solid OpenStack installation, which I can 
manage and upgrade,
not tens of containers, or other stuff which I cannot touch unless I take the 
risk of blowing up
everything. With the traditional method (packages/config management) I can sit 
and lay back,
upgrade when I want (did it from Liberty to Ocata in real OpenStack clusters, 
that means 3 upgrades,
and the clusters are still alive), can apply updates when a pacakage is 
released, and simply I feel 
that the infra is under my control, not under some install tool. 

These were the reasons why I wrote my ansible playbook set, and I still feel it 
was a
good decision (more than 2 years OpenStack operation experience says that).
I understand, maybe some wants to be at the bleeding edge, likes to run the 
most recent git revisions,
but most of them wants a stable installation in production.

I don't know if this opinion counts, but what I would like to see stable, good 
quality OpenStack packages (I
know it is very distro-specific, but it is not the problem of OpenStack, but 
the Linux ecosystem - containers
are just a workaround and not the right solution), and simple installers which 
just install these packages
and configures them. No more, no less.

My 2 cents,
Br,
György
__
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] [ptg] Simplification in OpenStack

[Rochelle Grober]

Clint Byrum wrote:
> Excerpts from Jonathan Proulx's message of 2017-09-26 16:01:26 -0400:
> > On Tue, Sep 26, 2017 at 12:16:30PM -0700, Clint Byrum wrote:
> >
> > :OpenStack is big. Big enough that a user will likely be fine with
> > learning :a new set of tools to manage it.
> >
> > New users in the startup sense of new, probably.
> >
> > People with entrenched environments, I doubt it.
> >
> 
> Sorry no, I mean everyone who doesn't have an OpenStack already.
> 
> It's nice and all, if you're a Puppet shop, to get to use the puppet modules.
> But it doesn't bring you any closer to the developers as a group. Maybe a few
> use Puppet, but most don't. And that means you are going to feel like
> OpenStack gets thrown over the wall at you once every
> 6 months.
> 
> > But OpenStack is big. Big enough I think all the major config systems
> > are fairly well represented, so whether I'm right or wrong this
> > doesn't seem like an issue to me :)
> >
> 
> They are. We've worked through it. But that doesn't mean potential users
> are getting our best solution or feeling well integrated into the community.
> 
> > Having common targets (constellations, reference architectures,
> > whatever) so all the config systems build the same things (or a subset
> > or superset of the same things) seems like it would have benefits all
> > around.
> >
> 
> It will. It's a good first step. But I'd like to see a world where developers 
> are
> all well versed in how operators actually use OpenStack.

Hear, hear!  +1000  Take a developer to work during peak operations.

For Walmart, that would be Black Firday/Cyber Monday.
For schools, usually a few days into the new session.
For otherseach has a time when things break more.  Having a developer 
experience what operators do to predict/avoid/recover/work around the normal 
state of operations would help each to understand the macro work flows.  Those 
are important, too.  Full stack includes Ops.

< Snark off />

--Rocky

> 
> __
> 
> 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] [ptg] Simplification in OpenStack

[Clint Byrum]

Excerpts from Jonathan Proulx's message of 2017-09-26 16:01:26 -0400:
> On Tue, Sep 26, 2017 at 12:16:30PM -0700, Clint Byrum wrote:
> 
> :OpenStack is big. Big enough that a user will likely be fine with learning
> :a new set of tools to manage it.
> 
> New users in the startup sense of new, probably.
> 
> People with entrenched environments, I doubt it.
> 

Sorry no, I mean everyone who doesn't have an OpenStack already.

It's nice and all, if you're a Puppet shop, to get to use the puppet
modules. But it doesn't bring you any closer to the developers as a
group. Maybe a few use Puppet, but most don't. And that means you are
going to feel like OpenStack gets thrown over the wall at you once every
6 months.

> But OpenStack is big. Big enough I think all the major config systems
> are fairly well represented, so whether I'm right or wrong this
> doesn't seem like an issue to me :)
> 

They are. We've worked through it. But that doesn't mean potential
users are getting our best solution or feeling well integrated into
the community.

> Having common targets (constellations, reference architectures,
> whatever) so all the config systems build the same things (or a subset
> or superset of the same things) seems like it would have benefits all
> around.
> 

It will. It's a good first step. But I'd like to see a world where
developers are all well versed in how operators actually use OpenStack.

__
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] [ptg] Simplification in OpenStack

[Samuel Cassiba]

Michał Jastrzębski  wrote:


On 26 September 2017 at 13:54, Alex Schultz  wrote:
On Tue, Sep 26, 2017 at 2:34 PM, Michał Jastrzębski   
wrote:

In Kolla, during this PTG, we came up with idea of scenario based
testing+documentation. Basically what we want to do is to provide set
of kolla configurations, howtos and tempest configs to test out
different "constellations" or use-cases. If, instead of in Kolla, do
these in cross-community manner (and just host kolla-specific things
in kolla), I think that would partially address what you're asking for
here.


So I'd like to point out that we do a lot of these similar deployments
in puppet[0] and tripleo[1] for a while now but more to get the most
coverage out of the fewest jobs in terms of CI.  They aren't
necessarily realistic deployment use cases. We can't actually fully
test deployment scenarios given the limited resources available.

The problem with trying to push the constellation concept to
deployment tools is that you're effectively saying in that the
upstream isn't going to bother to doing it and is relying on an
understaffed (see chef/puppet people emails) groups to now implement
the thing you expect end users to use.  Simplification in openstack
needs to not be pushed off to someone else as we're all responsible
for it.  Have you seen the number of feature/configuration options the
upstream services have? Now multiply by 20-30. Welcome to OpenStack
configuration management.  Oh an try and keep up with all the new ones
and the ones being deprecated every 6 months. /me cries

Honestly it's time to stop saying yes to things unless they have some
sort of minimum viability or it makes sense why we would force it on
the end user (as confirmed by the end user, not because it sounds like
a good idea).

OpenStack has always been a pick your poison and construct your own
cloud. The problem is that those pieces used for building are getting
more complex and have even more inter-dependencies being added each
cycle without a simple way for the operator to install or be able to
migrate between versions.

Thanks,
-Alex

[0] https://github.com/openstack/puppet-openstack-integration
[1]  
https://docs.openstack.org/tripleo-quickstart/latest/feature-configuration.html


Right, I don't think anyone considers addressing *all* of them... But
if you break down actual use cases, most people wants nova (qemu+kvm),
nautron (vxlan, potentially vlan), cinder+ceph ... if we agree to
cover 90% of users, that'll boil down to 4-5 different
"constellations". If you want fancy networking, we will try out best
to make it possible, but not necessarily as easy as just 20 or so node
mini private cloud for vms. I think if we could provide these 4 or 5
use cases, easy to deploy and manage, provide testing suite so people
can validate env, provide robust upgrades and so on, that alone would
make a lot of people happy.


I’ve been working to make OpenStack work in my local testing environment,
and it boiled down to this issue:
https://github.com/test-kitchen/test-kitchen/issues/873 - tl;dr being that  
while

everyone was generally +1, no paying customers pressed the issue enough
to allocate time from one of a small number of qualified people to implement
it. The main problem is the deficiency around machine orchestration, which
is not just a Chef problem. Look across the board and you’ll see everyone
has hacked their own way, which sorta works so long as you don’t sneeze
too hard near it. What works for one doesn’t work for the other and so on.

Why did I single out test-kitchen? It’s pluggable using community resources,
meaning that I can test Puppet, Ansible and Chef, on Ubuntu 16.04 and  
CentOS 7

all using the same tool on the same set of hardware. I am, by no means,
advocating burning down CI for it, but using an example from my realm. An
idempotent, repeatable, maintainable deployment would make a lot of people
happy, too.

The install docs still suggest hand configuring machines in 2017. It’s only  
after

people fall down that snake pit that they find projects like
TripleO/Ansible/Puppet/Chef, and wonder why everyone doesn’t use this stuff.
The established shops that are already using one of those methods will keep  
on
keeping on, so long as the pain is tolerable. It’s not that we have to pick  
one
thing at the detriment of others, but simply make people more aware of what  
is
out there that they don’t have to sacrifice small children and animals to  
get a working
cloud. The problem is, we keep kicking the can on who owns that bullhorn,  
so it

doesn’t get done.

However, I digress. The conversations about scenarios have happened in my  
area,
too, and while we agreed that it would be a worthwhile thing, there was no  
one

person who could reasonably take on such an undertaking. It’s all grand until
the elusive Nobody gets assigned all the work.




On 26 September 2017 at 13:01, Jonathan Proulx  

Re: [openstack-dev] [ptg] Simplification in OpenStack

[Michał Jastrzębski]

On 26 September 2017 at 13:54, Alex Schultz  wrote:
> On Tue, Sep 26, 2017 at 2:34 PM, Michał Jastrzębski  wrote:
>> In Kolla, during this PTG, we came up with idea of scenario based
>> testing+documentation. Basically what we want to do is to provide set
>> of kolla configurations, howtos and tempest configs to test out
>> different "constellations" or use-cases. If, instead of in Kolla, do
>> these in cross-community manner (and just host kolla-specific things
>> in kolla), I think that would partially address what you're asking for
>> here.
>>
>
> So I'd like to point out that we do a lot of these similar deployments
> in puppet[0] and tripleo[1] for a while now but more to get the most
> coverage out of the fewest jobs in terms of CI.  They aren't
> necessarily realistic deployment use cases. We can't actually fully
> test deployment scenarios given the limited resources available.
>
> The problem with trying to push the constellation concept to
> deployment tools is that you're effectively saying in that the
> upstream isn't going to bother to doing it and is relying on an
> understaffed (see chef/puppet people emails) groups to now implement
> the thing you expect end users to use.  Simplification in openstack
> needs to not be pushed off to someone else as we're all responsible
> for it.  Have you seen the number of feature/configuration options the
> upstream services have? Now multiply by 20-30. Welcome to OpenStack
> configuration management.  Oh an try and keep up with all the new ones
> and the ones being deprecated every 6 months. /me cries
>
> Honestly it's time to stop saying yes to things unless they have some
> sort of minimum viability or it makes sense why we would force it on
> the end user (as confirmed by the end user, not because it sounds like
> a good idea).
>
> OpenStack has always been a pick your poison and construct your own
> cloud. The problem is that those pieces used for building are getting
> more complex and have even more inter-dependencies being added each
> cycle without a simple way for the operator to install or be able to
> migrate between versions.
>
> Thanks,
> -Alex
>
> [0] https://github.com/openstack/puppet-openstack-integration
> [1] 
> https://docs.openstack.org/tripleo-quickstart/latest/feature-configuration.html

Right, I don't think anyone considers addressing *all* of them... But
if you break down actual use cases, most people wants nova (qemu+kvm),
nautron (vxlan, potentially vlan), cinder+ceph ... if we agree to
cover 90% of users, that'll boil down to 4-5 different
"constellations". If you want fancy networking, we will try out best
to make it possible, but not necessarily as easy as just 20 or so node
mini private cloud for vms. I think if we could provide these 4 or 5
use cases, easy to deploy and manage, provide testing suite so people
can validate env, provide robust upgrades and so on, that alone would
make a lot of people happy.

>> On 26 September 2017 at 13:01, Jonathan Proulx  wrote:
>>> On Tue, Sep 26, 2017 at 12:16:30PM -0700, Clint Byrum wrote:
>>>
>>> :OpenStack is big. Big enough that a user will likely be fine with learning
>>> :a new set of tools to manage it.
>>>
>>> New users in the startup sense of new, probably.
>>>
>>> People with entrenched environments, I doubt it.
>>>
>>> But OpenStack is big. Big enough I think all the major config systems
>>> are fairly well represented, so whether I'm right or wrong this
>>> doesn't seem like an issue to me :)
>>>
>>> Having common targets (constellations, reference architectures,
>>> whatever) so all the config systems build the same things (or a subset
>>> or superset of the same things) seems like it would have benefits all
>>> around.
>>>
>>> -Jon
>>>
>>> __
>>> 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
>
> __
> 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] [ptg] Simplification in OpenStack

[Alex Schultz]

On Tue, Sep 26, 2017 at 2:34 PM, Michał Jastrzębski  wrote:
> In Kolla, during this PTG, we came up with idea of scenario based
> testing+documentation. Basically what we want to do is to provide set
> of kolla configurations, howtos and tempest configs to test out
> different "constellations" or use-cases. If, instead of in Kolla, do
> these in cross-community manner (and just host kolla-specific things
> in kolla), I think that would partially address what you're asking for
> here.
>

So I'd like to point out that we do a lot of these similar deployments
in puppet[0] and tripleo[1] for a while now but more to get the most
coverage out of the fewest jobs in terms of CI.  They aren't
necessarily realistic deployment use cases. We can't actually fully
test deployment scenarios given the limited resources available.

The problem with trying to push the constellation concept to
deployment tools is that you're effectively saying in that the
upstream isn't going to bother to doing it and is relying on an
understaffed (see chef/puppet people emails) groups to now implement
the thing you expect end users to use.  Simplification in openstack
needs to not be pushed off to someone else as we're all responsible
for it.  Have you seen the number of feature/configuration options the
upstream services have? Now multiply by 20-30. Welcome to OpenStack
configuration management.  Oh an try and keep up with all the new ones
and the ones being deprecated every 6 months. /me cries

Honestly it's time to stop saying yes to things unless they have some
sort of minimum viability or it makes sense why we would force it on
the end user (as confirmed by the end user, not because it sounds like
a good idea).

OpenStack has always been a pick your poison and construct your own
cloud. The problem is that those pieces used for building are getting
more complex and have even more inter-dependencies being added each
cycle without a simple way for the operator to install or be able to
migrate between versions.

Thanks,
-Alex

[0] https://github.com/openstack/puppet-openstack-integration
[1] 
https://docs.openstack.org/tripleo-quickstart/latest/feature-configuration.html

> On 26 September 2017 at 13:01, Jonathan Proulx  wrote:
>> On Tue, Sep 26, 2017 at 12:16:30PM -0700, Clint Byrum wrote:
>>
>> :OpenStack is big. Big enough that a user will likely be fine with learning
>> :a new set of tools to manage it.
>>
>> New users in the startup sense of new, probably.
>>
>> People with entrenched environments, I doubt it.
>>
>> But OpenStack is big. Big enough I think all the major config systems
>> are fairly well represented, so whether I'm right or wrong this
>> doesn't seem like an issue to me :)
>>
>> Having common targets (constellations, reference architectures,
>> whatever) so all the config systems build the same things (or a subset
>> or superset of the same things) seems like it would have benefits all
>> around.
>>
>> -Jon
>>
>> __
>> 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

__
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] [ptg] Simplification in OpenStack

[Jonathan Proulx]

On Tue, Sep 26, 2017 at 01:34:14PM -0700, Michał Jastrzębski wrote:
:In Kolla, during this PTG, we came up with idea of scenario based
:testing+documentation. Basically what we want to do is to provide set
:of kolla configurations, howtos and tempest configs to test out
:different "constellations" or use-cases. If, instead of in Kolla, do
:these in cross-community manner (and just host kolla-specific things
:in kolla), I think that would partially address what you're asking for
:here.

Yeas, that sounds like a great idea.

-Jon

:On 26 September 2017 at 13:01, Jonathan Proulx  wrote:
:> On Tue, Sep 26, 2017 at 12:16:30PM -0700, Clint Byrum wrote:
:>
:> :OpenStack is big. Big enough that a user will likely be fine with learning
:> :a new set of tools to manage it.
:>
:> New users in the startup sense of new, probably.
:>
:> People with entrenched environments, I doubt it.
:>
:> But OpenStack is big. Big enough I think all the major config systems
:> are fairly well represented, so whether I'm right or wrong this
:> doesn't seem like an issue to me :)
:>
:> Having common targets (constellations, reference architectures,
:> whatever) so all the config systems build the same things (or a subset
:> or superset of the same things) seems like it would have benefits all
:> around.
:>
:> -Jon
:>
:> __
:> 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

-- 

__
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] [ptg] Simplification in OpenStack

[Michał Jastrzębski]

In Kolla, during this PTG, we came up with idea of scenario based
testing+documentation. Basically what we want to do is to provide set
of kolla configurations, howtos and tempest configs to test out
different "constellations" or use-cases. If, instead of in Kolla, do
these in cross-community manner (and just host kolla-specific things
in kolla), I think that would partially address what you're asking for
here.

On 26 September 2017 at 13:01, Jonathan Proulx  wrote:
> On Tue, Sep 26, 2017 at 12:16:30PM -0700, Clint Byrum wrote:
>
> :OpenStack is big. Big enough that a user will likely be fine with learning
> :a new set of tools to manage it.
>
> New users in the startup sense of new, probably.
>
> People with entrenched environments, I doubt it.
>
> But OpenStack is big. Big enough I think all the major config systems
> are fairly well represented, so whether I'm right or wrong this
> doesn't seem like an issue to me :)
>
> Having common targets (constellations, reference architectures,
> whatever) so all the config systems build the same things (or a subset
> or superset of the same things) seems like it would have benefits all
> around.
>
> -Jon
>
> __
> 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] [ptg] Simplification in OpenStack

[Jonathan Proulx]

On Tue, Sep 26, 2017 at 12:16:30PM -0700, Clint Byrum wrote:

:OpenStack is big. Big enough that a user will likely be fine with learning
:a new set of tools to manage it.

New users in the startup sense of new, probably.

People with entrenched environments, I doubt it.

But OpenStack is big. Big enough I think all the major config systems
are fairly well represented, so whether I'm right or wrong this
doesn't seem like an issue to me :)

Having common targets (constellations, reference architectures,
whatever) so all the config systems build the same things (or a subset
or superset of the same things) seems like it would have benefits all
around.

-Jon

__
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] [ptg] Simplification in OpenStack

[Jay Pipes]

On 09/26/2017 02:04 AM, Blair Bethwaite wrote:

I've been watching this thread and I think we've already seen an
excellent and uncontroversial suggestion towards simplifying initial
deployment of OS - that was to push towards encoding Constellations
into the deployment and/or config management projects.


ack. +1 to this. I supported the constellation concept when it was 
originally proposed in the TC vision draft thing.


Best,
-jay

__
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] [ptg] Simplification in OpenStack

[Clint Byrum]

Excerpts from Samuel Cassiba's message of 2017-09-25 17:27:25 -0700:
> 
> > On Sep 25, 2017, at 16:52, Clint Byrum  wrote:
> > 
> > Excerpts from Jonathan D. Proulx's message of 2017-09-25 11:18:51 -0400:
> >> On Sat, Sep 23, 2017 at 12:05:38AM -0700, Adam Lawson wrote:
> >> 
> >> :Lastly, I do think GUI's make deployments easier and because of that, I
> >> :feel they're critical. There is more than one vendor whose built and
> >> :distributes a free GUI to ease OpenStack deployment and management. That's
> >> :a good start but those are the opinions of a specific vendor - not he OS
> >> :community. I have always been a big believer in a default cloud
> >> :configuration to ease the shock of having so many options for everything. 
> >> I
> >> :have a feeling however our commercial community will struggle with
> >> :accepting any method/project other than their own as being part a default
> >> :config. That will be a tough one to crack.
> >> 
> >> Different people have differnt needs, so this is not meant to
> >> contradict Adam.
> >> 
> >> But :)
> >> 
> >> Any unique deployment tool would be of no value to me as OpenStack (or
> >> anyother infrastructure component) needs to fit into my environment.
> >> I'm not going to adopt something new that requires a new parallel
> >> management tool to what I use.
> >> 
> > 
> > You already have that if you run OpenStack.
> > 
> > The majority of development testing and gate testing happens via
> > Devstack. A parallel management tool to what most people use to actually
> > operate OpenStack.
> > 
> >> I think focusing on the existing configuration management projects it
> >> the way to go. Getting Ansible/Puppet/Chef/etc.. to support a well
> >> know set of "constellations" in an opinionated would make deployment
> >> easy (for most people who are using one of those already) and ,
> >> ussuming the opionions are the same :) make consumption easier as
> >> well.
> >> 
> >> As an example when I started using OpenStack (Essex) we  had recently
> >> switch to Ubuntu as our Linux platform and Pupept as our config
> >> management. Ubuntu had a "one click MAAS install of OpenStack" which
> >> was impossible as it made all sorts of assumptions about our
> >> environment and wanted controll of most of them so it could provide a
> >> full deployemnt solution.  Puppet had a good integrated example config
> >> where I plugged in some local choices and and used existing deploy
> >> methodologies.
> >> 
> >> I fought with MAAS's "simple" install for a week.  When I gave up and
> >> went with Puppet I had live users on a substantial (for the time)
> >> cloud in less htan 2 days.
> >> 
> >> I don't think this has to do with the relative value of MASS and
> >> Puppet at the time, but rather what fit my existing deploy workflows.
> >> 
> >> Supporting multiple config tools may not be simple from an upstream
> >> perspective, but we do already have these projects and it is simpler
> >> to consume for brown field deployers at least.
> >> 
> > 
> > I don't think anybody is saying we would slam the door in the face of
> > people who use any one set of tools.
> > 
> > But rather, we'd start promoting and using a single solution for the bulk
> > of community efforts. Right now we do that with devstack as a reference
> > implementation that nobody should use for anything but dev/test. But
> > it would seem like a good idea for us to promote a tool for going live
> > as well.
> 
> Except by that very statement, you slam the door in the face of tons of 
> existing
> knowledge within organizations. This slope has a sheer face.
> 
> Promoting a single solution would do as much harm as it would good, for all 
> it’s
> worth. In such a scenario, the most advocated method would become the only
> understood method, in spite of all other deployment efforts. Each project that
> did not have the most mindshare would become more irrelevant than they are now
> and further slip into decay. For those that did not have the fortune or
> foresight to land on this hypothetical winning side, what for their efforts,
> evolve or gtfo?
> 
> I'm not saying Fuel or Salt or Chef or Puppet or Ansible needs to be the
> 'winner', because there isn't a competition, at least in my opinion. The way I
> see it, we're all working to get to the same place. Our downstream consumers
> don’t really care how that happens in the grand scheme, only that it does.
> 

I definitely think you're right, those that aren't chosen will be
relegated to the 'contrib' section and see less and less attention.

But they're already there. Everybody is already there. The suggestion
is that we shine a light on one so developers can at least have a more
realistic target to hit that they can have a conversation with users
about.

While I'm glad you have spent your time on Chef, I don't think it's the
best use of the community's time to learn all the tools. It is, however,
in the user's best interest that they have common ground 

Re: [openstack-dev] [ptg] Simplification in OpenStack

[Samuel Cassiba]

> On Sep 25, 2017, at 22:44, Adam Lawson  wrote:
> 
> Hey Jay,
> I think a GUI with a default config is a good start. Much would need to 
> happen to enable that of course but that's where my mind goes. Any talk about 
> 'default' kind of infringes on what we've all strived to embrace; a cloud 
> architecture without bakes in assumptions. A default-anything need not mean 
> other options are not available - only that a default gets them started. I 
> would never ever agree to a default that consists of KVM+Contrail+NetApp. 
> Something neutral would be great- easier said than done of course.
> 
> Samuel,
> Default configuration as I envision it != "Promoting a single solution". I 
> really hope a working default install would allow new users to get started 
> with OpeStack without promoting anything. OpenStack lacking a default install 
> results in an unfriendly deployment exercise. I know for a fact the entire 
> community at webhostingtalk.com ignores OS for the most part because of how 
> hard it is to deploy. They use Fuel or other third-party solutions because we 
> as a OS community continue to fail to acknowledge the importance of an easier 
> of implementation. Imagine thousands of hosting providers deploying OpenStack 
> because we made it easy. That is money in the bank IMHO. I totally get the 
> thinking about avoiding the term default for the reasons you provided but 
> giving users a starting point does not necessarily mean we're trying to get 
> them to adopt that as their final design. Giving them a starting point must 
> take precedence over not giving them any starting point.
> 

I’ll pick on my own second job for a moment, Chef. We have an amazing single 
node deployment strategy, and we have a so-so multinode deployment strategy for 
the simple fact that the orchestration story for every configuration management 
flavor equates to a dumpster fire in the middle of a tire fire. Let me be clear 
up front: I say ‘we’ a lot, but in many cases, the ‘we’ comes down to really 
just me. Not to discredit my teammates, I sleep a _lot_ less.

I've said it in the past, but Chef consist of nothing but part-timers with much 
more pressing issues at $dayJob[0]. If the README.md doesn’t get updated, it’s 
because none of us have the time to dedicate to evangelism. We talked about 
spreading the word back when we were still having IRC meetings, but it all 
boiled down to E_NOTIME.

As time has gone on, the roles in the Chef OpenStack project have been changing 
from less facilitator to more circus barker. It’s coming down to almost begging 
people for feedback, if we can find them. What I can do is provide a means to 
get to OpenStack about 80-90% of the way, provided the consumer can grok the 
tooling, key phrase. That said, we don’t teach people to use Chef, merely how 
one might OpenStack with it should they choose to kick the tires. The problem 
is, those potential downstream consumers, for some reason or other, don’t file 
bugs or even communicate back with the maintainers to get an idea if their 
problem would/could be addressed. They just move on, sight unseen and a bit 
grumpier. I can’t change that by doing more work.

If I shift gears to working on an installation method abstracted behind a GUI, 
am I now expected to bring in bits of Xorg simply so I can run that installer 
from my remote systems? Are your security people okay with Xorg on servers? 
Will the bootstrapping now take place entirely from a laptop/workstation, 
outright ignoring existing development workflows and pipelines? Who’s writing 
this code? Is there a GitHub repo where I can start testing this pièce de 
résistance?

If you’ll excuse the morning snark and “poisonous” words, as you put it a few 
days ago, I don’t necessarily see how bundling the install process into a 
graphical installer would help. If anything, it might prove more distraction 
than it’s worth because now there have to be graphical installer experts within 
whatever team(s) may be doing this effort.

Maybe it’s because I’ve been using Chef, the tool, for as long as I have, but 
it isn’t exactly a mash of random, disparate tooling that we’re using over 
here. We use community-standard tooling bundled in the ChefDK for the basic 
building blocks, even to our detriment at times. For integration testing, we 
used chef-provisioning until it rotted away, now being replaced by test-kitchen 
and InSpec. If anything, we were the ones lagging behind because we number so 
few and are beholden to E_NOTIME. Is there a knowledge barrier to entry? Sure 
is, and you do have to be this tall to ride. Those that do find the IRC channel 
and stick around long enough for one of us to respond generally get the 
assistance they need, but we’re not omnipresent.

As an operator in the deployment space, my whole point of contributing back is 
to make things less complicated. As PTL, my job isn’t to make Chef, the 
software, less complicated, but how to get to 

Re: [openstack-dev] [ptg] Simplification in OpenStack

[Blair Bethwaite]

I've been watching this thread and I think we've already seen an
excellent and uncontroversial suggestion towards simplifying initial
deployment of OS - that was to push towards encoding Constellations
into the deployment and/or config management projects.

On 26 September 2017 at 15:44, Adam Lawson  wrote:
> Hey Jay,
> I think a GUI with a default config is a good start. Much would need to
> happen to enable that of course but that's where my mind goes. Any talk
> about 'default' kind of infringes on what we've all strived to embrace; a
> cloud architecture without bakes in assumptions. A default-anything need not
> mean other options are not available - only that a default gets them
> started. I would never ever agree to a default that consists of
> KVM+Contrail+NetApp. Something neutral would be great- easier said than done
> of course.
>
> Samuel,
> Default configuration as I envision it != "Promoting a single solution". I
> really hope a working default install would allow new users to get started
> with OpeStack without promoting anything. OpenStack lacking a default
> install results in an unfriendly deployment exercise. I know for a fact the
> entire community at webhostingtalk.com ignores OS for the most part because
> of how hard it is to deploy. They use Fuel or other third-party solutions
> because we as a OS community continue to fail to acknowledge the importance
> of an easier of implementation. Imagine thousands of hosting providers
> deploying OpenStack because we made it easy. That is money in the bank IMHO.
> I totally get the thinking about avoiding the term default for the reasons
> you provided but giving users a starting point does not necessarily mean
> we're trying to get them to adopt that as their final design. Giving them a
> starting point must take precedence over not giving them any starting point.
>
> Jonathan,
> "I'm not going to adopt something new that requires a new parallel
> management tool to what I use." I would hope not! :) I don't mean having a
> tool means the tool is required. Only that a user-friendly deployment tool
> is available. Isn't that better than giving them nothing at all?
>
> //adam
>
>
> Adam Lawson
>
> Principal Architect
> Office: +1-916-794-5706
>
> On Mon, Sep 25, 2017 at 5:27 PM, Samuel Cassiba  wrote:
>>
>>
>> > On Sep 25, 2017, at 16:52, Clint Byrum  wrote:
>> >
>> > Excerpts from Jonathan D. Proulx's message of 2017-09-25 11:18:51 -0400:
>> >> On Sat, Sep 23, 2017 at 12:05:38AM -0700, Adam Lawson wrote:
>> >>
>> >> :Lastly, I do think GUI's make deployments easier and because of that,
>> >> I
>> >> :feel they're critical. There is more than one vendor whose built and
>> >> :distributes a free GUI to ease OpenStack deployment and management.
>> >> That's
>> >> :a good start but those are the opinions of a specific vendor - not he
>> >> OS
>> >> :community. I have always been a big believer in a default cloud
>> >> :configuration to ease the shock of having so many options for
>> >> everything. I
>> >> :have a feeling however our commercial community will struggle with
>> >> :accepting any method/project other than their own as being part a
>> >> default
>> >> :config. That will be a tough one to crack.
>> >>
>> >> Different people have differnt needs, so this is not meant to
>> >> contradict Adam.
>> >>
>> >> But :)
>> >>
>> >> Any unique deployment tool would be of no value to me as OpenStack (or
>> >> anyother infrastructure component) needs to fit into my environment.
>> >> I'm not going to adopt something new that requires a new parallel
>> >> management tool to what I use.
>> >>
>> >
>> > You already have that if you run OpenStack.
>> >
>> > The majority of development testing and gate testing happens via
>> > Devstack. A parallel management tool to what most people use to actually
>> > operate OpenStack.
>> >
>> >> I think focusing on the existing configuration management projects it
>> >> the way to go. Getting Ansible/Puppet/Chef/etc.. to support a well
>> >> know set of "constellations" in an opinionated would make deployment
>> >> easy (for most people who are using one of those already) and ,
>> >> ussuming the opionions are the same :) make consumption easier as
>> >> well.
>> >>
>> >> As an example when I started using OpenStack (Essex) we  had recently
>> >> switch to Ubuntu as our Linux platform and Pupept as our config
>> >> management. Ubuntu had a "one click MAAS install of OpenStack" which
>> >> was impossible as it made all sorts of assumptions about our
>> >> environment and wanted controll of most of them so it could provide a
>> >> full deployemnt solution.  Puppet had a good integrated example config
>> >> where I plugged in some local choices and and used existing deploy
>> >> methodologies.
>> >>
>> >> I fought with MAAS's "simple" install for a week.  When I gave up and
>> >> went with Puppet I had live users on a substantial (for the time)
>> >> cloud in less 

Re: [openstack-dev] [ptg] Simplification in OpenStack

[Adam Lawson]

Hey Jay,
I think a GUI with a default config is a good start. Much would need to
happen to enable that of course but that's where my mind goes. Any talk
about 'default' kind of infringes on what we've all strived to embrace; a
cloud architecture without bakes in assumptions. A default-anything need
not mean other options are not available - only that a default gets them
started. I would never ever agree to a default that consists of
KVM+Contrail+NetApp. Something neutral would be great- easier said than
done of course.

Samuel,
Default configuration as I envision it != "Promoting a single solution". I
really hope a working default install would allow new users to get started
with OpeStack without *promoting* anything. OpenStack lacking a default
install results in an unfriendly deployment exercise. I know for a fact the
entire community at webhostingtalk.com ignores OS for the most part because
of how hard it is to deploy. They use Fuel or other third-party solutions
because we as a OS community continue to fail to acknowledge the importance
of an easier of implementation. Imagine thousands of hosting providers
deploying OpenStack because we made it easy. That is money in the bank
IMHO. I totally get the thinking about avoiding the term default for the
reasons you provided but giving users a starting point does not necessarily
mean we're trying to get them to adopt that as their final design. Giving
them a starting point must take precedence over not giving them any
starting point.

Jonathan,
"I'm not going to adopt something new that requires a new parallel management
tool to what I use." I would hope not! :) I don't mean having a tool means
the tool is *required*. Only that a user-friendly deployment tool is
*available*. Isn't that better than giving them nothing at all?

//adam


*Adam Lawson*

Principal Architect
Office: +1-916-794-5706

On Mon, Sep 25, 2017 at 5:27 PM, Samuel Cassiba  wrote:

>
> > On Sep 25, 2017, at 16:52, Clint Byrum  wrote:
> >
> > Excerpts from Jonathan D. Proulx's message of 2017-09-25 11:18:51 -0400:
> >> On Sat, Sep 23, 2017 at 12:05:38AM -0700, Adam Lawson wrote:
> >>
> >> :Lastly, I do think GUI's make deployments easier and because of that, I
> >> :feel they're critical. There is more than one vendor whose built and
> >> :distributes a free GUI to ease OpenStack deployment and management.
> That's
> >> :a good start but those are the opinions of a specific vendor - not he
> OS
> >> :community. I have always been a big believer in a default cloud
> >> :configuration to ease the shock of having so many options for
> everything. I
> >> :have a feeling however our commercial community will struggle with
> >> :accepting any method/project other than their own as being part a
> default
> >> :config. That will be a tough one to crack.
> >>
> >> Different people have differnt needs, so this is not meant to
> >> contradict Adam.
> >>
> >> But :)
> >>
> >> Any unique deployment tool would be of no value to me as OpenStack (or
> >> anyother infrastructure component) needs to fit into my environment.
> >> I'm not going to adopt something new that requires a new parallel
> >> management tool to what I use.
> >>
> >
> > You already have that if you run OpenStack.
> >
> > The majority of development testing and gate testing happens via
> > Devstack. A parallel management tool to what most people use to actually
> > operate OpenStack.
> >
> >> I think focusing on the existing configuration management projects it
> >> the way to go. Getting Ansible/Puppet/Chef/etc.. to support a well
> >> know set of "constellations" in an opinionated would make deployment
> >> easy (for most people who are using one of those already) and ,
> >> ussuming the opionions are the same :) make consumption easier as
> >> well.
> >>
> >> As an example when I started using OpenStack (Essex) we  had recently
> >> switch to Ubuntu as our Linux platform and Pupept as our config
> >> management. Ubuntu had a "one click MAAS install of OpenStack" which
> >> was impossible as it made all sorts of assumptions about our
> >> environment and wanted controll of most of them so it could provide a
> >> full deployemnt solution.  Puppet had a good integrated example config
> >> where I plugged in some local choices and and used existing deploy
> >> methodologies.
> >>
> >> I fought with MAAS's "simple" install for a week.  When I gave up and
> >> went with Puppet I had live users on a substantial (for the time)
> >> cloud in less htan 2 days.
> >>
> >> I don't think this has to do with the relative value of MASS and
> >> Puppet at the time, but rather what fit my existing deploy workflows.
> >>
> >> Supporting multiple config tools may not be simple from an upstream
> >> perspective, but we do already have these projects and it is simpler
> >> to consume for brown field deployers at least.
> >>
> >
> > I don't think anybody is saying we would slam the door in the face of
> > people who use 

Re: [openstack-dev] [ptg] Simplification in OpenStack

[Samuel Cassiba]

> On Sep 25, 2017, at 16:52, Clint Byrum  wrote:
> 
> Excerpts from Jonathan D. Proulx's message of 2017-09-25 11:18:51 -0400:
>> On Sat, Sep 23, 2017 at 12:05:38AM -0700, Adam Lawson wrote:
>> 
>> :Lastly, I do think GUI's make deployments easier and because of that, I
>> :feel they're critical. There is more than one vendor whose built and
>> :distributes a free GUI to ease OpenStack deployment and management. That's
>> :a good start but those are the opinions of a specific vendor - not he OS
>> :community. I have always been a big believer in a default cloud
>> :configuration to ease the shock of having so many options for everything. I
>> :have a feeling however our commercial community will struggle with
>> :accepting any method/project other than their own as being part a default
>> :config. That will be a tough one to crack.
>> 
>> Different people have differnt needs, so this is not meant to
>> contradict Adam.
>> 
>> But :)
>> 
>> Any unique deployment tool would be of no value to me as OpenStack (or
>> anyother infrastructure component) needs to fit into my environment.
>> I'm not going to adopt something new that requires a new parallel
>> management tool to what I use.
>> 
> 
> You already have that if you run OpenStack.
> 
> The majority of development testing and gate testing happens via
> Devstack. A parallel management tool to what most people use to actually
> operate OpenStack.
> 
>> I think focusing on the existing configuration management projects it
>> the way to go. Getting Ansible/Puppet/Chef/etc.. to support a well
>> know set of "constellations" in an opinionated would make deployment
>> easy (for most people who are using one of those already) and ,
>> ussuming the opionions are the same :) make consumption easier as
>> well.
>> 
>> As an example when I started using OpenStack (Essex) we  had recently
>> switch to Ubuntu as our Linux platform and Pupept as our config
>> management. Ubuntu had a "one click MAAS install of OpenStack" which
>> was impossible as it made all sorts of assumptions about our
>> environment and wanted controll of most of them so it could provide a
>> full deployemnt solution.  Puppet had a good integrated example config
>> where I plugged in some local choices and and used existing deploy
>> methodologies.
>> 
>> I fought with MAAS's "simple" install for a week.  When I gave up and
>> went with Puppet I had live users on a substantial (for the time)
>> cloud in less htan 2 days.
>> 
>> I don't think this has to do with the relative value of MASS and
>> Puppet at the time, but rather what fit my existing deploy workflows.
>> 
>> Supporting multiple config tools may not be simple from an upstream
>> perspective, but we do already have these projects and it is simpler
>> to consume for brown field deployers at least.
>> 
> 
> I don't think anybody is saying we would slam the door in the face of
> people who use any one set of tools.
> 
> But rather, we'd start promoting and using a single solution for the bulk
> of community efforts. Right now we do that with devstack as a reference
> implementation that nobody should use for anything but dev/test. But
> it would seem like a good idea for us to promote a tool for going live
> as well.

Except by that very statement, you slam the door in the face of tons of existing
knowledge within organizations. This slope has a sheer face.

Promoting a single solution would do as much harm as it would good, for all it’s
worth. In such a scenario, the most advocated method would become the only
understood method, in spite of all other deployment efforts. Each project that
did not have the most mindshare would become more irrelevant than they are now
and further slip into decay. For those that did not have the fortune or
foresight to land on this hypothetical winning side, what for their efforts,
evolve or gtfo?

I'm not saying Fuel or Salt or Chef or Puppet or Ansible needs to be the
'winner', because there isn't a competition, at least in my opinion. The way I
see it, we're all working to get to the same place. Our downstream consumers
don’t really care how that happens in the grand scheme, only that it does.

> 
> __
> 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] [ptg] Simplification in OpenStack

[Clint Byrum]

Excerpts from Jonathan D. Proulx's message of 2017-09-25 11:18:51 -0400:
> On Sat, Sep 23, 2017 at 12:05:38AM -0700, Adam Lawson wrote:
> 
> :Lastly, I do think GUI's make deployments easier and because of that, I
> :feel they're critical. There is more than one vendor whose built and
> :distributes a free GUI to ease OpenStack deployment and management. That's
> :a good start but those are the opinions of a specific vendor - not he OS
> :community. I have always been a big believer in a default cloud
> :configuration to ease the shock of having so many options for everything. I
> :have a feeling however our commercial community will struggle with
> :accepting any method/project other than their own as being part a default
> :config. That will be a tough one to crack.
> 
> Different people have differnt needs, so this is not meant to
> contradict Adam.
> 
> But :)
> 
> Any unique deployment tool would be of no value to me as OpenStack (or
> anyother infrastructure component) needs to fit into my environment.
> I'm not going to adopt something new that requires a new parallel
> management tool to what I use.
> 

You already have that if you run OpenStack.

The majority of development testing and gate testing happens via
Devstack. A parallel management tool to what most people use to actually
operate OpenStack.

> I think focusing on the existing configuration management projects it
> the way to go. Getting Ansible/Puppet/Chef/etc.. to support a well
> know set of "constellations" in an opinionated would make deployment
> easy (for most people who are using one of those already) and ,
> ussuming the opionions are the same :) make consumption easier as
> well.
> 
> As an example when I started using OpenStack (Essex) we  had recently
> switch to Ubuntu as our Linux platform and Pupept as our config
> management. Ubuntu had a "one click MAAS install of OpenStack" which
> was impossible as it made all sorts of assumptions about our
> environment and wanted controll of most of them so it could provide a
> full deployemnt solution.  Puppet had a good integrated example config
> where I plugged in some local choices and and used existing deploy
> methodologies.
> 
> I fought with MAAS's "simple" install for a week.  When I gave up and
> went with Puppet I had live users on a substantial (for the time)
> cloud in less htan 2 days.
> 
> I don't think this has to do with the relative value of MASS and
> Puppet at the time, but rather what fit my existing deploy workflows.
> 
> Supporting multiple config tools may not be simple from an upstream
> perspective, but we do already have these projects and it is simpler
> to consume for brown field deployers at least.
> 

I don't think anybody is saying we would slam the door in the face of
people who use any one set of tools.

But rather, we'd start promoting and using a single solution for the bulk
of community efforts. Right now we do that with devstack as a reference
implementation that nobody should use for anything but dev/test. But
it would seem like a good idea for us to promote a tool for going live
as well.

__
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] [ptg] Simplification in OpenStack

[Jonathan D. Proulx]

On Sat, Sep 23, 2017 at 12:05:38AM -0700, Adam Lawson wrote:

:Lastly, I do think GUI's make deployments easier and because of that, I
:feel they're critical. There is more than one vendor whose built and
:distributes a free GUI to ease OpenStack deployment and management. That's
:a good start but those are the opinions of a specific vendor - not he OS
:community. I have always been a big believer in a default cloud
:configuration to ease the shock of having so many options for everything. I
:have a feeling however our commercial community will struggle with
:accepting any method/project other than their own as being part a default
:config. That will be a tough one to crack.

Different people have differnt needs, so this is not meant to
contradict Adam.

But :)

Any unique deployment tool would be of no value to me as OpenStack (or
anyother infrastructure component) needs to fit into my environment.
I'm not going to adopt something new that requires a new parallel
management tool to what I use.

I think focusing on the existing configuration management projects it
the way to go. Getting Ansible/Puppet/Chef/etc.. to support a well
know set of "constellations" in an opinionated would make deployment
easy (for most people who are using one of those already) and ,
ussuming the opionions are the same :) make consumption easier as
well.

As an example when I started using OpenStack (Essex) we  had recently
switch to Ubuntu as our Linux platform and Pupept as our config
management. Ubuntu had a "one click MAAS install of OpenStack" which
was impossible as it made all sorts of assumptions about our
environment and wanted controll of most of them so it could provide a
full deployemnt solution.  Puppet had a good integrated example config
where I plugged in some local choices and and used existing deploy
methodologies.

I fought with MAAS's "simple" install for a week.  When I gave up and
went with Puppet I had live users on a substantial (for the time)
cloud in less htan 2 days.

I don't think this has to do with the relative value of MASS and
Puppet at the time, but rather what fit my existing deploy workflows.

Supporting multiple config tools may not be simple from an upstream
perspective, but we do already have these projects and it is simpler
to consume for brown field deployers at least.

-Jon

:That's what I got tonight. hve a great weekend.
:
://adam
:
:
:*Adam Lawson*
:
:Principal Architect
:Office: +1-916-794-5706
:
:On Thu, Sep 21, 2017 at 11:23 AM, Clint Byrum  wrote:
:
:> Excerpts from Jeremy Stanley's message of 2017-09-21 16:17:00 +:
:> > On 2017-09-20 17:39:38 -0700 (-0700), Clint Byrum wrote:
:> > [...]
:> > > Something about common use cases and the exact mix of
:> > > projects + configuration to get there, and testing it? Help?
:> > [...]
:> >
:> > Maybe you're thinking of the "constellations" suggestion? It found
:> > its way into the TC vision statement, though the earliest mention I
:> > can locate is in John's post to this ML thread:
:> >
:> > http://lists.openstack.org/pipermail/openstack-dev/2017-
:> April/115319.html
:> >
:>
:> Yes, constellations. Thanks!
:>
:> __
:> 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


-- 

__
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] [ptg] Simplification in OpenStack

[Jay Pipes]

Do you have any specific suggestions on things our community can do to
encourage adoption? I hear lots of complaints but not many specific
suggestions.

-jay

On Sep 23, 2017 3:07 AM, "Adam Lawson"  wrote:

> Quick note (started quick anyway) since I haven't been as active on this
> list as I have in the past.
>
> Two things:
>
>1. Great topic and addresses a historical, persistent well-known
>problem with OpenStack - complexity. Technology is useless if it's so
>complex new organizations can't get it to work easily or reliably.
>
>2. I'm gonna call it as I'm seeing it: it makes me sick to read
>statements/replies by some members taking the time to itemize every single
>suggestion by another member to simplify OpenStack with one snarky remark
>after another. Thankfully (hopefully?) the influence of those individuals
>will lessen over time. It's literally poisonous to read and holds no value.
>
> Okay aside from that, as an OpenStack architect now increasing my focus on
> AWS/GCP as well as OpenStack, I would suggest there are two key areas with
> OpenStack that desperately need to be simplified: the architecture and the
> implementation. I never hear people say the architecture is too complex so
> while that can see some improvements, what I hear over and over and over
> again is how hard it is to deploy OpenStack on more than one machine
> quickly and easily. I think that has to be the priority. Until deployments
> are easy and stable and 'just work', that's a missed opportunity and
> OpenStack will continue to scare away potential new users -- like we need
> any more of that. OpenStack is deep in the trough of disillusionment (my
> perception) whether others recognize it or not so anything that makes
> OpenStack adoption easier should be our Numero Uno goal.
>
> Lastly, I do think GUI's make deployments easier and because of that, I
> feel they're critical. There is more than one vendor whose built and
> distributes a free GUI to ease OpenStack deployment and management. That's
> a good start but those are the opinions of a specific vendor - not he OS
> community. I have always been a big believer in a default cloud
> configuration to ease the shock of having so many options for everything. I
> have a feeling however our commercial community will struggle with
> accepting any method/project other than their own as being part a default
> config. That will be a tough one to crack.
>
> That's what I got tonight. hve a great weekend.
>
> //adam
>
>
> *Adam Lawson*
>
> Principal Architect
> Office: +1-916-794-5706 <(916)%20794-5706>
>
> On Thu, Sep 21, 2017 at 11:23 AM, Clint Byrum  wrote:
>
>> Excerpts from Jeremy Stanley's message of 2017-09-21 16:17:00 +:
>> > On 2017-09-20 17:39:38 -0700 (-0700), Clint Byrum wrote:
>> > [...]
>> > > Something about common use cases and the exact mix of
>> > > projects + configuration to get there, and testing it? Help?
>> > [...]
>> >
>> > Maybe you're thinking of the "constellations" suggestion? It found
>> > its way into the TC vision statement, though the earliest mention I
>> > can locate is in John's post to this ML thread:
>> >
>> > http://lists.openstack.org/pipermail/openstack-dev/2017-Apri
>> l/115319.html
>> >
>>
>> Yes, constellations. Thanks!
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>
__
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] [ptg] Simplification in OpenStack

[Adam Lawson]

Quick note (started quick anyway) since I haven't been as active on this
list as I have in the past.

Two things:

   1. Great topic and addresses a historical, persistent well-known problem
   with OpenStack - complexity. Technology is useless if it's so complex new
   organizations can't get it to work easily or reliably.

   2. I'm gonna call it as I'm seeing it: it makes me sick to read
   statements/replies by some members taking the time to itemize every single
   suggestion by another member to simplify OpenStack with one snarky remark
   after another. Thankfully (hopefully?) the influence of those individuals
   will lessen over time. It's literally poisonous to read and holds no value.

Okay aside from that, as an OpenStack architect now increasing my focus on
AWS/GCP as well as OpenStack, I would suggest there are two key areas with
OpenStack that desperately need to be simplified: the architecture and the
implementation. I never hear people say the architecture is too complex so
while that can see some improvements, what I hear over and over and over
again is how hard it is to deploy OpenStack on more than one machine
quickly and easily. I think that has to be the priority. Until deployments
are easy and stable and 'just work', that's a missed opportunity and
OpenStack will continue to scare away potential new users -- like we need
any more of that. OpenStack is deep in the trough of disillusionment (my
perception) whether others recognize it or not so anything that makes
OpenStack adoption easier should be our Numero Uno goal.

Lastly, I do think GUI's make deployments easier and because of that, I
feel they're critical. There is more than one vendor whose built and
distributes a free GUI to ease OpenStack deployment and management. That's
a good start but those are the opinions of a specific vendor - not he OS
community. I have always been a big believer in a default cloud
configuration to ease the shock of having so many options for everything. I
have a feeling however our commercial community will struggle with
accepting any method/project other than their own as being part a default
config. That will be a tough one to crack.

That's what I got tonight. hve a great weekend.

//adam


*Adam Lawson*

Principal Architect
Office: +1-916-794-5706

On Thu, Sep 21, 2017 at 11:23 AM, Clint Byrum  wrote:

> Excerpts from Jeremy Stanley's message of 2017-09-21 16:17:00 +:
> > On 2017-09-20 17:39:38 -0700 (-0700), Clint Byrum wrote:
> > [...]
> > > Something about common use cases and the exact mix of
> > > projects + configuration to get there, and testing it? Help?
> > [...]
> >
> > Maybe you're thinking of the "constellations" suggestion? It found
> > its way into the TC vision statement, though the earliest mention I
> > can locate is in John's post to this ML thread:
> >
> > http://lists.openstack.org/pipermail/openstack-dev/2017-
> April/115319.html
> >
>
> Yes, constellations. Thanks!
>
> __
> 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] [ptg] Simplification in OpenStack

[Clint Byrum]

Excerpts from Jeremy Stanley's message of 2017-09-21 16:17:00 +:
> On 2017-09-20 17:39:38 -0700 (-0700), Clint Byrum wrote:
> [...]
> > Something about common use cases and the exact mix of
> > projects + configuration to get there, and testing it? Help?
> [...]
> 
> Maybe you're thinking of the "constellations" suggestion? It found
> its way into the TC vision statement, though the earliest mention I
> can locate is in John's post to this ML thread:
> 
> http://lists.openstack.org/pipermail/openstack-dev/2017-April/115319.html
> 

Yes, constellations. Thanks!

__
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] [ptg] Simplification in OpenStack

[Jeremy Stanley]

On 2017-09-20 17:39:38 -0700 (-0700), Clint Byrum wrote:
[...]
> Something about common use cases and the exact mix of
> projects + configuration to get there, and testing it? Help?
[...]

Maybe you're thinking of the "constellations" suggestion? It found
its way into the TC vision statement, though the earliest mention I
can locate is in John's post to this ML thread:

http://lists.openstack.org/pipermail/openstack-dev/2017-April/115319.html

-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
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] [ptg] Simplification in OpenStack

[Clint Byrum]

Wading in a bit late as I've been off-list for a while, but I have thoughts 
here.

Excerpts from Jay Pipes's message of 2017-09-13 13:44:55 -0400:
> On 09/12/2017 06:53 PM, Boris Pavlovic wrote:
> > Mike,
> > 
> > Great intiative, unfortunately I wasn't able to attend it, however I 
> > have some thoughts...
> > You can't simplify OpenStack just by fixing few issues that are 
> > described in the etherpad mostly..
> > 
> > TC should work on shrinking the OpenStack use cases and moving towards 
> > the product (box) complete solution instead of pieces of bunch barely 
> > related things..
> 
> OpenStack is not a product. It's a collection of projects that represent 
> a toolkit for various cloud-computing functionality.
>

I think Boris was suggesting that making it a product would simplify it.

I believe there is some effort under way to try this, but my brain
has ceased to remember what that effort is called or how it is being
implemented. Something about common use cases and the exact mix of
projects + configuration to get there, and testing it? Help?

> > *Simple things to improve: *
> > /This is going to allow community to work together, and actually get 
> > feedback in standard way, and incrementally improve quality. /
> > 
> > 1) There should be one and only one:
> > 1.1) deployment/packaging(may be docker) upgrade mechanism used by 
> > everybody
> 
> Good luck with that :) The likelihood of the deployer/packager community 
> agreeing on a single solution is zero.
> 

I think Boris is suggesting that the OpenStack development community
pick one to use, not the packaging and deployer community. The
only common thing dev has in this area is devstack, and that
has allowed dev to largely ignore issues they create because
they're not feeling the pain of the average user who is using
puppet/chef/ansible/tripleo/kolla/in-house-magic to deploy.

> > 1.2) monitoring/logging/tracing mechanism used by everybody
> 
> Also close to zero chance of agreeing on a single solution. Better to 
> focus instead on ensuring various service projects are monitorable and 
> transparent.
> 

I'm less enthused about this one as well. Monitoring, alerting, defining
business rules for what is broken and what isn't are very org-specific
things.

I also don't think OpenStack fails at this and there is plenty exposed
in clear ways for monitors to be created.

> > 1.3) way to configure all services (e.g. k8 etcd way)
> 
> Are you referring to the way to configure k8s services or the way to 
> configure/setup an *application* that is running on k8s? If the former, 
> then there is *not* a single way of configuring k8s services. If the 
> latter, there isn't a single way of configuring that either. In fact, 
> despite Helm being a popular new entrant to the k8s application package 
> format discussion, k8s itself is decidedly *not* opinionated about how 
> an application is configured. Use a CMDB, use Helm, use env variables, 
> use confd, use whatever. k8s doesn't care.
> 

We do have one way to configure things. Well.. two.

*) Startup-time things are configured in config files.
*) Run-time changable things are in databases fronted by admin APIs/tools.

> > 2) Projects must have standardize interface that allows these projects 
> > to use them in same way.
> 
> Give examples of services that communicate over *non-standard* 
> interfaces. I don't know of any.
> 

Agreed here too. I'd like to see a more clear separation between nova,
neutron, and cinder on the hypervisor, but the way they're coupled now
*is* standardized.

> > 3) Testing & R should be performed only against this standard deployment
> 
> Sorry, this is laughable. There will never be a standard deployment 
> because there are infinite use cases that infrastructure supports. 
> *Your* definition of what works for GoDaddy is decidedly different from 
> someone else's definition of what works for them.
> 

If there were a few well defined product definitions, there could be. It's
not laughable at all to me. devstack and the configs it creates are useful
for lightweight testing, but they're not necessarily representative of
the standard makeup of real-world clouds.

> > *Hard things to improve: *
> > 
> > OpenStack projects were split in far from ideal way, which leads to 
> > bunch of gaps that we have now:
> > 1.1) Code & functional duplications:  Quotas, Schedulers, Reservations, 
> > Health checks, Loggign, Tracing, 
> 
> There is certainly code duplication in some areas, yes.
> 

I feel like this de-duplication has been moving at the slow-but-consistent
pace anyone can hope for since it was noticed and oslo was created.

It's now at the things that are really hard to de-dupe like quotas and policy.

> > 1.2) Non optimal workflows (booting VM takes 400 DB requests) because 
> > data is stored in Cinder,Nova,Neutron
> 
> Sorry, I call bullshit on this. It does not take 400 DB requests to boot 
> a VM. Also: the DB is not at all the bottleneck in the VM launch 

Re: [openstack-dev] [ptg] Simplification in OpenStack

[Mike Perez]

On 15:53 Sep 12, Boris Pavlovic wrote:
> Mike,
> 
> Great intiative, unfortunately I wasn't able to attend it, however I have
> some thoughts...
> You can't simplify OpenStack just by fixing few issues that are described
> in the etherpad mostly..



Definitely agree that it's not going to be a few issues to fix. I purposely was
leading this effort being broad so we can take the comments of OpenStack being
complex, and have a conversation on what that actually means to people. 

The feedback from people on the etherpad, as well as the in person discussions
have been valuable in getting those different perspectives. Unfortunately
participation was low, but I'm interested in seeing if we can identify some
themes to have some actual doable objectives.

I appreciate you taking the time in writing up your feedback on this Boris.
I will make sure it's included in the more polished summary I'll be giving the
TC and the Board to act on. Thank you!

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] [ptg] Simplification in OpenStack

[Mike Perez]

Hey all,

I would like to encourage people from different teams to add items of
things they learned at the PTG about simplifying their own projects.
Maybe we can see some themes that can contribute to community wide
goals?

https://etherpad.openstack.org/p/simplifying-os

—
Mike Perez

On September 12, 2017 at 15:33:14, Mike Perez (thin...@gmail.com) wrote:
> Hey all,
>
> The session is over. I’m hanging near registration if anyone wants to discuss 
> things.
> Shout out to John for coming by on discussions with simplifying dependencies. 
> I welcome
> more packagers to join the discussion.
>
> https://etherpad.openstack.org/p/simplifying-os
>
> —
> Mike Perez
>
>
> On September 12, 2017 at 11:45:05, Mike Perez (thin...@gmail.com) wrote:
> > Hey all,
> >
> > Back in a joint meeting with the TC, UC, Foundation and The Board it was 
> > decided as an area
> > of OpenStack to focus was Simplifying OpenStack. This intentionally was 
> > very broad
> > so the community can kick start the conversation and help tackle some broad 
> > feedback
> > we get.
> >
> > Unfortunately yesterday there was a low turn out in the Simplification 
> > room. A group
> > of people from the Swift team, Kevin Fox and Swimingly were nice enough to 
> > start the conversation
> > and give some feedback. You can see our initial ether pad work here:
> >
> > https://etherpad.openstack.org/p/simplifying-os
> >
> > There are efforts happening everyday helping with this goal, and our team 
> > has made some
> > documented improvements that can be found in our report to the board within 
> > the ether
> > pad. I would like to take a step back with this opportunity to have in 
> > person discussions
> > for us to identify what are the area of simplifying that are worthwhile. 
> > I’m taking a
> break
> > from the room at the moment for lunch, but I encourage people at 13:30 
> > local time to meet
> > at the simplification room level b in the big thompson room. Thank you!
> >
> > —
> > Mike Perez
>

__
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] [ptg] Simplification in OpenStack

[Boris Pavlovic]

Jay,

OK, I'll bite.


This doesn't sound like a constructive discussion. Bye Bye.

Best regards,
Boris Pavlovic

On Thu, Sep 14, 2017 at 8:50 AM, Jay Pipes  wrote:

> OK, I'll bite.
>
> On 09/13/2017 08:56 PM, Boris Pavlovic wrote:
>
>> Jay,
>>
>> All that you say exactly explains the reason why more and more companies
>> are leaving OpenStack.
>>
>
> All that I say? The majority of what I was "saying" was actually asking
> you to back up your statements with actual proof points instead of making
> wild conjectures.
>
> Companies and actually end users care only about their things and how can
>> they get their job done. They want thing that they can run and support
>> easily and that resolves their problems.
>>
>
> No disagreement from me. That said, I fail to see what the above statement
> has to do with anything I wrote.
>
> They initially think that it's a good idea to take a OpenStack as a
>> Framework and build sort of product on top of it because it's so open and
>> large and everybody uses...
>>
>
> End users of OpenStack don't "build sort of product on top". End users of
> OpenStack call APIs or use Horizon to launch VMs, create networks, volumes,
> and whatever else those end users need for their own use cases.
>
> Soon they understand that OpenStack has very complicated operations
>> because it's not designed to be a product but rather framework and that the
>> complexity of running OpenStack is similar to development in house solution
>> and as time is spend they have only few options: move to public cloud or
>> some other private cloud solution...
>>
>
> Deployers of OpenStack use the method of installing and configuring
> OpenStack that matches best their cultural fit, experience and level of
> comfort with underlying technologies and vendors (packages vs. source vs.
> images, using a vendor distribution vs. going it alone, Chef vs. Puppet vs.
> Ansible vs. SaltStack vs. Terraform, etc). The way they configure OpenStack
> services is entirely dependent on the use cases they wish to support for
> their end users. And, to repeat myself, there is NO SINGLE USE CASE for
> infrastructure services like OpenStack. Therefore there is zero chance for
> a "standard deployment" of OpenStack becoming a reality.
>
> Just like there are myriad ways of deploying and configuring OpenStack,
> there are myriad ways of deploying and configuring k8s. Why? Because
> deploying and configuring highly distributed systems is a hard problem to
> solve. And maintaining and operating those systems is an even harder
> problem to solve.
>
> We as a community can continue saying that the current OpenStack approach
>> is the best
>>
>
> Nobody is saying that the current OpenStack approach is the best. I
> certainly have never said this. All that I have asked is that you actually
> back up your statements with proof points that demonstrate how and why a
> different approach to building software will lead to specific improvements
> in quality or user experience.
>
> and keep loosing customers/users/community, or change something
>> drastically, like bring technical leadership to OpenStack Foundation
>> that is going to act like benevolent dictator that focuses OpenStack
>> effort on shrinking uses cases, redesigning architecture and moving
>> to the right direction...
>>
>
> What *specifically* is the "right direction" for OpenStack to take?
> Please, as I asked you in the original response, provide actual details
> other than "we should have a monolithic application". Provide an argument
> as to how and why *your* direction is "right" for every user of OpenStack.
>
> When you say "technical leadership", what specifically are you wanting to
> see?
>
>
>> I know this all sounds like a big change, but let's be honest current
>> situation doesn't look healthy...
>> By the way, almost all successful projects in open source have benevolent
>> dictator and everybody is OK with that's how things works...
>>
>
> Who is the benevolent dictator of k8s? Who is the benevolent dictator of
> MySQL? Of PostgreSQL? Of etcd?
>
> You have a particularly myopic view of what "successful" is for open
> source, IMHO.
>
> Awesome news. I will keep this in mind when users (like GoDaddy) ask
>> Nova to never break anything ever and keep behaviour like scheduler
>> retries that represent giant technical debt.
>>
>> I am writing here on my behalf (using my personal email, if you haven't
>> seen), are we actually Open Source? or Enterprise Source?
>>
>> More over I don't think that what you say is going to be an issue for
>> GoDaddy, at least soon, because we still can't upgrade, because it's NP
>> complete problem (even if you run just core projects), which is what my
>> email was about, and I saw the same stories in bunch of other companies.
>>
>
> You continue to speak in hyperbole and generalizations. What
> *specifically* about your recommendations will improve the upgrade ability
> and story for OpenStack?
>
>  

Re: [openstack-dev] [ptg] Simplification in OpenStack

[Jay Pipes]

OK, I'll bite.

On 09/13/2017 08:56 PM, Boris Pavlovic wrote:

Jay,

All that you say exactly explains the reason why more and more companies 
are leaving OpenStack.


All that I say? The majority of what I was "saying" was actually asking 
you to back up your statements with actual proof points instead of 
making wild conjectures.


Companies and actually end users care only about their things and how 
can they get their job done. They want thing that they can run and 
support easily and that resolves their problems.


No disagreement from me. That said, I fail to see what the above 
statement has to do with anything I wrote.


They initially think that it's a good idea to take a OpenStack as a 
Framework and build sort of product on top of it because it's so open 
and large and everybody uses...


End users of OpenStack don't "build sort of product on top". End users 
of OpenStack call APIs or use Horizon to launch VMs, create networks, 
volumes, and whatever else those end users need for their own use cases.


Soon they understand that OpenStack has very complicated operations 
because it's not designed to be a product but rather framework and that 
the complexity of running OpenStack is similar to development in house 
solution and as time is spend they have only few options: move to public 
cloud or some other private cloud solution...


Deployers of OpenStack use the method of installing and configuring 
OpenStack that matches best their cultural fit, experience and level of 
comfort with underlying technologies and vendors (packages vs. source 
vs. images, using a vendor distribution vs. going it alone, Chef vs. 
Puppet vs. Ansible vs. SaltStack vs. Terraform, etc). The way they 
configure OpenStack services is entirely dependent on the use cases they 
wish to support for their end users. And, to repeat myself, there is NO 
SINGLE USE CASE for infrastructure services like OpenStack. Therefore 
there is zero chance for a "standard deployment" of OpenStack becoming a 
reality.


Just like there are myriad ways of deploying and configuring OpenStack, 
there are myriad ways of deploying and configuring k8s. Why? Because 
deploying and configuring highly distributed systems is a hard problem 
to solve. And maintaining and operating those systems is an even harder 
problem to solve.


We as a community can continue saying that the current OpenStack 
approach is the best


Nobody is saying that the current OpenStack approach is the best. I 
certainly have never said this. All that I have asked is that you 
actually back up your statements with proof points that demonstrate how 
and why a different approach to building software will lead to specific 
improvements in quality or user experience.



and keep loosing customers/users/community, or change something
drastically, like bring technical leadership to OpenStack Foundation
that is going to act like benevolent dictator that focuses OpenStack
effort on shrinking uses cases, redesigning architecture and moving
to the right direction...


What *specifically* is the "right direction" for OpenStack to take? 
Please, as I asked you in the original response, provide actual details 
other than "we should have a monolithic application". Provide an 
argument as to how and why *your* direction is "right" for every user of 
OpenStack.


When you say "technical leadership", what specifically are you wanting 
to see?




I know this all sounds like a big change, but let's be honest current 
situation doesn't look healthy...
By the way, almost all successful projects in open source have 
benevolent dictator and everybody is OK with that's how things works...


Who is the benevolent dictator of k8s? Who is the benevolent dictator of 
MySQL? Of PostgreSQL? Of etcd?


You have a particularly myopic view of what "successful" is for open 
source, IMHO.



Awesome news. I will keep this in mind when users (like GoDaddy) ask
Nova to never break anything ever and keep behaviour like scheduler
retries that represent giant technical debt.

I am writing here on my behalf (using my personal email, if you haven't 
seen), are we actually Open Source? or Enterprise Source?


More over I don't think that what you say is going to be an issue for 
GoDaddy, at least soon, because we still can't upgrade, because it's NP 
complete problem (even if you run just core projects), which is what my 
email was about, and I saw the same stories in bunch of other companies.


You continue to speak in hyperbole and generalizations. What 
*specifically* about your recommendations will improve the upgrade 
ability and story for OpenStack?



Yes, let's definitely go the opposite direction of microservices and
loosely coupled domains which is the best practices of software
development over the last two decades. While we're at it, let's
rewrite OpenStack projects in COBOL.

I really don't want to answer on this provocation, because it shifts the 
focus from major topic. 

Re: [openstack-dev] [ptg] Simplification in OpenStack

[Samuel Cassiba]

On Tue, Sep 12, 2017 at 3:53 PM, Boris Pavlovic  wrote:
> Mike,
>
> Great intiative, unfortunately I wasn't able to attend it, however I have
> some thoughts...
> You can't simplify OpenStack just by fixing few issues that are described in
> the etherpad mostly..

This is exactly how one gets started, though, by dragging the
skeletons to light. I, too, was unable to attend due to scheduling,
but as PTL of a project complicated by years of tech debt, before even
being an anointed OpenStack project, this topic is of particular
interest to me.

>
> TC should work on shrinking the OpenStack use cases and moving towards the
> product (box) complete solution instead of pieces of bunch barely related
> things..

I agree and disagree with what you say here. Shrinking use cases
misses the mark an order of magnitude or three. However, focusing on
the outcome is exactly what needs to happen for everyone to walk away
with the warm fuzzies, upstream and downstream alike.

>
> Simple things to improve:
> This is going to allow community to work together, and actually get feedback
> in standard way, and incrementally improve quality.
>
> 1) There should be one and only one:
> 1.1) deployment/packaging(may be docker) upgrade mechanism used by everybody
> 1.2) monitoring/logging/tracing mechanism used by everybody
> 1.3) way to configure all services (e.g. k8 etcd way)
> 2) Projects must have standardize interface that allows these projects to
> use them in same way.
> 3) Testing & R should be performed only against this standard deployment

You keep using that word. This feels like a "you can have it any color
you like, so long as it's black" argument. This is great for
manufacturing tangible products that sit on a shelf somewhere. Not so
much for a collection of software, already well into the maturation
phase, that is the collective output of hundreds, nay, thousands of
minds. What you propose almost never happens in practice, as nice as
it sounds. The outcome is significantly more important than what
people to do get there. I hereby refer to XKCD rule #927 on the topic
of standards, only partly in jest.

>
> Hard things to improve:
>
> OpenStack projects were split in far from ideal way, which leads to bunch of
> gaps that we have now:
> 1.1) Code & functional duplications:  Quotas, Schedulers, Reservations,
> Health checks, Loggign, Tracing, 

Yup. Large software projects have some duplication, it's natural and
requires occasional love. It takes people to actively battle the tech
debt, and not everyone has the luxury of a fully dedicated team.

> 1.2) Non optimal workflows (booting VM takes 400 DB requests) because data
> is stored in Cinder,Nova,Neutron

SQL is SQL, though, so I don't see what you're getting at. I'm sure
some things need some tuning and queries need some optimization, but I
hung up my DBA hat years ago.

> 1.3) Lack of resources (as every project is doing again and again same work
> about same parts)

I read that last part to mean people and not so much technical
limitations. If I've correctly read things with my corporate lens on,
that's a universal pain that is felt by nearly every specialized field
of work, and OpenStack is by no means unique. Downstream consumers of
OpenStack code are only willing to financially support so many
specialists, and they can support more than the Foundation. If the
problem is people, convince more people to contribute, since we're
remaking the universe.

>
> What we can do:
>
> 1) Simplify internal communication
> 1.1) Instead of AMQP for internal communication inside projects use just
> HTTP, load balancing & retries.

In my experiences, AMQP has mostly sat there in the background, until
someone comes along and touches it. We haven't touched the
openstack-ops-messaging cookbook beyond testing enhancements and
deprecations in at least a cycle because it just works. Retries just
mask an underlying problem. With my operator hat on, I don't want my
client to try N times if the service is intermittently failing.

>
> 2) Use API Gateway pattern
> 3.1) Provide to use high level API one IP address with one client
> 3.2) Allows to significant reduce load on Keystone because tokens are
> checked only in API gateway
> 3.3) Simplifies communication between projects (they are now in trusted
> network, no need to check token)

I don't see this as being something to beholden OpenStack development
teams to implement and maintain, even if people pay for this
functionality or implement it on their own. That's more of a use case,
not a feature request.

>
> 3) Fix the OpenStack split
> 3.1) Move common functionality to separated internal services: Scheduling,
> Logging, Monitoring, Tracing, Quotas, Reservations (it would be even better
> if this thing would have more or less monolithic architecture)

No, please, just... no. A monolithic architecture is fine for dev, but
it falls apart prematurely in the lifecycle when you throw the spurs
to it.

> 3.2) 

Re: [openstack-dev] [ptg] Simplification in OpenStack

[Boris Pavlovic]

Jay,

All that you say exactly explains the reason why more and more companies
are leaving OpenStack.

Companies and actually end users care only about their things and how can
they get their job done. They want thing that they can run and support
easily and that resolves their problems.

They initially think that it's a good idea to take a OpenStack as a
Framework and build sort of product on top of it because it's so open and
large and everybody uses...

Soon they understand that OpenStack has very complicated operations because
it's not designed to be a product but rather framework and that the
complexity of running OpenStack is similar to development in house solution
and as time is spend they have only few options: move to public cloud or
some other private cloud solution...

We as a community can continue saying that the current OpenStack approach
is the best and keep loosing customers/users/community, or change something
drastically, like bring technical leadership to OpenStack Foundation that
is going to act like benevolent dictator that  focuses OpenStack effort on
shrinking uses cases, redesigning architecture and moving to the right
direction...

I know this all sounds like a big change, but let's be honest current
situation doesn't look healthy...
By the way, almost all successful projects in open source have benevolent
dictator and everybody is OK with that's how things works...


Awesome news. I will keep this in mind when users (like GoDaddy) ask Nova
> to never break anything ever and keep behaviour like scheduler retries that
> represent giant technical debt.


I am writing here on my behalf (using my personal email, if you haven't
seen), are we actually Open Source? or Enterprise Source?

More over I don't think that what you say is going to be an issue for
GoDaddy, at least soon, because we still can't upgrade, because it's NP
complete problem (even if you run just core projects), which is what my
email was about, and I saw the same stories in bunch of other companies.


Yes, let's definitely go the opposite direction of microservices and
> loosely coupled domains which is the best practices of software development
> over the last two decades. While we're at it, let's rewrite OpenStack
> projects in COBOL.


I really don't want to answer on this provocation, because it shifts the
focus from major topic. But I really can't stop myself ;)

- There is no sliver bullet in programming. For example, would Git or Linux
be better if it was written using microservices approach?
- Mircroservices are obsolete you should use new hype thing called FaaS (I
am just curios when these FaaS fellow are going to implement modules for
FaaS and when they are going to understand that they will need actually
everything development in programming languages (OOP, AOP, DI, ...) to glue
these things;) )
- I was talking about architectural changes, not a programming language, so
it's sort of big type mismatch and logically wrong. However, what's wrong
with Cobol? If you use right architecture and right algorithms it will
definitely work better than implementation of program in any other language
with wrong architecture and bad algorithms... so not sure that I understand
this point/joke...


Best regards,
Boris Pavlovic

On Wed, Sep 13, 2017 at 10:44 AM, Jay Pipes  wrote:

> On 09/12/2017 06:53 PM, Boris Pavlovic wrote:
>
>> Mike,
>>
>> Great intiative, unfortunately I wasn't able to attend it, however I have
>> some thoughts...
>> You can't simplify OpenStack just by fixing few issues that are described
>> in the etherpad mostly..
>>
>> TC should work on shrinking the OpenStack use cases and moving towards
>> the product (box) complete solution instead of pieces of bunch barely
>> related things..
>>
>
> OpenStack is not a product. It's a collection of projects that represent a
> toolkit for various cloud-computing functionality.
>
> *Simple things to improve: *
>> /This is going to allow community to work together, and actually get
>> feedback in standard way, and incrementally improve quality. /
>>
>> 1) There should be one and only one:
>> 1.1) deployment/packaging(may be docker) upgrade mechanism used by
>> everybody
>>
>
> Good luck with that :) The likelihood of the deployer/packager community
> agreeing on a single solution is zero.
>
> 1.2) monitoring/logging/tracing mechanism used by everybody
>>
>
> Also close to zero chance of agreeing on a single solution. Better to
> focus instead on ensuring various service projects are monitorable and
> transparent.
>
> 1.3) way to configure all services (e.g. k8 etcd way)
>>
>
> Are you referring to the way to configure k8s services or the way to
> configure/setup an *application* that is running on k8s? If the former,
> then there is *not* a single way of configuring k8s services. If the
> latter, there isn't a single way of configuring that either. In fact,
> despite Helm being a popular new entrant to the k8s application package
> format 

Re: [openstack-dev] [ptg] Simplification in OpenStack

[Jay Pipes]

On 09/12/2017 06:53 PM, Boris Pavlovic wrote:

Mike,

Great intiative, unfortunately I wasn't able to attend it, however I 
have some thoughts...
You can't simplify OpenStack just by fixing few issues that are 
described in the etherpad mostly..


TC should work on shrinking the OpenStack use cases and moving towards 
the product (box) complete solution instead of pieces of bunch barely 
related things..


OpenStack is not a product. It's a collection of projects that represent 
a toolkit for various cloud-computing functionality.



*Simple things to improve: *
/This is going to allow community to work together, and actually get 
feedback in standard way, and incrementally improve quality. /


1) There should be one and only one:
1.1) deployment/packaging(may be docker) upgrade mechanism used by 
everybody


Good luck with that :) The likelihood of the deployer/packager community 
agreeing on a single solution is zero.



1.2) monitoring/logging/tracing mechanism used by everybody


Also close to zero chance of agreeing on a single solution. Better to 
focus instead on ensuring various service projects are monitorable and 
transparent.



1.3) way to configure all services (e.g. k8 etcd way)


Are you referring to the way to configure k8s services or the way to 
configure/setup an *application* that is running on k8s? If the former, 
then there is *not* a single way of configuring k8s services. If the 
latter, there isn't a single way of configuring that either. In fact, 
despite Helm being a popular new entrant to the k8s application package 
format discussion, k8s itself is decidedly *not* opinionated about how 
an application is configured. Use a CMDB, use Helm, use env variables, 
use confd, use whatever. k8s doesn't care.


2) Projects must have standardize interface that allows these projects 
to use them in same way.


Give examples of services that communicate over *non-standard* 
interfaces. I don't know of any.



3) Testing & R should be performed only against this standard deployment


Sorry, this is laughable. There will never be a standard deployment 
because there are infinite use cases that infrastructure supports. 
*Your* definition of what works for GoDaddy is decidedly different from 
someone else's definition of what works for them.



*Hard things to improve: *

OpenStack projects were split in far from ideal way, which leads to 
bunch of gaps that we have now:
1.1) Code & functional duplications:  Quotas, Schedulers, Reservations, 
Health checks, Loggign, Tracing, 


There is certainly code duplication in some areas, yes.

1.2) Non optimal workflows (booting VM takes 400 DB requests) because 
data is stored in Cinder,Nova,Neutron


Sorry, I call bullshit on this. It does not take 400 DB requests to boot 
a VM. Also: the DB is not at all the bottleneck in the VM launch 
process. You've been saying it is for years with no justification to 
back you up. Pointing to a Rally scenario that doesn't reflect a 
real-world usage of OpenStack services isn't useful.


1.3) Lack of resources (as every project is doing again and again same 
work about same parts)


Provide specific examples please.


What we can do:

*1) Simplify internal communication *
1.1) Instead of AMQP for internal communication inside projects use just 
HTTP, load balancing & retries.


Prove to me that this would solve a problem. First describe what the 
problem is, then show me that using AMQP is the source of that problem, 
then show me that using HTTP requests would solve that problem.



*2) Use API Gateway pattern *
3.1) Provide to use high level API one IP address with one client
3.2) Allows to significant reduce load on Keystone because tokens are 
checked only in API gateway
3.3) Simplifies communication between projects (they are now in trusted 
network, no need to check token)


Why is this a problem for OpenStack projects to deal with? If you want a 
single IP address for all APIs that your users consume, then simply 
deploy all the public-facing services on a single set of web servers and 
make each service's root endpoint be a subresource on the root IP/DNS name.



*3) Fix the OpenStack split *
3.1) Move common functionality to separated internal services: 
Scheduling, Logging, Monitoring, Tracing, Quotas, Reservations (it would 
be even better if this thing would have more or less monolithic 
architecture)


Yes, let's definitely go the opposite direction of microservices and 
loosely coupled domains which is the best practices of software 
development over the last two decades. While we're at it, let's rewrite 
OpenStack projects in COBOL.


3.2) Somehow deal with defragmentation of resources e.g. VM Volumes and 
Networks data which is heavily connected.


How are these things connected?


*4) Don't be afraid to break things*
Maybe it's time for OpenStack 2:

  * In any case most of people provide API on top of OpenStack for usage
  * In any case there is no standard and easy way to upgrade 

So 

Re: [openstack-dev] [ptg] Simplification in OpenStack

[Boris Pavlovic]

Mike,

Great intiative, unfortunately I wasn't able to attend it, however I have
some thoughts...
You can't simplify OpenStack just by fixing few issues that are described
in the etherpad mostly..

TC should work on shrinking the OpenStack use cases and moving towards the
product (box) complete solution instead of pieces of bunch barely related
things..

*Simple things to improve: *
*This is going to allow community to work together, and actually get
feedback in standard way, and incrementally improve quality. *

1) There should be one and only one:
1.1) deployment/packaging(may be docker) upgrade mechanism used by
everybody
1.2) monitoring/logging/tracing mechanism used by everybody
1.3) way to configure all services (e.g. k8 etcd way)
2) Projects must have standardize interface that allows these projects to
use them in same way.
3) Testing & R should be performed only against this standard deployment

*Hard things to improve: *

OpenStack projects were split in far from ideal way, which leads to bunch
of gaps that we have now:
1.1) Code & functional duplications:  Quotas, Schedulers, Reservations,
Health checks, Loggign, Tracing, 
1.2) Non optimal workflows (booting VM takes 400 DB requests) because data
is stored in Cinder,Nova,Neutron
1.3) Lack of resources (as every project is doing again and again same work
about same parts)

What we can do:

*1) Simplify internal communication *
1.1) Instead of AMQP for internal communication inside projects use just
HTTP, load balancing & retries.

*2) Use API Gateway pattern *
3.1) Provide to use high level API one IP address with one client
3.2) Allows to significant reduce load on Keystone because tokens are
checked only in API gateway
3.3) Simplifies communication between projects (they are now in trusted
network, no need to check token)

*3) Fix the OpenStack split *
3.1) Move common functionality to separated internal services: Scheduling,
Logging, Monitoring, Tracing, Quotas, Reservations (it would be even better
if this thing would have more or less monolithic architecture)
3.2) Somehow deal with defragmentation of resources e.g. VM Volumes and
Networks data which is heavily connected.


*4) Don't be afraid to break things*
Maybe it's time for OpenStack 2:

   - In any case most of people provide API on top of OpenStack for usage
   - In any case there is no standard and easy way to upgrade

So basically we are not losing anything even if we do not backward
compatible changes and rethink completely architecture and API.


I know this sounds like science fiction, but I believe community will
appreciate steps in this direction...


Best regards,
Boris Pavlovic

On Tue, Sep 12, 2017 at 2:33 PM, Mike Perez  wrote:

> Hey all,
>
> The session is over. I’m hanging near registration if anyone wants to
> discuss things. Shout out to John for coming by on discussions with
> simplifying dependencies. I welcome more packagers to join the
> discussion.
>
> https://etherpad.openstack.org/p/simplifying-os
>
> —
> Mike Perez
>
>
> On September 12, 2017 at 11:45:05, Mike Perez (thin...@gmail.com) wrote:
> > Hey all,
> >
> > Back in a joint meeting with the TC, UC, Foundation and The Board it was
> decided as an area
> > of OpenStack to focus was Simplifying OpenStack. This intentionally was
> very broad
> > so the community can kick start the conversation and help tackle some
> broad feedback
> > we get.
> >
> > Unfortunately yesterday there was a low turn out in the Simplification
> room. A group
> > of people from the Swift team, Kevin Fox and Swimingly were nice enough
> to start the conversation
> > and give some feedback. You can see our initial ether pad work here:
> >
> > https://etherpad.openstack.org/p/simplifying-os
> >
> > There are efforts happening everyday helping with this goal, and our
> team has made some
> > documented improvements that can be found in our report to the board
> within the ether
> > pad. I would like to take a step back with this opportunity to have in
> person discussions
> > for us to identify what are the area of simplifying that are worthwhile.
> I’m taking a break
> > from the room at the moment for lunch, but I encourage people at 13:30
> local time to meet
> > at the simplification room level b in the big thompson room. Thank you!
> >
> > —
> > Mike Perez
>
> __
> 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] [ptg] Simplification in OpenStack

[Mike Perez]

Hey all,

The session is over. I’m hanging near registration if anyone wants to
discuss things. Shout out to John for coming by on discussions with
simplifying dependencies. I welcome more packagers to join the
discussion.

https://etherpad.openstack.org/p/simplifying-os

—
Mike Perez


On September 12, 2017 at 11:45:05, Mike Perez (thin...@gmail.com) wrote:
> Hey all,
>
> Back in a joint meeting with the TC, UC, Foundation and The Board it was 
> decided as an area
> of OpenStack to focus was Simplifying OpenStack. This intentionally was very 
> broad
> so the community can kick start the conversation and help tackle some broad 
> feedback
> we get.
>
> Unfortunately yesterday there was a low turn out in the Simplification room. 
> A group
> of people from the Swift team, Kevin Fox and Swimingly were nice enough to 
> start the conversation
> and give some feedback. You can see our initial ether pad work here:
>
> https://etherpad.openstack.org/p/simplifying-os
>
> There are efforts happening everyday helping with this goal, and our team has 
> made some
> documented improvements that can be found in our report to the board within 
> the ether
> pad. I would like to take a step back with this opportunity to have in person 
> discussions
> for us to identify what are the area of simplifying that are worthwhile. I’m 
> taking a break
> from the room at the moment for lunch, but I encourage people at 13:30 local 
> time to meet
> at the simplification room level b in the big thompson room. Thank you!
>
> —
> Mike Perez

__
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