[Fiware-wpa] Packaging activities

[Juanjo Hierro]

Hi all,

  Mid last month I send an official email to our PO, Arian Zwegers, asking for clarification about the mean of "packaging" activities.   I forwarded him my interpretation of what "packaging" means and I asked whether he had the same interpretation.

  Unfortunately, I didn't receive any written response by our PO and he is now on holidays.     I had the opportunity to meet with him while at the Campus Party and I again shared my interpretation.   It seems like it was fine for him but, again unfortunately, this wasn't a written response so it cannot grant anything.

  At this point, I believe we should proceed and go ahead with the proposed interpretation.    I'll communicate this decision to our PO because the absence of his or reviewers' response.     After all, I believe this is a meaningful interpretation of what we should do regarding "packaging" so there shouldn't be major issues.

  Please note that "packaging" is NOT an activity required for GEis that are not planned to be delivered as open source (as stated in the catalogue and confirmed in the month 30 review) with the exception of GEis provided by Thales (whose exploitation plans were considered convincing by reviewers).    This was confirmed by Arian during my conversations with him.   They were asked to stop development/packaging activities with the end of release 3.2, planned by end of December, so they are supposed to have delivered the final version of GEi software and documentation by end of January (as planned in the original DoW, btw)

  Please also note that GEis whose owners declared their intention to go open source only at the month 30 review (and not previously in the catalogue) are requested to work only on packaging activities until end of Release 3 (planned by end of March, to be officially delivered by end of April).   GEis that were declared to be open source by end of November, plus those provided by Thales, have to deal with packaging in parallel to development activities in their roadmap.

  Regarding the interpretation of packaging we will adopt, here it is the interpretation I shared with our PO.   Basically, "packaging" comprises two kind of activities:

  *   Improving "packaging" of each GEi standalone:
     *   Making sure that the GEi can be easily be deployed on FI-Lab using FI-WARE Cloud deployment functionalities.   This means setting up VM images with the GEi configured, the definition of Blueprint templates and, eventually, some deployment recipes.   This applies for GEis for which it can be expected that FI-Lab users (developers) wish to have a dedicated instance running on the Cloud.    It won't apply for other GEis for which dedicated instances do not make so much sense (e.g., GEis in the Cloud, I2ND or Security chapters, GEis linked to the Business Framework or Store in the Apps chapter, GEis linked to the IoT gateway or the KIARA middleware GEi).
     *   Making sure that we end with a high-quality documentation including not just developers' guides but administration guidelines easing deployment and configuration on local premises.

  *   Developing the concept of "package of related GEis", which should mean:
     *   Defining a dedicated entry in the FI-WARE Catalogue.
     *   Developing the means for automated deployment on FI-Lab using Cloud deployment functionalities.  This means setting up VM images with the GEis of the package properly configured, Blueprint templates coping with automated deployment of all GEis in the package and, eventually, some deployment recipes.   Again, as with individual GEis, this applies for packages of GEis for which it can be expected that FI-Lab users (developers) wish to have a dedicated instance running on the Cloud.
     *   Developing good guides enabling easing deployment and configuration of the packages.

  Note that definition of a "package of related GEis" is not always meaningful/useful.  Chapter leaders/architects have to come with a list of packages that could make sense in their chapter.   Following is a list of packages I see as candidates in a first approach:

  *   combining several GEis in the IoT Backend: a package combining the IoT Broker GEi by NEC, the Orion Configuration Manager and the DCA Device Management GEis
  *   combining several GEis of the Data/Context Chapter: a package combining the Orion Context Broker, Cosmos (BigData) and Proton (CEP)

  Again, this is my own take on the matter.   Chapter leaders/architects are welcome to suggest other packages of related GEis.

  A package combining several GEis in the Cloud chapter or the Apps chapter (linked to the business framework, for example), also enabling to setup a portal similar to the one at lab.fi-ware.eu could be useful for potential FI-WARE Instance providers but not so much for users of FI-WARE instances (app developers).   I would argue that creation of such packages is mostly a task for the XiFi project but I'm happy to hear other opinions.

  Hope it helps.   Best regards,

-- Juanjo

-------------
Product Development and Innovation (PDI) - Telefonica Digital
website: www.tid.es<http://www.tid.es>
email: jhierro at tid.es<mailto:jhierro at tid.es>
twitter: twitter.com/JuanjoHierro

FI-WARE (European Future Internet Core Platform) Coordinator
and Chief Architect

FI-PPP Architecture Board chairman

You can follow FI-WARE at:
  website:  http://www.fi-ware.eu
  facebook: http://www.facebook.com/pages/FI-WARE/251366491587242
  twitter:  http://twitter.com/FIware
  linkedIn: http://www.linkedin.com/groups/FIWARE-4239932




________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-wpa/attachments/20140210/d5b05cdf/attachment.html>