Open Stack

Team,

A "bicycle" will have to be present anyway, as a code which interacts with
Ansible, because as far as I understand Ansible on it's own cannot provide
all the functionality in one go, so a wrapper for it will have to be
present anyway.

I think me and Alexander we will look into converting Timmy into
Ansible-based tool. One way to go would be to make Ansible a backend option
for Timmy (ssh being the alternative).

I agree that the folder-driven structure is not easy to manipulate, but you
don't want to put all your scripts inside Ansible playbooks, that would
also be a mess. Something in-between would work well - folder structure for
available
scripts, and playbooks which link to them via -script: <path-here>,
generated statically (default) or dynamically if need be.

Also, I imagine some functions might not be directly possible with Ansible,
such as parallel stdout delivery of binary data into separate files (Timmy
pulls logs compressed on the fly on the node side through ssh, to avoid
using any unnecessary disk space on env nodes and local machine). So again,
for maximum efficiency and specifc tasks a separate tool might be required,
apart of Ansible.



On Wed, Apr 20, 2016 at 5:36 PM, Dmitriy Novakovskiy <
dnovakovskiy at mirantis.com> wrote:

> There's a thread on openstack-dev, but
> - nobody replied there (I checked this morning)
> - I can't link PROD tickets there :)
>
>
> On Thursday, April 21, 2016, Mike Scherbakov <mscherbakov at mirantis.com>
> wrote:
>
>> Guys,
>> how did it turn into openstack-dev from mos-dev, without any tags and
>> original messages... ?
>>
>> Please be careful when replying... There is a different email thread
>> started in OpenStack dev, with [Fuel] in subject..
>>
>> On Wed, Apr 20, 2016 at 10:08 AM Dmitry Nikishov <dnikishov at mirantis.com>
>> wrote:
>>
>>> Dmitry,
>>>
>>> I mean, currently shotgun fetches services' configuration along with
>>> astute.yaml. These files contain passwords, keys, tokens. I beleive, these
>>> should be sanitized. Or, better yet, there should be an option to sanitize
>>> sensitive data from fetched files.
>>>
>>>
>>> Aleksandr,
>>>
>>> Currently Fuel has a service non-root account with passwordless sudo
>>> enabled. This may change in the future (the passwordless part), however,
>>> now I don't see an issue there.
>>> Additionally, it is possible for users to configure sudo for the
>>> user-facing account however they like.
>>>
>>> In regards to have this tool to use a non-root accounts, there are 2
>>> items:
>>> - execute commands, that require elevated privileges (the easy part --
>>> user has to be able to execute these commands with sudo and without
>>> password)
>>> - copy files, that this user doesn't have read privileges for.
>>>
>>> For the second item, there are 2 possible solutions:
>>> 1. Give the non-root user read privileges for these files.
>>> Pros:
>>> - More straightforward, generally acceptable way
>>> Cons:
>>> - Requires additional implementation to give permissions to the user
>>> - (?) Not very extensible: to allow copying a new file, we'd have to
>>> first add it to the tool's config, and somehow implement adding read
>>> permissions
>>>
>>> 2. Somehow allow to copy these files with sudo.
>>> Pros:
>>> - More simple implementation: we'll just need to make sure that the user
>>> can do passwordless sudo
>>> - Extensible: to add more files, it's enough to just specify them in the
>>> tool's configuration.
>>> Cons:
>>> - Non-obvious, obscure way
>>> - Relies on having to be able to do something like "sudo cat
>>> /path/to/file", which is not much better that just giving the user read
>>> privileges. In fact, the only difference between this and giving the user
>>> the read rights is that it is possible to allow "sudo cat" for files, that
>>> don't yet exist, whereas giving permissions requires that these files
>>> already are on the filesystem.
>>>
>>> What way do you think is more appropriate?
>>>
>>>
>>> On Wed, Apr 20, 2016 at 5:28 AM, Aleksandr Dobdin <adobdin at mirantis.com>
>>> wrote:
>>>
>>>> Dmitry,
>>>>
>>>> You can create a non-root user account without root privileges but you
>>>> need to add it to appropriate groups and configure sudo permissions (even
>>>> though you add this user to root group, it will fail with iptables command
>>>> for example) to get config files and launch requested commands.I
>>>> suppose that it is possible to note this possibility in the documentation
>>>> and provide a customer with detailed instructions on how to setup this user
>>>> account.There are some logs that will also be missing from the
>>>> snapshot with the message permission denied (only the root user has
>>>> access to some files with 0600 mask)
>>>> This user account could be specified into config.yaml (ssh -> opts
>>>> option)
>>>>
>>>> Sincerely yours,
>>>> Aleksandr Dobdin
>>>> Senior Operations Engineer
>>>> Mirantis
>>>> ​Inc.​
>>>>
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>> Dmitry Nikishov,
>>> Deployment Engineer,
>>> Mirantis, Inc.
>>>
>>> __________________________________________________________________________
>>> 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
>>>
>> --
>> Mike Scherbakov
>> #mihgen
>>
>
>
> --
> ---
> *Dmitriy Novakovskiy*
> Sr. Product Manager, Mirantis EMEA
> *NL:* +31650270244 | *UA:* +380509372711 | *US:* +‭16506606291‬
>
>


-- 
Yours sincerely,
Dmitry Sutyagin
OpenStack Escalations Engineer
Mirantis, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160421/c7d6465e/attachment.html>