Re: [openstack-dev] [requirements] adding uwsgi to global-requirements

> Original Message > Subject: Re: [openstack-dev] [requirements] adding uwsgi to > global-requirements > Local Time: December 19, 2017 9:57 PM > UTC Time: December 20, 2017 2:57 AM > From: mtrein...@kortar.org > To: Sam Yaple <s...@yaple.net>, OpenSta

Re: [openstack-dev] [requirements] adding uwsgi to global-requirements

> Original Message > Subject: Re: [openstack-dev] [requirements] adding uwsgi to > global-requirements > Local Time: December 19, 2017 6:34 PM > UTC Time: December 19, 2017 11:34 PM > From: mtrein...@kortar.org > To: Sam Yaple <s...@yaple.net>, OpenSta

[openstack-dev] [requirements] adding uwsgi to global-requirements

Hello, I wanted to bring up the idea of getting uwsgi into the requirements repo. I seem to recall this being discussed a couple of years back, but for the life of me I cannot find the thread, so forgive me if I am digging up ancient history. I would like to see uwsgi in

Re: [openstack-dev] [kolla] Ansiblize init-runonce script

For what its worth, this init-runonce script was never meant for production usage. Ops *shouldn't* be running it like you suggest. It was historically for use in the gate and a quick-n-dirty environment setup for testing. If you want to get into writing operations scripts, thats your

Re: [openstack-dev] Fwd: [Distutils][pbr][devstack][qa] Announcement: Pip 10 is coming, and will move all internal APIs

On Fri, Oct 20, 2017 at 4:32 PM, Doug Hellmann wrote: > Excerpts from Clark Boylan's message of 2017-10-20 13:14:13 -0700: > > On Fri, Oct 20, 2017, at 11:17 AM, Clark Boylan wrote: > > > On Fri, Oct 20, 2017, at 07:23 AM, Doug Hellmann wrote: > > > > It sounds like the

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

On Thu, Oct 19, 2017 at 11:23 PM, Gabriele Cerami <gcer...@redhat.com> wrote: > On 19 Oct, Sam Yaple wrote: > > So it seems tripleo is building *all* images and then pushing them. > > Reworking your number leads me to believe you will be consuming 10-15GB > in > > to

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

On Thu, Oct 19, 2017 at 9:38 PM, Gabriele Cerami <gcer...@redhat.com> wrote: > On 19 Oct, Sam Yaple wrote: > > docker_image wouldn't be the best place for that. Buf if you are looking > > for a quicker solution, kolla_docker was written specifically to be > license >

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

docker_image wouldn't be the best place for that. Buf if you are looking for a quicker solution, kolla_docker was written specifically to be license compatible for openstack. its structure should make it easily adapted to delete an image. And you can copy it and cut it up thanks to the license.

Re: [openstack-dev] [all][tc] TC Candidates: what does an OpenStack user look like?

I used to be able to say "my OpenStack background is in Operations" but that isn't strictly true anymore. I've now spent the majority of my time doing what is considered 'developer' work. One thing is for certain though, I have never stopped building OpenStack for what I see as the "hypothetical

Re: [openstack-dev] [Openstack-operators] [kolla][puppet][openstack-ansible][tripleo] Better way to run wsgi service.

I have been running api services behind uwsgi in http mode from Newton forward. I recently switched to the uwsgi+nginx model with 2 containers since I was having wierd issues with things that I couldn't track down. Mainly after I started using keystone with ldap. There would be timeouts and

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

I would like to bring up a subject that hasn't really been discussed in this thread yet, forgive me if I missed an email mentioning this. What I personally would like to see is a publishing infrastructure to allow pushing built images to an internal infra mirror/repo/registry for consumption of

Re: [openstack-dev] [kolla] rabbitmq cluster_partition_handling config in kolla-ansible

ything but 'autoheal' for OpenStack specifically. I certainly don't see any advantages. Now that the ask has been made though, a variable would be 2 lines of code in total, so I say go for it. Thanks, SamYaple Sam Yaple On Mon, Mar 20, 2017 at 2:43 PM, Nikita Gerasimov < nikita.gerasi...@o

Re: [openstack-dev] [kolla] Multi-Regions Support

