[FI-NEXT] Future of the Labe

Philipp Slusallek philipp.slusallek at dfki.de
Thu Dec 15 14:30:10 CET 2016


Hi Federico, all

I fully support this option. By coincidence, this is almost exactly what
I discussed with Ulrich as an interesting option at breakfast this morning.

In fact, such a system has already been developed in FIcontent (one of
the FI-PPP UseCase projects) a while ago. At the time we offered FWARE
to use this development as we thought that it would make FIWARE much
more attractive and solve a number of problems.

At the end FIWARE decided to develop something of their own -- but I am
not sure this ever happened (except for the ability to use Docker
directly, which was not available and which we had to implemnet on top
of the then existing infrastructure).

The system was based on Docker and allowed to deploy (a connected set
of) GEs and SEs together with a single click in a Web portal.

The portal is still here: http://lab.mediafi.org/, but I am not sure its
still fully functional. It allows to
-- DISCOVER enablers (like our catalog),
-- TRY it using a web-based UI to experience a service example,
-- TWEAK for modifying the code directly in the web browser, with
immediate effect on the example and storing/shring the resulting code,
-- RUN a GE or sets thereof by deploying them in either the FIWARE cloud
(required a lot of tweaks to get it working, you might remember the
discussion) or locally. We even had the option to directly deploy to AWS
and such but never published this (for political reasons :-).

We had some central nodes that ran the infrastructure as well as some
temporarily allocated instances from a FIWARE Lab pool for TRY and
TWEAK. Run required to have your own instance to deploy to.

That code should still be available if someone wants to look at it.


Best,

	Philipp


Am 15.12.2016 um 11:01 schrieb Federico Michele Facca:
> Dear All,
> In the past days we discussed about the sustainability of the nodes. it
> is clear that the federation, with centralised management of users and
> so on, it’s not sustainable
> if not by covering through the public funding or the foundation when the
> fi-next project is over. but this of course, it’s not going to be
> sustainable for the foundation.
> more the “cost” of managing the federation, it is quite relevant itself.
> we also know that users would prefer solutions with better slas (and
> potentially additional services).
> 
> Thus, after discussing with different people here at the summit (mainly
> Fernando and Alex), I think we should go for a much simpler set-up. I am
> trying to summarise my proposal below:
> 
> 1 - having one only real “fiware node” that is hosting the global
> instances, and providing some hosting capacity using containers /
> container clusters. access to vm
>      should be only granted in this reduced “lab” to fiware global
> service developer / operators.
> 2 - providing a front-end that allows the community users to deploy (and
> monitor) in a simple way containerised generic enablers and apps on the
> lab node and on the standalone nodes 
>       provided by other providers (ideally the fiware commercial providers).
> 3 - having a mechanism that allow users to insert their credentials from
> the commercial providers in the tool of bullet 2 so that the deployment
> after this step is very simple.
> 4 - (eventually) transforming fiware lab in an identity provider that
> can be leveraged by users to subscribe and access commercial providers
> services with a single account.
> 
> Different Open Source options are available to build 2 rapidly 
> The included providers may ask for money, or provide a free tier, anyhow
> this is a different matter. For sure for the time their operation will
> be covered by FI-NEXT,
> there should be a free tier.
> This will avoid the need for duplicating nodes in part of FIWARE Lab and
> commercial ones. It will also mostly avoid any problem in relation to
> NREN policies (assuming
> the central node will be hosted in RED.ES like today), because the NREN
> services will not be used for hosting commercial applications.
> 
> We should also probably the discuss about revising the policy for
> community accounts if want to make them more inclusive and simple for
> users. On one side,
> we could give up restrictions on getting details on what people want to
> do with FIWARE to attract more people to the Lab,
> on the other we can introduce automatic identity verification mechanisms
> (e.g. based on credit card validation transactions) to make community
> account available instantly.
> 
> Said so, as said already in the nodes mailinglist, the point that it is
> crucial to understand is also the vision of the foundation in this
> respect. We need to take decisions
> asap, because then accordingly we can discuss how to re-focus efforts on
> the operational tools part to support the vision realisation quickly.
> 
> My 2 cents,
> Federico
> 
> *Dr. Federico Michele Facca*
> /Head of Martel Lab/
> 
> *Martel Innovate*
> Dorfstrasse 73 - 3073 Gümligen (Switzerland)
> 0041 78 807 58 38
> 0041 31 994 25 25
> martel-innovate.com <http://martel-innovate.com>
> 
> 
> 
> 
> 
> __________________________________________________________________________________________
> 
> You can get more information about our cookies and privacy policies on the following links:
> - http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE_Privacy_Policy
> - http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Cookies_Policy_FIWARE
> 
> FI-NEXT mailing list
> FI-NEXT at lists.fiware.org
> https://lists.fiware.org/listinfo/fi-next
> 

-- 

-------------------------------------------------------------------------
Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH
Trippstadter Strasse 122, D-67663 Kaiserslautern

Geschäftsführung:
  Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
  Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
  Prof. Dr. h.c. Hans A. Aukes

Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
VAT/USt-Id.Nr.: DE 148 646 973, Steuernummer:  19/673/0060/3
---------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: philipp_slusallek.vcf
Type: text/x-vcard
Size: 462 bytes
Desc: not available
URL: <https://lists.fiware.org/private/fi-next/attachments/20161215/2a766ca7/attachment.vcf>


More information about the FI-NEXT mailing list

You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy   Cookies policy