Open Stack

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

> 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