Re: [openstack-dev] [kolla] Dropping core reviewer

Hello Kollegues, Koalas and Koalines, I feel I should do the same, as my work sadly doesn't involve Kolla, or OpenStack for that matter, any more. It has been a wonderful time and serving Kolla community as core and PTL is achievement I'm most proud of and I thank you all for giving me this

Re: [openstack-dev] [kolla][vote] Nominating Steve Noyes for kolla-cli core reviewer

+1 from me:) On Thu, May 31, 2018, 11:40 PM Martin André wrote: > If Steve wrote half of kolla-cli then it's a no brainer to me. +1! > > On Thu, May 31, 2018 at 7:02 PM, Borne Mace wrote: > > Greetings all, > > > > I would like to propose the addition of Steve Noyes to the kolla-cli core > >

Re: [openstack-dev] [kolla][vote]Core nomination for Mark Goddard (mgoddard) as kolla core member

strong +1 from me! Great work Mark! On 29 April 2018 at 03:16, Steven Dake (stdake) wrote: > +1 > > > > > > > > From: Jeffrey Zhang > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > > Date:

Re: [openstack-dev] [kolla] [tripleo] On moving start scripts out of Kolla images

So I'll re-iterate comment which I made in BCN. In previous thread we praised how Kolla provided stable API for images, and I agree that it was great design choice (to provide stable API, not necessarily how API looks), and this change would break it. So *if* we decide to do it, we need to follow

Re: [openstack-dev] [kolla][tc][openstack-helm][tripleo]propose retire kolla-kubernetes project

On 4 April 2018 at 14:45, Brandon Jozsa wrote: > I’ve been a part of the OpenStack-Helm project from the very beginning, and > there was a lot of early brainstorming on how we could collaborate and > contribute directly to Kolla-Kubernetes. In fact, this was the original >

Re: [openstack-dev] [kolla][kolla-kubernete][tc][openstack-helm]propose retire kolla-kubernetes project

So my take on the issue. I think splitting Kolla and Kolla-Ansible to completely new project (including name change and all) might look good from purity perspective (they're effectively separate), but would cause chaos and damage to production deployments people use. While code will be the same,

Re: [openstack-dev] [kolla] Ubuntu jobs failed on pike branch due to package dependency

I'm for option 1 definitely. accidental ceph upgrade during routine minor version upgrade is something we don't want. We will need big warning about this version mismatch in release notes. On 26 February 2018 at 07:01, Eduardo Gonzalez wrote: > I prefer option 1, breaking

Re: [openstack-dev] [kolla] Policy regarding template customisation

On 30 January 2018 at 09:34, Joshua Harlow wrote: > I'm ok with #2, > > Though I would like to show an alternative that we have been experimenting > with that avoids the whole needs for a globals.yml and such files in the > first place (and feels more naturally inline with

Re: [openstack-dev] [kolla] Policy regarding template customisation

Hey, So I'm also for option 2. There was big discussion in Atlanta about "how hard it is to keep configs up to date and remove deprecated options". merge_config makes it easier for us to handle this. With amount of services we support I don't think we have enough time to keep tabs on every config

Re: [openstack-dev] [Openstack-operators] [all][kolla][rdo] Collaboration with Kolla for the RDO test days

Cool, thank you David, sign me up!:) On 29 January 2018 at 05:30, David Moreau Simard wrote: > Hi ! > > For those who might be unfamiliar with the RDO [1] community project: > we hang out in #rdo, we don't bite and we build vanilla OpenStack > packages. > > These packages

Re: [OpenStack-Infra] Adding ARM64 cloud to infra

Thanks Gema! So it's my understanding (which is limited at best) that zuul currently doesn't support something like "this job has to run on nodepool X", which would be necessary. We might need to add some sort of metadata for nodepools and be able to specify in zuul job that "this job has to land

[openstack-dev] [kolla] PTL non candidacy

Hello, A bit earlier than usually, but I'd like to say that I won't be running for PTL reelection for Rocky cycle. I had privilege of being PTL of Kolla for last 3 cycles and I would like to thank Kolla community for this opportunity and trust. I'm very proud of what we've accomplished over last

