See more inline On 12/14/18 6:43 AM, Peters, Matt wrote:
See inline.
*From: *"Wang, Yi C" <yi.c.wang@intel.com> *Date: *Friday, December 14, 2018 at 3:53 AM *To: *"Peters, Matt" <Matt.Peters@windriver.com> *Cc: *"starlingx-discuss@lists.starlingx.io" <starlingx-discuss@lists.starlingx.io> *Subject: *RE: Deployment Improvements Proposal
Hi Matt,
I just went through your slides. And I have a few questions. I appreciate if you can share more information about your proposal. Many thanks!
1. We know config_controller will do many things, like bootstrap configuration and controller configuration together with required hieradata generation. All the jobs of config_controller will be taken over by Ansible, or just part of them?
/MP> Yes most of these tasks will be handled by the Ansible playbook. However, much of the existing capabilities may be leveraged in the implementation to avoid re-writing everything. The details will be outlined in the forthcoming spec./
We will look forward to the coming spec(s). Will you be addressing how to handle different OS setup? Ie will this move some of the existing kickstart related configuration into the Ansible playbook? I am just starting to look at Anisble, so I am not sure how much early system configuration it can take over from kickstart type of scripting. This is one of the challenges with supporting multiple os distributions, not just the build side, but the installation and configuration.
2. Does WindRiver has plan to replace Puppet with Ansible for all configuration jobs in the future?
/MP> There are no specific plans to replace Puppet for all configuration management. However, there are several features being actively developed in StarlingX that will be changing the existing Puppet manifests (e.g. OpenStack Containerization)./
I think this has been mentioned already, a concern is that containerization won't solve all problems, it just moves where and how the configuration work happens. I think we may still need to address how containers are handled as we need to address different OSes inside of the containers.
3. For the first controller, we still need local execution of Ansible playbook for initial bootstrap. Is my understanding correct?
/MP> This is one of the main drivers for changing some of the existing config_controller and Puppet manifest handling. The operator will have the ability to run the Ansible playbook locally or remotely. /
Another question is will this work further reduce the need for the configuration related packages (again multi-os related)? Can we move the system utility configuration into this Deployment work? Thanks Sau!
BR.
Yi
*From:*Peters, Matt [mailto:Matt.Peters@windriver.com] *Sent:* Friday, December 14, 2018 3:11 AM *To:* starlingx-discuss@lists.starlingx.io *Subject:* [Starlingx-discuss] Deployment Improvements Proposal
Hello,
Attached are the slides I presented during the TSC call on Dec 13, 2018 for the proposed improvements to the StarlingX initial bootstrap and system inventory. As indicated on the call, a detailed stx-spec will follow, but wanted to share the high-level changes being proposed before the arrival of the spec to get some early feedback.
Regards, Matt
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss