[Starlingx-discuss] Deployment Improvements Proposal

[Peters, Matt]

Hi Saul,
Sorry, I missed this somehow.  See inline.

On 2018-12-20, 10:31 AM, "Saul Wold" <sgw at 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 at intel.com>
    >> *Date: *Friday, December 14, 2018 at 3:53 AM
    >> *To: *"Peters, Matt" <Matt.Peters at windriver.com>
    >> *Cc: *"starlingx-discuss at lists.starlingx.io" 
    >> <starlingx-discuss at 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 at windriver.com]
    >> *Sent:* Friday, December 14, 2018 3:11 AM
    >> *To:* starlingx-discuss at 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 at lists.starlingx.io
    >> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
    >>
    > 
    > _______________________________________________
    > Starlingx-discuss mailing list
    > Starlingx-discuss at lists.starlingx.io
    > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss