> 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
> 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
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
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
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
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
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
>
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.
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
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
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
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
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].
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:
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
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
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
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
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
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
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
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
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 <
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.
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.
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
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
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
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
+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...@
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
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,
>
>
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:
>
+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
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
> >
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
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 <
+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
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, 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
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
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
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 + (+
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
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
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
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
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
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
>
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
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
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
_
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
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
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
__
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
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.
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
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
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
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
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
+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
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.
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
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
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
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:
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
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
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
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
>
+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
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
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
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
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 &
+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
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
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
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
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
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
+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
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
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,
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
+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)
88 matches
Mail list logo