Hi Aric, I like that suggestion – and we might consider a tiered approach:
· Single server booking: Open to all (like what we have right now) · Multi-server booking: Allow only PTLs to book resources. When booking, you need to supply a link to the INFO file on git to authorize yourself as PTL. With other projects also moving to INFO files, that would even work for other projects under the roof of the LFN. At the same time, there is only minimal burden on UNH – all they need to check is whether the UUID of the requesting user matches the PTL in the INFO file. Thoughts? Thanks, Frank From: [email protected] <[email protected]> On Behalf Of Aric Gardner Sent: Montag, 27. August 2018 17:11 To: Parker Berberian <[email protected]> Cc: Lincoln Lavoie <[email protected]>; Trevor Bramwell <[email protected]>; opnfv-tech-dis. <[email protected]> Subject: Re: [opnfv-tech-discuss] #infra #laas Deciding on LaaS usage policy Hi Parker, Lincoln, Just a note, if we ask for a project name when booking we can turn that into a github url and grab that projects info file, which can inform us on things like project committers and project lead. example for project opnfv/releng: https://github.com/opnfv/releng/blob/master/INFO.yaml In this way we could limit bookings to committers, or if resources are indeed scarce, project leads. Regards, Aric On Mon, Aug 27, 2018 at 10:42 AM, Parker Berberian <[email protected]<mailto:[email protected]>> wrote: Hi Trevor and Lincoln, I just want these points to be kept in mind: - Users can design and book 'PODs' of any size (up to a max that it TBD). Especially as LaaS expands beyond OPNFV, it may not be helpful to limit our thinking to just the Pharos spec. - a significant feature of this LaaS 2.0 release is the sharing of resources. We try to make it as easy as possible to have a POD owner share their resources with coworkers, team members, or other projects for integration, etc. For example, scenarios with ONAP development / testing happening on top of OPNFV as the VIM, it can be the case that multiple projects can share a POD and both get a lot of value from it. So if we want to limit booking on a per user / per project basis, we need to decide how shared resources count toward that cap. Thanks, Parker On Mon, Aug 27, 2018 at 9:21 AM, Lincoln Lavoie <[email protected]<mailto:[email protected]>> wrote: Hi Trevor, Does the LFN accounting system (i.e. what the dashboard performs authentication against) have any info tied to a user for the LFN project they participate in? To limit to 4 bookings per project, we'd need a source of truth for that. Another approach would be to present the user with a "drop down" list of which project the resource is for. What I want to avoid is requiring UNH-IOL to make a decision point about what a booking is being used for, because we don't always have 100% visibility into what project states are, etc. Cheers, Lincoln On Fri, Aug 24, 2018 at 3:54 PM Trevor Bramwell <[email protected]<mailto:[email protected]>> wrote: Hi Parker, From the minutes of this week's TSC call: http://meetbot.opnfv.org/meetings/opnfv-meeting/2018/opnfv-meeting.2018-08-21-12.52.html they've deferred the agreement till next week. Assuming there is an agreement, and LaaS is open to all LFN members, I agree we will run into a scarcity of resources if we don't set some restrictions upon users/projects. So the question is, should this restriction be on a per-user, per-group, per-lfn-project basis, or some combination thereof? With 48 x86 and 14 aarch64 machines, we can have in total 8 Pharos compliant PODs (6 servers) booked at once (with 4 extra servers). Perhaps we restrict bookings to 1 per-user, 4 per-lfn-project, with a max of 2-weeks per-booking? You would have to do some calculations of which groups/projects a user belongs to in order to figure out when the quota is reached. This will also be somewhat hard as the limit might depend on either the number of servers in total, or the number of PODs and that would have to be a separate calculation I'm not sure what the answer is here, but I wanted to respond to at least keep the discussion rolling. Regards, Trevor Bramwell On Fri, Aug 24, 2018 at 10:58:28AM -0400, Parker Berberian wrote: > Hi all, > > As the release of LaaS 2.0 (info here > <https://wiki.opnfv.org/display/INF/LaaS+Timeline>) nears, we need to come > to a conclusion on how we are going to limit access to the Lab as a Service. > > Background info: > > LaaS usage is currently around 50-80%. As we open LaaS to all of LFN and as > we allow users to book multiple servers together as one "POD", we expect to > have a resource scarcity. > > We need some way of policing who is allowed to book how many machines, and > for how long. > > > The infra call this monday has been cancelled, and we need to try and come > to a conclusion on this soon. > > Thank you, > Parker > > > -- ******************************************************************************* Lincoln Lavoie Senior Engineer, Broadband Technologies [Image removed by sender.]<https://www.iol.unh.edu> www.iol.unh.edu<https://www.iol.unh.edu> 21 Madbury Rd., Ste. 100, Durham, NH 03824<https://maps.google.com/?q=21+Madbury+Rd.,+Ste.+100,+Durham,+NH+03824&entry=gmail&source=g> Mobile: +1-603-674-2755 [email protected]<mailto:[email protected]> [Image removed by sender.]<http://www.facebook.com/UNHIOL> [Image removed by sender.] <https://twitter.com/#!/UNH_IOL> [Image removed by sender.] <http://www.linkedin.com/company/unh-interoperability-lab> Ars sine scientia nihil est! -- Art without science is nothing. Scientia sine ars est vacua! -- Science without art is empty. Broadband Forum Gfast Certified Product List<https://www.broadband-forum.org/implementation/interop-certification/gfast-certified-products> ******************************************************************************* -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21852): https://lists.opnfv.org/g/opnfv-tech-discuss/message/21852 Mute This Topic: https://lists.opnfv.org/mt/24945176/21656 Mute #laas: https://lists.opnfv.org/mk?hashtag=laas&subid=2783016 Mute #infra: https://lists.opnfv.org/mk?hashtag=infra&subid=2783016 Group Owner: [email protected] Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
