Re: [openstack-dev] [kolla] Proposing Mauricio Lima for core reviewer

+1 :) On 18 May 2016 at 10:02, Ryan Hallisey wrote: > +1 nice work mlima! > > -Ryan > > - Original Message - > From: "Vikram Hosakote (vhosakot)" > To: openstack-dev@lists.openstack.org > Sent: Wednesday, May 18, 2016 9:45:53 AM > Subject: Re:

Re: [openstack-dev] [kolla][kolla-k8s] Core team

On 3 May 2016 at 14:36, Martin André <m.an...@redhat.com> wrote: > On Tue, May 3, 2016 at 6:48 PM, Michał Jastrzębski <inc...@gmail.com> wrote: >> Hello, >> >> Since it seems that we have voted for separation of kolla-k8s repos >> (yay!) I would like to t

[openstack-dev] [kolla][kolla-k8s] Core team

Hello, Since it seems that we have voted for separation of kolla-k8s repos (yay!) I would like to table another discussion (but let's wait till its official). Core Team. We need to build up new core team that will guard the gates on our brand new repo (when it arrives). One of ideas Steven

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

Well, I don't think we should rely on ansible's config generation. We can't really as it's wired into ansible too much. jinja2 templates in Dockerfiles aren't connected to ansible in any way and are perfectly reusable. On 2 May 2016 at 16:13, Qiu Yu wrote: > On Mon, May 2,

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

I agree that we need one set of containers. Containers are kolla, deployment tools are consumers of kolla. We need our containers rock solid and decoupled from whatever is deploying them. Every company ops shop have their tooling and methods, let's help them. I'm not super in favor of ansible

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

I think merging 2 repos is possible with keeping a history. Tonyb also said that there will not be any issues with releasing z-streams. I recall we kinda made a decision on summit that we keep ansible in kolla tree as long as it's only stable deployment orchiestration tool, and when second one

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

While I'm not on this list, I'll speak up anyways:) on summit we agreed that we start from separate repo, and after kolla-k8s becomes stable, we either merge or not merge. I'm for separate repo. On May 1, 2016 4:06 PM, "Steven Dake (stdake)" wrote: > Ryan had rightly pointed

Re: [openstack-dev] [kolla][vote][kubernetes][infra] kolla-kubernetes repository management proposal up for vote

Also +1 :) On 30 April 2016 at 09:58, Michał Jastrzębski <inc...@gmail.com> wrote: > Add me too please Steven. > > On 30 April 2016 at 09:50, Steven Dake (stdake) <std...@cisco.com> wrote: >> Fellow core reviewers, >> >> We had a fantastic turnout at

Re: [openstack-dev] [kolla][vote][kubernetes][infra] kolla-kubernetes repository management proposal up for vote

Add me too please Steven. On 30 April 2016 at 09:50, Steven Dake (stdake) wrote: > Fellow core reviewers, > > We had a fantastic turnout at our fishbowl kubernetes as an underlay for > Kolla session. The etherpad documents the folks interested and discussion > at summit[1]. >

Re: [openstack-dev] [kolla] Deploying kolla from a container?