On Fri, Jan 6, 2017 at 8:01 PM, Jay Pipes wrote: > On 01/05/2017 09:12 AM, Ronan-Alexandre Cherrueau wrote: > >> Hello, >> >> TL;DR: We make a multi-regions deployment with Kolla. It requires to >> patch the code a little bit, and you can find the diff on our >> GitHub[1].

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

Yaple's message of 2017-01-05 17:02:35 +: > > > > On Thu, Jan 5, 2017 at 4:54 PM, Jeremy Stanley <fu...@yuggoth.org> > > > wrote: > > > > > > > > > On 2017-01-05 16:46:36 + (+), Sam Yaple wrote:

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

been discussed or considered up until now. We had all just assumed kolla-salt and kolla-puppet and kolla-chef would be a thing, but would there be a benefit to sitting under the kolla namespace? I am not sure what those benefits are. Thanks, SamYaple > Cheers, > Michal > > > On 5 Ja

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

On Thu, Jan 5, 2017 at 6:12 PM, Doug Hellmann <d...@doughellmann.com> wrote: > Excerpts from Sam Yaple's message of 2017-01-05 17:02:35 +: > > On Thu, Jan 5, 2017 at 4:54 PM, Jeremy Stanley <fu...@yuggoth.org> > wrote: > > > > > On 2017-01-05

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

extend > > breadth of the project indeed, but let's face it, religious wars are > > real (and vim is better than emacs.);) I don't thing problem would be > > ill intent tho, I could easily predict problem being rather in "I > > don't have time to look at this

Re: [openstack-dev] [kolla] Multi-Regions Support

On Thu, Jan 5, 2017 at 2:12 PM, Ronan-Alexandre Cherrueau < ronan-alexandre.cherru...@inria.fr> wrote: > Hello, > > > TL;DR: We make a multi-regions deployment with Kolla. It requires to > patch the code a little bit, and you can find the diff on our > GitHub[1]. This patch is just a first

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

On Thu, Jan 5, 2017 at 4:54 PM, Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2017-01-05 16:46:36 + (+0000), Sam Yaple wrote: > [...] > > I do feel this is slightly different than whats described. Since it is > not > > unrelated services, but rather, for lack

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

On Thu, Jan 5, 2017 at 4:34 PM, Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2017-01-05 15:58:45 + (+0000), Sam Yaple wrote: > > Involving kolla-ansible and kolla-kubernetes in a decision about > kolla-salt > > (or kolla-puppet, or kolla-chef) is silly since the

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

I should be voting on the acceptance of a new deployment tool I have no interest in that won't affect anything I am working on. Of course, this is just my opinion. Thanks, SamYaple Doug > > > > > Thanks, > > SamYaple > > > > > > > > Sam Yaple

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

are the images being consumed. Thanks, SamYaple Sam Yaple On Thu, Jan 5, 2017 at 12:31 AM, Steven Dake (stdake) <std...@cisco.com> wrote: > Michal, > > Another option is 2 individuals from each core review team + PTL. That is > lighter weight then 3 and 4, yet more constr

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

wanting to work on it, or one person putting forth work for a new deployment tool to use Kolla container and others joining in as they see the potential of the project themselves. I would prefer to keep it that way. Thanks, SamYaple Sam Yaple On Wed, Jan 4, 2017 at 11:38 PM, Michał Jastrzębski <

Re: [openstack-dev] [kolla] the user in container should NOT have write permission for configuration file

peoples development cycle with Kolla. I remember I personally changed the config from inside the running docker container once or twice while testing. SamYaple > so, for the file should be > > 0640 root:nova nova.conf > > > On Mon, Sep 26, 2016 at 10:43 PM, Sam Yaple <sam.

Re: [openstack-dev] [kolla] the user in container should NOT have write permission for configuration file

On Mon, Sep 26, 2016 at 3:03 PM, Christian Berendt < bere...@betacloud-solutions.de> wrote: > > On 26 Sep 2016, at 16:43, Sam Yaple <sam...@yaple.net> wrote: > > > > So this actually makes it _less_ secure. The 0600 permissions were > chosen for a reason.

Re: [openstack-dev] [kolla] the user in container should NOT have write permission for configuration file

