Re: [openstack-dev] [deployment] [oslo] [ansible] [tripleo] [kolla] [helm] Configuration management with etcd / confd

How does confd run inside the container? Does this mean we’d need some kind of systemd in every container which would spawn both confd and the real service? That seems like a very large architectural change. But maybe I’m misunderstanding it. Thx, britt On 6/9/17, 9:04 AM, "Doug Hellmann"

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

I agree with Paul here. I like the idea of solving this with labels instead of tags. A label is imbedded into the docker image, and if it changes, the checksum of the image changes. A tag is kept in the image manifest, and can be altered w/o changing the underlying image. So to me a label

Re: [openstack-dev] [kolla] PTG Day #1 Webex remote participation

I’ve attended two Kolla midcycles remotely everything Steve said here is true. But, as long as your expectations are set accordingly, suboptimal is better than nothing at all. =) Thx, britt On 2/19/17, 1:09 AM, "Steven Dake (stdake)" wrote: Jeremy, Completely

Re: [openstack-dev] [tc][kolla] Adding new deliverables

My sentiments exactly Michal. We’ll get there, but let’s not jump the gun quite yet. On 1/11/17, 1:38 PM, "Michał Jastrzębski" wrote: So from my point of view, while I understand why project separation makes sense in the long run, I will argue that at this moment it

Re: [openstack-dev] [tc][kolla] Adding new deliverables

all of our projects flourish without competing for resources, or being so entwined that we become technically paralyzed and overloaded. Sorry, Sam and Michal! You can have your thread back now :) On Fri, Jan 6, 2017 at 1:17 AM, Britt Houser (bhouser) <bhou...@cisco.com<mailto:bhou...@cisco.c

Re: [openstack-dev] [tc][kolla] Adding new deliverables

I think both Pete and Steve make great points and it should be our long term vision. However, I lean more with Michael that we should make that a separate discussion, and it’s probably better done further down the road. Yes, Kolla containers have come a long way, and the ABI has been stable

Re: [openstack-dev] [tc] Re: [kolla] A new kolla-salt deliverable

Seems like these are some of the same growing pains (cores can’t be experts on all technologies) neutron went through. Maybe at the PTG we could pick their brain and see if the path they have chosen would work well for Kolla. Thx, britt On 12/24/16, 10:31 AM, "Steven Dake (stdake)"

Re: [openstack-dev] [kolla][osic] OSIC cluster status

