IMHO it would be best to have the user provide the INFO.yaml link - and then just check that the repo belongs to an LFN project (just check the domain name). This mitigates the need to walk repo trees.
We should also limit things to LFN projects, given that it is LFN that pays for the service. LFN projects (see https://www.lfnetworking.org/) are Opnfv.org Onap.org Opendaylight.org Fd.io Pnda.io Tungsten.io Snas.io Cheers, Frank -----Original Message----- From: Aric Gardner <agard...@linuxfoundation.org> Sent: Montag, 27. August 2018 21:06 To: Parker Berberian <pberber...@iol.unh.edu> Cc: Frank Brockners (fbrockne) <fbroc...@cisco.com>; Lincoln Lavoie <lylav...@iol.unh.edu>; Trevor Bramwell <tbramw...@linuxfoundation.org>; opnfv-tech-dis. <opnfv-tech-discuss@lists.opnfv.org> Subject: Re: [opnfv-tech-discuss] #infra #laas Deciding on LaaS usage policy Hi Parker, Most LFN projects will have INFO files already, those that do not will have them added in the near future. The url to fetch the info files (or have the user provide them) is: https://raw.githubusercontent.com/$LFNproject/$repo/master/INFO.yaml LFNproject is one of onap opnfv acumos odl iotivity fdio hyperledger Regards, Aric On Mon, Aug 27, 2018 at 11:47 AM, Parker Berberian <pberber...@iol.unh.edu> wrote: > Hi all, > > This path makes sense to me. > Is there an official list of OPNFV / LFN projects for us to use? I > can use all opnfv/* projects on github with INFO.yaml files. Will all > 7 LFN projects have a similar structure? > > Thanks, > Parker > > On Mon, Aug 27, 2018 at 11:20 AM, Frank Brockners (fbrockne) > <fbroc...@cisco.com> wrote: >> >> 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: opnfv-tech-discuss@lists.opnfv.org >> <opnfv-tech-discuss@lists.opnfv.org> On Behalf Of Aric Gardner >> Sent: Montag, 27. August 2018 17:11 >> To: Parker Berberian <pberber...@iol.unh.edu> >> Cc: Lincoln Lavoie <lylav...@iol.unh.edu>; Trevor Bramwell >> <tbramw...@linuxfoundation.org>; opnfv-tech-dis. >> <opnfv-tech-discuss@lists.opnfv.org> >> 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 >> <pberber...@iol.unh.edu> 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 >> <lylav...@iol.unh.edu> >> 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 >> <tbramw...@linuxfoundation.org> wrote: >> >> Hi Parker, >> >> From the minutes of this week's TSC call: >> >> http://meetbot.opnfv.org/meetings/opnfv-meeting/2018/opnfv-meeting.20 >> 18-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 >> >> >> >> www.iol.unh.edu >> >> 21 Madbury Rd., Ste. 100, Durham, NH 03824 >> >> Mobile: +1-603-674-2755 >> >> lylav...@iol.unh.edu >> >> >> >> >> >> 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 >> >> >> ********************************************************************* >> ********** >> >> >> >> >> >> > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21860): https://lists.opnfv.org/g/opnfv-tech-discuss/message/21860 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: opnfv-tech-discuss+ow...@lists.opnfv.org Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
