Open Stack

Maybe I missed it - but is there a way to provide site specific
configurations?  Things we will run into in the wild include:
    Configuring multiple non-openstack nics
     IPMI configuration
     Password integration with Corporate LDAP etc.
     Integration with existing SANs
     Integration with existing corporate IPAM
     Corporate Security policy (firewall rules, sudo groups,
hosts.allow, ssh configs,etc)

Thats just off the top of my head - I'm sure we'll run into others.  I
tend to think the best way
to approach this is to allow some sort of 'bootstrap' role, that could
be populated by the
operators.  This should initially be empty (Kolla specific 'bootstrap'
actions should be
in another role) to prevent confusion.

We also have to be careful that kolla doesn't stomp on any non-kolla
configuration...


On Thu, Jun 30, 2016 at 12:43 PM, Mooney, Sean K
<sean.k.mooney at intel.com> wrote:
>
>
>> -----Original Message-----
>> From: Steven Dake (stdake) [mailto:stdake at cisco.com]
>> Sent: Monday, June 27, 2016 9:21 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [kolla][ironic] My thoughts on Kolla +
>> BiFrost integration
>>
>>
>>
>> On 6/27/16, 11:19 AM, "Devananda van der Veen"
>> <devananda.vdv at gmail.com>
>> wrote:
>>
>> >At a quick glance, this sequence diagram matches what I
>> >envisioned/expected.
>> >
>> >I'd like to suggest a few additional steps be called out, however I'm
>> >not sure how to edit this so I'll write them here.
>> >
>> >
>> >As part of the installation of Ironic, and assuming this is done
>> >through Bifrost, the Actor should configure Bifrost for their
>> >particular network environment. For instance: what eth device is
>> >connected to the IPMI network; what IP ranges can Bifrost assign to
>> >physical servers; and so on.
>> >
>> >There are a lot of other options during the install that can be
>> >changed, but the network config is the most important. Full defaults
>> >for this roles' config options are here:
>> >
>> >https://github.com/openstack/bifrost/blob/master/playbooks/roles/bifro
>> s
>> >t-i
>> >ronic-install/defaults/main.yml
>> >
>> >and documentation is here:
>> >
>> >https://github.com/openstack/bifrost/tree/master/playbooks/roles/bifro
>> s
>> >t-i
>> >ronic-install
>> >
>> >
>> >
>> >Immediately before "Ironic PXE boots..." step, the Actor must perform
>> >an action to "enroll" hardware (the "deployment targets") in Ironic.
>> >This could be done in several ways: passing a YAML file to Bifrost;
>> >using the Ironic CLI; or something else.
>> >
>> >
>> >"Ironic reports success to the bootstrap operation" is ambiguous.
>> >Ironic does not currently support notifications, so, to learn the
>> >status of the deployments, you will need to poll the Ironic API (eg,
>> >"ironic node-list").
>> >
>>
>> Great,
>>
>> Thanks for the feedback.  I'll integrate your changes into the sequence
>> diagram when I have a free hour or so - whenever that is :)
>>
>> Regards
>> -steve
> [Mooney, Sean K] I agree with most of devananda points and had come to similar
> Conlcutions.
>
> At a highlevel I think the workflow from 0 to cloud would be as follow.
> Assuming you have one linux system.
> - clone http://github.com/openstack/kolla && cd kolla
> - tools/kolla-host build-host-deploy
>         This will install ansible if not installed then invoke a playbook to install
>         All build dependencies and generate the kolla-build.conf passwords.yml and global.yml.
>      Install kolla python package
> - configure kolla-build.conf as required
> - tools/build.py or kolla-build to build image
> - configure global.yml and or biforst specific file
>   This would involve specifying a file that can be used with bifrost dynamic inventory.
>   Configuring network interface for bifrost to use.
>   Enable ssh-key generate or supply one to use as the key to us when connecting to the servers post deploy.
>   Configure diskimage builder options or supply path to a file on the system to use as your os image.
> - tools/kolla-host deploy-bifrost
>   Deploys bifrost container.
>   Copies images/keys
>   Bootstraps bifrost and start services.
> - tools/kolla-host deploy-servers
>   Invokes bifrost enroll and deploy dynamic then polls until all
>   Servers are provisioned or a server fails.
> - tools/kolla-hosts bootstrap-servers
>   Installs all kolla deploy dependencies
>   Docker ect. This will also optionally do things such as
>   Configure hugepages, configure cpu isolation, firewall settings
>   Or any other platform level config for example apply labels to ceph
>   Disks .
>   This role will reboot the remote server at the end of the role if required
>   e.g. after installing The wily kernel on Ubuntu 14.04
> - configure global.yml as normal
> - tools/kolla-ansible prechecks (this should now pass)
> - tools/kolla-ansible deploy
> - profit
>
> I think this largely agrees with the diagram you proposed but has a couple of extra steps/details.
>
>>
>> >
>> >
>> >Cheers,
>> >--Devananda
>> >
>> >On 06/23/2016 06:54 PM, Steven Dake (stdake) wrote:
>> >> Hey folks,
>> >>
>> >> I created the following sequence diagram to show my thinking on
>> >>Ironic  integration.  I recognize some internals of the recently
>> >>merged bifrost changes  are not represented in this diagram.  I would
>> >>like to see a bootstrap action do  all of the necessary things to
>> >>bring up BiFrost in a container using Sean's WIP  Kolla patch
>> followed
>> >>by bare metal minimal OS load followed by Kolla dependency  software
>> >>(docker-engine, docker-py, and ntpd) loading and initialization.
>> >>
>> >> This diagram expects ssh keys to be installed on the deployment
>> >>targets via BiFrost.
>> >>
>> >> https://creately.com/diagram/ipt09l352/ROMDJH4QY1Avy1RYhbMUDraaQ4%3D
>> >>
>> >> Thoughts welcome, especially from folks in the Ironic community or
>> >>Sean who is  leading this work in Kolla.
>> >>
>> >> Regards,
>> >> -steve
>> >>
>> >>
>> >>
>> >>
>> >>_____________________________________________________________________
>> _
>> >>___
>> >>_
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> >>OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >
>> >______________________________________________________________________
>> _
>> >___ OpenStack Development Mailing List (not for usage questions)
>> >Unsubscribe:
>> >OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> _______________________________________________________________________
>> ___
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-
>> request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Stephen Hindle - Senior Systems Engineer
480.807.8189 480.807.8189
www.limelight.com Delivering Faster Better

Join the conversation

at Limelight Connect

-- 
The information in this message may be confidential.  It is intended solely 
for
the addressee(s).  If you are not the intended recipient, any disclosure,
copying or distribution of the message, or any action or omission taken by 
you
in reliance on it, is prohibited and may be unlawful.  Please immediately
contact the sender if you have received this message in error.