On Mon, Sep 26, 2016 at 1:18 PM, Jeffrey Zhang wrote: > Using the same user for running service and the configuration files is > a danger. i.e. the service running user shouldn't change the > configuration files. > > a simple attack like: > * a hacker hacked into

Re: [openstack-dev] Neutron and MTU advertisements -- post newton

1500 mtu regardless of network type. If you want some extra IRC reading, there was a more extensive conversation about this [1]. Good luck, you'll need it. [1] http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2016-07-11.log.html#t2016-07-11T13:39:45 Sam Yaple

Re: [openstack-dev] Neutron and MTU advertisements -- post newton

On Mon, Jul 11, 2016 at 4:39 PM, Jay Pipes <jaypi...@gmail.com> wrote: > On 07/11/2016 07:45 AM, Sam Yaple wrote: > >> Hello, >> >> There was alot of work to get MTU advertisement working well in Mitaka. >> With the work that was done we can finally ha

[openstack-dev] Neutron and MTU advertisements -- post newton

to a switch which supports jumbo frames. Just because the switch will accept and process a 9000 mtu frame, doesnt mean the computer has to send a 9000 mtu frame. A very common scenario in the real world. [1] https://review.openstack.org/#/c/310448/ Sam Yaple

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

+1 Sam Yaple On Fri, Mar 25, 2016 at 4:52 PM, Michał Jastrzębski <inc...@gmail.com> wrote: > +1 > > On 25 March 2016 at 11:36, Jeffrey Zhang <zhang.lei@gmail.com> wrote: > > +1 > > > > On Sat, Mar 26, 2016 at 12:07 AM, Ryan Hallisey <rhall...@

[openstack-dev] [kolla][ptl] Kolla PTL Candidacy for Sam Yaple

reasons, I have a strong vision of the direction we can take Kolla over the next cycle. Thanks for your contributions and consideration. I look forward to continuing to work closely with our community! - Sam Yaple [0] http://stackalytics.com/?project_type=all=kol

Re: [openstack-dev] [kolla] [infra] Size of images built in the gate

Steve, overlayfs does not reduce the disk usage at all Paul, we can bump the size of the docker mountpoint up to ~20GB if you check all the gates for the appropriate space. Sam Yaple On Mon, Mar 14, 2016 at 7:20 PM, Steven Dake (stdake) <std...@cisco.com> wrote: > Vikarm, > >

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

On Mon, Mar 7, 2016 at 3:03 PM, Steven Dake (stdake) wrote: > Hi folks, > > It was never really discussed if we would back-port upgrades to liberty. > This came up during an irc conversation Friday [1], and a vote was > requested. Tthe facts of the discussion distilled are: >

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

+1 Keep up the great reviews and patches! Sam Yaple On Mon, Mar 7, 2016 at 3:41 PM, Jeff Peeler <jpee...@redhat.com> wrote: > +1 > > On Mon, Mar 7, 2016 at 3:57 AM, Michal Rostecki <mroste...@mirantis.co

Re: [openstack-dev] [kolla] unblocking the gate

On Mon, Feb 29, 2016 at 6:42 PM, Clark Boylan wrote: > On Mon, Feb 29, 2016, at 09:09 AM, Steven Dake (stdake) wrote: > > > > > > On 2/29/16, 12:26 AM, "Andreas Jaeger" wrote: > > >This is not needed, the CI system always rebases if you run tests. To > >

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

Oracle, Redhat, Mirantis, Servosity, 99cloud. Those are the biggest users, at least according to the reviews and commits. I am not in favor of limiting the number of cores from a single company. However, it is an unwritten rule that I've heard and abide by that a company should not push a patch

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

I was under the impression we did have a majority of cores in favor of the idea at the midcycle. But if this is a vote-vote, then I am a very strong +1 as well. This is something operators will absolutely want and and need. Sam Yaple On Sat, Feb 20, 2016 at 4:27 PM, Michał Jastrzębski <

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

+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 Rostecki <mroste...@mirantis.com> wrote: > On 02/19/2016 07:04 PM, Steven Dake (stdake) wrote: > >> Angus is already in kolla-mesos-core but doesn't have broad abi

Re: [openstack-dev] [kolla] Decision of how to manage stable/liberty from Kolla Midcycle

