Merge lp://staging/~doanac/ubuntu-ci-services-itself/ppa-assigner-design into lp://staging/ubuntu-ci-services-itself

On Tue, Nov 19, 2013 at 09:34:31PM -0000, Andy Doan wrote:
> Andy Doan has proposed merging lp:~doanac/ubuntu-ci-services-itself/ppa-assigner-design into lp:ubuntu-ci-services-itself.
>
> Requested reviews:
> Canonical CI Engineering (canonical-ci-engineering)
>
> For more details, see:
> https://code.launchpad.net/~doanac/ubuntu-ci-services-itself/ppa-assigner-design/+merge/195866
>
> Design proposal for the PPA-Assigner
> --
> https://code.launchpad.net/~doanac/ubuntu-ci-services-itself/ppa-assigner-design/+merge/195866
> Your team Canonical CI Engineering is requested to review the proposed merge of lp:~doanac/ubuntu-ci-services-itself/ppa-assigner-design into lp:ubuntu-ci-services-itself.

> === modified file 'docs/components/ppa-assigner.rst'
> --- docs/components/ppa-assigner.rst 2013-11-16 10:12:08 +0000
> +++ docs/components/ppa-assigner.rst 2013-11-19 21:33:54 +0000

I've added an 'api' sub-dir for consolidating the services' APIs. Would
it make sense to move this there and link to it from the components
page?

Looks awesome, thanks for submitting this so quickly.

Comments/Questions:
1) low cost tickets only need 1 PPA. Can this be changed to only hand out 1 PPA at a time (If 2 are needed, 2 calls can be made)?
2) is lockname essentially the ticket owning the PPA (or map to it)? I would assume that if the process owning the PPA were to die before releasing it, we would be able to clean up or reuse the same PPA if that process was restarted (yes this gets tricky when considering 1) )
3) it would be a good optimization to clean PPAs on populate and release_ppa_pair, that way there is no cleaning delay when getting a PPA.

> Looks awesome, thanks for submitting this so quickly.
>
> Comments/Questions:
> 1) low cost tickets only need 1 PPA. Can this be changed to only hand out 1
> PPA at a time (If 2 are needed, 2 calls can be made)?
> 2) is lockname essentially the ticket owning the PPA (or map to it)? I would
> assume that if the process owning the PPA were to die before releasing it, we
> would be able to clean up or reuse the same PPA if that process was restarted
> (yes this gets tricky when considering 1) )
> 3) it would be a good optimization to clean PPAs on populate and
> release_ppa_pair, that way there is no cleaning delay when getting a PPA.

Feel free to ignore this for now, I don't think now is the time to do a formal design review. We still have too many unknowns to really nail down these details. I think getting an initial API in place is good for now (but lets not over commit to them too much before we review).

On 11/20/2013 01:41 PM, Francis Ginther wrote:
> Feel free to ignore this for now, I don't think now is the time to do a formal design review. We still have too many unknowns to really nail down these details. I think getting an initial API in place is good for now (but lets not over commit to them too much before we review).

There's a couple of things I think are worth addressing and prototyping
related to your concerns. I'll probably do that tomorrow or tonight.

On 11/20/2013 10:12 AM, Joe Talbott wrote:
> I've added an 'api' sub-dir for consolidating the services' APIs. Would
> it make sense to move this there and link to it from the components
> page?

I don't have a strong opinion on this. Maybe as a component goes from
designed -> implemented, the API section should get moved to that
directory? ie - we document API's that *exist*?

On 11/20/2013 10:38 AM, Francis Ginther wrote:
> 1) low cost tickets only need 1 PPA. Can this be changed to only hand out 1 PPA at a time (If 2 are needed, 2 calls can be made)?

Good point. I've changed the API to just be "ppa" and not ppa_pair
oriented. This should make code cleaner and better in the future if we
ever need >2 PPA's for a ticket.

> 2) is lockname essentially the ticket owning the PPA (or map to it)? I would assume that if the process owning the PPA were to die before releasing it, we would be able to clean up or reuse the same PPA if that process was restarted (yes this gets tricky when considering 1) )

Its a bit of a hack, but I thought it made give us insight as to who
owned a lock. I'm wondering in the future if "locked" type objects in
our system might include something like a "ticket-id". Since we don't
have that concept, I thought this might help.

> 3) it would be a good optimization to clean PPAs on populate and release_ppa_pair, that way there is no cleaning delay when getting a PPA.

I've added verbage about making the PPA cleaning optional.

Design should be updated now.