1. ICS Software Development Environment Blaž Zupanc and Leandro Fernandez www.europeanspallationsource.se 19 February 2016

2. Agenda Introduction and Overview (Leandro) New release (Blaz) Testing of the development environment (Blaz) 2

3. We want to provide an environment where any user can find the right tools to develop software for the ESS Controls Systems. An environment easy to use and flexible enough to work on different conditions 3 Our goal “ “ Blaz and Leandro – 31 st August 2015. Lund, Sweden.

4. Concepts

5. 5 We use Ansible to automate the deployment and configuration of all our software infrastructure. Installation and configuration is written in playbooks and version controlled.

6. 6 Vagrant is a tool to deliver development environments in the form of virtual machines. We use Vagrant as a layer on top of VirtualBox. Using Vagrant commands we you will be able to: Start, stop, resume and destroy a VM (vagrant up) Update the software installed in the VM (vagrant provision)

7. 7 Jenkins is used in the ICS Continuous Integration. ICS will automate: Build software Test software Deploy software

8. 8 We use docker to create testing environments that simulate operational environments. Docker provides a “cheap” way to create virtual environments.

9. Current status (until yesterday)

10. @ESS 10 NFS EPICS (EEE) Server EPICS base EPICS modules IOCs ELDK Development Environment CS-Studio OpenXAL EPICS development tools IPython Notebook LDAP NFS

11. @In-kind facility 11 NFS EPICS (EEE) Server EPICS modules IOCs EPICS (EEE) Server

12. Disposable DevEnv

13. Don’t get attached to it 13

14. Use shared folders 14

15. How to install

16. 16 https://ess-ics.atlassian.net/wiki/pages/viewpage.action?pageId=50299442 Full description on Confluence: vagrant up

17. How to update

18. 18 Full description on Confluence: https://ess-ics.atlassian.net/wiki/display/DE/Upgrading+to+a+newer+version vagrant provision

19. How to destroy

20. 20 vagrant destroy

21. DevEnv 2.2.0

22. Problems we encountered Ansible provisioning worked on Friday, broke on Monday LDAP worked one day, the next not anymore Users detected simple problems before we did 22

23. What happened? Packages changed in the repositories causing provisioning issues Users upgraded to a newer version of a package which caused issues – Also, CentOS 7.2 got released No automated testing was in place 23

24. Development Environment 2.2.0 Stable repositories Uses stable repositories that do not change Automated testing Simple Jenkins testing in place Local EEE Option to have EEE (r)synced to your local machine 24 (requested by users)

25. Stable repositories CENTOS REPOSITORIES Centos 7.0 -> Centos 7.1 -> Centos 7.2 -> Centos 7.3 DevEnv uses the latest stable version of the repository -> 7.1 EPEL REPOSITORY (extra packages not present in Centos repo) Epel only provides epel 5, epel 6, epel 7 (still being updated) We took epel 7 on a date when it did not cause problems and put the whole repo on Artifactory DevEnv uses Epel repo from Artifactory 25 Latest, still being updated Latest stable

26. Jenkins automated testing How do tests work Create a Docker container with the target environment Run all playbooks in the ics-ans-devenv repo, report failure Three jobs according to target environment Production Centos 7.1 image + Centos latestStable + Epel latestStable Latest epel repo Centos 7.1 image + Centos latestStable + Epel latest Latest Centos and epel repos Centos 7.1 image + Centos latest + Epel latest 26 Centos latestStable -> 7.1 Epel lateststable -> 19.01.2016 Centos latest -> 7 Epel latest -> 7

27. Staying updated Centos releases version 7.3 We will: Centos latestStable: 7.1  7.2 Epel latestStable: 19.01.2016  new date – Put repo on Artifactory Do manual tests Release new DevEnv version with the new stable repositories 27

28. EEE local installation 28 Vagrantfile Rsync will sync the epics and startup folders in /opt/ NOTE: Local EEE installation goes against the agreed development workflow, its use will not be supported. Should only be used for testing or learning purposes where offline access to EEE is needed.

29. Conclusion With version 2.2.0 we: are able to predict provisioning problems before users do prevent package updates from breaking things have a set procedure for future environment upgrades have a simple testing infrastructure for future environments enable users to use local EEE in offline circumstances 29

30. Questions