<div dir="ltr">Hi,<div>I'd like to ask what's the current state of Shotgun and what are the plans for the future?</div><div>Is there any alternative chosen for Fuel diagnostic snapshot functionality and being worked on?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 18, 2016 at 3:39 PM, Igor Kalnitsky <span dir="ltr"><<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Evgeniy L. wrote:<br>
> I think such kind of tools should use as less as possible existing<br>
> infrastructure, because in case if something went wrong, you should<br>
> be able to easily get diagnostic information, even with broken RabbitMQ,<br>
> Astute and MCollective.<br>
<br>
</span>It's a good point indeed! Moreover, troubleshooting scenarios may vary<br>
from case to case, so it should be easily extendable and changeable.<br>
So users can use various (probably, downloaded) scenarios to gather<br>
diagnostic info.<br>
<br>
That's why I think Ansible could really be helpful here. Such<br>
scenarios may be distributed as Ansible playbooks.<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, Apr 18, 2016 at 4:25 PM, Evgeniy L <<a href="mailto:eli@mirantis.com">eli@mirantis.com</a>> wrote:<br>
>>> Btw, one of the ideas was to use Fuel task capabilities to gather<br>
>>> diagnostic snapshot.<br>
><br>
> I think such kind of tools should use as less as possible existing<br>
> infrastructure, because in case if something went wrong, you should be able<br>
> to easily get diagnostic information, even with broken RabbitMQ, Astute and<br>
> MCollective.<br>
><br>
> Thanks,<br>
><br>
><br>
> On Mon, Apr 18, 2016 at 2:26 PM, Vladimir Kozhukalov<br>
> <<a href="mailto:vkozhukalov@mirantis.com">vkozhukalov@mirantis.com</a>> wrote:<br>
>><br>
>> Colleagues,<br>
>><br>
>> Whether we are going to continue using Shotgun or<br>
>> substitute it with something else, we still need to<br>
>> decouple it from Fuel because Shotgun is a generic<br>
>> tool. Please review these [1], [2].<br>
>><br>
>> [1] <a href="https://review.openstack.org/#/c/298603" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/298603</a><br>
>> [2] <a href="https://review.openstack.org/#/c/298615" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/298615</a><br>
>><br>
>><br>
>> Btw, one of the ideas was to use Fuel task capabilities<br>
>> to gather diagnostic snapshot.<br>
>><br>
>> Vladimir Kozhukalov<br>
>><br>
>> On Thu, Mar 31, 2016 at 1:32 PM, Evgeniy L <<a href="mailto:eli@mirantis.com">eli@mirantis.com</a>> wrote:<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> Problems which I see with current Shotgun are:<br>
>>> 1. Luck of parallelism, so it's not going to fetch data fast enough from<br>
>>> medium/big clouds.<br>
>>> 2. There should be an easy way to run it manually (it's possible, but<br>
>>> there is no ready-to-use config), it would be really helpful in case if<br>
>>> Nailgun/Astute/MCollective are down.<br>
>>><br>
>>> As far as I know 1st is partly covered by Ansible, but the problem is it<br>
>>> executes a single task in parallel, so there is probability that lagging<br>
>>> node will slow down fetching from entire environment.<br>
>>> Also we will have to build a tool around Ansible to generate playbooks.<br>
>>><br>
>>> Thanks,<br>
>>><br>
>>> On Wed, Mar 30, 2016 at 5:18 PM, Tomasz 'Zen' Napierala<br>
>>> <<a href="mailto:tnapierala@mirantis.com">tnapierala@mirantis.com</a>> wrote:<br>
>>>><br>
>>>> Hi,<br>
>>>><br>
>>>> Do we have any requirements for the new tool? Do we know what we don’t<br>
>>>> like about current implementation, what should be avoided, etc.? Before that<br>
>>>> we can only speculate.<br>
>>>> From my ops experience, shotgun like tools will not work conveniently on<br>
>>>> medium to big environments. Even on medium env amount of logs is just too<br>
>>>> huge to handle by such simple tool. In such environments better pattern is<br>
>>>> to use dedicated log collection / analysis tool, just like StackLight.<br>
>>>> At the other hand I’m not sure if ansible is the right tool for that. It<br>
>>>> has some features (like ‘fetch’ command) but in general it’s a configuration<br>
>>>> management tool, and I’m not sure how it would act under such heavy load.<br>
>>>><br>
>>>> Regards,<br>
>>>><br>
>>>> > On 30 Mar 2016, at 15:20, Vladimir Kozhukalov<br>
>>>> > <<a href="mailto:vkozhukalov@mirantis.com">vkozhukalov@mirantis.com</a>> wrote:<br>
>>>> ><br>
>>>> > Igor,<br>
>>>> ><br>
>>>> > I can not agree more. Wherever possible we should<br>
>>>> > use existent mature solutions. Ansible is really<br>
>>>> > convenient and well known solution, let's try to<br>
>>>> > use it.<br>
>>>> ><br>
>>>> > Yet another thing should be taken into account.<br>
>>>> > One of Shotgun features is diagnostic report<br>
>>>> > that could then be attached to bugs to identify<br>
>>>> > the content of env. This report could also be<br>
>>>> > used to reproduce env and then fight a bug.<br>
>>>> > I'd like we to have this kind of report.<br>
>>>> > Is it possible to implement such a feature<br>
>>>> > using Ansible? If yes, then let's switch to Ansible<br>
>>>> > as soon as possible.<br>
>>>> ><br>
>>>> ><br>
>>>> ><br>
>>>> > Vladimir Kozhukalov<br>
>>>> ><br>
>>>> > On Wed, Mar 30, 2016 at 3:31 PM, Igor Kalnitsky<br>
>>>> > <<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>> wrote:<br>
>>>> > Neil Jerram wrote:<br>
>>>> > > But isn't Ansible also over-complicated for just running commands<br>
>>>> > > over SSH?<br>
>>>> ><br>
>>>> > It may be not so "simple" to ignore that. Ansible has a lot of modules<br>
>>>> > which might be very helpful. For instance, Shotgun makes a database<br>
>>>> > dump and there're Ansible modules with the same functionality [1].<br>
>>>> ><br>
>>>> > Don't think I advocate Ansible as a replacement. My point is, let's<br>
>>>> > think about reusing ready solutions. :)<br>
>>>> ><br>
>>>> > - igor<br>
>>>> ><br>
>>>> ><br>
>>>> > [1]: <a href="http://docs.ansible.com/ansible/list_of_database_modules.html" rel="noreferrer" target="_blank">http://docs.ansible.com/ansible/list_of_database_modules.html</a><br>
>>>> ><br>
>>>> > On Wed, Mar 30, 2016 at 1:14 PM, Neil Jerram<br>
>>>> > <<a href="mailto:Neil.Jerram@metaswitch.com">Neil.Jerram@metaswitch.com</a>> wrote:<br>
>>>> > ><br>
>>>> > > FWIW, as a naive bystander:<br>
>>>> > ><br>
>>>> > > On 30/03/16 11:06, Igor Kalnitsky wrote:<br>
>>>> > >> Hey Fuelers,<br>
>>>> > >><br>
>>>> > >> I know that you probably wouldn't like to hear that, but in my<br>
>>>> > >> opinion<br>
>>>> > >> Fuel has to stop using Shotgun. It's nothing more but a command<br>
>>>> > >> runner<br>
>>>> > >> over SSH. Besides, it has well known issues such as retrieving<br>
>>>> > >> remote<br>
>>>> > >> directories with broken symlinks inside.<br>
>>>> > ><br>
>>>> > > It makes sense to me that a command runner over SSH might not need<br>
>>>> > > to be<br>
>>>> > > a whole Fuel-specific component.<br>
>>>> > ><br>
>>>> > >> So I propose to find a modern alternative and reuse it. If we stop<br>
>>>> > >> supporting Shotgun, we can spend extra time to focus on more<br>
>>>> > >> important<br>
>>>> > >> things.<br>
>>>> > >><br>
>>>> > >> As an example, we can consider to use Ansible. It should not be<br>
>>>> > >> tricky<br>
>>>> > >> to generate Ansible playbook instead of generating Shotgun one.<br>
>>>> > >> Ansible is a  well known tool for devops and cloud operators, and<br>
>>>> > >> they<br>
>>>> > >> we will only benefit if we provide possibility to extend diagnostic<br>
>>>> > >> recipes in usual (for them) way. What do you think?<br>
>>>> > ><br>
>>>> > > But isn't Ansible also over-complicated for just running commands<br>
>>>> > > over SSH?<br>
>>>> > ><br>
>>>> > >         Neil<br>
>>>> > ><br>
>>>> > ><br>
>>>> > ><br>
>>>> > > __________________________________________________________________________<br>
>>>> > > OpenStack Development Mailing List (not for usage questions)<br>
>>>> > > Unsubscribe:<br>
>>>> > > <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>> > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>> ><br>
>>>> ><br>
>>>> > __________________________________________________________________________<br>
>>>> > OpenStack Development Mailing List (not for usage questions)<br>
>>>> > Unsubscribe:<br>
>>>> > <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>> ><br>
>>>> ><br>
>>>> > __________________________________________________________________________<br>
>>>> > OpenStack Development Mailing List (not for usage questions)<br>
>>>> > Unsubscribe:<br>
>>>> > <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>><br>
>>>> --<br>
>>>> Tomasz 'Zen' Napierala<br>
>>>> Product Engineering - Poland<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> __________________________________________________________________________<br>
>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>> Unsubscribe:<br>
>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe:<br>
>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div style="color:rgb(136,136,136);font-size:12.8000001907349px">Adam Heczko</div><div style="color:rgb(136,136,136);font-size:12.8000001907349px">Security Engineer @ Mirantis Inc.</div></div></div>
</div>