[openstack-dev] [kolla] no meeting 27th Dec

Because merry Christmas everyone:) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [Openstack-operators] [OpenStack] Upgrade Mitaka to Pike

Hello, M->P will be non trivial. One way to do it, a bit slow but safest would be to upgrade step by step through every intermediate release. Make sure to read and follow every projects upgrade notes, for example Nova added placement api during o->n upgrade which requires additional steps. Good

Re: [openstack-dev] [all] Switching to longer development cycles

On 14 December 2017 at 07:09, Nick Barcet wrote: > Hello Thierry, > > Really appreciate the effort you are putting to find creative ways to help > new contributors join our project. However, based on my experience, it > seems that: > - the longer the delay between the

[openstack-dev] [kolla] Proposal to add Marcin (hrw) to kolla images core team

It's my great pleasure to start another voting for core team addition! Everyone knows hrw, thanks to him Kolla now runs on both Power and ARM! Voting will be open for 14 days (until 16th of Nov). Consider this mail my +1 vote Regards, Michal

[openstack-dev] [kolla] Cancelling meeting 8 Nov

Have a good summit everyone! __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [TripleO][Kolla] Concerns about containers images in DockerHub

Additionally you can build only images you need. Some of images we have are quite.. niche. If you limit number of images to only those you care about, that will lower total size significantly On Oct 20, 2017 3:51 PM, "Steven Dake (stdake)" wrote: > Sam, > > > > Agreed this

Re: [openstack-dev] [TripleO][Kolla] Concerns about containers images in DockerHub

On 19 October 2017 at 13:37, Michał Jastrzębski <inc...@gmail.com> wrote: > On 19 October 2017 at 13:32, Joshua Harlow <harlo...@fastmail.com> wrote: >> This reminded me of something I wanted to ask. >> >> Is it true to state that only way to get 'fully' shared

Re: [openstack-dev] [TripleO][Kolla] Concerns about containers images in DockerHub

On 19 October 2017 at 13:32, Joshua Harlow wrote: > This reminded me of something I wanted to ask. > > Is it true to state that only way to get 'fully' shared-base layers is to > have `kolla-build` build all the projects (that a person/company/other may > use) in one

Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers

So my 0.02$ Problem with handling Newton goes beyond deployment tools. Yes, it's popular to use, but if our dependencies (openstack services themselves) are unmaintained, so should we. If we say "we support Newton" in deployment tools, we make kind of promise we can't keep. If for example there

Re: [openstack-dev] [tc] [kolla] [PTL] who can start the official meeting?

I haven't seen "malicious" meeting starters yet, let's hope that won't happen:) On the other hand, ad-hoc chair change can, and did, happen, so I agree with fungi - I don't think we need to put restrictions on that. On 11 October 2017 at 09:11, Jeremy Stanley wrote: > On

Re: [openstack-dev] [kolla] Non-critical, non-gate patches freeze during migration to zuul3

, Michał Jastrzębski <inc...@gmail.com> wrote: > Hello, > > As you all know, Zuul v3 is on! Unfortunate side effect was that it > broke our gates. For that reason I submitted patch removing legacy > jobs at all and we will do quick migration to zuulv3 compatible, local >

[openstack-dev] [kolla] Non-critical, non-gate patches freeze during migration to zuul3

Hello, As you all know, Zuul v3 is on! Unfortunate side effect was that it broke our gates. For that reason I submitted patch removing legacy jobs at all and we will do quick migration to zuulv3 compatible, local jobs. That means between this patch merges [1] and we finish that, we will be

Re: [openstack-dev] [ptg] Simplification in OpenStack

On 26 September 2017 at 13:54, Alex Schultz <aschu...@redhat.com> wrote: > On Tue, Sep 26, 2017 at 2:34 PM, Michał Jastrzębski <inc...@gmail.com> wrote: >> In Kolla, during this PTG, we came up with idea of scenario based >> testing+documentation. Basically what we w

Re: [openstack-dev] [ptg] Simplification in OpenStack

In Kolla, during this PTG, we came up with idea of scenario based testing+documentation. Basically what we want to do is to provide set of kolla configurations, howtos and tempest configs to test out different "constellations" or use-cases. If, instead of in Kolla, do these in cross-community

