[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
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? 2. Does WindRiver has plan to replace Puppet with Ansible for all configuration jobs in the future? 3. For the first controller, we still need local execution of Ansible playbook for initial bootstrap. Is my understanding correct? 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
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. 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). 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. 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
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
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.
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
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Saul, See inline, Brent -----Original Message----- From: Saul Wold [mailto:sgw@linux.intel.com] Sent: Thursday, December 20, 2018 10:31 AM To: starlingx-discuss@lists.starlingx.io; Peters, Matt <Matt.Peters@windriver.com> Subject: Re: [Starlingx-discuss] Deployment Improvements Proposal 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.
[BR] As we discussed a couple of days ago, this does not replace the need for kick starts.
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.
[BR] This is really outside the scope of this feature and needs to be covered under the umbrella of the multi-os project
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?
[BR] What tool are you referring to ?
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
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
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
Hi Matt, Thanks for your answers! Here is one further question about my #3 question. As you said, the operator will have the capability to run ansible playbook remotely. For now, the first controller network is configured during config_controller, so to support running playbook remotely for bootstrap, at which stage will the network will be configured, installation stage by anaconda? Thanks. Yi From: Peters, Matt [mailto:Matt.Peters@windriver.com] Sent: Friday, December 14, 2018 10:43 PM To: Wang, Yi C <yi.c.wang@intel.com> Cc: starlingx-discuss@lists.starlingx.io Subject: Re: Deployment Improvements Proposal See inline. From: "Wang, Yi C" <yi.c.wang@intel.com<mailto:yi.c.wang@intel.com>> Date: Friday, December 14, 2018 at 3:53 AM To: "Peters, Matt" <Matt.Peters@windriver.com<mailto:Matt.Peters@windriver.com>> Cc: "starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io>" <starlingx-discuss@lists.starlingx.io<mailto: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. 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). 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. BR. Yi From: Peters, Matt [mailto:Matt.Peters@windriver.com] Sent: Friday, December 14, 2018 3:11 AM To: starlingx-discuss@lists.starlingx.io<mailto: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
Hello Yi, The initial (temporary) configuration for external access will be via kickstart/DHCP. The remote install will set the default interface configuration to use DHCP, and the current interface configuration that is performed during config_controller will be performed during the host unlock. This will ensure the network connection is not disrupted while the Ansible playbook is executing and ensure the initial host is configured in the same way as other hosts in the cluster. -Matt From: "Wang, Yi C" <yi.c.wang@intel.com> Date: Friday, December 14, 2018 at 10:21 PM 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, Thanks for your answers! Here is one further question about my #3 question. As you said, the operator will have the capability to run ansible playbook remotely. For now, the first controller network is configured during config_controller, so to support running playbook remotely for bootstrap, at which stage will the network will be configured, installation stage by anaconda? Thanks. Yi From: Peters, Matt [mailto:Matt.Peters@windriver.com] Sent: Friday, December 14, 2018 10:43 PM To: Wang, Yi C <yi.c.wang@intel.com> Cc: starlingx-discuss@lists.starlingx.io Subject: Re: Deployment Improvements Proposal See inline. From: "Wang, Yi C" <yi.c.wang@intel.com<mailto:yi.c.wang@intel.com>> Date: Friday, December 14, 2018 at 3:53 AM To: "Peters, Matt" <Matt.Peters@windriver.com<mailto:Matt.Peters@windriver.com>> Cc: "starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io>" <starlingx-discuss@lists.starlingx.io<mailto: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. 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). 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. BR. Yi From: Peters, Matt [mailto:Matt.Peters@windriver.com] Sent: Friday, December 14, 2018 3:11 AM To: starlingx-discuss@lists.starlingx.io<mailto: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
Thanks Matt! Now it is clear for me. From: Peters, Matt [mailto:Matt.Peters@windriver.com] Sent: Monday, December 17, 2018 10:17 PM To: Wang, Yi C <yi.c.wang@intel.com> Cc: starlingx-discuss@lists.starlingx.io Subject: Re: Deployment Improvements Proposal Hello Yi, The initial (temporary) configuration for external access will be via kickstart/DHCP. The remote install will set the default interface configuration to use DHCP, and the current interface configuration that is performed during config_controller will be performed during the host unlock. This will ensure the network connection is not disrupted while the Ansible playbook is executing and ensure the initial host is configured in the same way as other hosts in the cluster. -Matt From: "Wang, Yi C" <yi.c.wang@intel.com<mailto:yi.c.wang@intel.com>> Date: Friday, December 14, 2018 at 10:21 PM To: "Peters, Matt" <Matt.Peters@windriver.com<mailto:Matt.Peters@windriver.com>> Cc: "starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io>" <starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io>> Subject: RE: Deployment Improvements Proposal Hi Matt, Thanks for your answers! Here is one further question about my #3 question. As you said, the operator will have the capability to run ansible playbook remotely. For now, the first controller network is configured during config_controller, so to support running playbook remotely for bootstrap, at which stage will the network will be configured, installation stage by anaconda? Thanks. Yi From: Peters, Matt [mailto:Matt.Peters@windriver.com] Sent: Friday, December 14, 2018 10:43 PM To: Wang, Yi C <yi.c.wang@intel.com<mailto:yi.c.wang@intel.com>> Cc: starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io> Subject: Re: Deployment Improvements Proposal See inline. From: "Wang, Yi C" <yi.c.wang@intel.com<mailto:yi.c.wang@intel.com>> Date: Friday, December 14, 2018 at 3:53 AM To: "Peters, Matt" <Matt.Peters@windriver.com<mailto:Matt.Peters@windriver.com>> Cc: "starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io>" <starlingx-discuss@lists.starlingx.io<mailto: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. 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). 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. BR. Yi From: Peters, Matt [mailto:Matt.Peters@windriver.com] Sent: Friday, December 14, 2018 3:11 AM To: starlingx-discuss@lists.starlingx.io<mailto: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
On Thu, Dec 13, 2018 at 2:42 PM Peters, Matt <Matt.Peters@windriver.com> wrote:
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.
Hi Matt, One question I have is around Zero Touch Provisioning (ZTP). Is the overall concept being put forward here a solution for the ZTP problem or is it a replacement of config_controller with an (remotely run?) Ansible playbook, ie. presuming the OS is already available in some capacity. Thanks, Curtis
Regards, Matt
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
-- Blog: serverascode.com
Hello Curtis, No, the proposal is not specifically addressing ZTP. The proposed changes are to make improvements for the initial host deployment so that it permits running locally or remotely and also uses more standard technologies for deployment. In addition, the system inventory changes expand the capabilities for identifying and classifying hardware, simplifying the installation and commissioning steps, which could be leveraged for improved deployment automation. -Matt From: Curtis <serverascode@gmail.com> Date: Thursday, December 20, 2018 at 7:23 AM To: "Peters, Matt" <Matt.Peters@windriver.com> Cc: "starlingx-discuss@lists.starlingx.io" <starlingx-discuss@lists.starlingx.io> Subject: Re: [Starlingx-discuss] Deployment Improvements Proposal On Thu, Dec 13, 2018 at 2:42 PM Peters, Matt <Matt.Peters@windriver.com<mailto:Matt.Peters@windriver.com>> wrote: 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. Hi Matt, One question I have is around Zero Touch Provisioning (ZTP). Is the overall concept being put forward here a solution for the ZTP problem or is it a replacement of config_controller with an (remotely run?) Ansible playbook, ie. presuming the OS is already available in some capacity. Thanks, Curtis Regards, Matt _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io<mailto:Starlingx-discuss@lists.starlingx.io> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss -- Blog: serverascode.com<http://serverascode.com>
Hello, The Ansible bootstrap deployment specification is now available for review. https://review.openstack.org/#/c/629581/ Your feedback is welcome and appreciated. Regards, Tee From: Peters, Matt [mailto:Matt.Peters@windriver.com] Sent: December-13-18 2:11 PM 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
Here is initial WIP review as part of this spec: https://review.openstack.org/#/c/639246/ Thanks, Dariush From: Ngo, Tee [mailto:Tee.Ngo@windriver.com] Sent: January-09-19 1:53 PM To: Peters, Matt <Matt.Peters@windriver.com>; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Deployment Improvements Proposal Hello, The Ansible bootstrap deployment specification is now available for review. https://review.openstack.org/#/c/629581/ Your feedback is welcome and appreciated. Regards, Tee From: Peters, Matt [mailto:Matt.Peters@windriver.com] Sent: December-13-18 2:11 PM To: starlingx-discuss@lists.starlingx.io<mailto: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
participants (7)
-
Curtis
-
Eslimi, Dariush
-
Ngo, Tee
-
Peters, Matt
-
Rowsell, Brent
-
Saul Wold
-
Wang, Yi C