W0t Great work so far everyone! =) On 8/5/16, 2:53 PM, "Michał Jastrzębski" wrote: >And we finished our first deployment >We had some hurdles due to misconfiguration, you can see it in along >with a fix. After these fixes and cleanups performed (we

Re: [openstack-dev] [kolla] repo split

-0 (My vote doesn't count). We had endless problems keeping containers and orchestration in sync when we had two repos. I am really impressed that Mitaka ansible can orchestrate Liberty containers. That really speaks volumes. And I understand there is a stable ABI now, but surely at some

Re: [openstack-dev] [kolla] our mascot - input needed

Koala is the best by a long shot. These ideas are all total stretches: Bee on a honeycomb – Its kinda like the bee is orchestrating containers of honey. Armadillo – It rolls up into a ball and is "immutable" Thx, britt From: "Steven Dake (stdake)" >

Re: [openstack-dev] [kolla] prototype of a DSL for generating Dockerfiles

I admit I'm not as knowledgable about the Kolla codebase as I'd like to be, so most of what you're saying is going over my head. I think mainly I don't understand the problem statement. It looks like you're pulling all the "hard coded" things out of the docker files, and making them user

Re: [openstack-dev] [kolla][kolla-kubernetes][kubernetes]

I wouldn't expect new users to be created on upgrade, so is the problem with bootstrap and upgrade that we do the database migration during bootstrap too? Thx, britt On 5/22/16, 3:50 PM, "Ryan Hallisey" wrote: >Hi all, > >At the Kolla meeting last week, I brought up

Re: [openstack-dev] [kolla] Vagrant environment for kolla-kubernetes

Would we ever run AIO-k8s vagrant w/o Kolla repo? If not, then it makes sense to me just to extend Vagrant kolla repo. Thx, britt On 5/13/16, 2:37 AM, "Michal Rostecki" wrote: >Hi, > >Currently we have nice guide about setting up AIO k8s environment in >review.

Re: [openstack-dev] [kolla] [bifrost] bifrost container.

hing else was running on the underlying deployment host, I'd have no issue running it in prod that way even with the Vagrant layer. Thank you, Mark On 5/9/2016 4:52 PM, Britt Houser (bhouser) wrote: Are we (as the Kolla community) open to other bare metal provisioners? The austin discussion was

Re: [openstack-dev] [kolla] [bifrost] bifrost container.

Are we (as the Kolla community) open to other bare metal provisioners? The austin discussion was titled generic bare metal, but very quickly turned into bifrost-only discourse. The initial survey showed cobbler/maas/OoO as alternatives people use today. So if the bifrost strategy is,

Re: [openstack-dev] [kolla][kubernetes] One repo vs two

t without infringing on master? Is it possible in gerrit for kolla-k8s-core have +2 on k8s branch and not master? Just food for thought. Thx, britt On 5/2/16, 1:32 AM, "Swapnil Kulkarni" <m...@coolsvap.net> wrote: >On Mon, May 2, 2016 at 9:54 AM, Britt Houser (bhouser)

Re: [openstack-dev] [kolla][kubernetes] One repo vs two

Although it seems I'm in the minority, I am in favor of unified repo. From: "Steven Dake (stdake)" > Reply-To: "OpenStack Development Mailing List (not for usage questions)" >

Re: [Openstack-operators] Dual stacking in Neutron and Nova

In the mean time, here is a blog post which covers it as well: http://www.debug-all.com/?p=52 Thx, britt On 5/8/15, 5:39 AM, Sean M. Collins s...@coreitpro.com wrote: On Thu, May 07, 2015 at 11:04:01AM EDT, Mike Spreitzer wrote: I am told that dual stacking is supported for compute

Re: [Openstack-operators] Problem creating volumes from images with ceph storage

What distribution is this? If RedHat based, try turning selinux to permissive and see if it works. Thx, britt From: Pedro Sousa pgso...@gmail.commailto:pgso...@gmail.com Date: Thursday, February 12, 2015 at 12:07 PM To:

Re: [Openstack-operators] Neutron DVR HA

Currently HA and DVR are mutually exclusive features. From: Pedro Sousa pgso...@gmail.commailto:pgso...@gmail.com Date: Tuesday, December 23, 2014 at 9:42 AM To: OpenStack-operators@lists.openstack.orgmailto:OpenStack-operators@lists.openstack.org

Re: [Openstack-operators] While adding external bridge connection lost to the network node

to do following command after this change ifdown eth0 Show error in following line in /etc/network/interfaces iface br-ex inet static Thanks again for your support. On Fri, Nov 21, 2014 at 6:05 PM, Britt Houser (bhouser) bhou...@cisco.commailto:bhou...@cisco.com wrote: The br-ex config looks

Re: [Openstack-operators] While adding external bridge connection lost to the network node

Interface tapa72fb9d6-4a type: internal ovs_version: 2.0.2 = On Mon, Nov 24, 2014 at 6:22 PM, Britt Houser (bhouser) bhou...@cisco.commailto:bhou...@cisco.com wrote: Geo, Sorry for not getting back sooner. Was out sick. Can you post the output of 'ovs-vsctl

Re: [Openstack-operators] While adding external bridge connection lost to the network node

, Nov 21, 2014 at 5:48 PM, Britt Houser (bhouser) bhou...@cisco.com wrote: Correct. You need to updated your /etc/interfaces file so that the 192.168.122.54/24 http://192.168.122.54/24 address gets assigned to br-ex instead of eth0. From: Geo Varghese gvargh...@aqorn.com Date: Friday, November 21

Re: [Openstack-operators] database hoarding

That would imply some extensible plugin type architecture, b/c all projects changes over time and from setup to setup. So each project would define its own cleanup routines, but those routines could be called using a common set of parameters from a single tool. Thx, britt On 10/31/14, 8:19 AM,