Dear Fernando, All, sorry for my late reply. Regarding the nodes, we should probably 1) check their initial commitment to FIWARE Lab (as by deliverables in FI-CORE) in term of dates and ensure that it will be fullflled 2) check if any of them plan to extend the commitment also in light of the FIWARE Foundation strategy for FIWARE Lab. This anyhow, requires a representative of the foundation to present and discuss it to the nodes. 3) make a transition plan inline with 1) and 2) Beside the node management, the most important thing it is to know what is the plan for FIWARE Lab by the foundation. This is gonna impact not only the nodes, but most probably will become a requirements to: a) procedures for the FIWARE Lab management; b) FIWARE Lab tools development So in general my feeling is that before any concrete plan on operational and technical evolutions of the lab, we should have a more clear picture of the Foundation strategy in this respect to get aligned. Either Juanjo or Stefano are key in this respect. Regarding the Lab: Simplifying life of infrastructure owners is very important but, the experience (at least this what I learnt) shows that sys admin tend to deploy and set up service the way they prefer, so not sure how much investing on the deployment (with a reducing number of “users” of this feature) is gonna pay off. Maybe, better focus on “monitoring” instruments. On the other side, the first customer of Lab are the end users, and improving their experience is crucial not only for the lab as such, but also for the infrastructures themselves. Getting more concrete, my feeling - which is the same I had at the beginning of FI-CORE, it is that one side the user experience is still very complex, on the other the maintenance of the lab with the different way we offer users to deploy GEs is becoming quite complex. Not sure is gonna be possible, but we should try to simplify, for own sake, the work on it. Which in my mind translates to: - reduce the adoption of proprietary solutions to the minimum; if there is an OS tool that provide the needed functionalities, let’s give up the proprietary solution for the that one and contributing to it; - reduce the way users can deploy GEs (or also actually access the lab), I am favour for going all docker, this will avoid having to maintain also VM images; we may also evaluate that we do not give except to “super users” access to VM deployment, but this may be more complicate and to be evaluated (to do so, we will need a reliable solution to allow users deploy and manage their containers). Also in this light it is important to understand the Foundation strategy. Let me explain: - if - as I understood - the foundation will be the primary actor to manage the lab in the future, I suppose the decision on how the tools should be selected and managed it’s somehow quite important to the foundation. on the other side, the single contributors (even if part of the foundation) may have interest for specific tools - because inline with their business or whatever. it is important to come to an agreement that is reasonable from “strategic" point of view for both that still have to ensure that the foundation is not gonna have a nightmare when FI-NEXT will be over. I.e. let’s try to be pragmatic. In this respect - an I am sorry if the request comes late - but being sick for the past 5 days and out of office for the previous three weeks, i could not do it earlier. I think it is important that before any discussion on what we do in FI-NEXT, we ask to current partners involved in FI-CORE to provide an overview of the architecture and components in place in the lab (beside the basic openstack). The presentation should highlight: - what is in production and what it is not (and why it is not in case) - what’s there reference open source project of the component (and if not, why reinvented the wheel) - what’s the relevance for the lab of the tool Out of this picture, I would start to discuss 1 - what is in and what is out. 2 - what are priorities to be fulfilled not yet covered in the current picture. 3 - what will be the goal architecture and who works on what 4 - allow people to present any tool they feel could be helpful and easy to integrate The last point may break down then in focused discussion. The result may changed the plans contained in the FI-NEXT dow defined in April, but I think this will be a great benefit for the Lab future. Of course, if partners oppose, we can simply stick with the original plan, hoping that all the work we will run will be useful for the future of the Lab. Cheers, Fede 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/> > On 06 Dec 2016, at 20:10, FERNANDO LOPEZ AGUILAR <fernando.lopezaguilar at telefonica.com <mailto:fernando.lopezaguilar at telefonica.com>> wrote: > > Dear all, > > Firstly, I have to apologize for the delay of this email, but we have to adopt a solution and I will take the ball from > the FI-Next representative in WP4 to resolve the issue. I send this email to all the represents that I think that are > working in FI-Next if I miss someone or we should add any other please feel free to forward this email. > > In the same line, I put in copy all the nodes due to currently I do not know how to manage them after the finalization > of FI-Core. I need to take a conversation with all of them and maybe also with Juanjo or Estefano about this issue. > > How you should know, we have planned the 1st FIWARE Summit in Malaga next week. This is an opportunity to > prepare the next activities related to the FI-Next project in the same line to prepare the new requirements an > actuations related to the continuation of the project. > > Currently, there is a separation between the different chapter in FI-Core but all these activities (FIWARE Ops and > FIWARE Lab) will be integrated in FI-Next in the same chapter. Taking into account the three tasks described in the > current FI-Next Part B document I see different point of actuations that should be nice to discuss during FIWARE > Summit event. (Please take into consideration the version of the document that I am managing maybe it is not the > last one). > > Task 4.1 FIWARE Lab overall coordination > Task lead: FIWARE Foundation, supported by: CreateNet, Engineering, Martel > > Here, there are mainly two important topics to discuss. > - Transition of coordination activities from FI-Core to FI-Next, I think that no more that 30m min and 1h max should be enough to fix and see responsibilities of different level of actuation in the Help Desk management. I would like to contact in this point with Alfonso Pietropaolo or someone else from Engineering in order to show us the current organization of different help desk level actuation and how to move to the new project without any service lost. > - Secondly, and not for it less important. We have to talk about the SLA management. It is described clearly in the DoW that each of the node HAVE TO ensure the performance accordingly to a SLA level. Although the responsibility of this activity is Task 4.1, I think that it is very important that all the nodes could attend the session in order to exchange ideas about how to measure the different KPIs and how to monitor the fulfilment of the SLA. I think that a meeting around 2 hours (maybe we can take one more) should be a good point to start with it. Remember that we do not have infinite time to put this action up and running. We have to find a solution ASAP that allows us to monitor the different KPIs. > - Way of working (WoW), fixing weekly meetings, dedicated workspace for exchange of data and best practices, and so on. I estimate 1h for this discussion (maybe less than it), to fix between all of us the different actions that have to be taken and the responsibilities of them. > - Last but not least, a calendar activities of the different deliverables, dates, scheduled activities and any other activity related to the coordination of this chapter will be presented during the FIWARE Summit (my own dog foot). > > > Task 4.2 FIWARE Ops tools > Task lead: Martel, supported by: CreateNet, ZHAW, FIWARE Foundation > > Firstly, we have to fix our WoW, weekly calls and workspace to start to work on this activity. Secondly, this activity should be managed by Martel, but I introduce some ideas that we can exchange in our meeting in Málaga. We have separated/identified 3 subgroups of activities inside this task. > - The FIWARE Lab monitoring infrastructure. > o This is a very stable and well defined solutions at the end of FI-Core BUT we have to think in evolving these tools and simplifying them. The first topics that we have to discuss is the evolution of the FIWARE Lab Monitoring API to use the Monasca API and simplify the current architecture that we have mainly for secure reasons but also to resolve inconsistencies in the data management due to delays or bad sinchronization of them. > o Secondly, we have identified a possible solution based in OpenStack community (Tempest and Rally) to keep up to date the testing tool in the same way that allow us to monitor any possible SLA. The best thing is that it is something to execute locally on each node the bad things is that we should see how to show a global information/status of the different FIWARE Lab nodes like the current solution of FI-Health. > o IMHO, the previous solution will facilitate a steep forward in the management of logs using ElasticSearch, Logstash and Kibana in the same way that incorporate benchmarking solution in the same way that allow us to keep a historical information about the time expended in the execution of the tests. > o Estimation: 2h > - The FIWARE Lab node deployment tool. > o In this point, we should discuss mainly the introduction of the FI-Health installation, but associated to the simplification and full alignment with OpenStack Community, we should think in the installation of Tempest and Ralli solution (discussion in the previous section). > o BUT, the main topics on this issue is related to the Federation Identity Management. The experience that I have is that the installation of one node it is the main problem that the IO found. We should work, together with FIWARE Security group about a solution that allows us to resolve this issue and help us to simplify the process to federate a new node. > o Last but not least, the installation of tools associated to the monitoring of tools described in the previous topics (FIWARE Lab monitoring infrastructure). > o Estimation: 2h > - FIWARE Lab operation tools, > o IMHO, all the activities in this topic are maintenance and operation of current solutions EXCEPT the development of resource migrations from one node to another. It is something that we have seen in FI-Core a necessary tool by the users and we should implement ASAP. The good thinks is that taking into account that ALL keep the same base images, it should not be a problem. The bad things is that we should implement a DIRTY solution if we do not want to keep snapshots from each server that we want to migrate from one region to other. Telefónica provides a possible solution during FI-Core but never was implemented as a service during the previous project. We should analyse it and see if we have any other alternative to work with. > o One important topic here is that taking into account the version of the document that I have, there are some tools that are not represented in the list of owners. I mean some of these tools were developed by partners that I do not see in the continuation, so I would like to know how to manage it promptly. > o Estimation: 1h > > > Task 4.3 Operation of FIWARE Lab nodes > Task lead: Engineering, supported by: Atos, ImagineLab, FIWARE Foundation, ZHAW > > This task should be managed by Engineering, therefore I hope that someone from them should be presented in Malaga. IMHO, the main activity that we should keep during this session is the transition between the FI-Core and FI-Next, taking into account that not all the nodes are represented in the FI-Next. Besides, we have to keep into account that not all the nodes are founded by FI-Next but they are integrated into the ecosystem (Brazil, Mexico, and so on…) Therefore, we have to fix some type the process to include them into the decisions that have to be taken in this task or just to inform them about the different steps that we follow in the community. > > Therefore, my idea is to resolve the WoW of the daily activities, fix weeky meeting (hopefully the same), define our workspace and keep the information up to date in some place. > > Estimation: 1h or 2h > > In this point my total estimation is around 11h. If we take a look to the agenda of the summit: > > https://docs.google.com/spreadsheets/d/1t7OyyDahvcsEPajYNjtglxQndDPHfgD2IeT-3JPhwJM/edit#gid=1803693554 <https://docs.google.com/spreadsheets/d/1t7OyyDahvcsEPajYNjtglxQndDPHfgD2IeT-3JPhwJM/edit#gid=1803693554> > > We have 3,5h on Tuesday (Day 1), 2,5h on Wednesday (Day 2) and 1h on Thursday (Day 3). It gives us only around 7h to discuss all the topics that I mentioned in the previous discussion. Therefore, we should be very efficient to talk about all of them with the time that we have. > > The first request. I would like to have a confirmation of the assistance of the FIWARE Summit to discuss about it. Which FIWARE Lab nodes will attend the sessions and after that confirm me if you are OK with this agenda or by contract you think that some topic should be include for discussion (feel free, I am not God ;) and maybe I forget something). > > PD: Remember that the Cloud team are requested a session about the migration of the cloud portal and keystone to the OpenStack Community the Day 1 between 14:30 and 16:00 and all of us are invited to the discussion. Feel free to reserve this 1,5h to talk about it. In the same line of Cloud Roadmap definition. > > Best regards, > Fernando.- > > > <FI-NEXT PartB - Section 1-3 v50.pdf> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-lab-federation-nodes/attachments/20161212/bcaa5126/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy