Re: [openstack-dev] [kolla] Tags, revisions, dockerhub

[Stephen Hindle]

On Tue, Apr 18, 2017 at 9:27 AM, Fox, Kevin M <kevin@pnnl.gov> wrote:
> Kolla's general target is in the node range of 1 - 100 nodes. A lot of
> smaller clusters can't afford to do ci/cd of their own and so Kolla
> currently pushes all the work to the site, and the site can't afford to do
> it right, and so just doesn't deal with security updates.
>

I agree - as more and more of the '10' end of the '1-100' nodes start
using kolla to experiment with OpenStack, having pre-baked images with
security/patches/etc. becomes more important...

-- 
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.


__
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

Re: [openstack-dev] [oslo][kolla][openstack-helm][tripleo][all] Storing configuration options in etcd(?)

[Stephen Hindle]

On Fri, Apr 7, 2017 at 3:00 PM, Doug Hellmann <d...@doughellmann.com> wrote:
>
> Although I was a proponent of having the reload feature address
> that issue, I'm not sure the complexity of the current implementation
> is something we want to hang on to. In the new spec, I propose an
> alternative treatment, which is to not cache mutable values in the
> first place so the service never needs to receive a signal to reload.
> The reload API is retained, and simply discards *everything* and
> starts the configuration object over as though it was being freshly
> created. This will be a big change, but the feature is new I think
> the propose behavior better fits the spirit of the need anyway. Please
> provide feedback if you think otherwise.
>

I'm still concerned about how this handles non-OpenStack services.
Kolla currently provides containers for MySQL, RabbitMQ, Ceph, etc.  I
agree with Paul Belanger, creating a 'special snowflake' for OpenStack
config would be bad.  Personally, I agree something like confd could
be used to keep configs 'out' of the containers, by generating them at
run time.  This could work for both OS and Non-OS services, giving a
consistent mechanism.



-- 
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.


__
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

Re: [openstack-dev] [deployment][forum] proposing a session about future of configuration management - ops + devs wanted!

[Stephen Hindle]

Unfortunately, I won't be in boston...
but I'm very interested in the topic as I have to design 'brownfield'
openstack deployments and operations runbooks.

On Tue, Mar 21, 2017 at 3:23 PM, Emilien Macchi <emil...@redhat.com> wrote:
> OpenStack developers and operators who work on deployments: we need you.
>
> http://forumtopics.openstack.org/cfp/details/15
>
> Abstract: I would like to bring Developers and Operators in a room to
> discuss about future of Configuration Management in OpenStack.
>
> Until now, we haven't done a good job in collaborating on how we make
> configuration management in a consistent way across OpenStack
> Deployment Tools.
> Some efforts started to emerge in Pike:
> https://etherpad.openstack.org/p/deployment-pike
> And some projects like TripleO started some discussion on future of
> configuration management:
> https://etherpad.openstack.org/p/tripleo-etcd-transition
>
> In this discussion, we will discuss about our common challenges and
> take some actions from there, where projects could collaborate.
>
> Desired people:
> - Folks from Deployment Tools (TripleO, Kolla, OSA, Kubernetes, etc)
> - Operators who deploy OpenStack
>
> Moderator: me + any volunteer.
>
> Any question on this proposal is very welcome by using this thread.
>
> Thanks for reading so far and I'm looking forward to making progress
> on this topic in Boston.
> --
> Emilien Macchi
>
> __
> 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



-- 
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.


__
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

[openstack-dev] [Kolla] [Fuel] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Stephen Hindle]

So just saw this:
  
http://www.computerweekly.com/blog/Open-Source-Insider/OpenStack-on-Kubernetes-Mirantis-fuels-Fuel-with-Google-Intel-heat

Wonder if that means we'll get more devs or maybe some prebuilt
containers for Kolla?


-- 
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.


__
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

Re: [openstack-dev] [kolla] Monitoring tooling

[Stephen Hindle]

My understanding was Sensu could produce metrics ?
And Kapacitor can do alerting for the TICK stack stuff mewald is doing...
I really don't see them as that different ?


