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 <[email protected]> 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 < > [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 > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
