Open Stack

On Mon, Apr 10, 2017, at 08:31 AM, Pavlo Shchelokovskyy wrote:
> Hi infra team,
> 
> on order to test a piece of functionality I am developing, during the
> devstack plugin run I need to create an extra user with password-less
> sudo
> permissions. As I am not sure of intricacies of our infra setup, I'd like
> to clarify if it is acceptable.
> 
> TL;DR
> There is 'openstack/networking-generic-switch' project that mainly aims
> to
> provide a Neutron ML2 plugin suitable to manage cheap HW switches that
> only
> allow configuration over SSH. The problem with those is that these
> switches
> usually have limitations on the number of concurrent SSH sessions open on
> the switch.
> 
> In order to overcome this, I am attempting to introduce DLM to
> networking-generic-switch to globally limit the number of active SSH
> connections to a given switch across all threads of neutron-service on
> all
> hosts [0].
> 
> To test this locally in my Xenial DevStack VM, I am creating and
> configuring "ovsmanager" user with password-less sudo permissions (so it
> is
> able to manage OVS), limit the number of allowed sessions for that user
> in
> /etc/security/limits.d/ and configure networking-generic-switch to access
> localhost via that user to simulate a switch with limited number
> of allowed SSH sessions.
> 
> My questions is is it ok if I replicate this logic in the devstack plugin
> of networking-generic-switch to set up gate testing for this feature?
> In the end it seems it boils down to whether infra re-uses VMs it creates
> to run gate jobs for anything else and if such changes can affect those
> re-using these VMs, but I might be missing something else.
> 
> [0] https://review.openstack.org/#/c/452959/

The test instances that run devstack are single use VMs that are not
reused. Every job running on these instances starts with sudo access,
but by default we remove sudo access for the stack user which is what
the OpenStack services run as. We do this to force those services to use
rootwrap (or its equivalent) and test that the rootwrap rules are
functional.

As long as you create your new user during the initial devstack run you
shouldn't have any issues with this.

It wasn't mentioned above, but I would run a separate sshd for this
rather than modify the existing one as ssh is the control mechanism for
the test jobs. Better to run a separate independent service that won't
conflict with job control.

Hope this helps,
Clark