Re: [openstack-dev] [devstack] Why do we apt-get install NEW files/debs/general at job time ?

and should speed things up quite a bit. For me deployment of 5 node openstack on vms similar to gate took 6min (I had registry available in same network). Also if you pull single image it will download all base images as well, so next one will be significantly faster. > > On Sat, Sep 23, 2017 at

Re: [openstack-dev] [devstack] Why do we apt-get install NEW files/debs/general at job time ?

On 22 September 2017 at 17:21, Paul Belanger wrote: > On Fri, Sep 22, 2017 at 02:31:20PM +, Jeremy Stanley wrote: >> On 2017-09-22 15:04:43 +0200 (+0200), Attila Fazekas wrote: >> > "if DevStack gets custom images prepped to make its jobs >> > run faster, won't

Re: [openstack-dev] [devstack] Why do we apt-get install NEW files/debs/general at job time ?

On 22 September 2017 at 11:45, Clark Boylan <cboy...@sapwetik.org> wrote: > On Fri, Sep 22, 2017, at 08:58 AM, Michał Jastrzębski wrote: >> Another, more revolutionary (for good or ill) alternative would be to >> move gates to run Kolla instead of DevStack. We're workin

Re: [openstack-dev] [devstack] Why do we apt-get install NEW files/debs/general at job time ?

On 22 September 2017 at 07:31, Jeremy Stanley wrote: > On 2017-09-22 15:04:43 +0200 (+0200), Attila Fazekas wrote: >> "if DevStack gets custom images prepped to make its jobs >> run faster, won't Triple-O, Kolla, et cetera want the same and where >> do we draw that line?). " >>

[openstack-dev] [all][deployment][kolla][tripleo][osa] Service diagnostics task force

Hello my dearest of communities, During deployment tools session on PTG we discussed need for deep health checking and metering of running services. It's very relevant in context of containers (especially k8s) and HA. Things like watchdog, heartbeats or exposing relative metrics (I don't want to

Re: [openstack-dev] [kolla] [cinder] [ironic] [tripleo] PTG cross-platform meetup possibility

Hey, I know about wed meeting. This is when we wanted to discuss kolla-k8s and tripleo shared resources, whatever they might be. I assumed Mon meeting is different? On Sep 8, 2017 6:22 PM, "Richard Wellum" wrote: > Emilien, > > Can you please update this on the schedule

Re: [openstack-dev] [kolla] [cinder] [ironic] PTG cross-platform meetup possibility

Awesome! Thanks Rich and see you all in Denver! On 8 September 2017 at 12:19, Richard Wellum wrote: > Room booked: 'Durango', 2-4pm for Kolla+Triple-O and 4-6 for > Kolla+Ironic+Cinder. > > Please see: https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms - > for

[openstack-dev] [kolla] Next 2 team meetings canceled

Hey, Let's cancel meetings at 6.9 and and 13.9 because of PTG. Cheers, Michal __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [tripleo] PTG Agenda draft - action required

Hey, I'll be there, we already have ceph topic (including move to L), thanks! On 1 September 2017 at 07:39, Emilien Macchi wrote: > On Fri, Sep 1, 2017 at 6:20 AM, Giulio Fidente wrote: > [...] >> roger, I have added to the thursday afternoon a 1h slot

Re: [openstack-dev] [docs] [ptls] Install guide testing

One thing I'd be worried about is that not only maintaining this doc will be very costly (we're now only talking of few services out of big tent..), will cover just basic architectures, but also if someone actually uses it, it will make things like upgrade quite hard. If it's only meant to be PoC

Re: [openstack-dev] [kolla] [tripleo] [openstack-ansible] [deployment] Collaboration at PTG

We (Kolla) planned some time for that discussion:) It would be awesome if we could have them on Mon-Tue, because Wed-Fri we'll have kolla-specific design room. That being said if needed we can use it for our cross-community discussions. Biggest one for me is new direction of tripleo (k8s+ansible)

[openstack-dev] [kolla] Kolla is now stable:follows-policy project