On Tue, Feb 16, 2016 at 6:15 PM, Steven Dake (stdake) wrote: > Hey folks, > > We held a midcycle Feb 9th and 10th. The full notes of the midcycle are > here: > https://etherpad.openstack.org/p/kolla-mitaka-midcycle > > We had 3 separate ~40 minute sessions on making stable

Re: [openstack-dev] Proposed Agenda for Kolla Midcycle

re, I think that makes sense :) > Surely you mean Wednesday. I am not sure that continuing the discussion and making decisions without everyone there is a good idea. I would prefer a working session where we could hammer out some code. Sam Yaple

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

ypervisors directly and can still utilize that low-level info. > On 6 Feb 2016 17:56, "Sam Yaple" <sam...@yaple.net> wrote: > >> On Sat, Feb 6, 2016 at 3:00 PM, Jeremy Stanley <fu...@yuggoth.org> wrote: >> >>> On 2016-02-05 16:38:19 + (+), S

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On Fri, Feb 5, 2016 at 3:31 PM, Jay Pipes <jaypi...@gmail.com> wrote: > On 02/05/2016 09:58 AM, Sam Yaple wrote: > >> Since Nova has no backup mechanism this is clearly a gap and that was the >> issue >> Ekko wants to solve. >> > > Nova

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On Thu, Feb 4, 2016 at 2:23 PM, gordon chung <g...@live.ca> wrote: > > > On 03/02/2016 10:38 AM, Sam Yaple wrote: > > On Wed, Feb 3, 2016 at 2:52 PM, Jeremy Stanley < <fu...@yuggoth.org> > fu...@yuggoth.org> wrote: > >> On 2016-02-03 14:32:36 + (+

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On Wed, Feb 3, 2016 at 1:41 PM, Duncan Thomas <duncan.tho...@gmail.com> wrote: > On 2 February 2016 at 02:28, Sam Yaple <sam...@yaple.net> wrote: > >> >> I disagree with this statement strongly as I have stated before. Nova has >> snapshots. Cinder has snapsho

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On Wed, Feb 3, 2016 at 2:37 PM, Duncan Thomas <duncan.tho...@gmail.com> wrote: > > > On 3 February 2016 at 16:32, Sam Yaple <sam...@yaple.net> wrote: > >> >> Looking into it, however, shows Cinder has no mechanism to delete backups >> in the middle

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On Wed, Feb 3, 2016 at 3:36 PM, Duncan Thomas <duncan.tho...@gmail.com> wrote: > On 3 February 2016 at 17:27, Sam Yaple <sam...@yaple.net> wrote: > > >> >> And here we get to the meat of the matter. Squashing backups is awful in >> object storage. It requir

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On Wed, Feb 3, 2016 at 2:52 PM, Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2016-02-03 14:32:36 + (+0000), Sam Yaple wrote: > [...] > > Luckily, digging into it it appears cinder already has all the > > infrastructure in place to handle what we had talked about

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On Wed, Feb 3, 2016 at 3:58 PM, Duncan Thomas <duncan.tho...@gmail.com> wrote: > On 3 February 2016 at 17:52, Sam Yaple <sam...@yaple.net> wrote: > > >> This is a very similiar method to what Ekko is doing. The json mapping in >> Ekko is a manifest file whic

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On Wed, Feb 3, 2016 at 4:53 PM, Preston L. Bannister <pres...@bannister.us> wrote: > On Wed, Feb 3, 2016 at 6:32 AM, Sam Yaple <sam...@yaple.net> wrote: > >> [snip] >> > Full backups are costly in terms of IO, storage, bandwidth and time. A >> full backup b

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

> I submitted an Ekko talk "The 'B' Word -- Backups in OpenStack". Title seems all inclusive, but in reality I am just talking about the block-based side of backups. I am co-presenting with another Ekko dev and we do have a brief slot in our outline for explaining Ekko's place i

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On Feb 2, 2016 7:41 AM, "Preston L. Bannister" wrote: > > Oh, for the other folk reading, in QEMU you want to look at: > > http://wiki.qemu.org/Features/IncrementalBackup > > The above page looks to be current. The QEMU wiki seems to have a number of stale pages that

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

ler. So if a merging is needed, then it should be fairly simple. None of this has to be decided right now. We aren't going down a path that can't be reversed, and we likely never will given how little these two projects overlap in their current forms. Sam Yaple _

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

ts to block others, Sam proposed solution is indeed >remarkable, but this is OpenStack, we work in Teams, why we cannot do that >and be less fragmented. > > > Thanks, > Fausto > > Sam Yaple __ OpenSt

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

Give it time :). Ekko has an informal mid-cycle planned since all the Core contributors as of now will be at the Kolla midcycle in Feb. We plan on documenting and presenting a roadmap at this time. > Please let me know what your thoughts are on this. > > Thanks, > Fausto > Hopefully the

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

