Ack, thank you for the feedback. I will put it in WIP until we reach Kilo.
We will track any new bugfixes or changes so the refactor is ready
for early kilo,
then after this is merged I will tackle a second refactor to extract Ipset
out as we planned, into a new driver which extends IptablesFi
Hi Kevin,
Typically we noticed that the underlay switches maintained a table like this:
VLAN IDMAC Address Learned-Interface
In the physical underlay, with the current architecture if we enable VLAN, the
same DVR Unique
MAC will appear on different VLANs as the packets get DVR Rout
Hi Congress Team,
Has anyone tried writing policies with Builtin operators like gt(), lt().
I see the class CongressBuiltinCategoryMap() to add/update the start map
defined in the same file.
However, these classes are never referred in any part of the code. So
clearly, I can assume Congress does
Hi, shihanzhang:
Thanks for bringing this up, again.
As I said before, this blueprint will solve the problems that the
'hard-coded' rules related to the default security group we are
suffering from, which I do think will give Fawad an anser. So, I
really hope that we can particapate all together
Though Code reviews for vendor code takes more time, I feel it must go through
Core reviews.
Since, Vendors might submit the code that is working fine within their third
party CI environment but the Code review make it more efficient with respect to
the coding standards followed in the communit
-Original Message-
From: Dean Troyer
Reply: OpenStack Development Mailing List (not for usage questions)
>
Date: September 17, 2014 at 21:21:47
To: OpenStack Development Mailing List (not for usage questions)
>
Subject: Re: [openstack-dev] PostgreSQL jobs slow in the gate
> >
> > Clark
Hi Fuelers,
as we have mini-summit in CA and majority of leads is busy with it, let's
cancel the meeting tomorrow.
We might want to cancel the meeting on 25th as well.
Thanks,
--
Mike Scherbakov
#mihgen
___
OpenStack-dev mailing list
OpenStack-dev@lists
+1
> I don't think it will be seen as punitive. Vendors can write their plugins
> or drivers when a deal occurs and they do not need to submit code to
> community and wait for approving.
Being a third party vendor, i do not think this is punitive. OpenStack has
already established through proces
A shared network means other tenants may create ports on that network (i.e.
the VMs will share an L2 broadcast domain).
On Wed, Sep 17, 2014 at 6:58 PM, Zirui Zhuang wrote:
> Hello everyone.
>
> As far as I'm concerned, a neutron network is actually a pure virtual
> concept layer which holds cou
Hi Salvatore,
Thanks for your hyperlink. It's really a monster thread that contains
everyone's opinion. But it's useful to me.
So, Before we focus on the Neutron core itself, we should firstly release a
suite standardized APIs and a framework for vendors' codes.
About this job, I think most of it i
>
> Clark Boylan Wrotr :
>
>> It appears that keystone eventlet is the source of the slowness in this
>> job. With keystone eventlet all of the devstack jobs are slower and with
>> keystone wsgi all of the jobs are quicker. Probably need to collect a
>> bit more data but this doesn't look good for
Clark Boylan Wrotr :
> On Wed, Sep 17, 2014, at 06:48 PM, Clark Boylan wrote:
> > On Wed, Sep 17, 2014, at 06:37 PM, Matt Riedemann wrote:
> > >
> > >
> > > On 9/17/2014 7:59 PM, Ian Wienand wrote:
> > > > On 09/18/2014 09:49 AM, Clark Boylan wrote:
> > > >> Recent sampling of test run times show
On 18 September 2014 14:42, Monty Taylor wrote:
> On 09/17/2014 03:09 PM, Doug Hellmann wrote:
>> 2. We could allow pbr to consider dev versions of pre-releases. This
>> might, for example, lead to a version number 1.3.0.0a3.dev10.
>>
>> This is apparently not supported by semver, but I don’t car
I just release python-swiftclient 2.3.0
In addition to some smaller changes and bugfixes, the biggest changes are the
support for Keystone v3 and a refactoring that allows for better testing and
extensibility of the functionality exposed by the CLI.
https://pypi.python.org/pypi/python-swiftclie
On Wed, Sep 17, 2014, at 06:48 PM, Clark Boylan wrote:
> On Wed, Sep 17, 2014, at 06:37 PM, Matt Riedemann wrote:
> >
> >
> > On 9/17/2014 7:59 PM, Ian Wienand wrote:
> > > On 09/18/2014 09:49 AM, Clark Boylan wrote:
> > >> Recent sampling of test run times shows that our tempest jobs run
> > >>
On Sep 17, 2014, at 8:43 PM, Jay Faulkner wrote:
> Comments inline.
>
>> -Original Message-
>> From: Monty Taylor [mailto:mord...@inaugust.com]
>> Sent: Wednesday, September 17, 2014 7:34 PM
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] Log Rationalization --
Comments inline.
> -Original Message-
> From: Monty Taylor [mailto:mord...@inaugust.com]
> Sent: Wednesday, September 17, 2014 7:34 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] Log Rationalization -- Bring it on!
>
> On 09/17/2014 04:42 PM, Rochelle.RochelleGr
Dear All,
I am getting below error while deploying all in one openstack using
Devstack Icehouse stable version.
2014-09-18 03:21:56.897 | + TENANT_ID=db7fd8d208db41ea8622be52b520d44e
2014-09-18 03:21:56.897 | + die_if_not_set 374 TENANT_ID 'Failure
retrieving TENANT_ID for demo'
2014-09-18 03:21
> On Sep 17, 2014, at 10:42 PM, Monty Taylor wrote:
>
> I'm more in favor of option 2. Semver doesn't really support _ANY_ of
> the PEP440 things we're doing - and I'm fine with that personally. The
> dev version of an alpha _is_ supported by PEP440.
>
> If we considered the logic to be:
>
> "
> On Sep 17, 2014, at 10:24 PM, Thomas Goirand wrote:
>
> On 09/18/2014 08:22 AM, Morgan Fainberg wrote:
>> I think that all of the conversation to this point has been valuable,
>> the general consensus is vendoring a library is not as desirable as
>> using it strictly as a dependency. It would
On 09/17/2014 03:09 PM, Doug Hellmann wrote:
> Earlier today we discovered a problem with the way pbr is generating
> dev version numbers for commits following tags using alpha
> pre-version suffixes [1]. Basically what’s happening is a commit
> following a tag like 1.3.0.0a3 is coming out as a 1.3
On 09/17/2014 04:42 PM, Rochelle.RochelleGrober wrote:
> TL;DR: I consider the poor state of log consistency a major
> impediment for more widespread adoption of OpenStack and would like
> to volunteer to own this cross-functional process to begin to unify
> and standardize logging messages and at
On 09/18/2014 08:22 AM, Morgan Fainberg wrote:
> I think that all of the conversation to this point has been valuable,
> the general consensus is vendoring a library is not as desirable as
> using it strictly as a dependency. It would be nice in a perfect
> world if vendoring wasn’t and issue, but
Hello everyone.
>From what I can see in current neutron implementation, a tenant may
organize its own network in following topology,
External Network <-> Tenant Router <-> Tenant Networks <-> Tenant Subnets
<-> Tenant Instances
This is a quite simple but efficient topology that should be enough
Hello everyone.
As far as I'm concerned, a neutron network is actually a pure virtual
concept layer which holds couples of subnets. Subnets are the ones connect
and provide virtualized network access, internal ip arrangement, and basic
layer-2 isolation. When using a GRE tunnel mode, the isolation
> -Original Message-
> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
> Sent: Wednesday, September 17, 2014 11:59 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [nova] are we going to remove the novaclient v3
> shell or what?
>
On Wed, Sep 17, 2014, at 06:37 PM, Matt Riedemann wrote:
>
>
> On 9/17/2014 7:59 PM, Ian Wienand wrote:
> > On 09/18/2014 09:49 AM, Clark Boylan wrote:
> >> Recent sampling of test run times shows that our tempest jobs run
> >> against clouds using PostgreSQL are significantly slower than jobs ru
On Mon, Sep 15, 2014 at 11:38 PM, Peeyush Gupta wrote:
>
> What I am interested to know is if this is a problem with precise or with
> devstack script?
>
As mentioned, we test this in the gate using Ubuntu Trusty 14.04. When we
were using Precise, we would setup access to the Ubuntu Cloud Archi
On Wed, 17 Sep 2014 04:53:28 PM Duncan Thomas wrote:
> On 16 September 2014 01:28, Nathan Kinder wrote:
> > The idea would be to leave normal tokens with a smaller validity period
> > (like the current default of an hour), but also allow one-time use
> > tokens to be requested.
>
> Cinder backup
On 9/17/2014 7:59 PM, Ian Wienand wrote:
On 09/18/2014 09:49 AM, Clark Boylan wrote:
Recent sampling of test run times shows that our tempest jobs run
against clouds using PostgreSQL are significantly slower than jobs run
against clouds using MySQL.
FYI There is a possibly relevant review ou
On Wed, 17 Sep 2014 17:42:30 +
"Day, Phil" wrote:
> I think in the hopefully not too distant future we'll be able to make
> the v1_1 client handle both V2 and V2.1 (who knows. Maybe we can even
> rename it v2) - and that's what we should do because it will prove if
> we have full compatibilit
On 09/18/2014 09:49 AM, Clark Boylan wrote:
Recent sampling of test run times shows that our tempest jobs run
against clouds using PostgreSQL are significantly slower than jobs run
against clouds using MySQL.
FYI There is a possibly relevant review out for max_connections limits
[1], although i
Same seen @
http://logs.openstack.org/80/121280/32/check/check-tempest-dsvm-postgres-full/395a05d/logs/postgres.txt.gz
Although I'm not sure if those are abnormal or not (seems likely they wouldn't
be).
Was there a postgres release?
On Sep 17, 2014, at 5:10 PM, Joe Gordon wrote:
> Postgres i
On Tue, Sep 16, 2014 at 2:58 AM, Michael Still wrote:
> Hi.
>
> Is time to start identifying (and working on) release critical bugs in
> nova before we ship RC1.
>
> My initial position is that any critical bug is release critical.
> There are currently critical bugs not targeted to rc1, but that
-Original Message-
From: Ian Cordasco
Reply: OpenStack Development Mailing List (not for usage questions)
>
Date: September 17, 2014 at 16:28:57
To: OpenStack Development Mailing List (not for usage questions)
>
Subject: Re: [openstack-dev] Please do *NOT* use "vendorized" versions of
Postgres is also logging a lot of errors:
http://logs.openstack.org/63/122263/1/check/check-tempest-dsvm-postgres-full/2f27252/logs/postgres.txt.gz
On Wed, Sep 17, 2014 at 4:49 PM, Clark Boylan wrote:
> Hello,
>
> Recent sampling of test run times shows that our tempest jobs run
> against clouds
On Thu, Sep 18, 2014 at 4:25 AM, Renat Akhmerov
wrote:
> Ok, here is what I think...
>
> I totally support the first option for its easiness in terms of
> understanding how it all should work (no need to figure out if some
> additional objects must be deleted if a workflow has been removed etc.
>
On Wed, Sep 17, 2014 at 11:57 PM, Mike Spreitzer
wrote:
> Background: Health maintenance is very important to users, and I have
> users who want to do it now and into the future. Today a Heat user can
> write a template that maintains the health of a resource R. The detection
> of a health prob
Hello,
Recent sampling of test run times shows that our tempest jobs run
against clouds using PostgreSQL are significantly slower than jobs run
against clouds using MySQL.
(check|gate)-tempest-dsvm-full has an average run time of 52.9 minutes
(stddev 5.92 minutes) over 516 runs.
(check|gate)-temp
TL;DR: I consider the poor state of log consistency a major impediment for
more widespread adoption of OpenStack and would like to volunteer to own this
cross-functional process to begin to unify and standardize logging messages and
attributes for Kilo while dealing with the most egregious issu
For reference, I proposed a review which does this for nova last
night: https://review.openstack.org/#/c/122109/
On Thu, Sep 18, 2014 at 8:42 AM, Aaron Rosen wrote:
> I agree as well. I think moving them to an unimplemented folder makes sense
> and would be helpful in reviewing if one re-proposes
On 9/17/14, 5:39 PM, "Mike Bayer" wrote:
>
>On Sep 17, 2014, at 4:31 PM, Ian Cordasco
>wrote:
>
>> Project X pins a version of requests. Alice doesn’t know anything about
>> requests and does pip install X. Until Alice takes a more active role in
>> the development of Project X and looks into re
On Thu, Sep 18, 2014 at 8:24 AM, James E. Blair wrote:
> "Sullivan, Jon Paul" writes:
>
> > I think this highlights exactly why this should be an automated
> > process. No errors in application, and no errors in interpretation of
> > what has happened.
> >
> > So the -1 from Jenkins was a react
Thanks for all your effort on Zaqar, Alej. And all the help for me when
I involved in Zaqar. I assume you will be not far away from the team and
OpenStack :)
On 18/09/14 09:50, Alejandro Cabrera wrote:
> Hey all,
>
> I am officially removing myself as a core member of the Zaqar project.
>
> Thank
On a related and slightly less problematic case is another one like this...
https://github.com/rholder/retrying/issues/11
On Sep 17, 2014, at 8:15 AM, Thomas Goirand wrote:
> Hi,
>
> I'm horrified by what I just found. I have just found out this in
> glanceclient:
>
> File "/tests/test_ssl.p
I agree as well. I think moving them to an unimplemented folder makes sense
and would be helpful in reviewing if one re-proposes a blueprint.
On Mon, Sep 15, 2014 at 7:20 AM, Russell Bryant wrote:
> On 09/15/2014 10:01 AM, Kevin Benton wrote:
> > Some of the specs had a significant amount of det
On Sep 17, 2014, at 4:31 PM, Ian Cordasco wrote:
> Project X pins a version of requests. Alice doesn’t know anything about
> requests and does pip install X. Until Alice takes a more active role in
> the development of Project X and looks into requests, she will never know
> she’s installed soft
Great question. So, some use cases, like guest agent, would like to see
something around ~20ms if the agent is needing to respond to requests from a
control surface/panel while a user clicks around. I spoke with a social media
company who was also interested in low latency just because they have
Thanks for everything Alej!
Besides your contributions to the Zaqar team you also shown to be a great
person.
I'm truly grateful that I could have you as a mentor during GSoC.
All the best :)
2014-09-17 19:14 GMT-03:00 Flavio Percoco :
> On 09/17/2014 11:50 PM, Alejandro Cabrera wrote:
> > Hey
Excerpts from Ian Cordasco's message of 2014-09-17 12:42:57 -0700:
> On 9/17/14, 1:46 PM, "Clint Byrum" wrote:
>
> >Excerpts from Davanum Srinivas's message of 2014-09-17 10:15:29 -0700:
> >> I was trying request-ifying oslo.vmware and ran into this as well:
> >> https://review.openstack.org/#/c/
"Sullivan, Jon Paul" writes:
> I think this highlights exactly why this should be an automated
> process. No errors in application, and no errors in interpretation of
> what has happened.
>
> So the -1 from Jenkins was a reaction to the comment created by adding
> the workflow -1. This is going
On 09/17/2014 11:50 PM, Alejandro Cabrera wrote:
> Hey all,
>
> I am officially removing myself as a core member of the Zaqar project.
>
> Thanks for all the good times, friends, and I wish you the best for the
> future!
Alejandro,
I think I speak for everyone when I say the project is where i
Earlier today we discovered a problem with the way pbr is generating dev
version numbers for commits following tags using alpha pre-version suffixes
[1]. Basically what’s happening is a commit following a tag like 1.3.0.0a3 is
coming out as a 1.3.0.devX version, which then appears to be older th
On Sep 17, 2014 3:48 PM, "Walter A. Boring IV" wrote:
>
> Thanks for the effort Ivan. Your interest in brick is also helping us
push forward with the idea of the agent that we've had in mind for quite
some time.
>
> For those interested, I have created an etherpad that discusses some of
the requ
Thanks guys!
Alex
On 17 September 2014 17:16, Russell Bryant wrote:
> On 09/17/2014 11:56 AM, Daniel P. Berrange wrote:
> > On Wed, Sep 17, 2014 at 04:47:06PM +0100, Alex Leonhardt wrote:
> >> hi,
> >>
> >> how does one re-open a abandoned change / pull request ? it just "timed
> >> out" and wa
Hey all,
I am officially removing myself as a core member of the Zaqar project.
Thanks for all the good times, friends, and I wish you the best for the future!
Cheers,
- Alej
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lis
Thanks for the effort Ivan. Your interest in brick is also helping us
push forward with the idea of the agent that we've had in mind for quite
some time.
For those interested, I have created an etherpad that discusses some of
the requirements and design decisions/discussion on the cinder/sto
Hi Sharan,
Sahara works with either network service installed in OpenStack. If
OpenStack uses neutron - sahara will use neutron too. If nova network is
used, Sahara supports that as well.
Thanks,
Andrew.
On Wed, Sep 17, 2014 at 1:38 PM, Sharan Kumar M wrote:
> Hi all,
>
> What is the default n
Can you clarify what you mean with the thrashing condition? MAC addresses
only need to be unique per-VLAN so I don't see how the same MAC on multiple
VLANs from the same physical port would lead to any issues.
On Wed, Sep 17, 2014 at 12:41 PM, Armando M. wrote:
> VLAN is on the radar, vxlan/gre
On Wed, Sep 17, 2014 at 6:26 PM, mar...@redhat.com
wrote:
> Hi,
>
> as part of general housekeeping on our reviews, it was discussed at last
> week's meeting [1] that we should set workflow -1 for stale reviews
> (like gerrit used to do when I were a lad).
>
> The specific criteria discussed was
On Wed, Sep 17, 2014 at 3:53 PM, Robert Collins
wrote:
> On 18 September 2014 08:01, Dean Troyer wrote:
> > Interestingly enough, the distros are doing exactly what they don't want
> us
> > to do, ie, rebuilding things to use 'their' tested version of
> dependencies
> > rather than the included
Hello magnetodb contributors,
I'm glad to nominate Charles Wang to core developers of MagnetoDB.
He is top non-core reviewer [1], implemented notifications [2] in mdb and
made a great progress with performance, stability and scalability testing
of MagnetoDB
[1] http://stackalytics.com/report/co
Hi folks, 0.7.2 has been released with the main changes - synced oslo,
updated requirements and support for security groups.
The 0.7.2 release introduced stable/icehouse incompatibility and so
we've released the 0.7.3 version with fix for it.
Thanks.
P.S. Some links:
https://launchpad.net/pytho
On 18 September 2014 08:01, Dean Troyer wrote:
> Interestingly enough, the distros are doing exactly what they don't want us
> to do, ie, rebuilding things to use 'their' tested version of dependencies
> rather than the included one...
Indeed - but the distros are solving for two specific issues:
Hi all,
What is the default networking service for Sahara? Is it Nova Network or
Neutron? I referred this page
http://docs.openstack.org/developer/sahara/userdoc/features.html#neutron-and-nova-network-support
and it says Nova Network. Is that right?
Thanks,
Sharan Kumar M
On 17/09/2014 23:12, Anita Kuno wrote:
> On 09/17/2014 04:01 PM, Maish Saidel-Keesing wrote:
>> This looks great - but I am afraid that something might be missing.
>>
>> As part of the Design summit in Atlanta there was an Ops Meetup track.
>> [1] I do not see where this fits into the current plan
Hi All,
My understanding of Zaqar is that it's like SQS. SQS uses distributed
queues, which have a few unusual properties [0]:
Message Order
Amazon SQS makes a best effort to preserve order in messages, but due to
the distributed nature of the queue, we cannot guarantee you will receive
messages
On 9/17/14, 3:11 PM, "Mike Bayer" wrote:
>
>On Sep 17, 2014, at 3:42 PM, Ian Cordasco
>wrote:
>
>>
>> Circling back to the issue of vendoring though: it’s a conscious
>>decision
>> to do this, and in the last two years there have been 2 CVEs reported
>>for
>> requests. There have been none for
On 09/17/2014 04:01 PM, Maish Saidel-Keesing wrote:
> This looks great - but I am afraid that something might be missing.
>
> As part of the Design summit in Atlanta there was an Ops Meetup track.
> [1] I do not see where this fits into the current planning process that
> has been posted.
> I woul
On Sep 17, 2014, at 3:42 PM, Ian Cordasco wrote:
>
> Circling back to the issue of vendoring though: it’s a conscious decision
> to do this, and in the last two years there have been 2 CVEs reported for
> requests. There have been none for urllib3 and none for chardet. (Frankly
> I don’t think
Interestingly enough, the distros are doing exactly what they don't want us
to do, ie, rebuilding things to use 'their' tested version of dependencies
rather than the included one...
On Wed, Sep 17, 2014 at 2:42 PM, Ian Cordasco
wrote:
>
> That aside, I’ve been mulling over how effectively the cl
This looks great - but I am afraid that something might be missing.
As part of the Design summit in Atlanta there was an Ops Meetup track.
[1] I do not see where this fits into the current planning process that
has been posted.
I would like to assume that part of the purpose of the summit is to al
On 09/16/2014 08:55 AM, Flavio Percoco wrote:
pub/sub doesn't necessarily guarantees messages delivery, it really
depends on the implementation.
As I understand it, the model for pub-sub in Zaqar is to have multiple
subscribers polling the queue with gets, and have the messages removed
from t
On 9/17/14, 1:46 PM, "Clint Byrum" wrote:
>Excerpts from Davanum Srinivas's message of 2014-09-17 10:15:29 -0700:
>> I was trying request-ifying oslo.vmware and ran into this as well:
>> https://review.openstack.org/#/c/121956/
>>
>> And we don't seem to have urllib3 in global-requirements eithe
VLAN is on the radar, vxlan/gre was done to start with.
I believe Vivek mentioned the rationale in some other thread. The gist
of it below:
In the current architecture, we use a unique DVR MAC per compute node
to forward DVR Routed traffic directly to destination compute node.
The DVR routed traf
On Tue, Sep 16, 2014 at 8:02 AM, Kurt Griffiths <
kurt.griffi...@rackspace.com> wrote:
> Right, graphing those sorts of variables has always been part of our
> test plan. What I’ve done so far was just some pilot tests, and I realize
> now that I wasn’t very clear on that point. I wanted to get a
On Sep 17, 2014, at 2:46 PM, Clint Byrum wrote:
> Excerpts from Davanum Srinivas's message of 2014-09-17 10:15:29 -0700:
>> I was trying request-ifying oslo.vmware and ran into this as well:
>> https://review.openstack.org/#/c/121956/
>>
>> And we don't seem to have urllib3 in global-requiremen
Thanks a lot for a comments!
As discussed in IRC (#openstack-cinder), moving Brick to Oslo or Stackforge
isn't the best solution.
We're moving on making Cinder Agent (or Cinder Storage agent) [1] based on
Brick code instead of making Brick as a separate python library used in
Cinder and Nova.
I
Excerpts from Derek Higgins's message of 2014-09-17 06:53:25 -0700:
> On 15/09/14 22:37, Gregory Haynes wrote:
> > This is a total shot in the dark, but a couple of us ran into issues
> > with the Ubuntu Trusty kernel (I know I hit it on HP hardware) that was
> > causing severely degraded performan
Excerpts from Jastrzebski, Michal's message of 2014-09-17 06:03:06 -0700:
> All,
>
> Currently OpenStack does not have a built-in HA mechanism for tenant
> instances which could restore virtual machines in case of a host
> failure. Openstack assumes every app is designed for failure and can
> hand
Excerpts from Davanum Srinivas's message of 2014-09-17 10:15:29 -0700:
> I was trying request-ifying oslo.vmware and ran into this as well:
> https://review.openstack.org/#/c/121956/
>
> And we don't seem to have urllib3 in global-requirements either.
> Should we do that first?
Honestly, after re
Ok, here is what I think...
I totally support the first option for its easiness in terms of understanding
how it all should work (no need to figure out if some additional objects must
be deleted if a workflow has been removed etc. etc.). We actually have two BPS
[0] and [1] where the idea was s
> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: 12 September 2014 19:37
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [nova] Expand resource name allowed
> characters
>
> Had to laugh about the PILE OF POO character :) Comments inline...
I think in the hopefully not too distant future we'll be able to make the v1_1
client handle both V2 and V2.1 (who knows. Maybe we can even rename it v2) -
and that's what we should do because it will prove if we have full
compatibility or not.
Right now the two things holding that back are the
On 09/17/2014 09:03 AM, Jastrzebski, Michal wrote:
> In short, what we'll need from nova is to have 100% reliable
> host-health monitor and equally reliable rebuild/evacuate mechanism
> with fencing and scheduler. In heat we need scallable and reliable
> event listener and engine to decide which ac
Use case:
The client software fires the workflow execution and needs to be know when the
workflow is complete. There is no good pool strategy as workflow can take
arbitrary time from ms to days. Callback notification is needed.
Solution is a webhook
Option 1: pass callback URL as part of star
+1 to Doug's comments.
On Wed, Sep 17, 2014 at 1:02 PM, Doug Hellmann wrote:
>
> On Sep 16, 2014, at 6:02 PM, Flavio Percoco wrote:
>
>> On 09/16/2014 11:55 PM, Ben Nemec wrote:
>>> Based on my reading of the wiki page about this it sounds like it should
>>> be a sub-project of the Storage progr
I was trying request-ifying oslo.vmware and ran into this as well:
https://review.openstack.org/#/c/121956/
And we don't seem to have urllib3 in global-requirements either.
Should we do that first?
-- dims
On Wed, Sep 17, 2014 at 1:05 PM, Clint Byrum wrote:
> This is where Debian's "one urllib3
This is where Debian's "one urllib3 to rule them all" model fails in
a modern fast paced world. Debian is arguably doing the right thing by
pushing everyone to use one API, and one library, so that when that one
library is found to be vulnerable to security problems, one update covers
everyone. Als
On Sep 16, 2014, at 6:02 PM, Flavio Percoco wrote:
> On 09/16/2014 11:55 PM, Ben Nemec wrote:
>> Based on my reading of the wiki page about this it sounds like it should
>> be a sub-project of the Storage program. While it is targeted for use
>> by multiple projects, it's pretty specific to int
On 17/09/2014 16:53, Marek Denis wrote:
> Hi,
>
> First of all, we should clarify whether your JS client wants to
> implement ECP or WebSSO workflow. They are slightly different.
Our modification to Horizon uses WebSSO since this is the obvious
profile for a browser to use as it can handle redi
On 09/17/2014 11:56 AM, Daniel P. Berrange wrote:
> On Wed, Sep 17, 2014 at 04:47:06PM +0100, Alex Leonhardt wrote:
>> hi,
>>
>> how does one re-open a abandoned change / pull request ? it just "timed
>> out" and was then abandoned -
>>
>> https://review.openstack.org/#/c/57834/
>>
>> please let me
Hi everyone,
I'd like to introduce the new activity board look and feel and other
improvements in the metrics side.
* What is it?
Activity board is the place where you can find development metrics of
the OpenStack Foundation projects.
* Where to get it?
===
There is a l
On Wed, Sep 17, 2014 at 04:47:06PM +0100, Alex Leonhardt wrote:
> hi,
>
> how does one re-open a abandoned change / pull request ? it just "timed
> out" and was then abandoned -
>
> https://review.openstack.org/#/c/57834/
>
> please let me know
Just re-upload the change, maintaining the same Ch
Hi all,
The code for my proof of concept software is at
https://github.com/kwss/horizon/tree/federated (templates)
And
https://github.com/kwss/django_openstack_auth/tree/federated (federation
handling).
Please note that the horizon branch also contains some additional panels for
managing Id
Hi,
- Original Message -
> From: "Adam Young"
> To: openstack-dev@lists.openstack.org
> Sent: Wednesday, September 17, 2014 5:00:16 PM
> Subject: Re: [openstack-dev] [Keystone][Horizon] CORS and Federation
>
> On 09/17/2014 10:35 AM, David Chadwick wrote:
>
>
>
> this would work as we
On 09/17/2014 11:47 AM, Alex Leonhardt wrote:
> hi,
>
> how does one re-open a abandoned change / pull request ? it just "timed
> out" and was then abandoned -
>
> https://review.openstack.org/#/c/57834/
>
> please let me know
I re-opened it. You should be able to update it now.
--
Russell
Hi,
First of all, we should clarify whether your JS client wants to
implement ECP or WebSSO workflow. They are slightly different.
I feel JS is smart enough to implement the ECP flow and then and it
could simply implement what we already have in the keystoneclient [0].
This + some "discovery
On 16 September 2014 01:28, Nathan Kinder wrote:
> The idea would be to leave normal tokens with a smaller validity period
> (like the current default of an hour), but also allow one-time use
> tokens to be requested.
Cinder backup makes many requests to swift during a backup, one per
chunk to be
hi,
how does one re-open a abandoned change / pull request ? it just "timed
out" and was then abandoned -
https://review.openstack.org/#/c/57834/
please let me know
thanks!
alex
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://l
1 - 100 of 143 matches
Mail list logo