As of today Kolla got this tag. That doesn't really mean we change anything in our model as tag is given to projects which already follows rules of stable policy, but that makes it official:) Keep up with good work Kolla team! Cheers, Michal

[openstack-dev] [kolla-kubernetes] Proposing Rich Wellum to core team

Hello, It's my pleasure to start another core team vote. This time for our colleague rwellum. I propose that he joins kolla-kubernetes team. This is my +1 vote. Every kolla-kubernetes core has a vote and it can be veto'ed. Voting will last 2 weeks and will end at 25th of August. Cheers, Michal

[openstack-dev] [kolla][PTL][elections] Candidacy for Kolla PTL

Hello everyone, Once more unto the breach dear friends! I would like to run for PTL again for Queens. Pike was very exciting release for Kolla. With strong focus on Kolla-Kubernetes, Kolla-Ansible getting more and more production deployments and Kolla images being successfully consumed by project

Re: [openstack-dev] [TripleO] breaking changes, new container image parameter formats

>>... >>DockerInsecureRegistryAddress: 172.19.0.2:8787/tripleoupstream >>DockerKeystoneImage: 172.19.0.2:8787/tripleoupstream/centos-binary- >> keystone:latest >>... That's strange construction, are you sure guys that you don't want to separate address:port from namespace?

Re: [openstack-dev] [TripleO] Let's use Ansible to deploy OpenStack services on Kubernetes

On 17 July 2017 at 10:13, Emilien Macchi wrote: > On Mon, Jul 17, 2017 at 5:32 AM, Flavio Percoco wrote: >> On 14/07/17 08:08 -0700, Emilien Macchi wrote: >>> >>> On Fri, Jul 14, 2017 at 2:17 AM, Flavio Percoco wrote:

Re: [openstack-dev] [TripleO] Let's use Ansible to deploy OpenStack services on Kubernetes

Guys you just described Kolla-Kubernetes pretty much... how about we join effort and work towards this goal together? On 14 July 2017 at 08:43, Flavio Percoco wrote: > On 14/07/17 17:26 +0200, Bogdan Dobrelya wrote: >> >> On 14.07.2017 11:17, Flavio Percoco wrote: >>> >>>

Re: [openstack-dev] [TripleO] Forming our plans around Ansible

Hey, I'll just throw a grenade (pun intended) into your discussion - sorry! How about kolla-kubernetes? State awareness is done by kubernetes, it's designed for containers and we already have most of services ready and we'll be running ansible inside containers on top of k8s, for all the things

Re: [openstack-dev] [kolla] Looking for Docker images for Cinder, Glance etc for oVirt

Hello, Unfortunately we still don't have proper dockerhub uploading mechanism, that's in progress. For now you need to build your own images, here's doc for that: https://docs.openstack.org/kolla/latest/image-building.html Also feel free to join us on #openstack-kolla irc if you have further

[openstack-dev] [kolla] Today meeting cancelled due to lack of agenda

Some time to kick start brains after 4th of July:) Regards, Michal __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [kolla][kolla-ansible] Proposing Surya (spsurya) for core

Aaaand it's done. Congrats Surya and welcome to core team! On 27 June 2017 at 19:56, zhubingbing <zhu.bingb...@99cloud.net> wrote: > > > > +1 > >>> -Original Message- >>> From: Michał Jastrzębski [mailto:inc...@gmail.com] >>> Sent: Wed

Re: [openstack-dev] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

Great idea! I would also throw another issue new people often have (I had it too). Namely what to contribute. Lot's of people wants to do something but not quite know where to start. So few ideas for start: * List of triaged bugs * List of work items of large blueprits Thoughts, Michal On 23

Re: [openstack-dev] [all][tc] Turning TC/UC workgroups into OpenStack SIGs

One of key components which, imho, made SIGs successful in k8s is infrastructure behind it. When someone proposes an issue, they can tag SIG to it. Everyone in this SIG will be notified that there is an issue they might be interested it, they check it out and provide feedback. That also creates

Re: [openstack-dev] [deployment][kolla][openstack-ansible][openstack-helm][tripleo] ansible role to produce oslo.config files for openstack services

