From GLIKSON at il.ibm.com Mon Aug 8 22:46:07 2011 From: GLIKSON at il.ibm.com (Alex Glikson) Date: Mon, 8 Aug 2011 23:46:07 +0300 Subject: [Fiware-cloud] meeting tomorrow In-Reply-To: References: Message-ID: All, I would like to remind you that tomorrow we are going to resume our periodic meetings, focusing on the topics outlined below. Regards, Alex Conf call details: IBM Haifa: (04-828)1281 France 0800-94-0558 Ireland 1-800-553-761 Spain 900-8-01334 Participant Code: 5546993 Additional phone numbers can be found at https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=5546993&accessNumber=1809417783 From: Alex Glikson/Haifa/IBM To: fiware-cloud at lists.fi-ware.eu Date: 29/07/2011 10:33 PM Subject: Fw: [Fiware-wpl] VERY IMPORTANT (updated): Coordination of FI-WARE backlog related activities All, Please, see below guidelines from Juanjo on managing assets and backlog. We will resume our weekly calls and start discussing this on August, 9th (at our regular slot -- 11am). Please, send *before* that meeting the initial list of assets that you consider for each of the GEs. Regards, Alex ----- Forwarded by Alex Glikson/Haifa/IBM on 29/07/2011 02:47 PM ----- From: Juanjo Hierro Hi all, Once we have dealt with the FI-WARE High-level Description (Product Vision) we have to start working in three major tasks on which we should concentrate our efforts until our plenary meeting in Turin: 1. Launch of activities dealing with final decision on assets and the creation of the FI-WARE backlog 2. Management of relationship with FI-PPP UC projects 3. Launch of activities dealing with development of contents of the FI-WARE website (setup of the public Wiki and start of activities in blogs) This email elaborates on the first point. Cheers, -- Juanjo 1. Launch of activities dealing with final decision on assets and the creation of the FI-WARE backlog At this point, I assume that you already understand the basis of how we plan to use Agile in our project. It summary, we will use it for managing the FI-WARE requirements, which will take the form of entries in what we refer as the FI-WARE backlog. In any case, please review the presentation I made during our kick-off meeting in May: https://forge.fi-ware.eu/docman/view.php/7/37/FI-WARE+agile+Intro+vfinal.pptx Following is the list of steps and considerations to take into account when launching the activities dealing with final decision on assets and the creation of the FI-WARE backlog: The first step we have to deal with has to do with closing the decision on the assets we will adopt as baseline for the reference implementation of each of the GEs. For this, every WP will have to come with a first proposal by August 31st on what asset, from what project+partner, will be adopted as baseline for the reference implementation of each of the GEs in the corresponding chapter. The different WP/chapter teams have to start this exercise now. It may not be feasible to close the mapping of assets for each of the GEs identified in a given chapter. This may be particularly the case for assets related to GEs for which there are still may points under discussion. It may also happen that we have identified assets for some of the components of a GE but not all. But at least we should have a relatively mature list of assets identified for the main GEs in each chapter by August 31st. This represents a first action point on WPLs and WPAs. There are some special cases in which we have a GE but two "competing" assets. Unless the contributing partners agree to carry out a joint development (open source or not), the number of GEs where this happens may allow us to make exceptions and allow two alternative reference implementations for the same GE (this instead of artificially trying to merge both). Of course, we have to work so that the two assets end up supporting the corresponding GE open specifications (APIs, protocols, visible behaviour) which should be only one. We also have to be able to provide enough rationale for this decission (e.g., reference implementations rely on different persistence technology or the combination of the two is what may allow an application provider to setup the most efficient solution in some large-scale, highly distributed architectures. We have to be very careful and analyze each of the cases where we will allow alternative reference implementations. These should be exceptions. Currently, the only one clearly identified is the Publish/Subscribe Broker GE, where two reference implementations (one from Orange, another from TI) will be developed. It has been pointed out that some of these exceptions may be found in the IoT chapter but we have to carefully analyze them and provide the rationale (here, I would add that we also have to find the way to reach the necessary alignment with APIs specified in the Data/Context Management chapter. Once assets have been identified (for some of the GEs, this decision may be taken right now) we have to start to populate the FI-WARE backlog. The fields for entries in the FI-PPP backlog (which includes the FI-WARE backlog) have already been defined and correspond to the ones described in the attached template (spreadsheet). Note that entries in the FI-PPP backlog will not comprise just features/user-stories linked to FI-WARE GEs but to other platform enablers which may happen to be common to several applications while still domain-specific. It will also comprise the backlogs of some of the UC projects, associated to their actual application development project, but only for those UC projects that have agreed to follow Agile. If you have any question/doubt regarding semantics of any field in the template, please let Thomas or me know. Regarding tools to create, maintain and manage requests on entries of the FI-PPP backlog, the following has been agreed: The FI-PPP will use Agilefant in order to perform the overall management of entries in backlogs. The FI-PPP will go for a configuration where we will define multiple backlogs in Agilefant. One per GE in each chapter, one covering entries for all the still uncategorized platform enablers, one (at least) for other platform enablers that are common but domain-specific (therefore out of the scope of FI-WARE) and one per each of the UC projects that wish to use Agilefant to manage their own application backlog (not all). This with the ability to transfer entries from one backlog to another. However, Agilefant is pretty simple, and entries of a backlog in Agilefant cannot be flexibly configured as to contain all of the fields we have defined for the FI-PPP backlog template (attached). Therefore, the description field of each entry in an Agilefant backlog will have to include an URL link to a page on a Wiki (based on Wikimedia) where all fields for that entry, as defined in the attached spreadsheet, can be fully specified. Regarding entries linked to the FI-WARE backlogs, and probably also for entries linked to platform enablers in general, this wiki will be provided by FI-WARE. ATOS, Thomas and me will work on defining the process and instructions on how to create backlog entries in the Wiki and in Agilefant before Thursday next week. In the meantime, you may wish to start working on entries, just using spreadsheets following the attached template. FI-WARE will put in place some system to manage the lifecycle of requests to create new entries in the FI-WARE backlogs or modify existing ones by third parties. This tool should not be offered just to UC projects but to the general public, because we have to be open to other communities. Most probably this tool will be the tracker system in FusionForge but we are still analyzing whether it could be managed directly through Agilefant, defining an intermediate backlog about "request for platform enablers" where request for entries formulated by UC projects would be created and only transferred to the FI-WARE backlogs when agreed with FI-WARE. However, the issue of dealing with other third parties/communities may lead to the need to put a more formal system such as tracker. ATOS, Thomas and me will work on this matter during the following days and will inform you before Thursday next week about what tool has been decided and what will be the procedures to follow. One point that was already understood and agreed during the FI-PPP AB is that requirements from end-users on applications to be developed by UC projects are different from requirements on FI-WARE (on platform enablers in general). During investigation of a end-user requirement "X" (no matter if it is a Theme, an EPIC or an user-story), a given UC project may conclude that it needs to rely on a platform that support a number of features "a", "b", and "c" plus develop an application implementing functionalities "M", "N", "O" on top of that platform. These "a", "b" and "c" features should translate into entries initially linked to the "platform enablers" backlog. Some of them will finally be addressed in FI-WARE so therefore will be transferred to the FI-WARE backlog. Whether we will manage this transference directly on Agilefant or through a tracker system, is something to decide. Nevertheless, note that specification of "X", "M", "N", "O" will not be part of the FI-WARE backlog. The level of concreteness is also different: "X" and even "M", "N" and "O" may be very concrete, with a quite detailed specification. However, "a", "b" and "c", at the time they are formulated by a UC project, may be just in the form of a "theme" or "epic", according to Agile terminology. Entries in backlog should evolve from Themes, to EPICS up to user-stories. Following remarks apply: The frontiers between Themes and EPICs use to be diffuse, they correspond to description of features at different levels of granularity. However, what is important is that user-stories provides all the details of WHAT has to be done that a development team need to know to perform their development work. Themes and EPICs matches different stages of approximation during the interaction process you have to perform until you end up having well detailed user-stories. Note that when refining an EPIC, you may end up having it split into several finer-grain EPICs, but still EPICs. You may also end up having it split into several finer-grain EPICs and some user-stories (covering part of the original EPIC) When planning a given sprint in Agile, only highest priority user-stories are considered. Themes and EPICs obviously not. This is because, at a given sprint, you only work on what can be done (get finished) by the end of the sprint. This means that if we have a MUST Theme or EPIC, it will never be developed before a COULD user-story. Themes and EPICs simply cannot be done (because development teams do not have all the info they need to implement them). At a given point in time, features "a", "b" and "c" will be submitted to FI-WARE for consideration. This means they will first be submitted to the "platform enablers" backlog. FI-WARE will then determine whether the feature can be considered inside the scope of FI-WARE and what priority is finally assigned. This decision will most probably imply several interactions with the UC projects that have identified the features. As mentioned before, we will come in the coming days with a concrete proposal on tools and procedures adopted for managing this process. Parallel to this process, UC projects may additionally require further clarifications about what we intend to deliver in a given chapter, for a given GE. In other words, they may ask for clarifications on parts of the FI-WARE High-level Description (Product Vision). This should be driven in a formal manner, to avoid getting into chaos. Therefore, a specific tracker system associated to the High-level Description (Product Vision) will be put in place for UC projects to formulate their questions. Explanations given to resolve tickets should lead to creation/update of contents in a FAQ Wiki we should start creating. This system will be also offered later to the general public, Parallel to UC projects running the process described above, FI-WARE should, own its own, work in defining entries for the FI-WARE backlogs. Whether they will be still generic ("themes" or "epics") or already detailed user-stories ready for implementation will depend on how clear we have things regarding the GEs in each of the chapters. There are three different types of entries that FI-WARE chapter teams should be able to generate from now until the Turing meeting (as a first milestone) 1. Entries related to new functional or non-functional features we need to implement in an asset adopted as baseline for the development of the reference implementation of a given GE (or part of it), in order to cover the gap between what that given asset supports at the time it is contributed by a given partner to the project and what it should support to actually become (part of) a reference implementation of the given GE. This will map to features we want to support during lifetime of FI-WARE. They should have a MUST or SHOULD MoSCoW priority assigned. 2. Entries related to new functional or non-functional features we wish to implement in an asset adopted as baseline for the development of the reference implementation of a given GE (or part of it), in order to further evolve it and therefore, evolve the corresponding GE (since GEs specifications may evolve over time and offer different functionality in subsequent releases of FI-WARE). This will map to features we may not support during lifetime of FI-WARE, for sure won't fit in the first release. They should have a SHOULD or COULD MoSCoW priority assigned. 3. Entries related to integration of assets, in those cases where an asset has to be combined with other assets to build the reference implementation of a given GE. Note that these entries are different than those ones related to implementing interfaces/protocols, etc in an asset implementing (part of) a GE, in order to support integration with another GE, because interfaces/protocols enabling integration of GEs should be part of their open specifications and, therefore, should be considered a particular case of points 1. or 2. A very IMPORTANT note: entries in the backlog should not describe what the assets adopted as baseline already provide, but what must, should, could be developed in those assets (see MoSCoW priority field in the attached template for FI-WARE backlog entries). A reminder about semantics linked to MoSCoW priorities: MUST - Features that absolutely have to be done are categorized as Must. If any of these features are not done, the project will be considered a failure. SHOULD - Features that are important to the success of the project, but are not absolute musts (they have a workaround or will not cause the project to fail) are categorized as Should COULD - Features that are nice to have but are not core features are categorized as Could. WON?T - Features that are not going to be implemented this time are marked as Wont. Remember that entries in the backlog are about "work to be done". User stories are, besides (and this distinguish them from themes and epics) work that is well-defined/detailed enough as to able to be done. Sometimes, it will be appropriate to create an user-story related to the specification of the API (or part of the API) that a given GE will have to provide and differentiate it from implementation (support) of some of the operations of that API, once it has been specified. Note, that regarding a given feature request, there will be essentially five scenarios: The feature applies to some of the GEs we have already identified in the FI-WARE High-level Description, and for which an asset has already been identified (therefore we have already identified entries for it in the FI-WARE backlog) The feature applies to some of the GEs we have already identified in the FI-WARE High-level Description, but for which an asset hasn't already been identified (it is a gap we have already identified that none of the partners in FI-WARE is able to fill contributing an asset) The feature applies to some GE we hadn't identified initially in FI-WARE (in the FI-WARE High-level Description) but we agree to incorporate it in the roadmap, despite no partner has an asset that can be contributed as baseline for development of a reference implementation The feature applies to some GE we hadn't identified initially in FI-WARE (in the FI-WARE High-level Description) but we agree to incorporate it, and there is a partner that has an asset that may be contributed as baseline for development of a reference implementation The feature applies to some enabler we hadn't identified initially in FI-WARE and we don't agree to accept it as GE since it is a common, yet domain-specific, platform enabler, but not a GE The first case will lead to negotiation of priorities between us and the UC project. The second and third case will lead to requirements that we should take into account in our Open Calls. The fourth case require careful consideration because we won't be able to change the assignment of resources to a given partner. We need to calibrate whether the partner can adjust its efforts to deal with more GEs that the originally planned (maybe addressing less new functionality in each) or we should finally issue an Open Call for the GE being considered. Despite the most active UC projects may start creating some initial requests for entries in the FI-WARE backlog during August, I do not expect so much activity, so keep going on your own, generating entries in the FI-WARE backlogs based on the principles of the previous point. During September negotiations with UC projects should become more intense. We indeed agreed with the UC projects to have a milestone by end of September in which we should already have produced a number of entries in the FI-WARE backlogs on our own, and they should have been produced some requests for entries in our FI-WARE backlogs. A period of negotiation/consolidation is then planned, which should end by end of November, with the first official release of the FI-WARE backlog to be considered for the first release of FI-WARE and also a clear definition of what we are going to request in the first Open Call of FI-WARE Some people have asked to me what should we do regarding the the second release of the FI-WARE High-level Description (Product Vision). We will transfer contents of the first official release of the FI-WARE High-level Description (Product Vision) to the public Wiki at the website. From then on, we will work making updates on the Wiki, so we will get rid of editing MS Word documents, etc. Therefore, delivery of the second release of the Product Vision will consist essentially in ... passing an URL. Note that major changes will be incremental, located in very concrete places and delivered in a "continuous". The type of changes that I would expect would distinguish the second release compared to the first one are the following: we should include a dedicated section per GE elaborating on the asset selected as baseline, which mostly will contain links to existing documentation which explains what the asset already provides today (user's/programmers guide, etc, whatever valuable documentation is available). This mostly what is going to be new in this "second release" (despite talking about releases would not make sense any more ... we will work in a continuous) we will probably need to update/add some content as a result of tackling some of the "topics still under discussion" 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 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 _______________________________________________ Fiware-wpl mailing list Fiware-wpl at lists.fi-ware.eu http://lists.fi-ware.eu/listinfo/fiware-wpl #### Backlog entries description v0 1 11-07-12.xls removed & duplicate added to MyAttachments Repository V3.8 () on 02 August 2011 by Alex Glikson. Original attachment record is here (). #### jhierro.vcf removed & duplicate added to MyAttachments Repository V3.8 () on 02 August 2011 by Alex Glikson. Original attachment record is here (). -------------- next part -------------- An HTML attachment was scrubbed... URL: From GLIKSON at il.ibm.com Mon Aug 8 23:56:43 2011 From: GLIKSON at il.ibm.com (Alex Glikson) Date: Tue, 9 Aug 2011 00:56:43 +0300 Subject: [Fiware-cloud] attendance at the F2F in Turin Message-ID: Hi All, As you know, a major part of the F2F in Turin in September will be devoted to technical sessions within the teams of each work package. This is a unique opportunity for us to meet F2F, and to have a productive discussion regarding the Cloud Hosting detailed architecture, requirements, assets, etc. This is supposed to be the 'culmination' of the discussions we start tomorrow towards the M5 deliverables. Therefore, it is important that we have a significant representation from all the partners. Of course, the folks coming to the F2F should be familiar with areas that the corresponding company is going to work on in FI-WARE, as well as with the assets being proposed. >From IBM, myself and David Breitgand will participate the Cloud Hosting sessions. Please, let me know who from your company plans to come. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From fla at tid.es Tue Aug 9 09:25:10 2011 From: fla at tid.es (FERNANDO LOPEZ AGUILAR) Date: Tue, 09 Aug 2011 09:25:10 +0200 Subject: [Fiware-cloud] attendance at the F2F in Turin In-Reply-To: References: Message-ID: <8EE61BA0CAEDBD4E9DA928D1206463D2A1851656FC@EXCLU2K7.hi.inet> Dear Alex et all, >From TID, I will be there from 13th to 16th Regarding the first version of the backlog, I send you my first version of it. See you soon. Fernando.- From: fiware-cloud-bounces at lists.fi-ware.eu [mailto:fiware-cloud-bounces at lists.fi-ware.eu] On Behalf Of Alex Glikson Sent: lunes, 08 de agosto de 2011 23:57 To: fiware-cloud at lists.fi-ware.eu Subject: [Fiware-cloud] attendance at the F2F in Turin Hi All, As you know, a major part of the F2F in Turin in September will be devoted to technical sessions within the teams of each work package. This is a unique opportunity for us to meet F2F, and to have a productive discussion regarding the Cloud Hosting detailed architecture, requirements, assets, etc. This is supposed to be the 'culmination' of the discussions we start tomorrow towards the M5 deliverables. Therefore, it is important that we have a significant representation from all the partners. Of course, the folks coming to the F2F should be familiar with areas that the corresponding company is going to work on in FI-WARE, as well as with the assets being proposed. >From IBM, myself and David Breitgand will participate the Cloud Hosting sessions. Please, let me know who from your company plans to come. Thanks, Alex ________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: Backlog entries description v0.1 TID.xlsx Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet Size: 47011 bytes Desc: Backlog entries description v0.1 TID.xlsx URL: From GLIKSON at il.ibm.com Thu Aug 11 16:13:04 2011 From: GLIKSON at il.ibm.com (Alex Glikson) Date: Thu, 11 Aug 2011 17:13:04 +0300 Subject: [Fiware-cloud] Fw: [Fiware-wpl] Hints and examples about entries for the FI-WARE backlog Message-ID: FYI ----- Forwarded by Alex Glikson/Haifa/IBM on 11/08/2011 05:12 PM ----- From: Juanjo Hierro To: "fiware-wpl at lists.fi-ware.eu" , "fiware-wpa at lists.fi-ware.eu" Date: 10/08/2011 07:10 PM Subject: [Fiware-wpl] Hints and examples about entries for the FI-WARE backlog Sent by: fiware-wpl-bounces at lists.fi-ware.eu Hi all, One of the action points that were agreed had to do with providing some detail examples of what the entries for an EPIC and a User Story (or Story, for short) in the FI-WARE backlog. Please find enclosed a spreadsheet where I have included two separate sheets describing: The template to be used for entries in the backlog. This is an update of the one you already had where I have addressed some points that were unresolved or required some clarifications. I have found also the need to add a new field (Detailed Status). An example of an EPIC An example of an User Story The examples are not "official". I just elaborate them on my own (although the EPIC was based on an initial proposal made by Fernando L?pez from TID). They just pretend to serve as example of the level of "granularity" associated to an EPIC compared to a User Story in an Agile backlog. What can be considered at the level of "user story" according to Agile ? Well ... there is no a black or white frontier between things nor a mathematical formula you can apply and then determine when something should be considered an EPIC rather than a User Story. As mentioned in the presentation on Agile we made at the FI-WARE kick-off meeting, User Stories have to comply with "INVEST" properties which mean they should be "Independent, Negotiable, Valuable, Estimatable, Small and Testable". Some resources that may be helpful in finding out what we mean by INVEST properties can be found at [1], [2] and even [3] but in general: Bear in mind that User Stories have to be something "Small" as to be affordable in a Sprint. Sprints should be of a maximum of two months in FI-WARE, unitary tests included (I'm even seriously considering to make them shorter, of about one month, therefore closer to the spirit of Agile). In general, something that would go beyond one single sprint should be considered an EPIC. It should be also detailed enough so that you can say "I understand what I want well enough that I could think how a test for it could be designed." This is what means it should be "Testable". User stories also should be "Estimatable" meaning that it should contain enough information enabling a developer to make a rough estimation of how much it would take to develop it (and shouldn't go beyond the time limits of a sprint :-). In our case, we are supposed to bring on the table tangible assets per GEs. Therefore, "Estimatable" means that the corresponding development team should be able to answer you how much would it take to implement the user story you are providing. Therefore, you can make a simple test: take one of your entries, go to the teams, and ask them "how much effort (roughly) would it take ?" ... if they give you answers like "unless you give me more details, it's simply impossible ... what you provide is too vague", then you don't have a user story for sure but probably an EPIC. They don't need to have ALL the details nor have everything closed. There should be details that may be worked out while developing it (again, bear the duration of sprints in mind, i.e., maximum between 1-2 months). You shouldn't enter into that level of detail at which you are probably wasting time and unnecessarily delaying development. But good developers are able to provide accurate estimations without knowing all details. This is why they should be "Negotiable" (detailed description may vary/be-refined over time even during development but without this implying a relevant deviation from the original estimation) "Independent" and "Valuable" are also relevant but I guess there may be many EPICs that would also cope with those properties. That's why I would make emphasis on the previous points. Some references (but you may find much more, just search for INVEST properties for User Stories in Agile or discussions on EPICs vs User Stories): [1] - http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ [2] - http://agilesoftwaredevelopment.com/blog/vaibhav/good-user-story-invest [3] - http://en.wikipedia.org/wiki/INVEST_%28mnemonic%29 Themes, are much more high-level or abstract than EPICs. The frontier between Themes and EPICs is also fuzzy, but is not that relevant as the frontier between EPICs and User Stories because this last frontier is what matters to know when you may stop refining. Indeed, we may adopt a convention regarding what to call Theme and what to call an EPIC. For example, we may map the notion of "Theme" to the notion of Generic Enabler in FI-WARE. Therefore, there would be a Theme linked to the "Publish/Subscribe Broker GE" which establishes as a goal that "Applications should be able to publish data and subscribe to data of their interest". The "target usage" text in the FI-WARE Product Vision / High-level Description deliverable for a given GE may well work as the content for the description of the corresponding Theme. Given said this, don't feel too frustrated if you are not able to identify too many User Stories in a first shot. I believe that we should feel confident if we end August with a complete and comprehensive set of EPICs per Generic Enabler. Then, during September, we may focus in trying to derive a number of User Stories from those EPICs that will enable to plan the first sprint in FI-WARE (which we should be able to start by early October) Please remind that we are supposed to rely the development of the reference implementation of FI-WARE GEs in a number of assets. We should concentrate on what will map into development tasks on those assets (so that they can integrate with other assets, comply with the final standard open royalty-free specification of interfaces we want them to provide, incorporate any function that we agree a target reference implementation must/should offer but our asset still do not offer). Don't focus on describing things already supported by an asset. Remember: backlog = work to be done. Review my previous mails on the matter if you have any doubt. Please share this with your teams. And don't hesitate to bring on the table any doubt, concern or comment you may have. Let's share them and share the answer. Last but not least, please send back two separate responses: a) first to Thomas and me, a response confirming that you have received this email b) later, to the fiware-wpl and fiware-wpa, an email confirming that you have read it and you feel like there is no essential obstacle for moving forward. If you have any initial questions/doubts/comments you would like to share at the time you send the response, please do so. Best regards, -- Juanjo 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 _______________________________________________ Fiware-wpl mailing list Fiware-wpl at lists.fi-ware.eu http://lists.fi-ware.eu/listinfo/fiware-wpl -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Backlog entries examples by TID 11-08-09.xls Type: application/vnd.ms-excel Size: 70656 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: jhierro.vcf Type: application/octet-stream Size: 443 bytes Desc: not available URL: From GLIKSON at il.ibm.com Mon Aug 15 08:43:13 2011 From: GLIKSON at il.ibm.com (Alex Glikson) Date: Mon, 15 Aug 2011 09:43:13 +0300 Subject: [Fiware-cloud] 9-Aug-2011 weekly conf call -- minutes & next steps Message-ID: Attendees: IBM, TID, TRDF, INRIA Minutes: We reviewed Juanjo's email regarding next steps. For each GE, we need to 1) refine architecture 2) identify assets, 3) map them into the architecture, 4) identify overlaps and gaps, and 5) define associated Agile work items (epics, stories, etc) Each company leading the work on a GE will be responsible for elaborating on the above points for the corresponding GE (with contribution from other participating partners) We agreed to have a deep-dive discussions on architecture and assets for each of the GEs. Due to vacations, most of these discussions will need to occur in September. TID will provide additional people to participate the discussions, to cover for vacations of regular participants (e.g., Fernando) Session on Cloud Edge will be scheduled for 6/9. We reviewed Fernando's initial draft of epics for the Service Management GE We need an exact notation to be used in the backlog. The latest email from Juanjo seems to address this. List of GEs and people responsible to drive the corresponding effort: RM - Alex Service, PaaS -- Fernando Cloud Edge -- Serge Object Storage -- Andy Monitoring -- TBD Metering & Accounting -- TBD Regards, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From GLIKSON at il.ibm.com Mon Aug 15 11:28:18 2011 From: GLIKSON at il.ibm.com (Alex Glikson) Date: Mon, 15 Aug 2011 12:28:18 +0300 Subject: [Fiware-cloud] Fw: First release of the FI-WARE High-level Description (Product Vision) deliverable Message-ID: FYI ----- Forwarded by Alex Glikson/Haifa/IBM on 15/08/2011 12:26 PM ----- From: Juanjo Hierro To: "fiware-wpl at lists.fi-ware.eu" , "fiware-wpa at lists.fi-ware.eu" Date: 15/08/2011 12:09 PM Subject: [Fiware-wpa] First release of the FI-WARE High-level Description (Product Vision) deliverable Sent by: fiware-wpa-bounces at lists.fi-ware.eu Hi all, Finally, I have been able to close the first official release of the FI-WARE High-level Description (Product Vision) deliverable. The official, .pdf version is available at: https://forge.fi-ware.eu/docman/view.php/7/308/FI-WARE+High-Level+Description+v1.0+11-08-15.pdf The MS Word version is privately available at: https://forge.fi-ware.eu/docman/view.php/7/309/FI-WARE+High-Level+Description+v1.0+11-08-15.doc Please try to make a final review and check that everything was fine with your chapter. Despite I have already sent it to the EC, I would kindly ask you to perform this final revision, just in case that I have miss something. You are entitled to share this document with the rest of your teams. Best regards, -- Juanjo P.S.: I will be travelling most of today. If you send some particular request to me, I won't be able to respond until later tonight. 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 [attachment "jhierro.vcf" deleted by Alex Glikson/Haifa/IBM] _______________________________________________ Fiware-wpa mailing list Fiware-wpa at lists.fi-ware.eu http://lists.fi-ware.eu/listinfo/fiware-wpa -------------- next part -------------- An HTML attachment was scrubbed... URL: From GLIKSON at il.ibm.com Wed Aug 17 19:15:36 2011 From: GLIKSON at il.ibm.com (Alex Glikson) Date: Wed, 17 Aug 2011 20:15:36 +0300 Subject: [Fiware-cloud] 16-Aug-2011 weekly conf call -- minutes & next steps Message-ID: Dear all, Please, see below a summary of our last weekly conf call. Your comments are welcome. For our next calls, I would suggest the following agenda (aiming at finalizing the architecture, assets and gaps for each GE): 23/8 -- Object Storage GE and PaaS Management GE (Intel and TID are lead contributors, correspondingly) 30/8 -- Service Management GE and Portal (TID and UPM are lead contributors) 6/9 -- Cloud Edge GE (TRDF is the leading contributor) For each of the topics, please, make sure that representatives from lead contributors attend and are well-prepared to discuss architecture, assets and gaps. Regards, Alex Attendees: IBM, TID, INTEL Agenda: architecture and assets for IaaS DataCenter Resource Management GE and Monitoring GE IaaS Resource Management GE Assets: OpenStack Nova is currently the leading candidate to be the basis for IaaS resource management functionality. It is well-architected, and has a strong growing community contributing to it. OpenStack Glance can be considered as a basis for image library functionality. However, the relationship to the asset proposed for service catalog managed by the Service Management GE needs to be clarified [owner: TID]. For example, does Glance need to keep OVFs, or just the individual VM images (while OVFs will be kept in Claudia)? Open vSwitch is the leading candidate to provide virtual networking functions, such as support for VLANs (an integration with OpenStack exists, but might require effort to provide what we need) PIVOT (from IBM) will be used for intelligent management (incl. resource scheduling, policies and admission control) of 'clusters' comprising the cloud infrastructure, potentially in a hierarchical manner (for scalability) xCAT (provided by IBM) will be used for bare-metal provisioning and hardware management of the physical machines comprising the cloud infrastructure. HSLT (from IBM) will provide resiliency features for the management fabric. Several tools can be considered to collect the monitoring metrics of the various resources, such as collectd, Ganglia, Nagios and xCAT. This would need to integrate with the framework provided by the Monitoring GE (described below). OCCI will be considered as the standardized interface that will be surfaced by this GE Other related assets to consider: Crowbar, Opscode (there are probably more) Architecture: The basis for the architecture will be the one of OpenStack Nova. A good summary can be found at http://ken.pepple.info/openstack/2011/04/22/openstack-nova-architecture/. TBD: need to map all the other assets on the architecture [owner: IBM] Gaps: Integration QoS admin kit Other? Monitoring GE: Note: the discussions regarding this GE are rather preliminary at this stage. An asset being considered for the monitoring GE is the Rocksteady framework (http://code.google.com/p/rocksteady/) An architecture including also few additional components (RabitMQ, Esper, Graphite) to gather and process metrics is outlined at http://code.google.com/p/rocksteady/ Gaps: TBD, requires further discussion -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewx.edmonds at intel.com Wed Aug 24 19:07:16 2011 From: andrewx.edmonds at intel.com (Edmonds, AndrewX) Date: Wed, 24 Aug 2011 17:07:16 +0000 Subject: [Fiware-cloud] attendance at the F2F in Turin In-Reply-To: References: Message-ID: <332A51FC2924EE4A8CDD5BB4BB05CE19014276@IRSMSX101.ger.corp.intel.com> I'll be there from Intel. From: fiware-cloud-bounces at lists.fi-ware.eu [mailto:fiware-cloud-bounces at lists.fi-ware.eu] On Behalf Of Alex Glikson Sent: Monday, August 08, 2011 10:57 PM To: fiware-cloud at lists.fi-ware.eu Subject: [Fiware-cloud] attendance at the F2F in Turin Hi All, As you know, a major part of the F2F in Turin in September will be devoted to technical sessions within the teams of each work package. This is a unique opportunity for us to meet F2F, and to have a productive discussion regarding the Cloud Hosting detailed architecture, requirements, assets, etc. This is supposed to be the 'culmination' of the discussions we start tomorrow towards the M5 deliverables. Therefore, it is important that we have a significant representation from all the partners. Of course, the folks coming to the F2F should be familiar with areas that the corresponding company is going to work on in FI-WARE, as well as with the assets being proposed. >From IBM, myself and David Breitgand will participate the Cloud Hosting sessions. Please, let me know who from your company plans to come. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5213 bytes Desc: not available URL: -------------- next part -------------- ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From joaquin.salvachua at upm.es Thu Aug 25 10:49:23 2011 From: joaquin.salvachua at upm.es (Joaquin Salvachua) Date: Thu, 25 Aug 2011 10:49:23 +0200 Subject: [Fiware-cloud] attendance at the F2F in Turin In-Reply-To: <332A51FC2924EE4A8CDD5BB4BB05CE19014276@IRSMSX101.ger.corp.intel.com> References: <332A51FC2924EE4A8CDD5BB4BB05CE19014276@IRSMSX101.ger.corp.intel.com> Message-ID: <7904422A-8E64-426A-A3C5-4F637C438170@upm.es> I will attend from UPM. Joaqu?n El 24/08/2011, a las 19:07, Edmonds, AndrewX escribi?: > I?ll be there from Intel. > > From: fiware-cloud-bounces at lists.fi-ware.eu [mailto:fiware-cloud-bounces at lists.fi-ware.eu] On Behalf Of Alex Glikson > Sent: Monday, August 08, 2011 10:57 PM > To: fiware-cloud at lists.fi-ware.eu > Subject: [Fiware-cloud] attendance at the F2F in Turin > > Hi All, > > As you know, a major part of the F2F in Turin in September will be devoted to technical sessions within the teams of each work package. This is a unique opportunity for us to meet F2F, and to have a productive discussion regarding the Cloud Hosting detailed architecture, requirements, assets, etc. This is supposed to be the 'culmination' of the discussions we start tomorrow towards the M5 deliverables. Therefore, it is important that we have a significant representation from all the partners. Of course, the folks coming to the F2F should be familiar with areas that the corresponding company is going to work on in FI-WARE, as well as with the assets being proposed. > From IBM, myself and David Breitgand will participate the Cloud Hosting sessions. > Please, let me know who from your company plans to come. > > Thanks, > Alex > ------------------------------------------------------------- > Intel Ireland Limited (Branch) > Collinstown Industrial Park, Leixlip, County Kildare, Ireland > Registered Number: E902934 > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > _______________________________________________ > Fiware-cloud mailing list > Fiware-cloud at lists.fi-ware.eu > http://lists.fi-ware.eu/listinfo/fiware-cloud ------------------------------------------------------------------------ Joaquin Salvachua tel: +34 91 549 57 00 x.3026 Associated Professor +34 91 549 57 62 x.3026 dpt. Telematica E.T.S.I. Telecomunicacion Ciudad Universitaria S/N fax: +34 91 336 73 33 E-28040 MADRID SPAIN mailto:jsalvachua at dit.upm.es // http://www.dit.upm.es/~jsr Blog: http://jsalvachua.blogspot.com/ -------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewx.edmonds at intel.com Thu Aug 25 15:01:24 2011 From: andrewx.edmonds at intel.com (Edmonds, AndrewX) Date: Thu, 25 Aug 2011 13:01:24 +0000 Subject: [Fiware-cloud] Monitoring Message-ID: <332A51FC2924EE4A8CDD5BB4BB05CE1901440E@IRSMSX101.ger.corp.intel.com> I've put down some of my thoughts on monitoring that I've talked about before on confcalls. Comments etc very welcome! HTH, Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: monitoring.pdf Type: application/pdf Size: 60942 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5213 bytes Desc: not available URL: -------------- next part -------------- ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From GLIKSON at il.ibm.com Thu Aug 25 22:33:37 2011 From: GLIKSON at il.ibm.com (Alex Glikson) Date: Thu, 25 Aug 2011 23:33:37 +0300 Subject: [Fiware-cloud] 23-Aug-2011 weekly conf call -- minutes Message-ID: All, Please, see below minutes of this week's conf call. Regarding next week's agenda -- we will not be able to discuss any of the other GEs (PaaS, Service Management, Portal, Cloud Edge) due to vacation of key participants (TID, TRDF). We may use this slot to discuss Epics associated with the Resource Management GE and Object Storage GE (and maybe Monitoring GE) -- unless sufficiently covered via email before that. Andy -- can you, please, prepare an initial list of Epics, representing the major work areas that you are aware of? we can then compare & consolidate. Regards, Alex Attendees: IBM, INTEL Agenda: architecture and assets for Object Storage GE; continue discussion on monitoring Minutes: Object Storage GE: OpenStack Swift is the main asset being considered for the Object Storage GE. It seems to have a reasonably complete set of features, and no major development effort is expected. This is also consistent with the current level of funding for this work (part of task 4.1). The main areas that require some work (based on our current understanding) include: Integration CDMI interface Security (integration with WP8) Collection of metrics (e.g., using collectd) -- for administration (e.g., quota or failure events), metering/accounting (e.g., usage statistics), etc Enhanced policies (e.g., QoS) Monitoring Continued the discussion from last meeting Rocksteady is a good basis for overall monitoring architecture Monitoring GE should provide a common instrumentation to be used by other GEs to handle metrics -- collection, distribution, storage, analysis We should consider using instrumentation provided by Data Management GEs Action Item [Alex]: follow up on this Each GE will be responsible for publishing its metrics. Any GE can be the consumer of its own metrics, as well as of metrics published by other GEs. For example, metering/accounting GE will be consuming resource usage metrics provided by resource management GE. Moreover, Service Management GE will consume resource utilization metrics provided by Resource Management GE. Action Item: need to follow-up on metrics provided/consumed by each GE Moreover, the monitoring GE should provide a management API, as well as role-based access control -------------- next part -------------- An HTML attachment was scrubbed... URL: From GLIKSON at il.ibm.com Thu Aug 25 22:56:40 2011 From: GLIKSON at il.ibm.com (Alex Glikson) Date: Thu, 25 Aug 2011 23:56:40 +0300 Subject: [Fiware-cloud] Resource Management GE -- initial list of Epics Message-ID: Hi, I've tried to come up with an initial list of Epics describing the main work areas associated with the Resource Management GE. Your comments are welcome. Basic IaaS stack up and running (compute, storage) Virtual networking with Open vSwitch Storage enhancements Security considerations Monitoring and integration with metrics framework (resource utilization, management events, etc) Enhancements to management fabric (scalability, resiliency, etc) Resource guarantees and performance isolation Mobility and related scenarios Enhanced VM placement Automation of bare-metal operations Capacity planning, over-commit management and admission control APIs (e.g., OCCI) Admin toolkit Integration with Service Management GE Support federation scenarios Regards, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewx.edmonds at intel.com Mon Aug 29 16:09:00 2011 From: andrewx.edmonds at intel.com (Edmonds, AndrewX) Date: Mon, 29 Aug 2011 14:09:00 +0000 Subject: [Fiware-cloud] Resource Management GE -- initial list of Epics In-Reply-To: References: Message-ID: <332A51FC2924EE4A8CDD5BB4BB05CE19014A2B@IRSMSX101.ger.corp.intel.com> Here are some more: The migration of one infrastructure service from service provider A to service provider B - see infoq.com/articles/open-interoperable-cloud for details The provisioning of a secure infrastructure service - partitioned VMs - partitioned networks - RBAC access enabled - VM images cryptographically verified Discovery, Negotiation and Provisioning of an infrastructure service using a machine readable SLA Open APIs to infrastructure services that not only open but are extensible - standardised but still allow service providers differentiate via easy extension Manipulation of infrastructure service monitoring and notifications both at provisioning time and during runtime and by service operator and service owner's perspectives Manipulation of data on an object store using a standardized interface (CDMI) - should allow setting of metadata per object to aid placement with respect to non-functional qualities - allow users and operators access to storage metrics Allow prospective users discover available service provider offerings Andy From: fiware-cloud-bounces at lists.fi-ware.eu [mailto:fiware-cloud-bounces at lists.fi-ware.eu] On Behalf Of Alex Glikson Sent: Thursday, August 25, 2011 9:57 PM To: fiware-cloud at lists.fi-ware.eu Subject: [Fiware-cloud] Resource Management GE -- initial list of Epics Hi, I've tried to come up with an initial list of Epics describing the main work areas associated with the Resource Management GE. Your comments are welcome. 1. Basic IaaS stack up and running (compute, storage) 2. Virtual networking with Open vSwitch 3. Storage enhancements 4. Security considerations 5. Monitoring and integration with metrics framework (resource utilization, management events, etc) 6. Enhancements to management fabric (scalability, resiliency, etc) 7. Resource guarantees and performance isolation 8. Mobility and related scenarios 9. Enhanced VM placement 10. Automation of bare-metal operations 11. Capacity planning, over-commit management and admission control 12. APIs (e.g., OCCI) 13. Admin toolkit 14. Integration with Service Management GE 15. Support federation scenarios Regards, Alex 1. 1. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5213 bytes Desc: not available URL: -------------- next part -------------- ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From GLIKSON at il.ibm.com Mon Aug 29 20:49:34 2011 From: GLIKSON at il.ibm.com (Alex Glikson) Date: Mon, 29 Aug 2011 21:49:34 +0300 Subject: [Fiware-cloud] Fw: [Fiware-wpl] Reminder about Backlog entries and some hints Message-ID: ----- Forwarded by Alex Glikson/Haifa/IBM on 29/08/2011 09:48 PM ----- From: Juanjo Hierro To: "fiware-wpl at lists.fi-ware.eu" , "fiware-wpa at lists.fi-ware.eu" Date: 29/08/2011 04:19 PM Subject: [Fiware-wpl] Reminder about Backlog entries and some hints Sent by: fiware-wpl-bounces at lists.fi-ware.eu Hi all, This mail is to remind you that you should be about providing entries for the FI-WARE Backlog in your respective chapters. There are some comments that have applied to the first take on the entries within the Data/Context Management WP so that I'm sharing them with you because may be they are helpful in collecting your own entries. They are, of course, generic: Try to stick to the formula proposed for goals in the example templates ("Applications should be able to ..." / "It should be possible ..."). This is common practice in Agile. So, as far as it feasible, and not too much artificious, try to follow it. Following a defined formula, we gain in uniformity but, overall it will be easier to extract , and . Note that in Agile, some people like to use a cannonical form which is "As a , I can so that ". We tried just to adapt this a bit to description of stories for a software platform, but the notion of "cannonical form" itself is something we should try to stick to. Chapter field: should be the name of your chapter: "Cloud Hosting", "Data/Context Management", "IoT Service Enablement", ... Source and Stakeholder fields: You should write "FI-WARE" in here, at least for the time being. Keep Source contact empty for the time being. Owner and Owner contact: this should be the name of your company (the company or companies behind the asset being considered as "baseline"). Fill the owner contact with your email for the time being but we'll see how to handle this later (we don't want that making entries publicly available becomes a source of spam :-) We mentioned that "name" should be an acronymun (indeed the last part of the Id) but I have found itself a little bit useless itself if it is actually part of the Id. Therefore, I suggest that we follow the approach of Thales and use it as a short description (should not be longer than 7 words, preferably 4-5 excluding "and"s "the"s and similar auxiliary articles, prepositions, etc) The Description field is free. Put there whatever makes sense to you and would be helpful to understand the entry. Don't hesitate to add URLs to complementary documents, standards, whatever you believe may be useful if read. You can upload a document to the docman system at FusionForge and then use the link if you wish. Regarding the Rationale: at least for entries prioritized with a MUST MoSCoW, try to give more info about why "it would have no sense" if we do not develop the corresponding feature. Note that a MUST priority is considered to be assigned for features that "If not done, the project will be considered a failure". In other words: the product doesn't make sense to you unless it supports that feature. UC projects may argue that some of the features they propose are going to be of a higher priority than these ones, so that better you work the rationale for keeping your priority. About the MoSCoW priority: It is assumed that you are bringing here an asset that your company had developed and had plans to keep evolving because it is of relevant priority to you. Therefore, here you are some guidelines that I would suggest you to bear in mind when reviewing the MoSCoW priorities you had assigned. You should assign a MUST priority to features you would plan to address in the following 12 months in your product (asset), no matter whether FI-WARE had existed or not. Again, the product doesn't make sense if you are not allowed to address this MUST priority. That's why you had it in your roadmap no matter if FI-WARE exists or not. You may assign a SHOULD priority to features that were in your roadmap and you believe were important although perhaps you couldn't address them in the next 12 months prior existence of FI-WARE because lack of resources. FI-WARE actually gaves you the opportunity to address them. You should assign a COULD priority to features you believe are nice to have and could be addressed thanks to FI-WARE. But you are open to learn about better ideas that may get assigned a higher priority. Hope all these comments become useful. Don't hesitate to formulate any question. Best regards, -- Juanjo 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[attachment "jhierro.vcf" deleted by Alex Glikson/Haifa/IBM] _______________________________________________ Fiware-wpl mailing list Fiware-wpl at lists.fi-ware.eu http://lists.fi-ware.eu/listinfo/fiware-wpl -------------- next part -------------- An HTML attachment was scrubbed... URL: