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

[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

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

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][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] 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] 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,

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

[openstack-dev] [kolla] OSIC cluster accepteed

Hello Kollagues, Some of you might know that I submitted request for 130 nodes out of osic cluster for testing Kolla. We just got accepted. Time window will be 3 weeks between 7/22 and 8/14, so we need to make most of it. I'd like some volunteers to help me with tests, setup and such. We need to

Re: [openstack-dev] [kolla] Request for changing the meeting time to 1600 UTC for all meetings

+1 from me. But I'd love to hear from Jeffrey if he'd be ok with that too. On 8 June 2016 at 07:54, Swapnil Kulkarni (coolsvap) wrote: > Dear Kollagues, > > Some time ago we discussed the requirement of alternating meeting > times for Kolla weekly meeting due to major

Re: [openstack-dev] [kolla] stepping down from core

Damn, bad news:( All the best Jeff! On 6 June 2016 at 17:57, Vikram Hosakote (vhosakot) wrote: > Thanks for all the contributions to kolla and good luck Jeff! > > Regards, > Vikram Hosakote > IRC: vhosakot > > From: "Steven Dake (stdake)" > Reply-To:

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

I am opposed to this idea as I don't think we need this. We can solve many problems by using jinja2 to greater extend. I'll publish demo of few improvements soon, please bear with me before we make a arch-changing call. On 29 May 2016 at 14:41, Steven Dake (stdake) wrote: >

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

Aaaand correct link: https://review.openstack.org/#/c/323589/ sorry for pastefail. On 1 June 2016 at 15:55, Michał Jastrzębski <inc...@gmail.com> wrote: > So this is prototype of working template overrides: > https://review.openstack.org/#/c/323612/ > > Pass --template-over

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

std...@cisco.com> wrote: > > > On 5/31/16, 1:42 PM, "Michał Jastrzębski" <inc...@gmail.com> wrote: > >>I am opposed to this idea as I don't think we need this. We can solve >>many problems by using jinja2 to greater extend. I'll publish demo of >>few i

Re: [openstack-dev] [kolla] Cinder multiple backends

Right now you can install it by providing --include-header file during build. We are working on cleaner mechanism in Newton [1]. [1] https://review.openstack.org/#/q/topic:bp/third-party-plugin-support On 20 June 2016 at 08:29, Carlos Cesario wrote: > Hi folks, > > It

Re: [openstack-dev] [kolla] Potential direction proposal - unified OpenStack containers

Hey, welcome back to Kolla guys!:) We've missed you! I'm sure we can figure out together best way to meet everyones needs, I'm happy to help! Also reviewed spec. Thanks. On 16 June 2016 at 10:23, Ryan Hallisey wrote: > Sergey, > > Thanks for reaching out to the community!

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] 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] 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] 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] 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] [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] 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][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][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] 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

> 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][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] 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] 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] [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] 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] [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][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][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] [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

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] 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] [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] 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

[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] 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

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][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][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] 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

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][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

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,

[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] [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] [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] [kolla] Monitoring tooling

Guys, thanks for all that! Can we for a second abstract this discussion from technology and start by lining up scenerios we want to achieve. Then put a software that will allow us to achieve all/most of scenerios with least amount of work/maintenance? So my scenerios: I want to see when health

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

mewald, we can add pid=host with kolla-docker. Look at nova libvirt container deployment As for telegraf/influx. Didnt influx require paid license to be deployed in cluster mode? On 25 July 2016 at 11:15, Mathias Ewald wrote: > Hi Steve, > > I can try collectd, too, no problem.

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

+1 I was reluctant to repo split by Newton timeframe as it was crucial time to our project, people will start using it, and I didn't want to cause needless confusion. Now time is right imho. On 20 July 2016 at 15:48, Ryan Hallisey wrote: > Hello. > > The repo split

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

I refuse to be cut out of this thread. It is my right to freely say what's in my mind in this, very important for our glorious project, issue! So here it is: Koala that holds openstack square'y logo and makes docker whale jumps through it See? No glue or any narcotics involved. Meanwhile I'll

Re: [openstack-dev] [kolla][vote] Applying for stable-follows tag

+1 ofc On 19 July 2016 at 06:02, Ryan Hallisey wrote: > +1 > > -Ryan > > - Original Message - > From: "Jeffrey Zhang" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Monday,

[openstack-dev] [kolla] New specs process - a dicussion

Hey guys, Since our project matured, we decided that we should have a discussion regarding our spec process. https://etherpad.openstack.org/p/kolla-N-midcycle-specs Currently we do specs for most critical things, and they require majority vote. We want to introduce another way, to enable

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

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

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

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 don't want to affect resulting time now do we?), we deployed functional openstack successfully within 20min:) More videos and tests to

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

Hello, So as some of you might know, I write from a peculiar position. I'm both Kolla core and Intel. I don't like to see where this thread is going to. We are all one community, we are all OpenStack after all. I think what's hurting us here is this sense of competition. I would like to share my

Re: [openstack-dev] [kolla][vote] Apply for release:managed tag

+1 while I know that we weren't actually good at freezing features, we were young project. Right now we're more mature and I think we can deal with feature freeze. On 30 June 2016 at 19:56, Steven Dake (stdake) wrote: > Hey folks, > > I'd like the release management team to

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

penstack.org> > wrote: >> >> Michał Jastrzębski wrote: >> > I agree this would make good PTG discussion for us, and maybe someone >> > from TC could join in. We are somehow special beast as Kolla itself is >> > just meant to be consumed. Kolla to me is

Re: [openstack-dev] [vote][kolla] deprecation for Debian distro support

2 as well, on multiple occasions we asked for maintainers to volunteer, however there have been little response. On 21 January 2017 at 05:51, Jeffrey Zhang wrote: > 2 > > On Thu, Jan 19, 2017 at 7:53 PM, Mauricio Lima > wrote: >> >> 2 >> >>

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

will allow us to keep track of deliverables. Review incoming:) Regards, Michal On 22 January 2017 at 11:52, Michał Jastrzębski <inc...@gmail.com> wrote: > Our voting ends in 2 days, but it's more about process how to include > code rather than if Kolla-salt stays. Kolla-salt resonate

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

