[Canonical-ci-engineering] User authentication for CI Lab Jenkins instances

[Larry Works]

On 04/14/2014 04:58 PM, Sergio Schvezov wrote:
> On Mon, Apr 14, 2014 at 5:53 PM, Alexander Sack <asac at canonical.com> wrote:
>> On Mon, Apr 14, 2014 at 10:37 PM, Sergio Schvezov
>> <sergio.schvezov at canonical.com> wrote:
>>> On Mon, Apr 14, 2014 at 5:14 PM, Thomi Richards
>>> <thomi.richards at canonical.com> wrote:
>>>> Hi Larry,
>>>>
>>>> On Tue, Apr 15, 2014 at 2:08 AM, Larry Works <larry.works at canonical.com>
>>>> wrote:
>>>>> During the migration each jenkins instance will be shut down. The
>>>>> jenkins configuration file and users directory will be backed up. Once
>>>>> the back up is complete the configuration will be switched from the
>>>>> jenkins internal user database to OpenID/SSO which will use
>>>>> https://login.ubuntu.com as the backend. User permissions will be
>>>>> controlled by LP groups instead of being managed on a per-user basis.
>>>>
>>>>
>>>> How will you be adding users to these launchpad groups? Which launchpad
>>>> groups will be used to control access? After the migration is done, will I
>>>> (and everyone else) still have permissions to run the same jobs as we did
>>>> before the migration, or will we need to contact you individually?
>> I agree which teams will get access (and to what) would be worth
>> sharing. ev/retoaded?
>>
>>> And if this is the case, will we have 24x7 support?
>> Are you asking if the CI team will be there after the change to ensure
>> you have everything you need and react swiftly? We surely don't offer
>> 24x7, but what we plan to do is roll this out early morning Larries
>> time, so all of you can check and test and we we can react swiftly.
>> Also the change is planned in a way that we can completely rollback it
>> in case there are too many unforseen issues.
> I'm more interested in the 7 than the 24; as in if a build fails; will
> I be able to trigger a rebuild? If we need to build a click package;
> will I still be able to trigger it? This is standard pre train stuff
> and only applicable if this change implies losing the privileges we
> currently have.
>
> Furthermore; trains on weekends would be nice.
>
Many apologies for not including this critical piece of information in
the original notice. The intent of the change in authentication method
is to a) simplify the process of user management from the administrative
perspective and b) normalize the user base across the Jenkins instances.
The permissions users currently have should still be available after the
change but will now be controlled at the LP group level instead of on a
per-user level.

I have sent an E-mail to the teams using the various CI lab Jenkins
instances requesting LP group names so they can be added when the
changes to the authentication method are made. The groups will be
assigned the same permissions the current individual users have now so
it should be mostly transparent to them. I say mostly since the userIDs
used to log in may change for some people; all users will use their LP
userIDs to log in which may or may not be the same as the IDs they use now.

Once I receive responses back from my queries to the various teams I
will send another message listing the LP teams that will be added for
review. If I do not receive responses in the next day or two (I know
people are quite busy right now) I will ping them on IRC for the
information. If further clarification is needed please don't hesitate to
let me know.

~w