Hi, Problems which I see with current Shotgun are: 1. Luck of parallelism, so it's not going to fetch data fast enough from medium/big clouds. 2. There should be an easy way to run it manually (it's possible, but there is no ready-to-use config), it would be really helpful in case if Nailgun/Astute/MCollective are down.
As far as I know 1st is partly covered by Ansible, but the problem is it executes a single task in parallel, so there is probability that lagging node will slow down fetching from entire environment. Also we will have to build a tool around Ansible to generate playbooks. Thanks, On Wed, Mar 30, 2016 at 5:18 PM, Tomasz 'Zen' Napierala < [email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > 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: > [email protected]?subject:unsubscribe > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > [email protected]?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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