; -Original Message- >> From: Michał Jastrzębski <inc...@gmail.com> <inc...@gmail.com> >> Reply: OpenStack Development Mailing List (not for usage questions) >> <openstack-dev@lists.openstack.org> <openstack-dev@lists.openstack.org> >> Date: Ja

Re: [openstack-dev] [kolla] Kolla PTG Day #2

I really appreciate this Steve:) No, I haven't setup the zoom.us yet, so let's stick to your webex to avoid confusion. See you all in ATL! On 17 February 2017 at 23:17, Steven Dake (stdake) wrote: > Hey folks, > > > > To take some load off Michal I’ve setup remote

[openstack-dev] [kolla] Mascot

And here we are, our mascot:) Feel free to use it in any Kolla related presentation or tattoo studio. https://www.dropbox.com/sh/94pukquiw425ji2/AAAl2wVmm72KHPLCAzR6Uboha?dl=0 __ OpenStack Development Mailing List (not for

Re: [openstack-dev] [tripleo][kolla][openstack-helm][kuryr] OpenStack on containers leaveraging kuryr

So from kolla (and kolla-k8s) point of view, this is chicken egg problem:) We could use kuryr for our networking, but who will deploy kuryr? We don't have undercloud concept in any of kollas so far. With Kolla-ansible we really use host networking all the way and for k8s we have k8s networking

[openstack-dev] [kolla] PTL candidacy

My dear community, I humbly ask you all to accept my candidacy as PTL of best cloud project there is, Kolla. I serve as PTL during current Ocata cycle, and I would like to continue serving during Pike. During Ocata cycle, even thou it was very short one with holiday season in the middle, we did

Re: [openstack-dev] [vote][kolla] Core nomination proposal for Eduardo Gonzalez Gutierrez (egonzales90 on irc)

+1 On 18 August 2016 at 18:09, Steven Dake (stdake) wrote: > Kolla Core Review Team: > > I am nominating Eduardo for the core reviewer team. His reviews are > fantastic, as I'm sure most of you have seen after looking over the review > queue. His 30 day stats place him at #3

Re: [openstack-dev] [kolla] which footer format we need

+1 to Jeffrey's points. We should deprecate old footer mechanism and remove it alltogether in Ocata timeframe. On 1 September 2016 at 23:51, Jeffrey Zhang wrote: > 1. so i think we need add the deprecated status to the include_footer option > and print a warn. > 2. when

Re: [openstack-dev] [kolla] Problem regarding named volume data location

So this is hard problem to solve without native docker support (which afaik it doesn't). One potential solution would be to write our own "named volume" mechanism that will be configurable, after all it's just bindmounted directory. However it will be hacky and costly to maintain, although in

Re: [openstack-dev] [vote][kolla] Core Nomination for Christian Berendt (berendt on irc)

+1 On 8 September 2016 at 06:35, Mauricio Lima wrote: > +1 > > 2016-09-08 5:52 GMT-03:00 Dave Walker : >> >> +1 >> >> Great stuff Christian >> >> On 8 September 2016 at 03:59, Steven Dake (stdake) >> wrote: >>> >>> Kolla core

Re: [openstack-dev] [vote][kolla] Splitting out Ansible into a separate deliverable

Option C will be best, but I guess we almost have enough votes for it?:) I vote for C. On 15 September 2016 at 06:45, Mauricio Lima wrote: > Option c. > > 2016-09-15 8:25 GMT-03:00 Eduardo Gonzalez : >> >> Option C >> >> >> On Thu, Sep 15, 2016, 1:23

Re: [openstack-dev] [openstack-ansible] cinder volume lxc and iscsi

