BEGIN:VCALENDAR
PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN
VERSION:2.0
METHOD:CANCEL
X-MS-OLK-FORCEINSPECTOROPEN:TRUE
BEGIN:VTIMEZONE
TZID:中国标准时间
BEGIN:STANDARD
DTSTART:16010101T00
TZOFFSETFROM:+0800
TZOFFSETTO:+0800
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
Minutes -
http://ircbot.wl.linuxfoundation.org/meetings/ovn4nfv-meeting/2018/ovn4nfv-meeting.2018-08-28-15.30.html
Thank you attending the meeting.
/Trinath
On Tue, Aug 28, 2018 at 10:35 AM Trinath Somanchi
wrote:
> Hi OVN4NFV Team -
>
> Please find the agenda for today's IRC based weekly
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
Hi Aric,
well... we can and should check that the provided link indeed links to a git
repo of the LFN. I.e. we'd only need to check on the overall top level domain,
as opposed to deal with every single project.
Frank
-Original Message-
From: opnfv-tech-discuss@lists.opnfv.org
On
Hi Frank,
Just a note, if we allow users to provide a direct link to the info
files, there is no validation, I could just point to a personal repo
with a yaml file that matches my lfid to gain access.
-Aric
On Tue, Aug 28, 2018 at 9:40 AM, Frank Brockners (fbrockne)
wrote:
> Hi Parker,
>
>
>
Hi Parker,
while I agree that option 2) would be nicer from a user perspective, IMHO we
should start with 1) – because not all the projects even have INFO files yet…
let alone that they are in the right location.
E.g. https://git.onap.org/appc/tree/ has an info file, while
Hi Frank,
Depending on how much onus we want to put on the dashboard, we have three
different options as I see it:
1) user gives the URL to 'their' INFO file
2) user selected their project from a drop-down and the dashboard is able
to grab the INFO file from there
3) the dashboard maintains a
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.
