Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

[Adam Heczko]

Hi,
I'd like to ask what's the current state of Shotgun and what are the plans
for the future?
Is there any alternative chosen for Fuel diagnostic snapshot functionality
and being worked on?

On Mon, Apr 18, 2016 at 3:39 PM, Igor Kalnitsky 
wrote:

> Evgeniy L. wrote:
> > I think such kind of tools should use as less as possible existing
> > infrastructure, because in case if something went wrong, you should
> > be able to easily get diagnostic information, even with broken RabbitMQ,
> > Astute and MCollective.
>
> It's a good point indeed! Moreover, troubleshooting scenarios may vary
> from case to case, so it should be easily extendable and changeable.
> So users can use various (probably, downloaded) scenarios to gather
> diagnostic info.
>
> That's why I think Ansible could really be helpful here. Such
> scenarios may be distributed as Ansible playbooks.
>
> On Mon, Apr 18, 2016 at 4:25 PM, Evgeniy L  wrote:
> >>> Btw, one of the ideas was to use Fuel task capabilities to gather
> >>> diagnostic snapshot.
> >
> > I think such kind of tools should use as less as possible existing
> > infrastructure, because in case if something went wrong, you should be
> able
> > to easily get diagnostic information, even with broken RabbitMQ, Astute
> and
> > MCollective.
> >
> > Thanks,
> >
> >
> > On Mon, Apr 18, 2016 at 2:26 PM, Vladimir Kozhukalov
> >  wrote:
> >>
> >> Colleagues,
> >>
> >> Whether we are going to continue using Shotgun or
> >> substitute it with something else, we still need to
> >> decouple it from Fuel because Shotgun is a generic
> >> tool. Please review these [1], [2].
> >>
> >> [1] https://review.openstack.org/#/c/298603
> >> [2] https://review.openstack.org/#/c/298615
> >>
> >>
> >> Btw, one of the ideas was to use Fuel task capabilities
> >> to gather diagnostic snapshot.
> >>
> >> Vladimir Kozhukalov
> >>
> >> On Thu, Mar 31, 2016 at 1:32 PM, Evgeniy L  wrote:
> >>>
> >>> 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
> >>>  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
>  >  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
>  >  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 

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

[Evgeniy L]

>> Btw, one of the ideas was to use Fuel task capabilities to gather
diagnostic snapshot.

I think such kind of tools should use as less as possible existing
infrastructure, because in case if something went wrong, you should be able
to easily get diagnostic information, even with broken RabbitMQ, Astute and
MCollective.

Thanks,


On Mon, Apr 18, 2016 at 2:26 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Colleagues,
>
> Whether we are going to continue using Shotgun or
> substitute it with something else, we still need to
> decouple it from Fuel because Shotgun is a generic
> tool. Please review these [1], [2].
>
> [1] https://review.openstack.org/#/c/298603
> [2] https://review.openstack.org/#/c/298615
>
>
> Btw, one of the ideas was to use Fuel task capabilities
> to gather diagnostic snapshot.
>
> Vladimir Kozhukalov
>
> On Thu, Mar 31, 2016 at 1:32 PM, Evgeniy L  wrote:
>
>> 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 <
>> tnapier...@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 <
>>> 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
>>> 

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

[Vladimir Kozhukalov]

Colleagues,

Whether we are going to continue using Shotgun or
substitute it with something else, we still need to
decouple it from Fuel because Shotgun is a generic
tool. Please review these [1], [2].

[1] https://review.openstack.org/#/c/298603
[2] https://review.openstack.org/#/c/298615


Btw, one of the ideas was to use Fuel task capabilities
to gather diagnostic snapshot.

Vladimir Kozhukalov

On Thu, Mar 31, 2016 at 1:32 PM, Evgeniy L  wrote:

> 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 <
> tnapier...@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 
>> 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
>> > > 

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

[Evgeniy L]

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 <
tnapier...@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 
> 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 
> 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 
> 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
> > 

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

[Tomasz 'Zen' Napierala]

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  
> 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  
> 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  
> 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

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

[Adam Heczko]

Osquery [1] could also be considered as providing a lot of useful
informations in a convenient way.

[1] https://osquery.io/


On Wed, Mar 30, 2016 at 3:20 PM, 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 
> 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 
>> 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
>
>


-- 
Adam Heczko
Security Engineer @ Mirantis Inc.
__
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

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

[Vladimir Kozhukalov]

​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 
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 
> 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

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

[Neil Jerram]

On 30/03/16 13:35, Igor Kalnitsky 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. :)

Agreed.
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

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

[Igor Kalnitsky]

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  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

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

[Roman Prykhodchenko]

+1 to discarding shotgun. Should we register a BP for that?

> 30 бер. 2016 р. о 12:03 Igor Kalnitsky  написав(ла):
> 
> 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.
> 
> 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?
> 
> Thanks,
> - Igor
> 
> On Tue, Mar 29, 2016 at 7:52 PM, Roman Prykhodchenko  wrote:
>> Please, propose your options here then:
>> https://etherpad.openstack.org/p/shotgun-rename
>> 
>> 29 бер. 2016 р. о 18:15 Jay Pipes  написав(ла):
>> 
>> On 03/29/2016 08:41 AM, Roman Prykhodchenko wrote:
>> 
>> Should we propose options and then arrange a poll?
>> 
>> 
>> Yup, ++ :)
>> 
>> 29 бер. 2016 р. о 16:40 Neil Jerram 
>> написав(ла):
>> 
>> On 29/03/16 15:17, Jay Pipes wrote:
>> 
>> Hi!
>> 
>> Once Shotgun is pulled out of Fuel, may I suggest renaming it to
>> something different? I know in the past that Anita and a few others
>> thought the name was not something we should really be encouraging in
>> the OpenStack ecosystem.
>> 
>> Just something to consider since it's being decoupled anyway and may be
>> a good opportunity to rename at that point...
>> 
>> Best,
>> -jay
>> 
>> 
>> +1
>> 
>> 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
>> 
>> 
>> 
>> __
>> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

