Hi Saul, Sorry, I missed this somehow. See inline. On 2018-12-20, 10:31 AM, "Saul Wold" <sgw@linux.intel.com> wrote: bump On 12/14/18 10:40 AM, Saul Wold wrote: > > 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. > MP> The current scope is targeting the config_controller logic, so should not be impacting the current kickstart scripts. Incrementally, if it makes sense to move some of the kickstart logic to the Playbook, that can be considered. I would also imagine that some of the kickstart logic may need to be moved to Puppet since that is not being replaced by this proposal. >> 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. MP> Agreed it doesn't solve it, but it does change how the configuration data is supplied. The containerized service configuration is supplied via Helm overrides (or K8S configmaps), I was just calling out that some of the existing Puppet manifests will be removed as part of the OpenStack containerization features. > >> 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? MP> I'm not familiar with the details of each of the packages. I think this would be out of scope for the current proposed changes. However, I think they could be scrubbed to see if anything could be moved to either Puppet or Ansible depending on the phase of the deployment. > > 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 >> > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss@lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss