Open Stack

Michał Jastrzębski <inc007 at gmail.com> wrote:

> On 26 September 2017 at 13:54, Alex Schultz <aschultz at redhat.com> wrote:
>> On Tue, Sep 26, 2017 at 2:34 PM, Michał Jastrzębski <inc007 at gmail.com>  
>> 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 <jon at csail.mit.edu> 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Best,

Samuel Cassiba
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170926/ee1420d5/attachment.sig>