Hi, Do we have any requirements for the new tool? Do we know what we don’t like about current implementation, what should be avoided, etc.? Before that we can only speculate. From my ops experience, shotgun like tools will not work conveniently on medium to big environments. Even on medium env amount of logs is just too huge to handle by such simple tool. In such environments better pattern is to use dedicated log collection / analysis tool, just like StackLight. At the other hand I’m not sure if ansible is the right tool for that. It has some features (like ‘fetch’ command) but in general it’s a configuration management tool, and I’m not sure how it would act under such heavy load.
Regards, > On 30 Mar 2016, at 15:20, Vladimir Kozhukalov <vkozhuka...@mirantis.com> > wrote: > > Igor, > > I can not agree more. Wherever possible we should > use existent mature solutions. Ansible is really > convenient and well known solution, let's try to > use it. > > Yet another thing should be taken into account. > One of Shotgun features is diagnostic report > that could then be attached to bugs to identify > the content of env. This report could also be > used to reproduce env and then fight a bug. > I'd like we to have this kind of report. > Is it possible to implement such a feature > using Ansible? If yes, then let's switch to Ansible > as soon as possible. > > > > Vladimir Kozhukalov > > On Wed, Mar 30, 2016 at 3:31 PM, Igor Kalnitsky <ikalnit...@mirantis.com> > wrote: > Neil Jerram wrote: > > But isn't Ansible also over-complicated for just running commands over SSH? > > It may be not so "simple" to ignore that. Ansible has a lot of modules > which might be very helpful. For instance, Shotgun makes a database > dump and there're Ansible modules with the same functionality [1]. > > Don't think I advocate Ansible as a replacement. My point is, let's > think about reusing ready solutions. :) > > - igor > > > [1]: http://docs.ansible.com/ansible/list_of_database_modules.html > > On Wed, Mar 30, 2016 at 1:14 PM, Neil Jerram <neil.jer...@metaswitch.com> > wrote: > > > > FWIW, as a naive bystander: > > > > On 30/03/16 11:06, Igor Kalnitsky wrote: > >> Hey Fuelers, > >> > >> I know that you probably wouldn't like to hear that, but in my opinion > >> Fuel has to stop using Shotgun. It's nothing more but a command runner > >> over SSH. Besides, it has well known issues such as retrieving remote > >> directories with broken symlinks inside. > > > > It makes sense to me that a command runner over SSH might not need to be > > a whole Fuel-specific component. > > > >> So I propose to find a modern alternative and reuse it. If we stop > >> supporting Shotgun, we can spend extra time to focus on more important > >> things. > >> > >> As an example, we can consider to use Ansible. It should not be tricky > >> to generate Ansible playbook instead of generating Shotgun one. > >> Ansible is a well known tool for devops and cloud operators, and they > >> we will only benefit if we provide possibility to extend diagnostic > >> recipes in usual (for them) way. What do you think? > > > > But isn't Ansible also over-complicated for just running commands over SSH? > > > > Neil > > > > > > __________________________________________________________________________ > > 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 -- Tomasz 'Zen' Napierala Product Engineering - Poland __________________________________________________________________________ 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
