On June 2, 2015 2:57:29 PM EDT, Andrew Woodward awoodw...@mirantis.com wrote:
Updated
Sean, I see that there is no spec linked in gerrit or the BP do we have
one?
On Tue, Jun 2, 2015 at 11:07 AM Sean M. Collins s...@coreitpro.com
wrote:
Can we update the vxlan bp to target it to 7.0? The
Hi all,
I'm running IceHouse (build using Fuel 5.1.1) on Ubuntu where dnsmask
version 2.59-4.
I have a very basic network layout where i have a private net which has 2
subnets
2fb7de9d-d6df-481f-acca-2f7860cffa60 | private-net
| e79c3477-d3e5-471c-a728-8d881cf31bee
On Jun 5, 2015 4:36 AM, Sean Dague s...@dague.net wrote:
On 06/05/2015 01:28 AM, Adrian Otto wrote:
On Jun 4, 2015, at 11:03 AM, Devananda van der Veen
devananda@gmail.com mailto:devananda@gmail.com wrote:
On Jun 4, 2015 12:00 AM, Xu, Hejie hejie...@intel.com
Thanks All Magnum Guys, It is my honor to work with all of you to make
Magnum Better.
:) Thanks Stdake.
Best Wishes,
Kai Qiang Wu (吴开强 Kennan）
IBM China System and Technology Lab, Beijing
E-mail:
On 6/7/15, 03:41, Thomas Goirand z...@debian.org wrote:
On 05/29/2015 09:23 PM, Ian Cordasco wrote:
Could you explain this as well? Do you mean fragmentation between what
distros are offering? In other words, Ubuntu is packaging Kilo @ SHA1
and
RHEL is at SHA2. I'm not entirely certain that's
On 5 June 2015 at 01:29, Itsuro ODA o...@valinux.co.jp wrote:
Hi,
After trying to reproduce this, I'm suspecting that the issue is actually
on the server side from failing to drain the agent report state queue in
time.
I have seen before.
I thought the senario at that time as follows.
On 6/7/15, 03:47, Thomas Goirand z...@debian.org wrote:
On 05/29/2015 09:36 PM, Dave Walker wrote:
Responses inline.
On 29 May 2015 6:15 pm, Haïkel hgue...@fedoraproject.org
mailto:hgue...@fedoraproject.org wrote:
2015-05-29 15:41 GMT+02:00 Thierry Carrez thie...@openstack.org
Salvatore,
By 'fairness' I meant chances for state report greenthread to get the
control. In DHCP case, each network processed by a separate greenthread, so
the more greenthreads agent has, the less chances that report state
greenthread will be able to report in time.
Thanks,
Eugene.
On Sun,
No, I think greenthread itself don't do anything special, it's just when
there are too many threads, state_report thread can't get the control for
too long, since there is no prioritization of greenthreads.
Eugene.
On Sun, Jun 7, 2015 at 8:24 PM, Kevin Benton blak...@gmail.com wrote:
I
I understand now. So the issue is that the report_state greenthread is just
blocking and yielding whenever it tries to actually send a message?
On Sun, Jun 7, 2015 at 8:10 PM, Eugene Nikanorov enikano...@mirantis.com
wrote:
Salvatore,
By 'fairness' I meant chances for state report greenthread
Hello Asha,
The AES type key should require an application/octet-stream Accept header to
retrieve the secret as it is a binary type. Please replace 'text/plain' with
'application/octet-stream' in your curl calls below.
Thanks,
John
From: Asha Seshagiri
Thanks John for your response.
I am aware that application/octet-stream works for the retrieval of secret
.
We are utilizing the key generated from Barbican in our AES encryption
algorithm . Hence we wanted the response in text/plain format from
Barbican since AES encryption algorithm would need
It wasn't using zuul at all. It's a super short bash script that just
clones the 3rd party repo, checks out the patch, and then runs 'tox
-epy27'.
I misspoke in my previous email, because it was setup to use
test-requirements.txt to pull in neutron. Did I understand your other email
that implied
On 6 June 2015 at 13:08, Ian Cordasco ian.corda...@rackspace.com wrote:
On 6/5/15, 02:55, Flavio Percoco fla...@redhat.com wrote:
On 04/06/15 11:46 -0600, Chris Friesen wrote:
On 06/04/2015 03:01 AM, Flavio Percoco wrote:
On 03/06/15 16:46 -0600, Chris Friesen wrote:
We recently ran into an
On 8 June 2015 at 10:14, Alan Pevec ape...@gmail.com wrote:
2015-06-06 19:08 GMT+02:00 Ian Cordasco ian.corda...@rackspace.com:
Not exactly. PBR/OpenStack follow SemVer and 2015.1.0.38 isn't valid
SemVer (http://semver.org/)
Right, so semver compatible versioning on stable/kilo would be
2015-06-06 19:08 GMT+02:00 Ian Cordasco ian.corda...@rackspace.com:
Not exactly. PBR/OpenStack follow SemVer and 2015.1.0.38 isn't valid
SemVer (http://semver.org/)
Right, so semver compatible versioning on stable/kilo would be 2015.1.N
but PBR doesn't support that.
If we want to be pedantic
On 4 June 2015 at 21:06, Ihar Hrachyshka ihrac...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/03/2015 11:08 PM, Robert Collins wrote:
...
One question that this raises, and this is why I wrote the email:
is there any need to support this at all:- can we say that
Robert Collins wrote:
On 6 June 2015 at 08:53, Joshua Harlowharlo...@outlook.com wrote:
Hopefully it's somewhat obvious to folks that altering the PBR version
schema (yet again), breaks *all the people* from using it in a reliable
manner, and if the goal of PBR is to bring reasonableness, well
and *Plan D* would be to start doing automatic per-project
micro-versions on each commit: e.g. 2015.1.N where N is increased on
each commit.
How do you gpg sign these tags? I hope the solution isn't to store a key
in infra without a passphrase.
Plan D doesn't include git tags, 2015.1.N
On 8 June 2015 at 10:45, Robert Collins robe...@robertcollins.net wrote:
You'll also note that according to PEP 440, (as Jeremy pointed out) .postN
is meant for non-code changes. If we want to be pedantic about the version
numbers generated by PBR (at the gate, in tox, etc.), it should be
On 6/1/15, 7:38 AM, Jeff Peeler jpee...@redhat.com wrote:
On Sat, May 30, 2015 at 03:00:04AM +, Steven Dake (stdake) wrote:
Hey Folks,
I noticed the Kolla functional gate is failing sporadically.
It seems that sometimes an image doesn¹t build.
On 05/29/2015 07:14 PM, Haïkel wrote:
2015-05-29 15:41 GMT+02:00 Thierry Carrez thie...@openstack.org:
Hi everyone,
TL;DR:
- We propose to stop tagging coordinated point releases (like 2015.1.1)
- We continue maintaining stable branches as a trusted source of stable
updates for all projects
On 05/29/2015 09:23 PM, Ian Cordasco wrote:
Could you explain this as well? Do you mean fragmentation between what
distros are offering? In other words, Ubuntu is packaging Kilo @ SHA1 and
RHEL is at SHA2. I'm not entirely certain that's a bad thing. That seems
to give the packagers more
On 05/29/2015 09:36 PM, Dave Walker wrote:
Responses inline.
On 29 May 2015 6:15 pm, Haïkel hgue...@fedoraproject.org
mailto:hgue...@fedoraproject.org wrote:
2015-05-29 15:41 GMT+02:00 Thierry Carrez thie...@openstack.org
mailto:thie...@openstack.org:
Hi everyone,
TL;DR:
- We
On 06/01/2015 10:40 AM, Ihar Hrachyshka wrote:
No time synchronization between projects, no freeze dates, nothing, just
SemVer compatible version bumps e.g. once per two weeks or month.
Would it fix your problem?
How do you check if project X in version n works with project Y in
version m,
On 06/01/2015 05:32 PM, Alan Pevec wrote:
*Plan C* would be to just let projects tag stable point releases from
time to time. That would solve all the original stated problems. And
that would solve objections 2 and 3, which I think are the most valid ones.
and *Plan D* would be to start
Hi Vikram,
Agree with what you stated. Additional use case can be Tap as a Service to
allow filtering of the mirrored packets.
BR,
Irena
On Fri, Jun 5, 2015 at 11:47 AM, Vikram Choudhary
vikram.choudh...@huawei.com wrote:
Dear All,
There are multiple proposal floating around flow
On 6 June 2015 at 08:53, Joshua Harlow harlo...@outlook.com wrote:
Hopefully it's somewhat obvious to folks that altering the PBR version
schema (yet again), breaks *all the people* from using it in a reliable
manner, and if the goal of PBR is to bring reasonableness, well changing it
in a way
On 7 June 2015 at 05:08, Ian Cordasco ian.corda...@rackspace.com wrote:
On 6/6/15, 02:03, Alan Pevec ape...@gmail.com wrote:
2015-06-05 15:16 GMT+02:00 Jeremy Stanley fu...@yuggoth.org:
On 2015-06-05 14:56:30 +0200 (+0200), Thierry Carrez wrote:
[...]
I was wondering if we could switch to
How do you check if project X in version n works with project Y in
version m, using this non-scheduled point release free for all model?
That was an illusion of point releases, as Thierry said there wasn't
significantly more testing and I don't remember any testing reports
during stable freeze
On 5 June 2015 at 04:54, Kevin Benton blak...@gmail.com wrote:
+1. I had setup a CI for a third-party plugin and the easiest thing to do to
make sure it was running tests with the latest copy of the corresponding
neutron branch was to put the git URL in requirements.txt.
We wanted to always
On 8 June 2015 at 11:16, Kevin Benton blak...@gmail.com wrote:
It wasn't using zuul at all. It's a super short bash script that just clones
the 3rd party repo, checks out the patch, and then runs 'tox -epy27'.
I misspoke in my previous email, because it was setup to use
test-requirements.txt
2015-06-04 23:27 GMT+08:00 Lucas Alvares Gomes lucasago...@gmail.com:
Hi Ruby,
Thanks for starting this thread, just like you I've been always
confused about when and when not bump the microversioning of the API.
Backwards compatible API adds with no user signaling is a fallacy
because
Hi Cinder folks,
Can any cores in cinder take a review of this patch
https://review.openstack.org/#/c/186327/?
I am have already received +1's from Jay, Patrick, Mitsuhiro and Avishay.
If you have comments, please feedback to me. If not, can any of you
approved this spec?
Thank you so much.
34 matches
Mail list logo