rnal_interface`, it says in your dev guide that you can use > a veth pair when there's only a single public interface on a machine, which > is the case here. Is there any documentation available for how to do that? > > > Jamie > > > > Fr

Re: [openstack-dev] [kolla] Deploying kolla from a container?

Hey, So privileged containers are required by stuff like libvirt, and there isn't much we can do about it. Shared /run is required by openvswitch afair. We didn't try to run Kolla with swarm, but I'm afraid that privileged container and network host are unfortunately a must. OpenStack wasn't

[openstack-dev] [kolla] Ubuntu build is broken

Hey, I'm sorry to say that we can't currently build ubuntu with default options. This will be addressed by this review: https://review.openstack.org/#/c/310574/1 There is a workaround for that and that is building with either --base-tag=14.04 or change in /etc/kolla/kolla_build.conf : base_tag

Re: [openstack-dev] [kolla][kubernetes] Mirantis participation in kolla-mesos project and shift towards Kubernetes

On 26 April 2016 at 13:51, Tomasz Pa wrote: > Hey Steven, > > answers inline. > > On Mon, Apr 25, 2016 at 9:27 AM, Steven Dake (stdake) > wrote: >> >> I disagree with your assertion. You are gaming your data to provide the >> worst possible container (nova)

Re: [openstack-dev] [kolla] kolla-kubernetes pm's

Hey, Right now kolla-k8s is on the drawing board. We didn't write any code so far. We will have session in Austin about this topic, so feel free to jump in, your input would be extremely valuable Cheers, Michal On 22 April 2016 at 19:31, Fox, Kevin M wrote: > Are there any

Re: [openstack-dev] [kolla][vote] Place kolla-mesos in openstack-attic

+1 since Mirantis was only company actively developing kolla-mesos. If anyone want's to take over kolla-mesos, now is the time. On 22 April 2016 at 19:08, Steven Dake (stdake) wrote: > Fellow Core Reviewers, > > Since many of the engineers working on the kolla-mesos repository

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

be snapshotted for rollbacks. On 18 April 2016 at 11:15, Matthew Thode <prometheanf...@gentoo.org> wrote: > On 04/18/2016 10:57 AM, Michał Jastrzębski wrote: >> So I also want to stress out that shared libraries are huge pain >> during upgrades. While I'm not in favor of packages with em

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

So I also want to stress out that shared libraries are huge pain during upgrades. While I'm not in favor of packages with embedded virtualenvs (as Matt pointed out, this has a lot of issues), having shared dependency pool pretty much means that you need to upgrade *everything* that is openstack at

Re: [openstack-dev] [kolla][vote] Nit-picking documentation changes

So one way to approach it is to decouple docs from code, make it 2 reviews. We can -1 code without docs and ask to create separate patchset depending on one in question with docs. Then we can nitpick all we want:) new contributor will get his/hers code merged, at least one patchset, so it will

Re: [openstack-dev] [all] Newton Summit: cross-project session for deployment tools projects

Ahh I never run from good flame war;) Just kidding ofc. I personally think this is brilliant and should be somewhat tradition per release as we all deal with things like upgrades and deployment changes (yes, I'm looking at you nova-api-database). Please consider me a volunteer from Kolla:)

Re: [openstack-dev] [kolla][vote] Just make Mitaka deploy Liberty within the Liberty branch

, Michał Jastrzębski <inc...@gmail.com> wrote: > So I made this: > https://review.openstack.org/#/c/299563/ > > I'm not super fond of reverting commits from the middle of release, > because this will make a lot of mess. I'd rather re-implement keystone > bootstrap logic

Re: [openstack-dev] [kolla][vote] Just make Mitaka deploy Liberty within the Liberty branch

So I made this: https://review.openstack.org/#/c/299563/ I'm not super fond of reverting commits from the middle of release, because this will make a lot of mess. I'd rather re-implement keystone bootstrap logic and make it conditional as it is not that complicated. On 30 March 2016 at 12:37,

Re: [openstack-dev] [kolla][vote] Just make Mitaka deploy Liberty within the Liberty branch

I think that it goes without saying that I'm +1 On 29 March 2016 at 22:27, Steven Dake (stdake) wrote: > Dear cores, > > inc0 has been investigating our backport options for 1.1.0 and they look > bleak. At this time we would have to backport heka because of changes in > Docker

Re: [openstack-dev] [kolla][vote] Nominating Vikram Hosakot for Core Reviewer

+1 On 29 March 2016 at 11:39, Ryan Hallisey wrote: > +1 > > - Original Message - > From: "Paul Bourke" > To: openstack-dev@lists.openstack.org > Sent: Tuesday, March 29, 2016 12:10:38 PM > Subject: Re: [openstack-dev] [kolla][vote] Nominating

Re: [openstack-dev] [kolla][vote] deprecation of icehosue/juno/kilo branches

+1 On 25 March 2016 at 11:36, Jeffrey Zhang wrote: > +1 > > On Sat, Mar 26, 2016 at 12:07 AM, Ryan Hallisey wrote: >> >> +1 for sure >> >> -Ryan >> >> - Original Message - >> From: "Paul Bourke" >> To:

Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO

Hello, So Ryan, I think you can make use of heat all the way. Architecture of kolla doesn't require you to use ansible at all (in fact, we separate ansible code to a different repo). Truth is that ansible-kolla is developed by most people and considered "the way to deploy kolla" by most of us,

Re: [openstack-dev] [kolla][vote] exception for backporting upgrades to liberty/stable

Upgrades are required, true, but not necessarily automatic ones. People still can rebuild and redeploy containers using normal deploy. It will be downtime causing and less optimal, but possible. Also with backport of named volumes it won't be data-destroying. It will cause total downtime of APIs,

Re: [openstack-dev] [kolla][vote] Proposing Alicja Kwasniewska for core reviewer

+1! congrats Ala! I'm super proud! For others, I had pleasure to be in same team with Ala and I vouch for her with all the credibility I have:) she will be wonderful addition to core team! On 4 March 2016 at 10:55, Steven Dake (stdake) wrote: > Core Reviewers, > > Alicja has

Re: [openstack-dev] [kolla][security] Obtaining the vulnerability:managed tag

As I said on irc:) count me in sdake! On 1 March 2016 at 22:11, Swapnil Kulkarni wrote: > On Tue, Mar 1, 2016 at 10:25 PM, Steven Dake (stdake) > wrote: >> Core reviewers, >> >> Please review this document: >>

Re: [openstack-dev] [kolla][infra] Publishing kolla images to docker-registry.openstack.org

I'd say 5Gigs should be enough for all the images per distro (maybe less if we have to squeeze). Since we have have 2 strongly supported distro 10Gigs. If we would like to add all distros we support, that's 20-25 (I think). That also depends how many older versions we want to keep (current+stable

Re: [openstack-dev] [kolla][vote] port neutron thin containers to stable/liberty

> Date: Saturday, February 20, 2016 at 9:32 AM >>> To: "OpenStack Development Mailing List (not for usage questions)" >>> <openstack-dev@lists.openstack.org >>> <mailto:openstack-dev@lists.openstack.org>> >>> Subject: Re: [openstac

Re: [openstack-dev] [kolla] discussion about core reviewer limitations by company

I don't think kolla will need limit of cores per company, we are diverse and our diversity grows if anything. Mirantis did make a lot of commitment this release, and that's great, but that won't change our diversity really. Let's deal with this case-by-case, I'd hate to disqualify someone for core

Re: [openstack-dev] [kolla][vote] port neutron thin containers to stable/liberty

Strong +1 from me. This have multiple benefits: Easier (aka possible) debugging of networking in running envs (not having tools like tcpdump at your disposal is a pain) - granted, there are ways to get this working without thin containers but require fair amount of docker knowledge. Docker daemon

Re: [openstack-dev] [kolla][vote] Proposing Angus Salkeld for kolla-core

+1 on condition that he will appear in kolla itself, after all...you'll be a kolla core as well right?;) On 19 February 2016 at 21:44, Sam Yaple wrote: > +1 of course. I mean, its Angus. Who can say no to Angus? > > Sam Yaple > > On Fri, Feb 19, 2016 at 10:57 PM, Michal

Re: [openstack-dev] [kolla] pid=host

Hey, So quick steps to reproduce this: 0. install docker 1.10 1. Deploy kolla 2. Run VM 3. On compute host - ps aux | grep qemu, should show your vm process 4. docker rm -f nova_libvirt 5. ps aux | grep qemu should still show running vm 6. re-deploy nova_libvirt 7. docker exec -it nova_libvirt

Re: [openstack-dev] [kolla] Location of Heka Lua plugins

TLDR; +1 to have lua in tree of kolla, not sure if we want to switch later So I'm not so sure about switching. If these git repos are in /openstack/ namespace, then sure, otherwise I'd be -1 to this, we don't want to add dependency here. Also we're looking at pretty simple set of files that won't

Re: [openstack-dev] OpenStack installer

Disclaimer: I'm from Kolla. Well, you will see these benefits when you'll try to perform upgrade:) that's the tricky part about containers - they become really useful after 6 months. Without them you'll end up having to upgrade every service at the very same time, and that's disruptive at best,

Re: [openstack-dev] [kolla] 40 hour time commitment requested from core reviewers before Feb 9th/10th midcycle

Well we still can perform upgrades with some API downtime, so it's not like we're bound to rolling upgrades on architectural level. I'll talk to you after midcycle and we'll find a good way to tackle it. Cheers, Michal On 26 January 2016 at 08:40, Michał Dulko wrote: >

Re: [openstack-dev] [kolla] Nominating Lei Zhang (Jeffrey Zhang in English) - jeffrey4l on irc

+1 :) On 19 January 2016 at 07:28, Ryan Hallisey wrote: > +1 nice work! > > -Ryan > > - Original Message - > From: "Steven Dake (stdake)" > To: openstack-dev@lists.openstack.org > Sent: Tuesday, January 19, 2016 3:26:38 AM > Subject:

Re: [openstack-dev] [kolla] kolla-mesos IRC meeting

Hey, Since we're growing and if anything, more people will join kolla from APAC (we already see few new faces this release), I'd vote for re-introducing apac-friendly meeting. We'll need to do it anyway at some point. Cheers, Michal./ On 17 January 2016 at 03:26, Martin André

Re: [openstack-dev] [kolla] Please vote -> Removal of Harm Weites from the core reviewer team

That's an unfortunate +1, it's always sad to lose one of our own. Hope we'll see you back soon! Thanks for all the fis...reviews! On 15 January 2016 at 06:59, Ryan Hallisey wrote: > Hello all, > > Harm, really appreciate all your reviews. You were always very thorough and

Re: [openstack-dev] [kolla] Heka v ELK stack logistics

Yeah that's true. We did all of openstack systems but we didn't implement infra around yet. I'd guess most of services can log either to stdout or file, and both sources should be accessible by heka. Also, I'd be surprised if heka wouldn't have syslog driver? That should be one of first:) Maybe

Re: [openstack-dev] [kolla] kolla-mesos IRC meeting

As long as you guys do your best to attend normal Kolla meeting that's ok by me. Shame that probably we won't be able to attend because of out tz, but that's ok, we can read logs;) Just make sure to be part of kolla community as well, don't let separation like Ryan mentioned happen. +1 On 15

Re: [openstack-dev] [kolla] Heka v ELK stack logistics

On 14 January 2016 at 04:46, Eric LEMOINE wrote: > On Wed, Jan 13, 2016 at 1:15 PM, Steven Dake (stdake) > wrote: >> Hey folks, >> >> I'd like to have a mailing list discussion about logistics of the ELKSTACK >> solution that Alicja has sorted out vs the

Re: [openstack-dev] [kolla] Introduction of Heka in Kolla

e multiple logs from a single container. > > Sam Yaple > > On Mon, Jan 11, 2016 at 10:16 PM, Eric LEMOINE <elemo...@mirantis.com> > wrote: >> >> >> Le 11 janv. 2016 18:45, "Michał Jastrzębski" <inc...@gmail.com> a écrit : >> > >> >

Re: [openstack-dev] [kolla] Introduction of Heka in Kolla

On 11 January 2016 at 09:16, Eric LEMOINE wrote: > Hi > > As discussed on IRC the other day [1] we want to propose a distributed > logs processing architecture based on Heka [2], built on Alicja > Kwasniewska's ELK work with > .

Re: [openstack-dev] [kolla] Introduction of Heka in Kolla

On 11 January 2016 at 10:55, Eric LEMOINE <elemo...@mirantis.com> wrote: > On Mon, Jan 11, 2016 at 5:01 PM, Michał Jastrzębski <inc...@gmail.com> wrote: >> On 11 January 2016 at 09:16, Eric LEMOINE <elemo...@mirantis.com> wrote: > >>> * Logstash

Re: [openstack-dev] [kolla] Adding Ubuntu Liberty to Kolla-Mitaka

Hey, So one thing we need to consider there is that currently 3 options we support (binary+souce centos and source ubuntu) basically behaves the same way - it install current master (or last nights master, which is close enough). This one will have fundamentally different behavior, and we need to

Re: [openstack-dev] [kolla][nova] Orchiestrated upgrades in kolla

Hey, Since our instances (and qemu) is in different container than nova services, there is no reason (specific to kolla) to meddle with them. Ofc it would be required if you'd like to upgrade qemu, but that's beyond scope of this change. For now we assume that project upgrade won't affect running

Re: [openstack-dev] [kolla][nova] Orchiestrated upgrades in kolla

So Dan, correct me if I'm wrong, but after this merges (we're working on L->M upgrade) we can simply go with version=auto on every node and just hit SIGHUP on conductors once we're done with all of compute nodes right? Also, are there any other nice things that you guys plan for M and we could use

Re: [openstack-dev] [kolla][nova] Orchiestrated upgrades in kolla

On 6 December 2015 at 09:33, Jay Pipes <jaypi...@gmail.com> wrote: > > On 12/04/2015 11:50 PM, Michał Jastrzębski wrote: >> >> Hey guys, >> >> Orchiestrated upgrades is one of our highest priorities for M in kolla, >> so following up after discussion

[openstack-dev] [kolla][nova] Orchiestrated upgrades in kolla

Hey guys, Orchiestrated upgrades is one of our highest priorities for M in kolla, so following up after discussion on summit I'd like to suggest an approach: Instead of creating playbook called "upgrade my openstack" we will create "upgrade my nova" instead and approach to each service case by

Re: [openstack-dev] [kolla][nova] Orchiestrated upgrades in kolla

is into your model? > > Regards > -steve > > [1] https://www.youtube.com/watch?v=guVAeFs5XwE > > From: Michał Jastrzębski <inc...@gmail.com> > Reply-To: "openstack-dev@lists.openstack.org" < > openstack-dev@lists.openstack.org> > Date: Friday, Decem

Re: [openstack-dev] [kolla] ValueError: No JSON object could be decoded

Hello, First of all, this is not a mailing list for debugging, I invite you sir/madam to join us on #kolla and ask questions there. Second, this doesn't help whole lot, we can get to the source of problem, but we need your help with that, so let me invite you again to our #kolla channel. Third,

<    1   2   3