Michał Jastrzębski <inc...@gmail.com> wrote:
On 26 September 2017 at 13:54, Alex Schultz <aschu...@redhat.com> wrote:On Tue, Sep 26, 2017 at 2:34 PM, Michał Jastrzębski <inc...@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.htmlRight, 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 <j...@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-requ...@lists.openstack.org?subject:unsubscribehttp://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:unsubscribehttp://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
-- Best, Samuel Cassiba
signature.asc
Description: Message signed with OpenPGP
__________________________________________________________________________ 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