On 19 June 2017 at 06:05, Doug Hellmann wrote: > Excerpts from Michał Jastrzębski's message of 2017-06-16 15:50:54 -0700: >> So I'm trying to figure out how to actually use it. >> >> We (and any other container based deploy..) will run into some >> chicken/egg problem - you

Re: [openstack-dev] [deployment][kolla][openstack-ansible][openstack-helm][tripleo] ansible role to produce oslo.config files for openstack services

So I'm trying to figure out how to actually use it. We (and any other container based deploy..) will run into some chicken/egg problem - you need to deploy container to generate big yaml with defaults, then you need to overload it with your configurations, validate if they're not deprecated, run

Re: [openstack-dev] [tc] Status update, Jun 16

Since there are 2 topics that are very very important to me: 1. binary resolution waiting for votes 2. kolla stable:follows-policy tag Is there anything I can to do help with either? On 16 June 2017 at 09:23, Thierry Carrez wrote: > Clay Gerrard wrote: >> I'm loving this

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

First of all, we definitely need that distinction to be clear. Second, what are incentives to actually be an OpenStack project? 1. TC oversight - it's more a requirement than incentive 2. PTG space - definitely incentive ...anything else? What else? TC has an important role, we need oversight to

[openstack-dev] [kolla][kolla-ansible] Proposing Surya (spsurya) for core

Hello, With great pleasure I'm kicking off another core voting to kolla-ansible and kolla teams:) this one is about spsurya. Voting will be open for 2 weeks (till 28th Jun). Consider this mail my +1 vote, you know the drill:) Regards, Michal

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

On 8 June 2017 at 09:50, Michał Jastrzębski <inc...@gmail.com> wrote: > On 8 June 2017 at 09:27, Flavio Percoco <fla...@redhat.com> wrote: >> On 08/06/17 18:23 +0200, Flavio Percoco wrote: >>> >>> On 07/06/17 12:04 +0200, Bogdan Dobrelya wrote: >>>

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

On 8 June 2017 at 09:27, Flavio Percoco wrote: > On 08/06/17 18:23 +0200, Flavio Percoco wrote: >> >> On 07/06/17 12:04 +0200, Bogdan Dobrelya wrote: >>> >>> On 06.06.2017 18:08, Emilien Macchi wrote: Another benefit is that confd will generate a configuration file

[openstack-dev] [stable][kolla][release] Policy regarding backports of gate code

Hello, Since we're working hard on providing pipeline for docker publishing, that will require heavy gating of container images to be published. We also would like to publish stable/ocata images to enable release upgrade gates from O to P. My question is, is it ok to backport gate logic to

Re: [openstack-dev] [ptg] Strawman Queens PTG week slicing

On 1 June 2017 at 09:22, Jeremy Stanley wrote: > On 2017-06-01 16:38:05 +0200 (+0200), Thierry Carrez wrote: > [...] >> For teams that are placed on the Wednesday-Friday segment, please >> let us know whether you'd like to make use of the room on Friday >> (pick between 2 days

Re: [openstack-dev] [release][tc][infra][security][stable] Proposal for shipping binaries and containers

On 23 May 2017 at 08:13, Doug Hellmann wrote: > Excerpts from Davanum Srinivas (dims)'s message of 2017-05-23 10:44:30 -0400: >> Team, >> >> Background: >> For projects based on Go and Containers we need to ship binaries, for > > Can you elaborate on the use of the term

Re: [openstack-dev] [doc][ptls][all] Documentation publishing future

