Hi Boris,
thanks for the feedback, I'll try to address them inline:
On Mon, Nov 28, 2016 at 10:03 PM, Boris Derzhavets
<bderzhavets(a)hotmail.com> wrote:
I do realize that Core RDO deployment tool is TripleO ( TripleO QS )
been
pushed and stable on bare metal.
TripleO is one of the deployment tools which work with RDO packages,
it never was and never will be the only one, so you have a choice.
However, numbers in report bellow:- 38% packstack deployments vs 20%
TripleO
deployments
fairly prove that just for Newton && Ocata releases makes sense to have
storage.pp role for packstack.
Sample was rather small so I would not jump to the conclusion, but
just to clarify that Packstack is a community supported project and
you can report the request details in
https://bugs.launchpad.net/packstack and/or propose a patch in gerrit
then we can discuss how it can fit. Maybe feature does not fit in
Packstack directly e.g. cloud be integrated with some other tool,
let's keep open mind and not assume implementation details.
As an example, recent Magnum support in Packstack was contributed from
outside Red Hat.
TripleO is exciting , but maintain prod environment via update of
heat stack
"overcloud" targeting for instance :-
1. Adding one more compute node
2. Replacing Controller node in PCS Cluster
would scare too much admins.
Can you provide more details, I'm sure Emilien as TripleO PTL would
like to hear them :)
Regression in packstack been done ahead of right time might have
negative
drawback and it would.
I guess you mean focusing Packstack to be excellent all-in-one
proof-of-concept installation tool?
Repeating myself again: if we don't have it covered in CI, it will be
broken by design so focusing is all about _avoiding_ regressions.
E.g. we have found out today that Nagios support in Packstack is
broken only after being reported on #rdo ... because it is not covered
in CI. To fix that, I would propose to drop Nagios support in
Packstack and instead look at integrating with CentOS Opstools SIG.
Cheers,
Alan