On Fri, Jul 22, 2016 at 5:19 PM, Dave Walker <em...@daviey.com> wrote:
> Yes, this is my thought.
>
> The scope of the Sensu work is: "Is this thing working?" (with the reference
> being up/down)
> But the scope of the Grafana and friends is, "How hard is this working?"
> (but no alerting)
>
> They are certainly complementary However, Sensu can throw data at a
> Grafana stack (aiui).. but I fear that is too much to achieve this cycle.
>
> --
> Kind Regards,
> Dave Walker
>
> On 23 July 2016 at 00:11, Fox, Kevin M <kevin@pnnl.gov> wrote:
>>
>> I think those are two different, complementary things.
>>
>> One's metrics and the other is monitoring. You probably want both at the
>> same time.
>>
>> Thanks,
>> Kevin
>> 
>> From: Steven Dake (stdake) [std...@cisco.com]
>> Sent: Friday, July 22, 2016 3:52 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [kolla] Monitoring tooling
>>
>> Thanks for pointing that out.  Brain out to lunch today it appears :(
>>
>> I think choices are a good thing even though they increase our
>> implementation footprint.  Anyone opposed to implementing both with
>> something in globals.yml like
>> monitoring: grafana or
>> monitoring: sensu
>>
>> Comments questions or concerns welcome.
>>
>> Regards
>> -steve
>>
>> On 7/22/16, 3:42 PM, "Stephen Hindle" <shin...@llnw.com> wrote:
>>
>> >Don't forget mewalds implementation as well - we now have 2 monitoring
>> >options for kolla :-)
>> >
>> >On Fri, Jul 22, 2016 at 3:15 PM, Steven Dake (stdake) <std...@cisco.com>
>> >wrote:
>> >> Hi folks,
>> >>
>> >> At the midcycle we decided to push off implementing Monitoring until
>> >>post
>> >> Newton.  The rationale for this decision was that the core review team
>> >>has
>> >> enough on their plates and nobody was super keen to implement any
>> >>monitoring
>> >> solution given our other priorities.
>> >>
>> >> Like all good things, communities produce new folks that want to do new
>> >> things, and Sensu was proposed as Kolla's monitoring solution (atleast
>> >>the
>> >> first one).  A developer that has done some good work has shown up to
>> >>do the
>> >> job as well :)  I have heard good things about Sensu, minus the fact
>> >>that it
>> >> is implemented in Ruby and I fear it may end up causing our gate a lot
>> >>of
>> >> hassle.
>> >>
>> >> https://review.openstack.org/#/c/341861/
>> >>
>> >>
>> >> Anyway I think we can work through the gate problem.
>> >>
>> >> Does anyone have any better suggestion?  I'd like to unblock Dave's
>> >> work
>> >> which is blocked on a ­2 pending a complete discussion of our
>> >> monitoring
>> >> solution.  Note we may end up implementing more than one down the road
>> >> ­
>> >> Sensu is just where the original interest was.
>> >>
>> >> Please provide feedback, even if you don't have a preference, whether
>> >>your a
>> >> core reviewer or not.
>> >>
>> >> My take is we can merge this work in non-prioirty order, and if it
>> >>makes the
>> >> end of the cycle fantastic ­ if not, we can release it in Ocatta.
>> >>
>> >> Regards
>> >> -steve
>> >>
>> >>
>> >>
>>
>> >> >>_
>> >>_
>> >> 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
>> >>
>> >
>> >
>> >
>> >--
>> >Stephen Hindle - Senior Systems Engineer
>> >480.807.8189 480.807.8189
>> >www.limelight.com Delivering Faster Better
>> >
>> >Join the conversation
>> >
>> >at Limelight Connect
>> >
>> >--
>> >The informa

Re: [openstack-dev] [kolla] Monitoring tooling

[Stephen Hindle]

Don't forget mewalds implementation as well - we now have 2 monitoring
options for kolla :-)

On Fri, Jul 22, 2016 at 3:15 PM, Steven Dake (stdake) <std...@cisco.com> wrote:
> Hi folks,
>
> At the midcycle we decided to push off implementing Monitoring until post
> Newton.  The rationale for this decision was that the core review team has
> enough on their plates and nobody was super keen to implement any monitoring
> solution given our other priorities.
>
> Like all good things, communities produce new folks that want to do new
> things, and Sensu was proposed as Kolla's monitoring solution (atleast the
> first one).  A developer that has done some good work has shown up to do the
> job as well :)  I have heard good things about Sensu, minus the fact that it
> is implemented in Ruby and I fear it may end up causing our gate a lot of
> hassle.
>
> https://review.openstack.org/#/c/341861/
>
>
> Anyway I think we can work through the gate problem.
>
> Does anyone have any better suggestion?  I'd like to unblock Dave's work
> which is blocked on a –2 pending a complete discussion of our monitoring
> solution.  Note we may end up implementing more than one down the road –
> Sensu is just where the original interest was.
>
> Please provide feedback, even if you don't have a preference, whether your a
> core reviewer or not.
>
> My take is we can merge this work in non-prioirty order, and if it makes the
> end of the cycle fantastic – if not, we can release it in Ocatta.
>
> Regards
> -steve
>
>
> __
> 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
>



-- 
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.


__
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

Re: [openstack-dev] [kolla][ironic] My thoughts on Kolla + BiFrost integration

[Stephen Hindle]

