As someone that has upgraded rdo clouds on multiple occasions, I concur. Its way easier to upgrade a whole cloud, (or even pieces of a cloud are possible) with properly isolated containers instead of rpms. Thats the case where containers really shine, and you don't experience it until you try and upgrade an existing cloud, or try to run multiple services from different releases on the same controller.
Thanks, Kevin ________________________________________ From: Michał Jastrzębski [inc...@gmail.com] Sent: Wednesday, January 27, 2016 6:36 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] OpenStack installer Disclaimer: I'm from Kolla. Well, you will see these benefits when you'll try to perform upgrade:) that's the tricky part about containers - they become really useful after 6 months. Without them you'll end up having to upgrade every service at the very same time, and that's disruptive at best, disastrous at worst. Containers gives you benefit of separation between services dependencies, so you won't even run into conflict of versions. Another benefit is pre-built images gives you repeatability of deployments, which is something you don't appreciate until you lose it. Last but not least, cleanups and rollbacks are a breeze, and doesn't leave any trash on base system - another benefit easily underestimated. feel free to find us in #kolla if you have any questions. Cheers, inc0 On 27 January 2016 at 02:49, Gyorgy Szombathelyi <gyorgy.szombathe...@doclerholding.com> wrote: >> >> Hi Gyorgy, >> > Hi Kevin, > >> I'll definitely give this a look and thanks for sharing. I would like to ask >> however why you found OpenStack-Anisble overly complex so much so that >> you've taken on the complexity of developing a new installer all together? >> I'd >> love to understand the issues you ran into and see what we can do in >> upstream OpenStack-Ansible to overcome them for the greater community. >> Being that OpenStack-Ansible is no longer a Rackspace project but a >> community effort governed by the OpenStack Foundation I'd been keen on >> seeing how we can simplify the deployment offerings we're currently >> working on today in an effort foster greater developer interactions so that >> we can work together on building the best deployer and operator >> experience. >> > Basically there were two major points: > > - containers: we don't need it. For us, that was no real benefits to use > them, but just > added unnecessary complexity. Instead of having 1 mgmt address of a > controller, it had > a dozen, installation times were huge (>2 hours) with creating and updating > each controller, the > generated inventory was fragile (any time I wanted to change something in the > generated > inventory, I had a high chance to break it). When I learned how to install > without containers, > another problem came in: every service listens on 0.0.0.0, so haproxy can't > bind to the service ports. > > - packages: we wanted to avoid mixing pip and vendor packages. Linux great > power was > always the package management system. We don't have the capacity to choose > the right > revision from git. Also a .deb package come with goodies, like the init > scripts, proper system > users, directories, upgrade possibility and so on. Bugs can be reported > against .debs. > > And some minor points: > - Need root rights to start. I don't really understand why it is needed. > - I think the role plays are unnecessary fragmented into files. Ansible > designed with simplicity in mind, > now keystone for example has 29 files, lots of them with 1 task. I could > not understand what the > - The 'must have tags' are also against Ansible's philosophy. No one should > need to start a play with a tag > (tagging should be an exception, not the rule). Running a role doesn't take > more than 10-20 secs, if it is already > completed, tagging is just unnecessary bloat. If you need to start something > at the middle of a play, then that play > is not right. > > So those were the reason why we started our project, hope you can understand > it. We don't want to compete, > just it serves us better. > >> All that said, thanks for sharing the release and if I can help in any way >> please >> reach out. >> > Thanks, maybe we can work together in the future. > >> -- >> >> Kevin Carter >> IRC: cloudnull >> > Br, > György > >> >> ________________________________________ >> From: Gyorgy Szombathelyi <gyorgy.szombathe...@doclerholding.com> >> Sent: Tuesday, January 26, 2016 4:32 AM >> To: 'openstack-dev@lists.openstack.org' >> Subject: [openstack-dev] OpenStack installer >> >> Hello! >> >> I just want to announce a new installer for OpenStack: >> https://github.com/DoclerLabs/openstack >> It is GPLv3, uses Ansible (currently 1.9.x, 2.0.0.2 has some bugs which has >> to >> be resolved), has lots of components integrated (of course there are missing >> ones). >> Goal was simplicity and also operating the cloud, not just installing it. >> We started with Rackspace's openstack-ansible, but found it a bit complex >> with the containers. Also it didn't include all the components we required, >> so >> started this project. >> Feel free to give it a try! The documentation is sparse, but it'll improve >> with >> time. >> (Hope you don't consider it as an advertisement, we don't want to sell this, >> just wanted to share our development). >> >> Br, >> György >> >> __________________________________________________________ >> ________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: OpenStack-dev- >> requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> __________________________________________________________ >> ________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: OpenStack-dev- >> requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
