Please see Philipp's comments and make changes to your GE where required.
Best Regards,
Kenneth Nagin
Ph: +972-4-8296227
Cell: 054-6976227
Fx: +972-4- 8296114
http://researcher.ibm.com/view.php?person=il-NAGIN
----- Forwarded by Kenneth Nagin/Haifa/IBM on 28/08/2016 02:45 PM -----
From: Philipp Slusallek <philipp.slusallek at dfki.de>
To: MIGUEL CARRILLO PACHECO <miguel.carrillopacheco at telefonica.com>,
Kenneth Nagin/Haifa/IBM at IBMIL, Álvaro Alonso <aalonsog at dit.upm.es>,
FERNANDO LOPEZ AGUILAR <fernando.lopezaguilar at telefonica.com>
Cc: JUAN JOSE HIERRO SUREDA <juanjose.hierrosureda at telefonica.com>
Date: 27/08/2016 10:52 PM
Subject: Re: [Fiware-chapter-architects] R5 Open Specs: next steps
Hi,
Sorry, just came back from vacations today. Here are my reviews for the
Cloud Chapter.
There is one general issue I would like to raise: While all GEs make
sense (well they are simply OpenStack components anyway), the
PolicyManager seems to becompletely overdesigned and underdelivers on
what it is supposed to be able to do. It simply allows to compares a few
values and send two types of actions -- unless I am missing something. I
do not think this is really a GE and might be a topic to be discussed at
the next TSC.
For convenience, I am putting my review results of the Cloud GEs right
into this email:
Docker:
=======
Specification:
-- Thanks for mentioning FIcontent-2!!
-- Might be worth to briefly define terms such as "FIWARE Cloud
Container Instance" in the Overview. Similarly, its unclear what is
meant with "the Docker GE exposes the *docker API*". Either make it "a"
Docker API" or put a reference to where this API is defined.
-- The footnote for "FIWARE Cloud compliant provider^1" is very hard to
find. Would be worth making it a link and/or putting footnotes in a
separate section, so they are easier to find.
-- I find the Overview a bit difficult to understand what exactly is
provided by the different parts described here. Maybe a more clear
description and few examples would help. Also when describing the
capabilities, maybe link to the descripions of each of them elsewhere.
-- "Docker images are the *build* component of Docker", Highlight the
terms that come up again in these paragraphs.
-- "Each container is created from a Docker image" --> "one or more
images"
-- "is *as* simple as ``docker run´´ +": Add "as" and add quotes (or
other means) to distinguish the commands. Many times.
-- I find the example of installing a Apache server via the command
line, while having explained that the end of the bash will terminate the
docker container, very confusing. I understand that the installtion will
vanish after the end. Also it would be better to describe the case where
someone starts running his (new) service in a container.
-- "Docker provides far denser server consolidation than you can get
with VMs": Intel would argue that this doe snot have to be the case. but
in general, this is true today.
-- "mili-seconds" --> "milli"
-- "Docker GE is done through the Docker Rest API": I think it would be
good to state that the GE uses the official Docker API (also see above).
-- I breifly also looked over the "Docker Container Service User Guide"
as it is referenced here. Looks OK but a few comments on that:
-- fiware-docker-container-service: ==> It seems that the use of Docker
must use HTTS to be secure as the token is send in plain in the HTTP
header. This should be pointed out (or is this automatically enforced?).
Isn't there another way of configuring an automatically reestablishing
token. This does not seem to be that hard. Does KeyStone allow that?
-- It is not clear, if I need my own FIWARE VM to run or how the backend
manages the assignement of docker containers to VMs in FIWARE Lab. This
should be described. This would also be a good place to discuss how
Docker relates to FIWARE VM/IAAS GE in general and when to use what.
-- Please do a careful scan of the text for typos, missing spaces, and
commas and such.
API:
-- As its the official Docker API, I did not review it.
IAAS:
=====
Specification:
-- Given that this GE builds on top of
-- Under Open API Specification it references only OpenStack. It would
be helpful to explicitly state that this GE is the same os the relevant
OpenStack release (or what the differences are).
-- "DCRM GE" is mentioned but not defined. Is this an old name?
-- "associated to a virtual server" --> "associated *with*"
-- "ephemeral disk" should mention that the contents are non-persistant
-- Please review the "Terms and definitions" as some entries seem not to
match the GE.
API:
-- As its the official OpenStack API, I did not review it.
ObjectStorage:
==============
Specification:
-- "that has been specifically requested by Use Cases": This does not
make sense any more.
-- "In terms of providing the service, the Cloud Instance Providers will
require a system that demands as little maintenance as is possible.": It
is not clear what that ost say here. Is this something that is provided
by this GE?
-- The paragraph of consuking the service by the provider should be
indended by one as it should be part of the previous bullet point.
-- Basic Concepts: This talks about "should provide": Shouldn't this say
"does provide" by now?
-- The link to " Identity Management GE" is broken.
-- "In this section we describe an extension to Swift": Is this the only
difference to the Swift API?
-- "Storlets Overview": The text gives the impression that Storelets
come from FIWARE and are now adopted by OpenStack. If this is true, this
should be mentioned. Otherwise the text should probably be reformulated.
-- "The FIWARE Object Storage extends OpenStack Swift with the feature
of Storlets.": If I understood this correctly then this is no longer
true as its now part of OpenStack. Correct?
-- "Terms and definitions": This seems to contain a lot of things that
did not come up in the specification and seems to come from some other GE.
API:
-- As its the official OpenStack API, I did not review it.
SelfServiceInterfaces:
======================
Specification:
-- "that permit to that enable to perform": ???
-- "following actions: ...": Maybe add some more information about the
actions that can be performed. Furthermore, it seems that these actions
are based on the features provided by IaaS. However, there does not seem
to be a 1:1 connection between items and terminology between the two.
E.g. snapshots are not mentioned in IaaS. Please synchronize the two or
point out where terminilogy is different.
-- "lunch instances" --> launch; Also here is a second list of actions
that is different. Maybe create a single list of actions (table?) and
defined the actions there.
-- "Moreover the portal facilitates management of a Virtual Data centers
(VDCs), Services and Service Data Centers (SDCs), PaaS management and
will offer monitoring statistics of the physical and virtual machines.":
I do not find anything related to this in the specification. Either
remove it or add info about this (link?).
-- Specify more clearly that the toolkit is a set of scripts that run
where? use what API? etc.
-- "Moreover the portal facilitates management of a Virtual Data centers
(VDCs), Services and Service Data Centers (SDCs), PaaS management and
will offer monitoring statistics of the physical and virtual machines.":
This sentence is confusing given the definitions before. Please reword.
-- Its unclear to me what the realtionship between the GE and the
OpenStack Dashboard is. Do they build on each other? What are the
differences, etc.
-- "of the SM GE components": What is SM? (Not the obvious I hope :-)
-- "SM GE, DCRM GE, Object Storage GE, Keystone/IdM GE and Monitoring
GE." Please check the names and provide links.
-- "A web client-side application" and "It is a Backbone-based
application" seems to contradict each other.
-- "The portal uses the underlying Cloud Library" : What is this? Link?
It is somewhat confusing what the different parts are. Given that the
Toolkit are a set of scripts, does this mean that it is using node.js
since the "sub-libraries" are in JS? Please be more specific here. BTW,
where is all this defined (Github?).
-- The arch diagram uses a number of terms that are not defined and
their relationship makes no sense currently. Please add a more detailed
description!
-- "Main Interactions": Please clean up and provide links. Most of the
items are in the IaaS, no?
API:
-- There is nothing to review
-- Wouldn't it make sense to describe the APIs of the different
components in JS. Or at least specify how they interact. Currently this
is pretty confusing. Link to where things are provided.
AppManagement:
==============
Specification:
-- "phase for as well as the on going". Delete "for" and change to
"on-going"
-- At the beginning of the description it is not clear to me who is the
customer for these services. Could be described more clearly.
-- "interacts with the Compute service, Image service, and Network
service by using the Orchestrator service": Clarify that the first three
are part of the IaaS GE. Orchestrator service is not defined anywhere as
far as I can tell. Please provide links.
-- Instead of linking to Murano directly, wouldn't it be better to link
to the IaaS GE?
-- The text lists some "capabilities" and then "service features".
However they are very similar but not identical. Should be cleaned up,
ideally into one list that also describes the service briefly and links
to more detailed info.
-- "a way to publish applications and services": What is the difference
between apps and services? Please define it. Do we have a catalog of
apps? Please provide links.
-- "Entities": Here Application is defined but not as something that
most people would call an "application". Also the term service does not
show up here any more, in contrast to its use in the beginning of the
spec.
-- The text talks about a north and south-bound interface but its not
clear in the diagram. Also there is a interface that goes via
orchestration (discussed in text) and a direct one to the agent (not
discussed). Confusing.
-- The text describes "three phases" but discusses only two of them.
Also it would be good if the naming would be such that its clear that
each paragraph is for one of these phases.
-- "Terms and Definitions": "Project" and "SLA" do not seem to be
relevant for this specification
-- IN general I find this specification more confusing that really
helping. I get a rough idea what it is doing but the details are
confusing. Either shorten it to its basics or provide more details that
tell me what is really happening.
API:
-- As its the official OpenStack API, I did not review it.
PolicyManager:
==============
Specification:
-- "management of the corresponding resources within the FIWARE Cloud
Instance like actions based on physical monitoring or infrastructure,
security monitoring of resources and services or whatever that could be
defined by a facts, actions and rules.": Please reword.
-- "Management of scalability rules. It is possible to manage rules
whose target is not to scale and this ...": Very confusing, please reword.
-- Do not link to Orion on Github but to FIWARE GE.
-- THe main interaction almost look like an API specification already
and are probably better shown there. Here I would only expect a short
overvoew of what services/interactions are offered.
-- Please urgently check English language in more detail thoughout the
text. In many cases I have difficulties to understand what the sentences
say (even though I have a rough idea of what this services does, which
many readers may not have!).
-- Instead it would be good to give examples how events are specified
and received, how rules look like, give several examples of simple
rules, etc. (there are some in the API already!)
-- The Spec refers to an API that seems different from the one liked to
by what I am reviewing.
-- I actually got more and better information from reading the API than
from reading the spec. This is not ideal and should be improved.
-- It seems that this GE is complete overkill for what it actually does
(comparing a few values and sending an action). This should be discussed
by the TSC, I think. It seems to be completely overdesigned (AI rule
engine!) but then underdelivers
API:
-- It seems that the window size is specified globally for a tenant and
not per resource, which would seem much more logical as the update
intervals and the amount of changes can vary dramatically.
-- In the action descriptions, it talks about "operations" (like
scaleUp" but when sending the action this is called an actionName which
already has a very semantics before. Also the structure of this
description is off as the two actions are on the same intendation level
as their descriptions, which is confusing.
-- The API talks about URLs but they are often just OpenStackIDs which
are certainly not URLs!
Best,
Philipp
Am 19.08.2016 um 12:51 schrieb MIGUEL CARRILLO PACHECO:
> Dear all,
>
> The Open Specs should be ready by now. We need to start the review cycle
> as agreed in a coordination call. Note that:
>
> * Each chapter leader decides whether to distribute it internally or
> to do it himself. No excuses: if someone is on holidays, he will
> have to assign it to someone else or do it himself
> * This has *_3 parts_*: Open Specification, API Specification and
> Apiari project.
>
> We agreed on having cross reviews so here we go. We will do this:
>
> * 19/Aug - 26/Aug - cross chapter reviews . On 26/8 the review report
> should be sent - with 3 parts per GE: Open Specification, API
> Specification and Apiari project
> * 26/Aug - 31/Aug - changes from GE owner after receiving the reviews
> * 1/Sept - 7/Sept - review from the coordinator
>
> *Assignments*: (to be completed as the chapters are ready)
>
> * WebUi reviews Cloud
> * Cloud reviews WebUI
>
> Assignments pending: Security, Data, Apps, IoT , I2ND (we will do it as
> they deliver)
>
> Note that the GE template was broken (an unintentional edit from a wiki
> user) and it was impossible to add the ApIary links. This is fixed now,
> please *t**hose who have already delivered take a look and put the right
> APIary link**s*.
>
> Note that this message is for the coordinators only, to allow you to
> coordinate things internally in the way that you prefer.
>
> _*Actions*_:
>
> *_1)_* Fix the APIary links those who already provided the info of
> the delivery
>
> _*2)*_ Organize internally in your chapters to do this
>
> *_3) _*Those who have not delivered yet: please do so
>
> Regards
>
> Miguel
>
> --
>
> Please update your address book with my new e-mail address:
miguel.carrillopacheco at telefonica.com
>
> ----------------------------------------------------------------------
> _/ _/_/ Miguel Carrillo Pacheco
> _/ _/ _/ _/ Telefónica Distrito Telefónica
> _/ _/_/_/ _/ _/ Investigación y Edifico Oeste 1, Planta 6
> _/ _/ _/ _/ Desarrollo Ronda de la Comunicación S/N
> _/ _/_/ 28050 Madrid (Spain)
> Tel: (+34) 91 312 94 15
>
> e-mail: miguel.carrillopacheco at telefonica.com
>
> Follow FIWARE on the net
>
> Website: http://www.fiware.org
> Facebook: https://www.facebook.com/eu.fiware
> Twitter: http://twitter.com/Fiware
> LinkedIn: https://www.linkedin.com/groups/FIWARE-4239932
> ----------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud
> de la legislación vigente. Si ha recibido este mensaje por error, le
> rogamos que nos lo comunique inmediatamente por esta misma vía y proceda
> a su destrucción.
>
> The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution
> or copying of this communication is strictly prohibited. If you have
> received this transmission in error, do not read it. Please immediately
> reply to the sender that you have received this communication in error
> and then delete it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu
> destinatário, pode conter informação privilegiada ou confidencial e é
> para uso exclusivo da pessoa ou entidade de destino. Se não é vossa
> senhoria o destinatário indicado, fica notificado de que a leitura,
> utilização, divulgação e/ou cópia sem autorização pode estar proibida em
> virtude da legislação vigente. Se recebeu esta mensagem por erro,
> rogamos-lhe que nos o comunique imediatamente por esta mesma via e
> proceda a sua destruição
>
>
> _______________________________________________
> Fiware-chapter-architects mailing list
> Fiware-chapter-architects at lists.fiware.org
> https://lists.fiware.org/listinfo/fiware-chapter-architects
>
--
-------------------------------------------------------------------------
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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-cloud/attachments/20160828/a45af161/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: philipp_slusallek.vcf
Type: application/octet-stream
Size: 456 bytes
Desc: not available
URL: <https://lists.fiware.org/private/fiware-cloud/attachments/20160828/a45af161/attachment.obj>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy