Open Stack

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 <
tnapierala at mirantis.com> 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 <vkozhukalov at 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 <ikalnitsky at 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.Jerram at 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-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
>
> --
> Tomasz 'Zen' Napierala
> Product Engineering - Poland
>
>
>
>
>
>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160331/46cd89fa/attachment.html>