<div dir="ltr">On Sat, Dec 29, 2012 at 11:06 PM, Ori Livneh <span dir="ltr"><<a href="mailto:ori@wikimedia.org" target="_blank">ori@wikimedia.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
                <div><span style="font-size:12px">I'm glad many of these issues are resolved or on their way to getting resolved, but I worry that we're missing the bigger usability and security issue posed by having so many permission bits:</span></div>

<div><span style="font-size:12px"><br></span></div><div><span style="font-size:12px">Not everyone with a Gerrit account has a Labs account; not everyone with a Labs account has shell access; not everyone with shell access has access to bastion; not everyone with access to bastion has access to Labs instances; not everyone with access to Labs instances is a sysadmin; not every sysadmin is a netadmin, and not every netadmin gets to have a public IP.</span></div>

<div><span style="font-size:12px"><br></span></div><div><span style="font-size:12px">Some of the distinctions above have been identified as bugs and fixed, but I wonder if the distinctions could not be collapsed even further, so that new Labs users do not experience the process of getting set up with a comfortable development instance as a series of "gotchas". There are oodles of usability studies online that have reproduced what appears to be a universal truth: that hurdles and quirks in a site's on-boarding experience will frustrate users and drive them away.</span></div>


                <div><div><br></div></div></blockquote><div><br></div><div>Here's the current process and permissions:<br><br></div><div>1. User self-registers an account; this gives:<br></div><div>    - Gerrit access<br>

</div><div>    - Access to Labs wiki<br></div><div>    - Access to Hadoop?<br></div><div>    Bug 43370: automatically add a shell request at this step<br></div><div>2. A user requests for shell access (this step will be eliminated)<br>

</div><div>3. A shell request is granted by a wiki admin, this gives:<br></div><div>    - Access to be added to projects<br></div><div>    - Membership in the bastion project<br></div><div>    Without this step there's no way to stop troublesome users from<br>

    getting accounts.<br></div><div>    Bug 43371: allow some non-admins to grant shell access<br></div><div>4. A user requests access to a project, or requests a new project<br></div><div>    If a project is created, that user is given membership, sysadmin<br>

    and netadmin roles<br></div><div>    The current process for requesting access to projects is to ask a<br></div><div>    project owner. It's not easy to determine who a project owner is.<br></div><div>    Bug 43514: Create a request queue for project membership<br>

</div><div>    Bug 43515: List project sysadmin and netadmin users on<br>    project page<br></div><div><br></div><div>Outside of those steps there's also the need to upload an ssh key and learn how to set up ssh properly. There's a usability issue here with needing to upload the keys in two spots: <<a href="http://code.google.com/p/gerrit/issues/detail?id=1124">http://code.google.com/p/gerrit/issues/detail?id=1124</a>>.<br>

<br><div>Something we'll be doing to further simplify processes is to move 
the content from <a href="http://wikitech.wikimedia.org">wikitech.wikimedia.org</a> into labsconsole's wiki. This 
eliminates the creation of one more user account from our dev/ops infrastructure.<br><br></div><div>Additionally, as time goes on we tie more web service authentication to Labs' LDAP. I'd very much like to make labsconsole an OpenID provider so that services in Labs can use the same authentication source. OpenID as a provider on labsconsole is blocked by bugs 40068 and 40067.<br>

</div><br></div><div>If there's more ideas to fix the process, feedback is always appreciated. I'd love some help with dev work in OpenStackManager or Gerrit to fix some of the process issues, if you or any volunteers are willing to help.<br>

<br></div><div>- Ryan<br></div></div></div></div>