On Mon, Jul 4, 2016 at 7:53 AM, Michał Jastrzębski  wrote:
> I'd be cautious about how much of customization we allow. But don't
> forget that Kolla itself and BiFrost will be effectively separate. Run
> bifrost, run every customization playbook you want on host, run
> kolla-host-bootstrap playbook for installation of docker and stuff and
> then run kolla. This will not be single-step operation, so you can do
> stuff in between.
>

So it sounds like we effectively have a 'post-bifrost' hook already
(run another playbook after bifrost). Having a 'pre-bifrost' hook at
the start of the bifrost playbook to setup things like OpenVSwitch
networking (so kolla/bifrost know your using it for host networking)
would cover most things I can think of

Steve

-- 
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.


__
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

Re: [openstack-dev] [kolla][ironic] My thoughts on Kolla + BiFrost integration

[Stephen Hindle]

Hi Steve

  I'm just suggesting the bi-frost stuff allow sufficient 'hooks' for
operators to insert site specific setup.  Not that Kolla/Bi-Frost try
to handle 'everything'.

  For instance LDAP... Horizon integration with LDAP would certainly
be within Kolla's perview.  However, operators also use LDAP for login
access to the host via PAM.  This is site-specific, and outside of
Kolla's mission.

  As an example of 'respecting existing configuration' - some sites
may use OpenVSwitch for host level networking.  Kolla currently starts
a new openvswitchdb container without checking if OpenVSwitch is
already running - this kills the host networking.

  If you'll pardon the pun, there are a 'host' of situations like
this, where operators will have to provide
(possibly many/detailed) site specific configurations to a bare metal
host.  Networking, Security, Backups, Monitoring/Logging, etc.  These
may all be subject to corporate wide policies that are non-negotiable
and have to be followed.

  Again, I realize Kolla/BiFrost can not be everything for everyone.
I just want to suggest that we provide well documented methods for
operators to insert site-specific roles/plays/whatever, and that we
take care to avoid 'stepping on' things.

  I have no idea as to what/how-many 'hooks' would be required.  I
tend to think a simple 'before-bifrost' role and 'after-bifrost' role
would be enough.  However, others may have more input on that...
I like the idea of using roles, as that would allow you to centralize
all your 'site-specific' bits.  This way operators don't have to
modify the existing kolla/BiFrost stuff.


On Sat, Jul 2, 2016 at 3:10 PM, Steven Dake (stdake) <std...@cisco.com> wrote:
> Stephen,
>
> Responses inline.
>
> On 7/1/16, 11:35 AM, "Stephen Hindle" <shin...@llnw.com> wrote:
>
>>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
>
> We don¹t have anything like this at present or planned.  Would you mind
> explaining the use case?  Typically we in the Kolla community expect a
> production deployment to only deploy OpenStack, and not other stacks on
> top of the bare metal hardware.  This is generally considered best
> practice at this time, unless of course your deploying something on top of
> OpenStack that may need these nics.  The reason is that OpenStack itself
> managed alongside another application doesn¹t know what it doesn't know
> and can't handle capacity management or any of a number of other things
> required to make an OpenStack cloud operate.
>
>> IPMI configuration
>
> BiFrost includes IPMI integration - assumption being we will just use
> whatever BiFrost requires here for configuration.
>
>> Password integration with Corporate LDAP etc.
>
> We have been asked several times for this functionality, and it will come
> naturally during either Newton or Occata.
>
>> Integration with existing SANs
>
> Cinder integrates with SANs, and in Newton, we have integration with
> iSCSI.  Unfortunately because of some controversy around how glance should
> provide images with regards to cinder, using existing SAN gear with iSCSI
> integration as is done by Cinder may not work as expected in a HA setup.
>
>> Integration with existing corporate IPAM
>
> No idea
>
>> Corporate Security policy (firewall rules, sudo groups,
>>hosts.allow, ssh configs,etc)
>
> This is environmental specific and its hard to make a promise on what we
> could deliver in a generic way that would be usable by everyone.
> Therefore our generic implementation will be the "bare minimum" to get the
> system into an operational state.  The things listed above are outside the
> "bare minimum" iiuc.
>
>>
>>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'
>
> Our bootstrap playbook is for launching BiFrost and bringing up the bare
> metal machines with an SSH credential.  It appears from this thread we
> will have another playbook to do the bare metal initialization (thiings
> like turning off firewalld, turning on chrony, I.e. Making the bare metal
> environment operational for OpenStack)
>
> I think what you want is a third playbook which really belongs in the
> domain of the operators to handle site-specific configuration as required
> by corporate rules and the like.
>
>
>>actions should be
>>in another role) to prevent confusion.
>>
>>We also have to be careful tha

Re: [openstack-dev] [kolla][ironic] My thoughts on Kolla + BiFrost integration

[Stephen Hindle]

olls 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-requ...@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-requ...@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-
>> requ...@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-requ...@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.


__
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