On Tue, Jul 11, 2017 at 6:53 PM, Steve Baker <sba...@redhat.com> wrote: > > > On Tue, Jul 11, 2017 at 6:51 AM, James Slagle <james.sla...@gmail.com> > wrote: >> >> On Mon, Jul 10, 2017 at 11:37 AM, Lars Kellogg-Stedman <l...@redhat.com> >> wrote: >> > On Fri, Jul 7, 2017 at 1:50 PM, James Slagle <james.sla...@gmail.com> >> > wrote: >> >> >> >> There are also some ideas forming around pulling the Ansible playbooks >> >> >> >> and vars out of Heat so that they can be rerun (or run initially) >> >> independently from the Heat SoftwareDeployment delivery mechanism: >> > >> > >> > I think the closer we can come to "the operator runs ansible-playbook to >> > configure the overcloud" the better, but not because I think Ansible is >> > inherently a great tool: rather, I think the many layers of indirection >> > in >> > our existing model make error reporting and diagnosis much more >> > complicated >> > that it needs to be. Combined with Puppet's "fail as late as possible" >> > model, this means that (a) operators waste time waiting for a deployment >> > that is ultimately going to fail but hasn't yet, and (b) when it does >> > fail, >> > they need relatively intimate knowledge of our deployment tools to >> > backtrack >> > through logs and find the root cause of the failure. >> > >> > If we can offer a deployment mode that reduces the number of layers >> > between >> > the operator and the actions being performed on the hosts I think we >> > would >> > win on both fronts: faster failures and reporting errors as close as >> > possible to the actual problem will result in less frustration across >> > the >> > board. >> > >> > I do like Steve's suggestion of a split model where Heat is responsible >> > for >> > instantiating OpenStack resources while Ansible is used to perform host >> > configuration tasks. Despite all the work done on Ansible's OpenStack >> > modules, they feel inflexible and frustrating to work with when compared >> > to >> > Heat's state-aware, dependency ordered deployments. A solution that >> > allows >> > Heat to output configuration that can subsequently be consumed by >> > Ansible -- >> > either running manually or perhaps via Mistral for >> > API-driven-deployments -- >> > seems like an excellent goal. Using Heat as a "front-end" to the >> > process >> > means that we get to keep the parameter validation and documentation >> > that is >> > missing in Ansible, while still following the Unix philosophy of giving >> > you >> > enough rope to hang yourself if you really want it. >> >> This is excellent input, thanks for providing it. >> >> I think it lends itself towards suggesting that we may like to persue >> (again) adding native Ironic resources to Heat. If those were written >> in a way that also addressed some of the feedback about TripleO and >> the baremetal deployment side, then we could continue to get the >> advantages from Heat that you mention. >> >> My personal opinion to date is that Ansible's os_ironic* modules are >> superior in some ways to the Heat->Nova->Ironic model. However, just a >> Heat->Ironic model may work in a way that has the advantages of both. > > > I too would dearly like to get nova out of the picture. Our placement needs > mean the scheduler is something we need to work around, and it discards > basically all context for the operator when ironic can't deploy for some > reason. > > Whether we use a mistral workflow[1], a heat resource, or ansible os_ironic, > there will still need to be some python logic to build the config drive ISO > that injects the ssh keys and os-collect-config bootstrap. > > Unfortunately ironic iPXE boot from iSCSI[2] doesn't support config-drive > (still?) so the only option to inject ssh keys is the nova ec2-metadata > service (or equivalent). I suspect if we can't make every ironic deployment > method support config-drive then we're stuck with nova. > > I don't have a strong preference for a heat resource vs mistral vs ansible > os_ironic, but given there is some python logic required anyway, I would > lean towards a heat resource. If the resource is general enough we could > propose it to heat upstream, otherwise we could carry it in tripleo-common. > > Alternatively, we can implement a config-drive builder in tripleo-common and > invoke that from mistral or ansible.
Ironic's cli node-set-provision-state command has a --config-drive option where you just point it a directory and it will automatically bundle that dir into the config drive ISO format. Ansible's os_ironic_node[1] also supports that via the config_drive parameter. Combining that with a couple of template tasks to create meta_data.json and user_data files makes for a very easy to user interface. [1] http://docs.ansible.com/ansible/os_ironic_node_module.html -- -- James Slagle -- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