Freezer and Ekko they can still live side-by-side without any conflict at all. As of now, Ekko and Freezer teams have started a dialogue and we will continue to collaborate rather than compete in every way that is reasonable for both projects. Sam Yaple __

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On Tue, Jan 26, 2016 at 10:15 AM, Jay Pipes <jaypi...@gmail.com> wrote: > On 01/26/2016 02:47 AM, Sam Yaple wrote: > >> Hello Fausto, >> >> I am happy to have a conversation about this with you and the Freezer >> team. I have a feeling the current direction

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

On Mon, Jan 25, 2016 at 11:44 AM, Sean M. Collins wrote: > Just an FYI for anyone taking the Neutron piece, please feel free to > attend the upgrades subteam - we have a meeting today. > > https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam > -- > Sean M.

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

Didn't hit the mailing list with the last reply. Forwarding to a wider audience than just Dean -- Forwarded message -- From: "Sam Yaple" <sam...@yaple.net> Date: Jan 26, 2016 12:00 PM Subject: Re: [openstack-dev] Announcing Ekko -- Scalable block-based back

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On Tue, Jan 26, 2016 at 9:57 PM, Jay Pipes wrote: > > I am not suggesting you "share an API" at all. I am requesting that if you > have a RESTful API planned for your "backup", then you do not use the same > RESTful API resource endpoint names that Freezer does. Because if

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On Mon, Jan 25, 2016 at 8:45 AM, Thierry Carrez <thie...@openstack.org> wrote: > Sam Yaple wrote: > >> We would like to introduce you to a new community-driven OpenStack >> project called Ekko. >> >> The aim of Ekko is to provide incremental block-level backup

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

Hello Fausto, I am happy to have a conversation about this with you and the Freezer team. I have a feeling the current direction of Ekko will add many components that will not be needed for Freezer and vice-versa. Nevertheless, I am all about community! Sam Yaple On Tue, Jan 26, 2016 at 2:20 AM

[openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

Dear community, We would like to introduce you to a new community-driven OpenStack project called Ekko. The aim of Ekko is to provide incremental block-level backup and restore of Nova instances. We see backups as a key area that is missing in OpenStack. One issue that has previously prevented

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

+1 another full time kolla dev. w00t. Jeffrey has done some amazing reviews and great work for Kolla. Sam Yaple On Tue, Jan 19, 2016 at 3:30 PM, Michał Jastrzębski <inc...@gmail.com> wrote: > +1 :) > > On 19 January 2016 at 07:28, Ryan Hallisey <rhall...@redhat.com> wr

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

to mix its logs in with the neutron logs in stdout/err. Can Heka handle this and separate them efficiently? Otherwise I see no choice but to stick with something that can handle multiple logs from a single container. Sam Yaple On Mon, Jan 11, 2016 at 10:16 PM, Eric LEMOINE <elemo...@mirantis.

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

I like the idea of using Heka. You and I have discussed this on IRC before. So my vote for this is +1. I can't think of any downside. I would like to hear Alicja Kwasniewska's view on this as she has done the majority of work with Logstash up until this point. Sam Yaple On Mon, Jan 11, 2016 at 3

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

That said if you have a link to the project-config patch I will be more than happy to review it and follow it. Sam Yaple On Sun, Jan 3, 2016 at 10:05 AM, Thomas Goirand <z...@debian.org> wrote: > On 12/29/2015 10:36 PM, Steven Dake (stdake) wrote: > > Thomas, > > > > I also

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

