Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Being Brave: Deploying OpenStack from Master


Published on

Fatih Degirmenci, Ericsson, Yolanda Robla Mota, RedHat, Markos Chandras, SUSE

OPNFV has been working with the communities such as OpenStack, OpenDaylight, and as part of its Cross Community CI (XCI) effort in order to provide means for the developers to work with the latest versions of upstream components, cutting the time it takes to develop new features significantly and testing them on the OPNFV Infrastructure.

Apart from developing and testing new features, OPNFV XCI will enable developers to identify bugs earlier, issue fixes faster, and get feedback on a daily basis. This is a prerequisite for OPNFV in its CD & DevOps journey.

OPNFV aims to run XCI by reusing what other communities developed such as bifrost and openstack-ansible. While doing this, OPNFV intends to develop, maintain, and evolve OPNFV Infrastructure like how the other OPNFV projects do; upstream first. Whatever missing functionality and issues we identify in the components we use as part of our infrastructure and CI/CD toolchain, we strive to fix them directly upstream.

During this session, we will talk about the progress we have made so far, contributions we made to our upstream communities, and share our experiences. We will also highlight the key benefits of XCI for the community in order for developers to utilize the mechanisms, work with OpenStack master to implement new features and fix bugs using the toolchain XCI established.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Being Brave: Deploying OpenStack from Master

  1. 1. Being Brave: Deploying OpenStack from Master Fatih Degirmenci, Ericsson Yolanda Robla Mota, RedHat Markos Chandras, SUSE
  2. 2. • Story so far • How can we improve? • Bifrost and OpenStack Ansible • Current status & Next steps
  3. 3. Our story so far • What has OPNFV achieved? • 4 releases • 10s of scenarios • 100s of developers • 1000s of deployments • How did OPNFV achieve this? • Put good (enough) way of working for integration and testing • Always regarded automation as crucial • Established good (enough) CI pipeline
  4. 4. What are our pains? • Late integration • It takes months for a feature/fix to be available to OPNFV • Slow feedback • It takes months to know if the feature/fix works • Lack of visibility • It is not easy to track the progress of anything • High demand on limited no of people • new OpenStack release -> installer uplift -> feature integration • Too fragmented • Too many ways to do same thing, differently
  5. 5. How have we been working? Project Team OPNFV Gerrit OPNFV CI/Test OPNFV Release Upstream Gerrit Upstream CI/Test Upstream Release Requirement Patch Test Release Downstream Release Test Test Document • Long development cycle • Downstream will delay to next release • Slow feedback, > 5 months • OPNFV specific issues cannot be tested/detected in time
  6. 6. How can we improve? • Work against trunk • Do things when things happen • Provide means for developers to develop • Use upstream tooling
  7. 7. Enablers + bifrost openstack-ansible
  8. 8. Bifrost • What is it? • Standalone Ironic • Tool for provisioning virtual and bare metal machines • Ansible based • Supports Ubuntu, Centos, and SUSE • Easy to use – create inventory, install bifrost, enroll and deploy machines! • Current Status • Rock-solid! • OPNFV runs 3rd Party CI for all the patches! • Used by OPNFV XCI
  9. 9. Bifrost – Node Enrollment
  10. 10. Bifrost – Node Deployment
  11. 11. OpenStack Ansible • What is it? • Tool for installing OpenStack • Containerized (lxc) OpenStack services (or install them on baremetal too) • Ansible based • Easy integration – write your own role • Ability to deploy using patches • Supports Ubuntu, and Centos • Current Status • Possibility to be used for OpenStack gating • SUSE support is on its way
  12. 12. Putting all together
  13. 13. What we will achieve? • early integration – work with master branch (weekly) • faster feedback – feedback per patchset or on a daily basis • alignment and reuse – use of upstream tooling • better visibility – discover bugs in OPNFV environment and fix them
  14. 14. Where are we now and what is next? • We have the first scenario – os-nosdn-nofeature-ha from master! • Virtual machines • Bare metal nodes • We have the developer sandbox available for quite some time • 4 flavors; all in one, mini, noha, ha • OpenDaylight, Tacker, OVS integration work is on its way
  15. 15. QUESTIONS?