[snip] So from Kolla perspective, since our dev guide is really also operators guide (we are operators tool so we're kinda "special" on that front), we'd love to handle both deployment guide, user manuals and all that in our tree. If we could create infrastructure that would allow us to segregate

Re: [openstack-dev] [all] Onboarding rooms postmortem, what did you do, what worked, lessons learned

Kolla: Attendees - full room (20-30?) Notes - Conflict with kolla-k8s demo probably didn't help While we didn't have etherpad, slides, recording (and video dongle that could fit my laptop), we had great session with analog tools (whiteboard and my voice chords). We walked through architecture of

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

h?) during low time. Then in this job we can turn off using infra mirrors and just use upstream signed. That being said, all the technical issues we saw so far (unless I'm missing something) are solvable and we (kolla community) would love to do all the heavy lifting to solve it. We need to wait

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

>> Issue with that is >> >> 1. Apache served is harder to use because we want to follow docker API >> and we'd have to reimplement it > > No, the idea is apache is transparent, for now we have been using proxypass > module in apache. I think what Doug was mentioning was have a primary docker >

Re: [openstack-dev] [TripleO][Kolla] default docker storage backend for TripleO

Be careful with overlay, I've seen it acting in a ways you don't want it to act up. That was some time ago, but memories persist. To my experience best option is btrfs. If you don't want to repartition disk, btrfs on loopback isn't horrible too. deviemapper on loopback is horrible, but that's

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

On 17 May 2017 at 11:36, Michał Jastrzębski <inc...@gmail.com> wrote: > On 17 May 2017 at 11:04, Doug Hellmann <d...@doughellmann.com> wrote: >> Excerpts from Michał Jastrzębski's message of 2017-05-17 07:47:31 -0700: >>> On 17 May 2017 at 04:14, Chris Dent

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

On 17 May 2017 at 11:04, Doug Hellmann wrote: > Excerpts from Michał Jastrzębski's message of 2017-05-17 07:47:31 -0700: >> On 17 May 2017 at 04:14, Chris Dent wrote: >> > On Wed, 17 May 2017, Thierry Carrez wrote: >> > >> >> Back to container image

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

On 17 May 2017 at 08:55, Doug Hellmann wrote: > Excerpts from Chris Dent's message of 2017-05-17 12:14:40 +0100: >> On Wed, 17 May 2017, Thierry Carrez wrote: >> >> > Back to container image world, if we refresh those images daily and they >> > are not versioned or archived

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

On 17 May 2017 at 04:14, Chris Dent wrote: > On Wed, 17 May 2017, Thierry Carrez wrote: > >> Back to container image world, if we refresh those images daily and they >> are not versioned or archived (basically you can only use the latest and >> can't really access past

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

On 16 May 2017 at 12:36, Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2017-05-16 11:46:14 -0700 (-0700), Michał Jastrzębski wrote: > [...] >> So CVE tracking might not be required by us. Since we still use >> distro packages under the hood, we can just use these. > [..

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

On 16 May 2017 at 11:49, Doug Hellmann wrote: > Excerpts from Michał Jastrzębski's message of 2017-05-16 11:38:19 -0700: >> On 16 May 2017 at 11:27, Doug Hellmann wrote: >> > Excerpts from Michał Jastrzębski's message of 2017-05-16 09:46:19 -0700: >>

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

On 16 May 2017 at 11:33, Doug Hellmann wrote: > Excerpts from Michał Jastrzębski's message of 2017-05-16 08:20:17 -0700: >> On 16 May 2017 at 08:12, Doug Hellmann wrote: >> > Excerpts from Michał Jastrzębski's message of 2017-05-16 06:52:12 -0700: >>

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

On 16 May 2017 at 11:27, Doug Hellmann wrote: > Excerpts from Michał Jastrzębski's message of 2017-05-16 09:46:19 -0700: >> So another consideration. Do you think whole rule of "not building >> binares" should be reconsidered? We are kind of new use case here. We >> aren't

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

On 16 May 2017 at 10:41, Jeremy Stanley wrote: > On 2017-05-16 11:17:31 -0400 (-0400), Doug Hellmann wrote: >> Excerpts from Sam Yaple's message of 2017-05-16 14:11:18 +: > [...] >> > If you build images properly in infra, then you will have an image that is >> > not

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

On 16 May 2017 at 09:40, Clint Byrum wrote: > Excerpts from Michał Jastrzębski's message of 2017-05-15 10:52:12 -0700: >> > Container images introduce some extra complexity, over the basic >> > operating system style packages mentioned above. Due to the way >> > they are

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

So another consideration. Do you think whole rule of "not building binares" should be reconsidered? We are kind of new use case here. We aren't distro but we are packagers (kind of). I don't think putting us on equal footing as Red Hat, Canonical or other companies is correct here. K8s is

Re: [openstack-dev] [tc][all] Do we need a #openstack-tc IRC channel

On 16 May 2017 at 08:32, Doug Hellmann wrote: > Excerpts from Sean McGinnis's message of 2017-05-16 10:17:35 -0500: >> On Tue, May 16, 2017 at 09:38:34AM -0400, Davanum Srinivas wrote: >> > Folks, >> > >> > See $TITLE :) >> > >> > Thanks, >> > Dims >> > >> >> My preference

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

ote: >>> >Excerpts from Flavio Percoco's message of 2017-05-15 21:50:23 -0400: >>> >> On 15/05/17 11:49 -0700, Michał Jastrzębski wrote: >>> >> >On 15 May 2017 at 11:19, Davanum Srinivas <dava...@gmail.com> wrote: >>> >> >> Sorry

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

On 16 May 2017 at 08:12, Doug Hellmann wrote: > Excerpts from Michał Jastrzębski's message of 2017-05-16 06:52:12 -0700: >> On 16 May 2017 at 06:20, Flavio Percoco wrote: >> > On 16/05/17 14:08 +0200, Thierry Carrez wrote: >> >> >> >> Flavio Percoco

Re: [openstack-dev] [tc][all] Do we need a #openstack-tc IRC channel

On 16 May 2017 at 07:49, Sean Dague wrote: > On 05/16/2017 09:38 AM, Davanum Srinivas wrote: >> Folks, >> >> See $TITLE :) >> >> Thanks, >> Dims > > I'd rather avoid #openstack-tc and just use #openstack-dev. > #openstack-dev is pretty low used environment (compared to like >

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

> among them. They are absolutely not images that should ever be run in > production and are only suited for testing. These are the only types of > images that can come out of infra. So I guess we need new feature:) since we can test gpg packages... > Thanks, > SamYaple

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

On 16 May 2017 at 06:22, Doug Hellmann wrote: > Excerpts from Thierry Carrez's message of 2017-05-16 14:08:07 +0200: >> Flavio Percoco wrote: >> > From a release perspective, as Doug mentioned, we've avoided releasing >> > projects >> > in any kind of built form. This was

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

On 16 May 2017 at 06:22, Doug Hellmann wrote: > Excerpts from Thierry Carrez's message of 2017-05-16 14:08:07 +0200: >> Flavio Percoco wrote: >> > From a release perspective, as Doug mentioned, we've avoided releasing >> > projects >> > in any kind of built form. This was

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

On 16 May 2017 at 06:20, Flavio Percoco wrote: > On 16/05/17 14:08 +0200, Thierry Carrez wrote: >> >> Flavio Percoco wrote: >>> >>> From a release perspective, as Doug mentioned, we've avoided releasing >>> projects >>> in any kind of built form. This was also one of the

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

On 15 May 2017 at 12:12, Doug Hellmann wrote: > Excerpts from Michał Jastrzębski's message of 2017-05-15 10:52:12 -0700: >> For starters, I want to emphasize that fresh set of dockerhub images >> was one of most requested features from Kolla on this summit and few >> other

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

On 15 May 2017 at 11:47, Sean Dague <s...@dague.net> wrote: > On 05/15/2017 01:52 PM, Michał Jastrzębski wrote: >> For starters, I want to emphasize that fresh set of dockerhub images >> was one of most requested features from Kolla on this summit and few >> other fea

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

nal. > > Thanks, > Dims > > On Mon, May 15, 2017 at 1:52 PM, Michał Jastrzębski <inc...@gmail.com> wrote: >> For starters, I want to emphasize that fresh set of dockerhub images >> was one of most requested features from Kolla on this summit and few >> other feat

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

For starters, I want to emphasize that fresh set of dockerhub images was one of most requested features from Kolla on this summit and few other features more or less requires readily-available docker registry. Features like full release upgrade gates. This will have numerous benefits for users

Re: [openstack-dev] [tc] [all] OpenStack moving both too fast and too slow at the same time

You are talking about OpenStack being hard because it's complex and at the same time you're talking about using "non-linux-mainstream" tools around. It's either flexibility or ease guys... Prescriptive is easy, flexible is hard. When you want to learn about linux you're not starting from compiling

Re: [openstack-dev] [tc] [all] OpenStack moving both too fast and too slow at the same time

On 5 May 2017 at 11:33, Alex Schultz wrote: > On Fri, May 5, 2017 at 10:48 AM, Chris Dent wrote: >> On Fri, 5 May 2017, Alex Schultz wrote: >> >>> You have to understand that as I'm mainly dealing with having to >>> actually deploy/configure the

[openstack-dev] [kolla] Next 2 meetings canceled

As we said on last meeting, next 2 (3.05 and 10.05) meetings are canceled due to summit and pre-summit preparation. See you all at 17! Cheers, Michal __ OpenStack Development Mailing List (not for usage questions)

[openstack-dev] [kolla][kolla-ansible] Proposing Bertrand Lallau for kolla and kolla-ansible core

Hello, It's my pleasure to start another core reviewer vote. Today it's Bertrand (blallau). Consider this mail my +1 vote. Members of kolla-ansible and kolla core team, please cast your votes:) Voting will be open for 2 weeks (until 16th of May). I also wanted to say that Bertrand went through

