----- Original Message ----- I think it can be reduced to a single manifest per node. Also, when a review is created it would be easier to check if you create one review for the python, puppet, tests and release notes. I would like to have packstack to be multi node since the requirements for TripleO are still to big for PoC. Does it make sense to convert packstack to an ansible module? I started a refactor [1] as part of a manifest cleanup, unifcation and to start de refactor discussion, i'm happy that Javier took the puppet-openstack-integration road. Another idea around this refactor is to make packstack create manifests that can be used even without packstack runs, installing them in the proper puppet environment directories and setting the OPM path as part of the this OpenStack? environment, thus making packstack a puppet manifest generator... Cheers, Ivan [1] https://review.openstack.org/#/c/307519/

On Wed, Jun 8, 2016 at 9:51 PM, Mohammed Arafa <mohammed.arafa(a)gmail.com&gt; wrote: It is not and it is not the same thing. Packstack really should focus to on original proof-of-concept use case and do one-thing well which is single node installation. Multinode will be hard to get reliably working in CI and is best left to the tripleo project to handle, at most we can have experimental wrapper based on Ansible, running single node Packstack. But core Packstack should have simple deps and NOT depend on Ansible. Cheers, Alan

----- Original Message ----- well, make it just one big commit if there's no way around this So in your opinion we should drop features that packstack already has because this are difficult to test. I don't agree with this, we can set the untested features as "experimental" or "unsupported" I can be wrong but right now Packstack can already do this stuff, more command line options are needed or it might need little tweaks to the code but this is not far from current Packstack options. I think this refactor discussion should focus on a proper puppet usage and optimizations instead of retiring stuff that already works. Actually Packstack used to be able to install all the components in different nodes and this feature was modified to the current limited multinode features. We need a tool like Packstack so users can try RDO without the complexity of TripleO, imagine you're new to OpenStack and you want to test it in different scenarios, not everybody has a spare machine with 16GB of ram just to test, not to mention the fact of understanding the concept of undercloud before understanding the key concepts of OpenStack. Cheers, Ivan

On Thu, Jun 09, 2016 at 12:40:39AM +0200, Hugh Brock wrote: The point of instack has always been to reuse the same tooling that is used for the overcloud to do the undercloud install. Given: - the composability that is coming in tripleo-heat-templates - driving SoftwareDeployment via Heat without a full stack - applying those SoftwareDeployments to servers that don't even have to be known to Heat I actually think we'd move more in the direction of using tripleo-heat-templates in some fashion to install the undercloud. Also given the requirements around undercloud HA, TripleO doesnt want to reinvent the wheel coming up with a new multinode HA installer. Users are likely to want compsability, network isolation, ipv6, etc, for their HA underclouds too. Reusing what we're already doing for the overcloud makes the most sense to me. That would be the next iteration of instack IMO, using Heat and tripleo-heat-templates. As long as those are our tools for the overcloud, I'd want to reuse them for the undercloud as well, especially as the requirements grow to require more complexity. That solution might result in a nice and simple AIO installer as well, but I don't hear a lot of requests for that outside the context of "how can we get rid of packstack". Which doesn't seem like all that valid of a reason tbh given that packstack is already really good at doing AIO. Approaching it from the other angle, what if packstack were really good at multinode HA, and we used that for undercloud HA? That could definitely work, but you don't have any code reuse between the undercloud and overcloud other than the puppet modules. Further, there would be a fair amount of churn in the install experience unless we developed a compatibility layer as well, would we really want to deprecate every undercloud.conf already out there, and require rewriting it as answers file? I think there's a fair amount of complexity and trade-offs to consider in going this route as well. I think the last time we had this discussion, it more or less inspired/moved us along the lines of creating tripleo-quickstart. It's just not clear to me if the current discussion is about making AIO better or making multinode easier via packstack. It might be useful to define who we're actually targetting with this effort, and what the requirements are. IME, the effort to get to a simple and working multinode installer if actually pretty easy. But then you're staring at a huge amount of complexity to move it to the next level of even being usable for POC's. We're spending a lot of time trying to make TripleO easier for POC's as well. I think what we're finding though is that there are no "simple" POC's either, every one is different. You still need a fair amount of customization, which results in complexity, even for POC's. -- -- James Slagle --

----- Original Message ----- Taking in account comments by Javier and Daniel, i think we can effectively eliminate the multinode functionality of Packstack but not loosing its ability to install different components in a separate way. Extending what Daniel said we could do stuff like: packstack --controller-node packstack --compute-node packstack --network-node and if you want you can use: packstack --os-install-mariadb=y , etc... Cheers, Ivan

If it is not tested, it doesn't work, by definition. We want to ensure, with resources available, that Packstack works well in the future for the use-case it was designed for, proof-of-concept installations. For production installations TripleO is recommended. Cheers, Alan