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 oppor
+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
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: Thursday, April 26, 2018 at 5:32 PM
> To: OpenStack Development Mailing List
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 d
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
> intent when we met with
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, d
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 stable policy is not goo
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 how ansible works IMHO).
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
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 are what allows you to l
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 3
Because merry Christmas everyone:)
__
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/
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 releases, the harder they ar
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
_
Have a good summit everyone!
__
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/openst
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 matches my experience.
On 19 October 2017 at 13:37, Michał Jastrzębski wrote:
> 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`
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 invocation? (in part because o
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 is
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 2017-10-11 21:35:26 +0530
, Michał Jastrzębski 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
> jobs. That means between th
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 without
On 26 September 2017 at 13:54, Alex Schultz wrote:
> On Tue, Sep 26, 2017 at 2:34 PM, Michał Jastrzębski wrote:
>> 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 confi
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 manne
p 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 5:12 AM, Michał Jastrz
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 Triple-O, Kolla, et cetera want
On 22 September 2017 at 11:45, Clark Boylan 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 working towards
>> registry
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?). "
>>
>> IMHO we can try
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 g
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 if it's not already? T
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 more details.
>
> Thanks,
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
http://
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 to discuss future
>> developments around Ce
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
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)
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
__
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
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
>>...
>>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? (tripleo
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:
Greetings,
As some of you know, I've been working on
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:
>>>
>>>
>>> Greetings,
>>>
>
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 th
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 quest
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
http://lists.opensta
Aaaand it's done. Congrats Surya and welcome to core team!
On 27 June 2017 at 19:56, zhubingbing wrote:
>
>
>
> +1
>
>>> -Original Message-
>>> From: Michał Jastrzębski [mailto:inc...@gmail.com]
>>> Sent: Wednesday, June 14, 2017 10:46 PM
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 Jun
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 ad
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 need to deploy containe
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 c
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 new ML thing the TC is d
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 k
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
_
On 8 June 2017 at 09:50, Michał Jastrzębski wrote:
> 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, Emilie
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 when
the applicat
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 stable
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 or 3 days).
> [...]
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 "need" here. Is that becaus
[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
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
e
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 for TC to
reso
>> 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
> reg
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 diffe
On 17 May 2017 at 11:36, Michał Jastrzębski wrote:
> 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
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 world, if we refresh those images daily and the
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 (basically you can only
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 dailies), I think we'd be in
On 16 May 2017 at 12:36, Jeremy Stanley 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.
> [...]
>
> I think
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:
>> >> So another consideration. Do you think whol
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:
>> >> On 16 May 2017 at 06:20, Flavio Percoco wr
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 distro but we are packag
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 security checked (no gpg v
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 constructed, they are like
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 somethin
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 would be to have an #ope
co'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 wrote:
>>> >> >> Sorry for the top post, Michal, Can you please clarify a couple of
>>
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 wrote:
>> >>>
>> >>> From a release perspective
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
> #openstack-infra or #
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
>
> On Tue, May 16, 2017
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 also one of the concerns
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 also one of the concerns
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 concerns I raised
>>> when
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 features more or less re
On 15 May 2017 at 11:47, Sean Dague 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 features more or less requi
ks,
> Dims
>
> On Mon, May 15, 2017 at 1: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 features more or less requires readily-availabl
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 tha
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
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 software, when I see 'new project X'
>>> that does
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)
Unsubscribe
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 ou
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 currently have moderators
>>
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
>> wrote:
>>
>> Does someone care about Ubuntu?
>
> Yes, we do. We ar
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 fa
ated deployment
> should specify a new tag to distinguish it from the old tag so that roll
> forwards/roll backs work atomically and as designed. Otherwise, roll back can
> actually break or roll forward wont actually grab newer images.
>
> Thanks,
> Kevin
>
> _
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 feedback
ware
> installed 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
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:
>> >> On Tue, Apr 18, 2017 at 9:57 AM, Doug Hellmann
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 -0700:
>> > > My dear Kollegues,
>> > >
>> > >
Our issue is a bit complex tho. Dockerhub-pushed images are less
affected by version of our code than versions of everyone else's code.
On 18 April 2017 at 07:36, Flavio Percoco wrote:
> On 13/04/17 13:48 +1200, Steve Baker wrote:
>>
>> On Thu, Apr 13, 2017 at 10:59 AM
So, while I agree that everyone should use images built locally, I
also see what is value of downloading dockerhub-hosted images (besides
speed). Images at dockerhub passed our gates and are CI tested. Which
means quality of these images is ensured by our CI. Not everyone can
afford to have CI/CD s
Thanks sdake!
I added this topic to next meeting agenda. Way I see it it might not
be any more load on core reviewer as answering questions and reviewing
is part of our job already. However having some "trusted" person to
ask can mean a lot to new reviewer as it will lower this fear of being
asham
1 - 100 of 256 matches
Mail list logo