Re: [Openstack-operators] [Forum] Moderators needed!

I can moderate HA session if you want (although there is one listed in schedule?). Feel free to sign me up On 28 April 2017 at 06:07, Jay Pipes wrote: > On 04/28/2017 08:22 AM, Shamail Tahir wrote: >> >> Hi everyone, >> >> Most of the proposed/accepted Forum sessions

Re: [openstack-dev] [Openstack-operators] [Forum] Moderators needed!

I can moderate HA session if you want (although there is one listed in schedule?). Feel free to sign me up On 28 April 2017 at 06:07, Jay Pipes wrote: > On 04/28/2017 08:22 AM, Shamail Tahir wrote: >> >> Hi everyone, >> >> Most of the proposed/accepted Forum sessions

Re: [openstack-dev] [kolla] Which distros are used as base ones?

We tried to use mariadb package few months ago, but it turns out it was ancient version that broke horribly on multinode.. On 28 April 2017 at 02:41, Christian Berendt wrote: > >> On 27. Apr 2017, at 11:46, Marcin Juszkiewicz >>

Re: [openstack-dev] [kolla] Which distros are used as base ones?

Ofc we do. I, for one, run mostly ubuntu (but I must admit I haven't been building images last 2 or so weeks). It's strange what you're saying because ubunut-source build is a voting gate, so if there would be problem like that - we couldn't merge anything... Let's try to find out why your build

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

c/skopeo >>> [1] https://github.com/docker/distribution/issues/1252 >> >> >> >> You beat me to it, Paul. >> >> I think using lables to communicate the version of each openstack software >> installed in the image is the way to go here. We're looking into doing

[openstack-dev] [kolla][all] Core mentorship program kickoff

Hello everyone, On todays meeting we officially started mentorship program in Kolla:) If you are core or you are interested in becoming one, please sign up on this etherpad https://etherpad.openstack.org/p/kolla-mentorship-signup Idea is to provide safe environment to ask questions, get

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

lled in the image is the way to go here. We're looking into doing this > ourselves as part of the RDO pipeline and it'd be awesome to have it being > part > of kolla-build itself. Steve Baker, I believe, was working on this. > > The more explicit we are about the contents of the image, the

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

On 18 April 2017 at 13:54, Doug Hellmann wrote: > Excerpts from Michał Jastrzębski's message of 2017-04-18 13:37:30 -0700: >> On 18 April 2017 at 12:41, Doug Hellmann wrote: >> > Excerpts from Steve Baker's message of 2017-04-18 10:46:43 +1200: >> >>

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

On 18 April 2017 at 12:41, Doug Hellmann wrote: > Excerpts from Steve Baker's message of 2017-04-18 10:46:43 +1200: >> On Tue, Apr 18, 2017 at 9:57 AM, Doug Hellmann >> wrote: >> >> > Excerpts from Michał Jastrzębski's message of 2017-04-12 15:59:34

  1   2   3   >