now. With the pace he is going the code should be mergable before the end of the week. Sam Yaple On Mon, Dec 28, 2015 at 4:28 PM, Michał Jastrzębski <inc...@gmail.com> wrote: > Hey, > > So one thing we need to consider there is that currently 3 options we > support (binary+so

Re: [openstack-dev] [kolla] Using existing ceph pools

This is a planned feature from the beginning, but not implemented. I have done this locally, but I have not submitted a patchset. You can expect this available and working by mitaka-2. On Dec 1, 2015 6:08 AM, "OpenStack Mailing List Archive" wrote: > Link:

Re: [openstack-dev] [kolla] docker module replacement

Point of clarification, Brian Coca (bcoca) confirmed there _will_ be an ansible 1.9.5 to me the other day. So we will be unblocked at some point for Docker 1.8.2. Unfortunately the module is broken with v1 registry past Docker 1.8.2. That said here are my issues: * its been 4 weeks since we

Re: [openstack-dev] [kolla] Proposing Michal Rostecki for Core Reviewer (nihilfer on IRC)

Michal does great patches and is very receptive to feedback. +1 for me. We may need to call him Michal2 though. Might get confusing to have multiple Michals on the team. Sam Yaple On Thu, Nov 12, 2015 at 9:23 AM, Paul Bourke <paul.bou...@oracle.com> wrote: > +1 > > > On 12/1

Re: [openstack-dev] [kolla] Backport policy for Liberty

is alot closer to a client or a library than it is to Nova or Neutron. And given its mission maybe it should break from the "typical OpenStack backports policy" so we can give a consistent deployment experience across all stable and supported version of OpenStack at any given time. Those

Re: [openstack-dev] [kolla] new yaml format for all.yml, need feedback

Also in favor is it lands before Liberty. But I don't want to see a format change straight into Mitaka. Sam Yaple On Wed, Sep 30, 2015 at 1:03 PM, Steven Dake (stdake) <std...@cisco.com> wrote: > I am in favor of this work if it lands before Liberty. > > Regards > -steve >

Re: [openstack-dev] [kolla] proposing Michal Jastrzebski (inc0) for core reviewer

+1 Michal will be a great addition to the Core team. On Sep 29, 2015 6:48 PM, "Martin André" wrote: > > > On Wed, Sep 30, 2015 at 7:20 AM, Steven Dake (stdake) > wrote: > >> Hi folks, >> >> I am proposing Michal for core reviewer. Consider my proposal

Re: [openstack-dev] [kolla] Followup to review in gerrit relating to RHOS + RDO types

On Mon, Sep 14, 2015 at 11:19 AM, Paul Bourke <paul.bou...@oracle.com> wrote: > > > On 13/09/15 18:34, Steven Dake (stdake) wrote: > >> Response inline. >> >> From: Sam Yaple <sam...@yaple.net<mailto:sam...@yaple.net>> >> Reply-To: &quo

Re: [openstack-dev] [kolla] Followup to review in gerrit relating to RHOS + RDO types

On Sun, Sep 13, 2015 at 3:01 AM, Steven Dake (stdake) <std...@cisco.com> wrote: > Response inline. > > From: Sam Yaple <sam...@yaple.net> > Reply-To: "s...@yaple.net" <s...@yaple.net> > Date: Saturday, September 12, 2015 at 11:34 PM > To: S

Re: [openstack-dev] [kolla] Followup to review in gerrit relating to RHOS + RDO types

On Sun, Sep 13, 2015 at 12:39 AM, Steven Dake (stdake) wrote: > Hey folks, > > Sam had asked a reasonable set of questions regarding a patchset: > https://review.openstack.org/#/c/222893/ > > The purpose of the patchset is to enable both RDO and RHOS as binary > choices on RHEL

Re: [openstack-dev] [kolla] Followup to review in gerrit relating to RHOS + RDO types

Sam Yaple On Sun, Sep 13, 2015 at 1:15 AM, Steven Dake (stdake) <std...@cisco.com> wrote: > > > From: Sam Yaple <sam...@yaple.net> > Reply-To: "s...@yaple.net" <s...@yaple.net> > Date: Saturday, September 12, 2015 at 11:01 PM > To: Steven Dake &

Re: [openstack-dev] [kolla] Proposing Swapnil Kulkarni (coolsvap) for kolla core reviewer team

+1 Swapnil has always been very helpful. On Aug 14, 2015 2:21 PM, Harm Weites h...@weites.com wrote: great! +1 :) Op 14-08-15 om 15:38 schreef Paul Bourke: +1, Swapnil has made a ton of useful contributions and continues to do so :) On 14/08/15 14:29, Steven Dake (stdake) wrote: Hi

