Hello Gyorgy, Few more responses inline:
On 01/27/2016 02:51 AM, Gyorgy Szombathelyi 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 I can see the benefit of both a containerized and non-containerized stack. This is one of the reasons the we made the OSA deployment solution capable of doing a deployment without containers. It's really as simple as setting the variable "is_metal=true". While I understand the desire to reduce the deployment times I've found deployments a whole lot more flexible and stable when isolating services especially as it pertains to upgrades. > 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, This is true, the generated inventory can be frustrating when you getting used to setting things up. I've not found it fragile when running prod though. Was there something that you ran into on that front which caused you instabilities or were these all learning pains? > another problem came in: every service listens on 0.0.0.0, so haproxy can't > bind to the service ports. > As a best practice when moving clouds to production I'd NOT recommend running your load balancer on the same hosts as your service infrastructure. One terrible limitation with that kind of a setup, especially without containers or service namespaces, is the problem that arise when a connection go into a sleep wait state while a vip is failing over. This will cause immanent downtime for potentially long periods of time and can break things like DB replication, messaging, etc... This is not something you have to be aware of as your tooling around but when a deployment goes into production its something you should be aware of. Fencing with pacemaker and other things can help but they also bring in other issues. Having an external LB is really the way to go which is why HAP on a controller without containers is not recommended. HAP on a VM or stand alone node works great! Its worth noting in the OSA stack the bind addresses which are assumed 0.0.0.0 can be arbitrarily set using a template override for a given service. > - 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. > I apologize but I could disagree this more. We have all of the system goodies you'd expect running OpenStack on a Ubuntu system, like init scripts, proper system users, directories, etc.. we even have upgradability between major and minor versions. Did you find something that didn't work? Within the OSA project we're choosing the various version from git for the deployer by default and basing every tag off of the stable branches as provided by the various services; so its not like you had much to worry about in that regard. As for the ability to create bugs I fail to see how creating a bug report on a deb from a third party would be more beneficial and have a faster turn around than creating a bug report within a given service project, there by interacting with its developers and maintainers. By going to source we're able to fix general bugs, CVEs, and anything else within hours not days or weeks. Also I question the upgrade-ability of the general OpenStack package ecosystem. As a deployer whom has come from that space and knows what types of shianigans goes on in there, using both debs and rpms, I've found running OpenStack clouds at various sizes for long periods of time becomes very difficult as packages, package dependencies, patches the third party is carrying, and other things change causing instability and general breakage. That said I agree package management in Linux has always been a strong point but I've found out the hard way that package deployments of OpenStack don't scale or upgrade well. It may be better today than it was before however color me skeptical. > And some minor points: > - Need root rights to start. I don't really understand why it is needed. You do need root to run the OSA playbooks, however you could use the ansible "become" process to achieve it. Even in package deployments of OpenStack, as provided by the distro, you still need root privileges to create users, init scripts, etc... > - 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. This is true, some of our roles are rather large but they do just about everything that the service provides. We've found it better to structure the roles with includes instead of simply overloading the main.yml. It makes debugging and focusing parts of the role on specific tasks a given service may require easier to understand and develop. While the Roles could be greatly simplified we're looking to support as many things as possible within a given service, such as Keystone w/ various token provider backens, federation, using apache+mod-wsgi for the api service etc... I'd like to point our that "simplicity in mind" is the driving thought and something that we try to adhere too however holding fast on simplicity is not always possible when the services being deployed are complex. As a deployer simplicity should be a driver in how something works which doesn't always translate to implementation. >...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). I'm not sure what this means. The only thing I could think of is when rebootstratping the galera cluster after every node within the cluster is down. Not that the tag is required is this case, its only used to speed up the bootstrap process and recover the cluster. We do have a few sanity checks in places that will cause a role to hard fail and may require passing an extra variable on the command line to run however the fail output provides a fairly robust message regarding why the task is being hard stopped. This was done so that you don't inadvertently cause yourself downtime or data-loss. In either case, these are the exceptions and not the rules. So like I said I think I'm missing the point here. 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. This is plain wrong... Tags are not bloat and you'll wish you had them when you need to rapidly run a given task to recover or reconfigure something especially as your playbooks and roles grow in sophistication and capabilities. I will say though that we had a similar philosophy in our early Ansible adventures however we've since reversed that position entirely. > > 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. > I too hope that we can work together. It'd be great to get different perspectives on roles and plays that we're creating and that you may need to serve your deployments. I'll also note that we've embarked on a massive decoupling of the roles from the main OSA repository which may be beneficial to you and your project, or other projects like it. A full list of roles we've done thus far can be seen here [0]. In the Mitaka release time we hope to have the roles fully stand alone and brought into OSA via the ansible-galaxy resolver which will make it possible for developers and deployers a like to benifit from the roles on an `a la carte` basis. If you ever have other questions as you build out your own project or if there's something that we can help with please let us know. We're almost always in the #openstack-ansible channel and generally I'd say that most of the folks in there are happy to help. Take care and happy Ansible'ing! [0] - https://github.com/openstack?utf8=%E2%9C%93&query=openstack-ansible >> -- >> >> 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