> 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 , OpenStack Development
> 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 , OpenStack Development
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 global-requirements.txt
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 prerogative
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 PyPI/PyPA folks are planni
On Thu, Oct 19, 2017 at 11:23 PM, Gabriele Cerami
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
> > total on Dockerhub. Kolla
On Thu, Oct 19, 2017 at 9:38 PM, Gabriele Cerami 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
> > compatible for op
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.
Ar
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
Op
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 message
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 in
d to justify anything 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 Ger
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]. This patch is just a fi
gt; > > > On Thu, Jan 5, 2017 at 4:54 PM, Jeremy Stanley
> > > wrote:
> > > >
> > > > > On 2017-01-05 16:46:36 + (+), Sam Yaple wrote:
> > > > > [...]
> > > > > > I do feel this is slightly different than wh
t is just a point that hasn't 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
>
On Thu, Jan 5, 2017 at 6:12 PM, Doug Hellmann 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
> wrote:
> >
> > > On 2017-01-05 16:46:36 + (+), Sam Yaple wrote:
> > >
l friendly rivalry, it is meant to 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
> &g
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 attempt
On Thu, Jan 5, 2017 at 4:54 PM, Jeremy Stanley wrote:
> On 2017-01-05 16:46:36 + (+), Sam Yaple wrote:
> [...]
> > I do feel this is slightly different than whats described. Since it is
> not
> > unrelated services, but rather, for lack of a better word, competin
On Thu, Jan 5, 2017 at 4:34 PM, Jeremy Stanley wrote:
> On 2017-01-05 15:58:45 + (+), 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 projects are
> unrelat
ng 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
> >
> > On
are
the images being consumed.
Thanks,
SamYaple
Sam Yaple
On Thu, Jan 5, 2017 at 12:31 AM, Steven Dake (stdake)
wrote:
> Michal,
>
> Another option is 2 individuals from each core review team + PTL. That is
> lighter weight then 3 and 4, yet more constrained then 1 and 2 and w
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
th 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 wrote:
>
>> On Mon, Sep 26,
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 wrote:
> >
> > So this actually makes it _less_ secure. The 0600 permissions were
> chosen for a reason. The nova.conf file has passwor
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 nova-api container with nova user
iving 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
On Mon, Jul 11, 2016 at 4:39 PM, Jay Pipes 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 have 1500 mtu networks for
>>
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
wrote:
> +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
> >>
&g
hese 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&module=k
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)
wrote:
> Vikarm,
>
> /var/lib/docker i
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:
>
>- We never ag
+1 Keep up the great reviews and patches!
Sam Yaple
On Mon, Mar 7, 2016 at 3:41 PM, Jeff Peeler wrote:
> +1
>
> On Mon, Mar 7, 2016 at 3:57 AM, Michal Rostecki
> wrote:
> > +1
> >
> >
> >
> _
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
> > >get current tests, a simple "recheck" is
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 th
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
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 Rostecki
wrote:
> On 02/19/2016 07:04 PM, Steven Dake (stdake) wrote:
>
>> Angus is already in kolla-mesos-core but doesn't have broad ability to
>> approve c
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 stable. The reason
>
s 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
__
can still utilize that
low-level info.
> On 6 Feb 2016 17:56, "Sam Yaple" wrote:
>
>> On Sat, Feb 6, 2016 at 3:00 PM, Jeremy Stanley wrote:
>>
>>> On 2016-02-05 16:38:19 + (+), Sam Yaple wrote:
>>> > I always forget to qualify that statement
On Sat, Feb 6, 2016 at 3:00 PM, Jeremy Stanley wrote:
> On 2016-02-05 16:38:19 + (+), Sam Yaple wrote:
> > I always forget to qualify that statement don't I? Nova does not
> > have a mechanism for _incremental_ backups. Nor does Nova have
> > compression or enc
On Fri, Feb 5, 2016 at 3:31 PM, Jay Pipes 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 has had backups for a long time:
>
&
On Thu, Feb 4, 2016 at 2:23 PM, gordon chung 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> wrote:
>
>> On 2016-02-03 14:32:36 + (+), Sam Yaple wrote:
>> [...]
&
On Wed, Feb 3, 2016 at 4:53 PM, Preston L. Bannister
wrote:
> On Wed, Feb 3, 2016 at 6:32 AM, Sam Yaple wrote:
>
>> [snip]
>>
> Full backups are costly in terms of IO, storage, bandwidth and time. A
>> full backup being required in a backup plan is a big problem
On Wed, Feb 3, 2016 at 3:58 PM, Duncan Thomas
wrote:
> On 3 February 2016 at 17:52, Sam Yaple wrote:
>
>
>> This is a very similiar method to what Ekko is doing. The json mapping in
>> Ekko is a manifest file which is a sqlite database. The major difference I
>>
On Wed, Feb 3, 2016 at 3:36 PM, Duncan Thomas
wrote:
> On 3 February 2016 at 17:27, Sam Yaple wrote:
>
>
>>
>> And here we get to the meat of the matter. Squashing backups is awful in
>> object storage. It requires you to pull both backups, merge them, then
>
On Wed, Feb 3, 2016 at 2:52 PM, Jeremy Stanley wrote:
> On 2016-02-03 14:32:36 + (+), Sam Yaple wrote:
> [...]
> > Luckily, digging into it it appears cinder already has all the
> > infrastructure in place to handle what we had talked about in a
> > separate em
On Wed, Feb 3, 2016 at 2:37 PM, Duncan Thomas
wrote:
>
>
> On 3 February 2016 at 16:32, Sam Yaple wrote:
>
>>
>> Looking into it, however, shows Cinder has no mechanism to delete backups
>> in the middle of a chain since you use dependent backups (please correct m
On Wed, Feb 3, 2016 at 1:41 PM, Duncan Thomas
wrote:
> On 2 February 2016 at 02:28, Sam Yaple wrote:
>
>>
>> I disagree with this statement strongly as I have stated before. Nova has
>> snapshots. Cinder has snapshots (though they do say cinder-backup). Freezer
ko 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&
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 describe proposed function tha
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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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
__
). 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 these have a
zer 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 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 you do,
> then users of
Didn't hit the mailing list with the last reply. Forwarding to a wider
audience than just Dean
-- Forwarded message --
From: "Sam Yaple"
Date: Jan 26, 2016 12:00 PM
Subject: Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup
for OpenStack
To: &q
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. Collins
>
Thanks Sean. I j
On Tue, Jan 26, 2016 at 10:15 AM, Jay Pipes 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 of Ekko will add many
>>
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
On Mon, Jan 25, 2016 at 8:45 AM, Thierry Carrez
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 and restore
>> of Nov
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 ba
+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
wrote:
> +1 :)
>
> On 19 January 2016 at 07:28, Ryan Hallisey wrote:
> > +1 nice work!
> >
> > -
ve 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
wrote:
>
>
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,
en on an Ubuntu host. 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 wrote:
> On 12/29/2015 10:36 PM, Steven Dake (stdake) wrote:
> > Thomas,
> >
> >
patches right 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
wrote:
> Hey,
>
> So one thing we need to consider there is that currently 3 options we
> support (binary+souce cento
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: https://openstack.nimeyo.com/67172/?sho
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 fi
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 wrote:
> +1
>
>
> On 12/11/15 08:41, Steven Dake (s
No you should not push with latest tag.
The initial push should have tag '1.0.0-liberty-000'. After we validate
that is a good build we can add additional tags '1.0.0' and '1.0.0-liberty'
If the build is not good we will rebuild and repush with tag
'1.0.0-liberty-001'. We should never be overwrit
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 a
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)
wrote:
> I am in favor of this work if it lands before Liberty.
>
> Regards
> -steve
>
>
> On 9/30/
+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 as a +1
>> vote. Michal has done a fantast
On Mon, Sep 14, 2015 at 11:19 AM, Paul Bourke
wrote:
>
>
> On 13/09/15 18:34, Steven Dake (stdake) wrote:
>
>> Response inline.
>>
>> From: Sam Yaple mailto:sam...@yaple.net>>
>> Reply-To: "s...@yaple.net<mailto:s...@yaple.net>" > s.
On Sun, Sep 13, 2015 at 3:01 AM, Steven Dake (stdake)
wrote:
> Response inline.
>
> From: Sam Yaple
> Reply-To: "s...@yaple.net"
> Date: Saturday, September 12, 2015 at 11:34 PM
> To: Steven Dake
> Cc: "OpenStack Development Mailing List (not for
Sam Yaple
On Sun, Sep 13, 2015 at 1:15 AM, Steven Dake (stdake)
wrote:
>
>
> From: Sam Yaple
> Reply-To: "s...@yaple.net"
> Date: Saturday, September 12, 2015 at 11:01 PM
> To: Steven Dake
> Cc: "OpenStack Development Mailing List (not for
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 platforms. I susp
+1 Swapnil has always been very helpful.
On Aug 14, 2015 2:21 PM, "Harm Weites" 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 f
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)
wrote:
> Hi,
>
> Alicja has been heading up this blueprint
On Wed, Aug 5, 2015 at 1:29 PM, Dan Prince 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
> files?
>
>
Yes
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
> wrote:
>
>> I let the creators of the project speak for themse
on where we 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:0
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
O
+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
.
Additionally, I have left a review pointing you to an issue you may run
into with creating all of the endpoints with v3 directly as it appears you
are doing in that patchset's playbooks.
Sam Yaple
On Wed, Jul 8, 2015 at 8:14 PM, Steven Dake (stdake)
wrote:
> Kevin,
>
> Thanks for
mit
referencing where they were pulled from with the appropriate license).
https://review.openstack.org/199463
Sam Yaple
864-901-0012
On Tue, Jul 7, 2015 at 9:21 PM, Steven Dake (stdake)
wrote:
>
>
> On 7/7/15, 2:05 PM, "Robert Collins" wrote:
>
> >On 4 July 2015 at 06:
ense or violate some stackforge 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 wrote:
> Option 3 sounds fine to me. We hope to hav
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
wrote:
>
>
> On 6/29/15, 23:59, "Steven Dake (std
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 wrote:
> I'm ok with moving to 16:30 UTC instead of staying at 16:00.
>
> I actually prefer it in my ev
+1 for me as well. Designate looks great
On Jun 15, 2015 6:43 AM, "Ryan Hallisey" wrote:
> +1 Great job with Cinder.
>
> -Ryan
>
> - Original Message -
> From: "Steven Dake (stdake)"
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.or
92 matches
Mail list logo