So in Kolla we managed to put both iscsi and tgtd into containers. It did require quite a few shares from host, not sure how feasible it is with LXC https://github.com/openstack/kolla/blob/master/ansible/roles/iscsi/tasks/start.yml Look at volumes, this is what we share, you can try to mimic

[openstack-dev] [kolla][elections] PTL candidacy

Hello, You all hopefully know me as inc0 on IRC. I would like to submit my candidacy for the PTL position in the following cycle. I think we, as a team, did a tremendous job in last cycles, ensuring that Kolla is and will be the great project to work on and to use. Opensource project is only as

Re: [openstack-dev] [Kolla] Deprecation Policies (related to Heka)

notification = of course relase note with information and upgrade info = of course 1 full release of supporting both heka and alternative = not so much On 29 September 2016 at 10:54, Swapnil Kulkarni (coolsvap) wrote: > On Sep 29, 2016 3:06 PM, "Christian Berendt" >

Re: [openstack-dev] Deprecation Policies (related to Heka)

Agree with Christian, this is our internal wiring. As long as we provide automated upgrade procedure which will seamlessly migrate from heka to alternative we want, we should be good without deprecation per se. Cheers, Michal On 29 September 2016 at 04:36, Christian Berendt

[openstack-dev] [Kolla] Ocata summit session poll

Hello, Now, when we have full list of sessions, let's prioritize them accordingly to our preferences. Based on this we'll allocate our summit space. http://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_8368e1e74f8a0049=91bbcf4baeff0a2f

Re: [openstack-dev] [Kolla] Ocata summit session poll

summit, so it >> is probably worth ignoring entirely. >> >> Regards >> -steve >> >> >> On 9/21/16, 10:14 AM, "Michał Jastrzębski" <inc...@gmail.com> wrote: >> >> Hello, >> >> Now, when we have full list of sessi

Re: [openstack-dev] [kolla][fuel][tripleo] Reference architecture to deploy OpenStack on k8s

Flavio, So as you surely know k8s is an orchiestration tools, docker is container engine. If you are running k8s, you still run docker:) Kolla-kubernetes is a part of Big Tent, is project developed by Kolla community and we're close to our big showdown:) Come over to our session in Barcelona, in

Re: [openstack-dev] [vote][kolla] deprecation for debian distro support

I'm also reluctant to deprecation of debian.There are few changes to ubuntu and it might just work:) However, I'd love to ask whoever would like us to keep using debian to create gates for it. I would like to give debian one more release to go and deprecate it if we fail to create gates in Ocata

Re: [openstack-dev] [kolla][fuel][tripleo] Reference architecture to deploy OpenStack on k8s

com> wrote: > On 22/09/16 09:39 -0500, Michał Jastrzębski wrote: >> >> Flavio, >> >> So as you surely know k8s is an orchiestration tools, docker is >> container engine. If you are running k8s, you still run docker:) > > > I know this (although, if we re

Re: [openstack-dev] [vote][kolla] deprecation for fedora distro support

yup, +1 on deprecation On 19 September 2016 at 13:58, Ryan Hallisey wrote: > option 2 > > Thanks > -Ryan > > - Original Message - > From: "Mauricio Lima" > To: "OpenStack Development Mailing List (not for usage questions)" >

Re: [openstack-dev] [kolla][vote] Core nomination for Dave Walker (Daviey on irc)

+1 good job Davey:) On 24 August 2016 at 08:27, Mauricio Lima wrote: > +1 > > 2016-08-24 9:15 GMT-03:00 Kwasniewska, Alicja > : >> >> +1 >> >> >> >> From: Eduardo Gonzalez [mailto:dabar...@gmail.com] >> Sent: Wednesday, August 24, 2016 1:42

Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

Hey Fungi! So unfortunately I don't see any viable way to write this plugin from scratch. Plugin we'd need to write would have to mimic (without derivative:)) this one https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/strategy/linear.py <- I don't think it's possible to reinvent

Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

So as Clint mentioned, strategy plugins probably will be tainted by GPL. One of alternatives would be to create separate project for this single plugin, but I'd rather avoid that. Any other alternatives comes to mind? On Nov 4, 2016 5:18 PM, "Fox, Kevin M" wrote: > Must be

Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

write it as ASL2.0. > The fact that it plugs in or uses GPLv3 code is totally irrelevant since it > is isolated by a network layer (specifically popen). > > > > Regards > > -steve > > > > > > *From: *Michał Jastrzębski <inc...@gmail.com> > *Reply-To

Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

Logistically it would be best to make this one file GPLv3. No other files would need to be GPLv3 in Kolla as this is only one that will be derivative, rest of Kolla will be safe because of subprocess separation. Who would be able to say whether or not it's possible to put single GPLv3 file into

Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

Sooowe do have a precedence (multiple of them in fact), just it seems to be flying under the radar? On 14 November 2016 at 11:26, Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2016-11-14 09:53:03 -0600 (-0600), Michał Jastrzębski wrote: > [...] >> We don't have

  1   2   3   >