[Neil Jerram]

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

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

[Igor Kalnitsky]

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.

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?

Thanks,
- Igor

On Tue, Mar 29, 2016 at 7:52 PM, Roman Prykhodchenko  wrote:
> Please, propose your options here then:
> https://etherpad.openstack.org/p/shotgun-rename
>
> 29 бер. 2016 р. о 18:15 Jay Pipes  написав(ла):
>
> On 03/29/2016 08:41 AM, Roman Prykhodchenko wrote:
>
> Should we propose options and then arrange a poll?
>
>
> Yup, ++ :)
>
> 29 бер. 2016 р. о 16:40 Neil Jerram 
> написав(ла):
>
> On 29/03/16 15:17, Jay Pipes wrote:
>
> Hi!
>
> Once Shotgun is pulled out of Fuel, may I suggest renaming it to
> something different? I know in the past that Anita and a few others
> thought the name was not something we should really be encouraging in
> the OpenStack ecosystem.
>
> Just something to consider since it's being decoupled anyway and may be
> a good opportunity to rename at that point...
>
> Best,
> -jay
>
>
> +1
>
> 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
>
>
>
> __
> 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

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

[Roman Prykhodchenko]

Please, propose your options here then: 
https://etherpad.openstack.org/p/shotgun-rename

> 29 бер. 2016 р. о 18:15 Jay Pipes  написав(ла):
> 
> On 03/29/2016 08:41 AM, Roman Prykhodchenko wrote:
>> Should we propose options and then arrange a poll?
> 
> Yup, ++ :)
> 
>>> 29 бер. 2016 р. о 16:40 Neil Jerram  
>>> написав(ла):
>>> 
>>> On 29/03/16 15:17, Jay Pipes wrote:
 Hi!
 
 Once Shotgun is pulled out of Fuel, may I suggest renaming it to
 something different? I know in the past that Anita and a few others
 thought the name was not something we should really be encouraging in
 the OpenStack ecosystem.
 
 Just something to consider since it's being decoupled anyway and may be
 a good opportunity to rename at that point...
 
 Best,
 -jay
>>> 
>>> +1
>>> 
>>> 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 
> 


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

[Jay Pipes]

On 03/29/2016 08:41 AM, Roman Prykhodchenko wrote:

Should we propose options and then arrange a poll?


Yup, ++ :)


29 бер. 2016 р. о 16:40 Neil Jerram  написав(ла):

On 29/03/16 15:17, Jay Pipes wrote:

Hi!

Once Shotgun is pulled out of Fuel, may I suggest renaming it to
something different? I know in the past that Anita and a few others
thought the name was not something we should really be encouraging in
the OpenStack ecosystem.

Just something to consider since it's being decoupled anyway and may be
a good opportunity to rename at that point...

Best,
-jay


+1

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

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

[Roman Prykhodchenko]

Should we propose options and then arrange a poll?

> 29 бер. 2016 р. о 16:40 Neil Jerram  написав(ла):
> 
> On 29/03/16 15:17, Jay Pipes wrote:
>> Hi!
>> 
>> Once Shotgun is pulled out of Fuel, may I suggest renaming it to
>> something different? I know in the past that Anita and a few others
>> thought the name was not something we should really be encouraging in
>> the OpenStack ecosystem.
>> 
>> Just something to consider since it's being decoupled anyway and may be
>> a good opportunity to rename at that point...
>> 
>> Best,
>> -jay
> 
> +1
> 
>   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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

[Neil Jerram]

On 29/03/16 15:17, Jay Pipes wrote:
> Hi!
>
> Once Shotgun is pulled out of Fuel, may I suggest renaming it to
> something different? I know in the past that Anita and a few others
> thought the name was not something we should really be encouraging in
> the OpenStack ecosystem.
>
> Just something to consider since it's being decoupled anyway and may be
> a good opportunity to rename at that point...
>
> Best,
> -jay

+1

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

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

[Jay Pipes]

Hi!

Once Shotgun is pulled out of Fuel, may I suggest renaming it to 
something different? I know in the past that Anita and a few others 
thought the name was not something we should really be encouraging in 
the OpenStack ecosystem.


Just something to consider since it's being decoupled anyway and may be 
a good opportunity to rename at that point...


Best,
-jay

On 03/29/2016 02:37 AM, Vladimir Kozhukalov wrote:

Dear colleagues,

This is a part of our plan to make Fuel even more modular.

Governance patch: https://review.openstack.org/#/c/298603/
Project-config patch: https://review.openstack.org/#/c/298615/
Launchpad project: https://launchpad.net/shotgun
Wiki page: https://wiki.openstack.org/wiki/Shotgun

If we have a consensus here and merge these
governance and project-config patches (not earlier than Fuel 9.0 SCF),
all new bug reports should be sent to https://bugs.launchpad.net/shotgun
Yet another thing is that Shotgun roadmap and releases will
be up to a Shotgun independent team.

BTW, volunteers are needed to drive Shotgun project. We need to inspect
its possible use cases, we should make it even more generic, convenient
and well documented. We also need to figure out what
we can improve in the project and how and then create roadmap.


Vladimir Kozhukalov


__
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