IT priorities from GDP Delivery Team

Agustin Benito Bethencourt agustin.benito at codethink.co.uk
Fri Jun 24 11:19:32 EDT 2016


Hi Nicholas,

I finally got some time to provide you the list of IT priorities from 
the GDP Delivery Team

1.- Deployment infrastructure.

We need a service to deploy big images/metadata, expose them to the 
public, either to be downloaded or used by a different service. This 
service would work via http, torrent or any other p2p protocol. If the 
service could be mirrored, we can add servers from other organizations 
to increase band-with and availability.

2.- Analytics

We need analytics to understand how GDP is consumed. There are two 
aspects of this request:

* Track basic data about downloads and updates.

* Track hits and visits in the content pages, specially in the download 
and landing wiki  pages as well as announcements.

A mix of this request and the previous request was set by the tools team 
as priority for this cycle (before AMM).

https://at.projects.genivi.org/jira/browse/TOOL-59

3.- Cont. delivery management tool

GDP is the the main go.cd user within GENIVI since we are already using 
it in production. We depend on the tool. Please count on us for the 
transition since we might get affected.

I strongly recommend setting a test environment and a production one. 
Others will need to learn as they use it as we do and we want to make 
sure we provide the right perception to users and contributors about GDP 
status. Mixing testing agents and production ones is misleading when 
results for GDP from different agents are contradictory.

GDP needs to scale up its CI in order to accelerate the project. We will 
require more agents since the number of targets, contributors and 
software are growing. I believe GDP requirements will be higher than the 
current set up might hint.

Put go.cd in production was defined by the tools team as priority for 
this cycle (before AMM)

https://at.projects.genivi.org/jira/browse/TOOL-57

3.- URLs

Currently we are working with long and unreadable URLs. To mitigate this 
issue Joel set up user friendly re-directions for specific needs GDP had.

Once the consolidation is finished and the time to re-configure the DNS 
comes, please talk to us so we work to minimise the impact, which can be 
significant. We talked about this in the last Tools Team meeting.

4.- FOSSology

I see license compliance as a key value that GENIVI can provide to the 
members. Using FOSSology in GDP on regular basis would be a major step 
forward for the project. We would need to set it up in GENIVI's 
infrastructure for testing before putting it in production. False 
positives needs to be discovered and managed before having FOSSology in 
production in the open.

5.- Automated source mirroring

Setting up all the infrastructure in one place has many advantages. Some 
of the main ones get diluted if we need to go to internet every time we 
want to build GDP. It is not only about reliability but also about 
efficiency.

I would like to have data from our infrastructure before opening the 
debate of how we manage/mirror our sources. When other key services get 
in production, I will request access to a VM to set up a source 
mirroring service and configure GDP to use it.

Other

* I am a little worry about the usage of Confluence as CMS. The 
deployment infrastructure/service might work as such, specially for big 
documents. In any case, using a wiki for attaching documents brings 
scalability and migration challenges.

* "Pad" service for taking notes in minutes and other collaboration use 
cases would be extremely helpful for improving the communication 
internally. Jeremiah has pointed at this before.

* We need a "paste" service to provide logs through links instead of 
through mail or chat. This is a small but high impact service to boost 
collaboration. In GDP we are currently using Baserock one. Maybe others 
have a similar need.

And what about testing?

We are focused now in promoting Open Source best quality practices[1]. 
We will start soon working on simple additional acceptance testing. We 
are still far away from automated testing.

We would like first to socialise simple but useful manual test 
(scripts). Once we have the right processes in place and contributions 
in the form of more tests and results, we will be ready for something 
more ambitious. More people involved in this topic is welcome.

Feel free to provide feedback on this.

[1] http://blog.toscalix.com/2016/05/testing-quality-really.html

Best Regards
-- 
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito at codethink.co.uk



More information about the genivi-projects mailing list