Re: [openstack-dev] [kolla] Developers please assign yourself 3 or more Docker templates

Sure thing, I can handle rabbitmq and keystone tonight. The keystone one I wrote during the mid-cycle so I will just throw it in a patch. Sam Yaple On Tue, Aug 11, 2015 at 10:54 AM, Steven Dake (stdake) std...@cisco.com wrote: Hi, Alicja has been heading up this blueprint: https

Re: [openstack-dev] [TripleO] [Puppet] Deploying OpenStack with Puppet modules on Docker with Heat

On Wed, Aug 5, 2015 at 1:29 PM, Dan Prince dpri...@redhat.com wrote: ...snip... -The external config file mechanism for Kolla containers only seems to support a single config file. Some services (Neutron) can have multiple files. Could we extend the external config support to use multiple

Re: [openstack-dev] [Neutron][Kuryr][kolla] - Bringing Dockers networking to Neutron

would love to help you add MidoNet in! Sam Yaple On Thu, Jul 23, 2015 at 1:16 PM, Antoni Segura Puimedon toni+openstac...@midokura.com wrote: On Thu, Jul 23, 2015 at 7:35 PM, Mohammad Banikazemi m...@us.ibm.com wrote: I let the creators of the project speak for themselves but here is my

Re: [openstack-dev] [kolla][magnum] Removal of Daneyon Hansen from the Core Reviewer team for Kolla

Daneyon, We haven't had much overlap here in Kolla, but our interactions have always been pleasant and informative. You are clearly a very smart and driven guy. Good luck with Magnum. Hopefully you will see me around Magnum more in the future as well, I expect great things! Sam Yaple On Wed

Re: [openstack-dev] [Neutron][Kuryr][Kolla] - Bringing Dockers networking to Neutron

are re-inventing the wheel for each different project. Unfortunately, I am not seeing much documentation about this project. I would love to read more about the current status and plans so we can both contribute to each other! Sam Yaple On Wed, Jul 22, 2015 at 2:04 PM, Fox, Kevin M kevin

Re: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

+1 from me. Paul reviews are always helpful and easily in the same number with the other Core members (108 reviews this cycle!). Additionally he has been helpful in testing the new Ansible pieces as well as pushing forward the source installation, both areas we need help in currently. Sam Yaple

Re: [openstack-dev] [kolla][tc] Plans for using Pre-2.0 Ansible modules

rule. This too would only be temporary until Ansible 2.0. [1] https://github.com/emonty/ansible-modules-core/tree/merge-it-all/cloud/openstack Sam Yaple 864-901-0012 On Fri, Jul 3, 2015 at 1:56 PM, Greg DeKoenigsberg g...@ansible.com wrote: Option 3 sounds fine to me. We hope to have 2.0 out

Re: [openstack-dev] [kolla][release] Announcing Liberty-1 release of Kolla

Ian, The most significant difference would be that Kolla uses image based deployment rather than building from source on each node at runtime allowing for a more consistent and repeatable deployment. On Tue, Jun 30, 2015 at 2:28 PM, Ian Cordasco ian.corda...@rackspace.com wrote: On 6/29/15,

Re: [openstack-dev] [kolla] Proposal for changing 1600UTC meeting to 1700 UTC

1600 is late for me as it is. The earlier the better is my vote. I would make 1630 work, 1700 is too late. Sam Yaple 864-901-0012 On Tue, Jun 16, 2015 at 2:09 PM, Harm Weites h...@weites.com wrote: I'm ok with moving to 16:30 UTC instead of staying at 16:00. I actually prefer it in my

Re: [openstack-dev] [kolla] Proposal for new core-reviewer Harm Waites

+1 for me as well. Designate looks great On Jun 15, 2015 6:43 AM, Ryan Hallisey rhall...@redhat.com wrote: +1 Great job with Cinder. -Ryan - Original Message - From: Steven Dake (stdake) std...@cisco.com To: OpenStack Development Mailing List (not for usage questions)