On Thu, Aug 4, 2016 at 4:26 PM, Antoni Segura Puimedon <
toni+openstac...@midokura.com> wrote:
>
> It would be really awesome if, in true OSt and OSS spirit this work
> happened in an OpenStack repository with an open, text based format like
> SVG. This way people could contribute and review.
>
>
Hi all,
alexchadin has consistently contributed to Watcher for a while. He is also very
active on IRC. Based on his contribution (e.g: continuously-optimization
blueprint) and expertise which adds concrete value to Watcher, I'd like to
promote alexchadin to the core team.
According to the Open
Alexander Chadin did prove he knew the various moving parts of Watcher
by participating the numerous design discussions and blueprints during
the last months which makes him a precious asset for our team.
So that's a definite +1 for me as well.
On 04/08/2016 09:11, Jean-Émile DARTOIS wrote:
> Hi
Morgan Fainberg wrote:
> Based upon my personal time demands among a number of other reasons I
> will be stepping down from the Technical Committee. This is planned to
> take effect with the next TC election so that my seat will be up to be
> filled at that time.
>
> For those who elected me in, t
Devdatta Kulkarni wrote:
> As current PTL of one of the projects that has the team:single-vendor tag,
> I have following thoughts/questions on this issue.
In preamble I'd like to reiterate that the proposal is not on the table
at this stage -- this is just a discussion to see whether it would be a
On 08/01/2016 09:39 AM, Thierry Carrez wrote:
> But if a project is persistently single-vendor after some time and
> nobody seems interested to join it, the technical value of that project
> being "in" OpenStack rather than a separate project in the OpenStack
> ecosystem of projects is limited. It'
Hi,
I would like to put for discussion adding new driver to Magnum. We would
like to propose opensuse with kubernetes as driver. I did some initial
work in bug
https://launchpad.net/bugs/1600197
and changes
https://review.openstack.org/339480
https://review.openstack.org/349994
I've got also
On 08/02/2016 09:36 PM, Christian Schwede wrote:
Hello everyone,
thanks Christian,
I'd like to improve the Swift deployments done by TripleO. There are a
few problems today when deployed with the current defaults:
1. Adding new nodes (or replacing existing nodes) is not possible,
because the
Hi Chris,
Yes we used qcow image. However I still have something not clear. What I know
is that:
- disk_available_least = free_disk - disk_over_commit
- disk_over_commit = int(virt_size) - physical_disk_size
Before launching:
- free_disk = 1025
- disk_available_least = 1016
If we use the norm
On 1 August 2016 at 18:14, Adrian Otto wrote:
> I am struggling to understand why we would want to remove projects from
> our big tent at all, as long as they are being actively developed under the
> principles of "four opens". It seems to me that working to disqualify such
> projects sends an al
On Tue, 2 Aug 2016 at 16:54 Andrey Pavlov wrote:
> James, thank you for your answer.
>
No problem.
I'll file bug to glance - but in current releases glance-charm have to
> do it himself, right?
>
We should be able to add the required bits using an Ubuntu SRU - lets raise
the bug and see exactl
Hi Andrey
On Wed, 3 Aug 2016 at 14:35 Andrey Pavlov wrote:
> Instead of adding one more relation to glance, I can relate my charm to
> new relation 'cinder-volume-service'
>
almost
>
> So there is no more changes in the glance charm.
> And additional in my charm will be -
>
> metadata.yaml -
+1. Tom's reviews and guidance are helpful
and spot-on.
-Ramana
On Thursday, August 4, 2016 7:52 AM, Zhongjun (A)
wrote:
> Subject: Re: [openstack-dev] [Manila] Nominate Tom Barron for core reviewer
> team
>
>
>
> +1 Tom will be a great addition to the core team.
>
>
>
>
>
>
> 发件人 : D
For those starting work on the OSIC cluster, I was having some trouble
installing the F5 VPN browser plugin, not to mention it's no good if
wanting to access the cluster remotely.
In the spirit of Kolla here's a Dockerfile I knocked up to run the VPN
client in a container: https://github.com/b
Yeah, Tom consists of experience. +1
On Thu, Aug 4, 2016 at 12:35 PM, Ramana Raja wrote:
> +1. Tom's reviews and guidance are helpful
> and spot-on.
>
> -Ramana
>
> On Thursday, August 4, 2016 7:52 AM, Zhongjun (A)
> wrote:
> > Subject: Re: [openstack-dev] [Manila] Nominate Tom Barron for core
On 04.08.16 10:27, Giulio Fidente wrote:
> On 08/02/2016 09:36 PM, Christian Schwede wrote:
>> Hello everyone,
>
> thanks Christian,
>
>> I'd like to improve the Swift deployments done by TripleO. There are a
>> few problems today when deployed with the current defaults:
>>
>> 1. Adding new nodes
On 07/31/2016 05:59 PM, Fox, Kevin M wrote:
> This sounds good to me.
>
> What about making it iterative but with a delayed start. Something like:
>
> There is a grace period of 1 year for projects that newly join the big tent.
> After which, the following criteria will be evaluated to keep a pr
Hi all,
I'm running on Kilo (by customer demands) and I have a problem where I get
random failures while deploying a stack, the stack is a series of DB
instances, each with their own volume. I can reproduce it in pretty much
every run, usually in a different instance each time.
The problem is that
On 08/03/2016 08:54 PM, Andrew Laski wrote:
> I've brought some of these thoughts up a few times in conversations
> where the Nova team is trying to decide if a particular change warrants
> a microversion. I'm sure I've annoyed some people by this point because
> it wasn't germane to those discussi
Thomas Goirand wrote:
> On 08/01/2016 09:39 AM, Thierry Carrez wrote:
>> But if a project is persistently single-vendor after some time and
>> nobody seems interested to join it, the technical value of that project
>> being "in" OpenStack rather than a separate project in the OpenStack
>> ecosystem
On 2016-08-03 19:08:22 -0500 (-0500), Matt Riedemann wrote:
> On 8/3/2016 6:34 PM, Saju M wrote:
> > I want to clone deleted icehouse branch of cinder. I know that,
> > we can't clone it directly. Are we keeping the history of the
> > last commit id of deleted stable branches. Please share the last
On 2016-08-04 01:27:23 +0100 (+0100), Kiall Mac Innes wrote:
> Without wanting to diverge too much from the topic at hand, I believe this
> is why those of us who only occasionally want to look at post job output
> usually just give up! Keeping this in your head for the once every few
> months it's
On Thu, Aug 4, 2016, at 08:20 AM, Sean Dague wrote:
> On 08/03/2016 08:54 PM, Andrew Laski wrote:
> > I've brought some of these thoughts up a few times in conversations
> > where the Nova team is trying to decide if a particular change warrants
> > a microversion. I'm sure I've annoyed some peop
Excerpts from Kiall Mac Innes's message of 2016-08-04 01:27:23 +0100:
> On 18/07/16 20:14, Jeremy Stanley wrote:
> > Note that this will only be true if the change's parent commit in
> > Gerrit was the branch tip at the time it landed. Otherwise (and
> > quite frequently in fact) you will need to i
On Thu, Aug 04, 2016 at 09:24:15AM -0400, Doug Hellmann wrote:
> Excerpts from Kiall Mac Innes's message of 2016-08-04 01:27:23 +0100:
> > On 18/07/16 20:14, Jeremy Stanley wrote:
> > > Note that this will only be true if the change's parent commit in
> > > Gerrit was the branch tip at the time it
On 08/04/2016 01:26 PM, Christian Schwede wrote:
On 04.08.16 10:27, Giulio Fidente wrote:
On 08/02/2016 09:36 PM, Christian Schwede wrote:
Hello everyone,
thanks Christian,
I'd like to improve the Swift deployments done by TripleO. There are a
few problems today when deployed with the curre
On 2016-08-04 09:36:18 -0400 (-0400), Jim Rollenhagen wrote:
[...]
> Nice! FWIW, it's also documented here:
> http://docs.openstack.org/infra/manual/developers.html#automated-testing
I just proposed a note clarifying the situation with URLs for merge
commits too, since that seems to have been prev
On 08/04/2016 02:42 AM, Tuan Luong wrote:
Hi Chris,
Yes we used qcow image. However I still have something not clear. What I know
is that:
- disk_available_least = free_disk - disk_over_commit
- disk_over_commit = int(virt_size) - physical_disk_size
Before launching:
- free_disk = 1025
- disk
I have zero say here, but just want to say Tom is always a great guy to
have around and knows his stuff. +1 from me that he should be core.
On Wed, Aug 03, 2016 at 02:42:04PM -0400, Ben Swartzlander wrote:
> Tom (tbarron on IRC) has been working on OpenStack (both cinder and
> manila) for more tha
On Wed, Aug 03, 2016 at 07:47:37PM -0400, Jay Pipes wrote:
> Hi Novas and anyone interested in how to represent capabilities in a
> consistent fashion.
>
> I spent an hour creating a new os-capabilities Python library this evening:
>
> http://github.com/jaypipes/os-capabilities
>
> Please see th
On 08/04/2016 10:31 AM, Jim Rollenhagen wrote:
On Wed, Aug 03, 2016 at 07:47:37PM -0400, Jay Pipes wrote:
Hi Novas and anyone interested in how to represent capabilities in a
consistent fashion.
I spent an hour creating a new os-capabilities Python library this evening:
http://github.com/jaypi
Hello team,
During the IRC meeting on August 3 [1], the group agreed to have a face-to-face
meeting on August 18 & 19 in Silicon Valley to discuss various topics and set
up schedule for a potential demo in OpenStack Summit in Barcelona.
The meeting logistics is available at [2], and tentative a
Hi Chris,
Actually, the system does not belong to us therefore we only had the log file.
But it seems reasonable that besides the size of ephemeral diisk in _base, we
also have the image of vm downloaded from Glance that consumes the disk
capacity. That can make the strange value of disk_over_c
+1
On 8/3/16, 5:36 PM, "Thomas Goirand" wrote:
On 08/03/2016 12:19 PM, Rob Cresswell wrote:
> Hi all,
>
> Angular 1.5.8 is now updated in its XStatic
> repo: https://github.com/openstack/xstatic-angular
>
> I've done some manual testing of the angular content and fo
Hi all,
after 6 months of Glare v1 API development we have decided to continue our
work in a separate project in the "openstack" namespace with its own core
team (me, Kairat Kushaev, Darja Shkhray and the original creator -
Alexander Tivelkov). We want to thank Glance community for their support
du
On Aug 4, 2016, at 8:18 AM, Andrew Laski wrote:
> This gets to the point I'm trying to make. We don't guarantee old
> behavior in all cases at which point users can no longer rely on
> microversions to signal non breaking changes. And where we do guarantee
> old behavior sometimes we do it artifi
On 4 August 2016 at 16:28, Edward Leafe wrote:
> On Aug 4, 2016, at 8:18 AM, Andrew Laski wrote:
>
>> This gets to the point I'm trying to make. We don't guarantee old
>> behavior in all cases at which point users can no longer rely on
>> microversions to signal non breaking changes. And where we
I am the one who started the initiative 2.5 years ago, and was always
advocating the "let's stay in Glance" approach during numerous discussions
on "where should it belong" for all these years.
Now I believe that it is time to move forward indeed. Some things remain to
be defined (first of all the
Ok. I'll play devils advocate here and speak to the other side of this, because
you raised an interesting issue...
Ceph is outside of the tent. It provides a (mostly) api compatible
implementation of the swift api (radosgw), and it is commonly used in OpenStack
deployments.
Other OpenStack pro
On 04 Aug 2016, at 17:27, Mikhail Fedosin
mailto:mfedo...@mirantis.com>> wrote:
Hi all,
after 6 months of Glare v1 API development we have decided to continue our work
in a separate project in the "openstack" namespace with its own core team (me,
Kairat Kushaev, Darja Shkhray and the original
On Thu, Aug 4, 2016 at 4:46 PM, Alexander Tivelkov
wrote:
> I am the one who started the initiative 2.5 years ago, and was always
> advocating the "let's stay in Glance" approach during numerous discussions
> on "where should it belong" for all these years.
> Now I believe that it is time to move
Steve Dake asked: “Heidi, I received a related question from a Kolla core
reviewer. Do the project teams have input into the mascot design? If this has
already been discussed on the list, I may have missed it.”
HJ: While we haven’t discussed this on the ML, we referenced a bit in the web
page.
Excerpts from Tim Bell's message of 2016-08-04 15:55:48 +:
>
> On 04 Aug 2016, at 17:27, Mikhail Fedosin
> mailto:mfedo...@mirantis.com>> wrote:
> >
> > Hi all,
> > > > after 6 months of Glare v1 API development we have decided to continue
> > our work in a separate project in the "openstack
Michal,
The right place for drivers is the /drivers folder.
Take a look at the existing drivers as an examples. You'll also need to update
this file https://github.com/openstack/magnum/blob/master/setup.cfg#L60
and add a new entry point for the driver.
I would encourage you to hold off on this
On Thu, Aug 4, 2016, at 11:40 AM, John Garbutt wrote:
> On 4 August 2016 at 16:28, Edward Leafe wrote:
> > On Aug 4, 2016, at 8:18 AM, Andrew Laski wrote:
> >
> >> This gets to the point I'm trying to make. We don't guarantee old
> >> behavior in all cases at which point users can no longer rel
On 4 August 2016 at 14:18, Andrew Laski wrote:
> On Thu, Aug 4, 2016, at 08:20 AM, Sean Dague wrote:
>> On 08/03/2016 08:54 PM, Andrew Laski wrote:
>> > I've brought some of these thoughts up a few times in conversations
>> > where the Nova team is trying to decide if a particular change warrants
Kevin,
What do you mean by "Other OpenStack projects don't take it into
account because its not a big tent thing"? I think there is pretty
decent adoption of Ceph across the projects where it would make sense.
Also I doubt none of them would be against 3rd party Ceph gates to
those project if the
On Thu, 2016-08-04 at 10:10 +0200, Thierry Carrez wrote:
> Devdatta Kulkarni wrote:
> > As current PTL of one of the projects that has the team:single
> > -vendor tag, I have following thoughts/questions on this issue.
>
> In preamble I'd like to reiterate that the proposal is not on the
> table
On Thu, Aug 4, 2016 at 9:56 AM, Duncan Thomas wrote:
> On 1 August 2016 at 18:14, Adrian Otto wrote:
>>
>> I am struggling to understand why we would want to remove projects from
>> our big tent at all, as long as they are being actively developed under the
>> principles of "four opens". It seems
On 08/04/2016 09:28 AM, Edward Leafe wrote:
The idea that by specifying a distinct microversion would somehow guarantee
an immutable behavior, though, is simply not the case. We discussed this at
length at the midcycle regarding the dropping of the nova-network code; once
that's dropped, there w
On Thu, Aug 4, 2016 at 9:57 AM, Fox, Kevin M wrote:
> Ok. I'll play devils advocate here and speak to the other side of this,
> because you raised an interesting issue...
>
> Ceph is outside of the tent. It provides a (mostly) api compatible
> implementation of the swift api (radosgw), and it is
On 08/04/2016 11:57 AM, Fox, Kevin M wrote:
Ok. I'll play devils advocate here and speak to the other side of this, because
you raised an interesting issue...
Ceph is outside of the tent. It provides a (mostly) api compatible
implementation of the swift api (radosgw), and it is commonly used i
On Thu, Aug 4, 2016 at 5:20 PM, Clint Byrum wrote:
> Excerpts from Tim Bell's message of 2016-08-04 15:55:48 +:
>>
>> On 04 Aug 2016, at 17:27, Mikhail Fedosin
>> mailto:mfedo...@mirantis.com>> wrote:
>> >
>> > Hi all,
>> > > > after 6 months of Glare v1 API development we have decided to con
Folks,
As some of you may be familiar with, the typical agenda for the drivers
meeting [1] involves the members of the drivers team going over triaged
RFEs. Prior to the meeting we typically process confirmed and new RFEs to
see whether some of them are worth triaging (i.e. discussed during the
we
Hi Neutrinos,
I have noticed that Liberty seems to be belly up [1]. I wonder if anyone
knows anything or has the time to look into it.
Many thanks,
Armando
[1] https://review.openstack.org/#/c/349039/
__
OpenStack Developmen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hey there,
The existing openstack-ansible-security role uses security configurations from
the Security Technical Implementation Guide (STIG) and the new Red Hat
Enterprise Linux 7 STIG is due out soon. The role is currently based on the
RHEL 6 S
Greetings OpenStack community,
This week, the API-WG was visited by Deepti Ramakrishna from the Cinder
project. Deepti brought up a spec currently being implemented by the
Cinder team about resource capabilities, "New public core APIs to expose
system capabilities"[5][6]. The result of this wa
> On 04 Aug 2016, at 19:34, Erno Kuvaja wrote:
>
> On Thu, Aug 4, 2016 at 5:20 PM, Clint Byrum wrote:
>> Excerpts from Tim Bell's message of 2016-08-04 15:55:48 +:
>>>
>>> On 04 Aug 2016, at 17:27, Mikhail Fedosin
>>> mailto:mfedo...@mirantis.com>> wrote:
Hi all,
>> after 6
On Aug 4, 2016, at 12:17 PM, Chris Friesen wrote:
>> The idea that by specifying a distinct microversion would somehow guarantee
>> an immutable behavior, though, is simply not the case. We discussed this at
>> length at the midcycle regarding the dropping of the nova-network code; once
>> that's
+1. This moves yet more work towards the operators. That should be taken into
account.
Thanks,
Kevin
From: Tim Bell [tim.b...@cern.ch]
Sent: Thursday, August 04, 2016 8:55 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-
One of the cycle goals in newton was to get devstack over to neutron by
default. Neutron is used by 90+% of our users, and nova network is
deprecated, and is not long for this world.
Because devstack is used by developers as well as by out test
infrastructure, the major stumbling block was coming
On 08/04/2016 12:47 PM, John Garbutt wrote:
> On 4 August 2016 at 14:18, Andrew Laski wrote:
>> On Thu, Aug 4, 2016, at 08:20 AM, Sean Dague wrote:
>>> On 08/03/2016 08:54 PM, Andrew Laski wrote:
I've brought some of these thoughts up a few times in conversations
where the Nova team is t
Sorry, I was a bit unclear here. I meant the radosgw in particular. I've seen
multiple OpenStack projects fail to integrate with it.
The most recent example I can think of is Trove can't do database backups to it
as the namespacing is slightly different in the older radosgw versions. (I
think t
On 08/04/2016 01:36 PM, Armando M. wrote:
Hi Neutrinos,
I have noticed that Liberty seems to be belly up [1]. I wonder if anyone knows
anything or has the time to look into it.
Many thanks,
Armando
[1] https://review.openstack.org/#/c/349039/
This could be due to this backport;
https://revi
-Original Message-
From: Tim Bell
Reply: OpenStack Development Mailing List (not for usage questions)
Date: August 4, 2016 at 13:19:02
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker]
Glar
-Original Message-
From: Fox, Kevin M
Reply: OpenStack Development Mailing List (not for usage questions)
Date: August 4, 2016 at 13:40:53
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] persistently single-vendor projects
> Sorry
On 4 August 2016 at 11:45, Brian Haley wrote:
> On 08/04/2016 01:36 PM, Armando M. wrote:
>
>> Hi Neutrinos,
>>
>> I have noticed that Liberty seems to be belly up [1]. I wonder if anyone
>> knows
>> anything or has the time to look into it.
>>
>> Many thanks,
>> Armando
>>
>> [1] https://review.
On Thu, Aug 4, 2016 at 7:13 PM, Tim Bell wrote:
>
>> On 04 Aug 2016, at 19:34, Erno Kuvaja wrote:
>>
>> On Thu, Aug 4, 2016 at 5:20 PM, Clint Byrum wrote:
>>> Excerpts from Tim Bell's message of 2016-08-04 15:55:48 +:
On 04 Aug 2016, at 17:27, Mikhail Fedosin
mailto:mfedo...@
Nope. The incompatibility was for things that never were in radosgw, not things
that regressed over time. tmpurls differences and the namespacing things were
there since the beginning first introduced.
At the last summit, I started with the DefCore folks and worked backwards until
someone said,
Yeah, I wasn't thinking when I +2'ed that. There are two use cases for the
pinger, one for ensuring continuous connectivity and one for eventual
connectivity.
I think the revert is okay for a quick fix, but we really need a new
argument to the pinger for strictness to decide which behavior the tes
We are jubilant to announce the release of:
glance_store 0.16.0: OpenStack Image Service Store Library
This release is part of the newton release series.
With source available at:
http://git.openstack.org/cgit/openstack/glance_store
With package available at:
https://pypi.python.org/p
On 08/04/2016 12:04 PM, Kevin Benton wrote:
Yeah, I wasn't thinking when I +2'ed that. There are two use cases for
the pinger, one for ensuring continuous connectivity and one for
eventual connectivity.
I think the revert is okay for a quick fix, but we really need a new
argument to the pinger f
I disagree. I see glare as a superset of the needs of the image api and one
feature I need thats image related was specifically shot down as "the artefact
api will solve that".
You have all the same needs to version/catalog/store images. They are not more
special then a versioned/cataloged/stor
On 08/04/2016 03:16 PM, Rick Jones wrote:
On 08/04/2016 12:04 PM, Kevin Benton wrote:
Yeah, I wasn't thinking when I +2'ed that. There are two use cases for
the pinger, one for ensuring continuous connectivity and one for
eventual connectivity.
I think the revert is okay for a quick fix, but we
On 08/04/2016 03:02 PM, Fox, Kevin M wrote:
Nope. The incompatibility was for things that never were in radosgw, not things
that regressed over time. tmpurls differences and the namespacing things were
there since the beginning first introduced.
At the last summit, I started with the DefCore f
Hi all,
I'd like to abandon any ironic-specs reviews that haven't had any updates in 6
months or more. This works out to about 27 patches. The primary reason for this
is to get items out of the review queue that are old and stale.
I'll be performing this action next week unless there's objectio
On 08/04/2016 03:25 PM, Brian Haley wrote:
On 08/04/2016 03:16 PM, Rick Jones wrote:
On 08/04/2016 12:04 PM, Kevin Benton wrote:
Yeah, I wasn't thinking when I +2'ed that. There are two use cases for
the pinger, one for ensuring continuous connectivity and one for
eventual connectivity.
I thin
The problem is, OpenStack is a very fractured landscape. It takes significant
amounts of time for an operator to deploy "one more service".
So, I spent a while deploying Trove, got it 90% working, then discovered Trove
didn't work with RadosGW. RadosGW was a done deal long ago, and couldn't be
I get that. I don't blame Mirantis for that either. Thats a really difficult
place to be in.
This is the kind of silo disconnect I've been talking about though, where users
of a project have real concrete needs, and the project doesn't listen as they
think the current solution is "good enough"
On Aug 4, 2016, at 12:43 PM, Fox, Kevin M
mailto:kevin@pnnl.gov>> wrote:
The problem is, OpenStack is a very fractured landscape. It takes significant
amounts of time for an operator to deploy "one more service".
So, I spent a while deploying Trove, got it 90% working, then discovered Trov
That's fine, I might have an idea who have been saying so, but that
statement has never been the consensus even among the Glance core
team. In fct you would be well aware of this if you did follow the
pretty colorful discussion around glance spec.
We also have not had any intention to provide vers
Awesome. Thanks for letting me know. :) This does raise it back up on my
priority list a bit, as i know its more likely to work now with less effort.
Thanks,
Kevin
From: Jay Faulkner [j...@jvf.cc]
Sent: Thursday, August 04, 2016 12:52 PM
To: OpenStack Development
On 08/04/2016 01:17 PM, Chris Friesen wrote:
On 08/04/2016 09:28 AM, Edward Leafe wrote:
The idea that by specifying a distinct microversion would somehow
guarantee
an immutable behavior, though, is simply not the case. We discussed
this at
length at the midcycle regarding the dropping of the n
On 08/04/2016 01:52 PM, Jay Faulkner wrote:
Ironic does have radosgw support, and it's documented here:
http://docs.openstack.org/developer/ironic/deploy/radosgw.html -- clearly it's
not "first class" as we don't validate it in CI like we do with swift, but the
code exists and I believe we have
Yep. Some tests are making sure there are no packets lost. Some are making
sure that stuff starts working eventually.
On Aug 4, 2016 12:28, "Brian Haley" wrote:
> On 08/04/2016 03:16 PM, Rick Jones wrote:
>
>> On 08/04/2016 12:04 PM, Kevin Benton wrote:
>>
>>> Yeah, I wasn't thinking when I +2'e
On 08/04/2016 01:39 PM, Kevin Benton wrote:
Yep. Some tests are making sure there are no packets lost. Some are
making sure that stuff starts working eventually.
Not to be pedantic, but what sort of requirement exists that no packets
be lost?
rick
__
Hitless restart logic in the agent.
On Aug 4, 2016 14:07, "Rick Jones" wrote:
> On 08/04/2016 01:39 PM, Kevin Benton wrote:
>
>> Yep. Some tests are making sure there are no packets lost. Some are
>> making sure that stuff starts working eventually.
>>
>
> Not to be pedantic, but what sort of re
From: Heidi Joy Tretheway
mailto:heidi...@openstack.org>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, August 4, 2016 at 9:13 AM
To: "OpenStack Development Mailing List (not for usage questions)"
mailto:open
Excerpts from Fox, Kevin M's message of 2016-08-04 19:20:43 +:
> I disagree. I see glare as a superset of the needs of the image api and one
> feature I need thats image related was specifically shot down as "the
> artefact api will solve that".
>
> You have all the same needs to version/cat
Last week I started some prototype work on what could be a new way to
install the Undercloud. The driving force behind this was some of the
recent "composable services" work we've done in TripleO so initially I
called in composable undercloud. There is an etherpad here with links
to some of the pat
On 08/04/2016 05:30 PM, Clint Byrum wrote:
Excerpts from Fox, Kevin M's message of 2016-08-04 19:20:43 +:
I disagree. I see glare as a superset of the needs of the image api and one feature I
need thats image related was specifically shot down as "the artefact api will solve
that".
You ha
Excerpts from Jay Pipes's message of 2016-08-04 18:14:46 -0400:
> On 08/04/2016 05:30 PM, Clint Byrum wrote:
> > Excerpts from Fox, Kevin M's message of 2016-08-04 19:20:43 +:
> >> I disagree. I see glare as a superset of the needs of the image api and
> >> one feature I need thats image relat
On 08/04/2016 06:40 PM, Clint Byrum wrote:
Excerpts from Jay Pipes's message of 2016-08-04 18:14:46 -0400:
On 08/04/2016 05:30 PM, Clint Byrum wrote:
Excerpts from Fox, Kevin M's message of 2016-08-04 19:20:43 +:
I disagree. I see glare as a superset of the needs of the image api and one f
On 4 August 2016 at 11:35, Sean Dague wrote:
> One of the cycle goals in newton was to get devstack over to neutron by
> default. Neutron is used by 90+% of our users, and nova network is
> deprecated, and is not long for this world.
>
> Because devstack is used by developers as well as by out te
Hi,
I'm currently working by iteration to get a new upstream job that test
upgrades and update.
Until now, I'm doing baby steps. I bootstrapped the work to upgrade
undercloud, see https> ://review.openstack.org/#/c/346995/ for details
(it's almost working hitting a packaging issue now).
Now I am
I think all the problem is caused by the definition "official OpenStack
project" for one big-tent project.
I understand that each OpenStack vendor wants some differentiation in their
solution, while also would
like to collaborate with common core projects.
If we replace the title "official Open
I disagree as well. From users perspective, Glare looks like a Glance API v3.
Having Glare and Glance as two independent services is quite confusing. I guess
you would get a lot of questions like "what is the difference between Glance
and Glare?", "does Glance depends on Glare?", "is Glare a bac
1) Roll Call
2) Daisy Call Graph doc and CI doc
3) Git tag sync between Kolla code and images
4) Getting backend type and its use cases
5) Image 2.0.3 login problem
6) Daisy4nfv related status update
B.R.,
Zhijiang
__
OpenS
Forgot to mentioned , the channel has been changed from #daisycloud to
#openstack-meeting
B.R.,
Zhijiang
发件人: HuZhiJiang180967/user/zte_ltd
收件人: hu.zhiji...@zte.com.cn, huzhiji...@gmail.com,
lu.yao...@zte.com.cn, zhou...@zte.com.cn, sun.jin...@zte.com.cn,
kong.w...@zte.com.c
> On 05 Aug 2016, at 01:02, Jay Pipes wrote:
>
> On 08/04/2016 06:40 PM, Clint Byrum wrote:
>> Excerpts from Jay Pipes's message of 2016-08-04 18:14:46 -0400:
>>> On 08/04/2016 05:30 PM, Clint Byrum wrote:
Excerpts from Fox, Kevin M's message of 2016-08-04 19:20:43 +:
> I disagree.
1 - 100 of 103 matches
Mail list logo