> Disclaimer: I'm not fully vested on ceilometer internals, so bear with me.
>
> For consumers wanting to leverage ceilometer as a telemetry service atop
> non-OpenStack Clouds or infrastructure they don't own, some edge cases
> crop up. Most notably the consumer may not have access to the hyper
Hi! I'm now developing in Fuel and I want to add a virtual ip address to the
NIC of br-ex with the same ip range of public address. So I want to know where
IPs of node's such as br-ex, br-storage are generated. Can you tell me ?
Mail:zh...@certusnet.com.cn
_
Hi,
This mail is generic to all openstack service and explained the problem with
respect to heat here.
I have come across the situation where, updates are involved in the heat db
model and corresponding code changes in the heat-engine component. Now assume
that in a given deployment, there are
Hi Trinath,
I think you missed some configuration in tempest.conf for your testing, the
exception is duo to no "public_network_id" defined.
an example of tempest.conf for upsteam gate tests is here for your
reference
http://logs.openstack.org/32/99832/5/check/check-tempest-dsvm-neutron/0bab272/log
Big +1
Best Regards!
Kevin (Chen) Ji 纪 晨
Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC
From: Sagar Nikam
To: "OpenSta
+1
Regards,
Sagar
On Thu, Jul 31, 2014 at 2:32 AM, Michael Still wrote:
> Greetings,
>
> I would like to nominate Jay Pipes for the nova-core team.
>
> Jay has been involved with nova for a long time now. He's previously
> been a nova core, as well as a glance core (and PTL). He's been around
On 07/31/2014 06:26 PM, Michael Still wrote:
> On Thu, Jul 31, 2014 at 9:57 PM, Russell Bryant wrote:
>
>> Further, I'd like to propose that we treat all of existing +1 reviews as
>> +2 (once he's officially added to the team). Does anyone have a problem
>> with doing that? I think some folks w
Hi-
When I execute router tests from tempest on my devstack environment, I get the
following error for all the tests.
ft46.5:
tempest.api.network.test_routers.RoutersTest.test_create_show_list_update_delete_router[gate,smoke]_StringException:
Empty attachments:
stderr
stdout
pythonlogging
Shaunak, I think it's safe to say I agree with all of your points. Thanks
for responding so quickly.
On Thu, Jul 31, 2014 at 7:01 PM, Shaunak Kashyap <
shaunak.kash...@rackspace.com> wrote:
> Thanks for compiling this, Matt. I think you captured all the major
> points here; I just have three ad
Thanks for compiling this, Matt. I think you captured all the major points
here; I just have three additions/changes:
class RackspaceObject extends Object {}
I know this is the exact sample code we put up on the whiteboard and I know we
totally didn’t discuss namespaces at all at the time.
We just completed a meeting on the OpenStack SDK for PHP and this email
attempts to sum up the discussion and action items to come from the
meeting. This was a face to face meeting that included discussions of
processes and architecture.
In attendance were,
- Glen Campbell, Rackspace
- Shaunak Kas
On Thu, Jul 31, 2014 at 9:57 PM, Russell Bryant wrote:
> Further, I'd like to propose that we treat all of existing +1 reviews as
> +2 (once he's officially added to the team). Does anyone have a problem
> with doing that? I think some folks would have done that anyway, but I
> wanted to clarif
Team,
I have continued new LBaaS API testing with Tempest. Status at this point
is:
1) POST operations work for loadbalancers, healthmonitors, listeners, pools
and members
2) GET, POST, PUT, DELETE operations work for loadbalancers
3) The only exception to point 2 is DELETE when it is preceded
On Thu, 31 Jul 2014 07:57:30 -0400
Russell Bryant wrote:
> On 07/30/2014 05:10 PM, Russell Bryant wrote:
> > On 07/30/2014 05:02 PM, Michael Still wrote:
> >> Greetings,
> >> Please respond with +1s or any concerns.
> >
> > +1
> >
>
> Further, I'd like to propose that we treat all of existing
The changes to port tripleo-heat-templates to HOT have been rebased to
the current state and are ready to review. They are the next steps in
blueprint tripleo-juno-remove-mergepy.
However there is coordination needed to merge since every existing
tripleo-heat-templates change will need to be rebas
In my latest devstack pull I notice that
backup_namespace
restore_namespace
have moved from the default conf group to per datastore (commit
61935d3). However they still appear in the common_opts section of
trove/common/cfg.py
This seems like an oversight - or is there something I'm missing
It is not my intention debating, pointing fingers and finding culprits,
these issues can be addressed in some other context.
I am gonna say three things:
1) If a core-reviewer puts a -2, there must be a good reason for it. If
other reviewers blindly move on as some people seem to imply here, then
Hi Kyle,
I also agree with Mandeep's suggestion of putting a time frame on the
lingering "-2" if the addressed concerns have been taken care of. In my
experience also a sticky -2 detracts other reviewers from reviewing an
updated patch.
Either a time-frame or a possible override by PTL (move to -
Hi Kyle:
As -2 is sticky, and as there exists a possibility that the original core
might not get time to get back to re-reviewing his, do you think that there
should be clearer guidelines on it's usage (to avoid what you identified as
"dropping of the balls")?
Salvatore had a good guidance in a r
Hi Madhu,
We have not yet concluded on an API port, the code currently defaults to 8080,
but we are considering 1789.
The Congress API is built on a custom framework that encourages data models
that follow REST conventions. Are you interested in adding additional API
calls?
- Peter
From: Ma
On 11:30 Thu 31 Jul , Nikesh Kumar Mahalka wrote:
> I deployed a single node devstack on Ubuntu 14.04.
> This devstack belongs to Juno.
>
> When i am running tempest api volume test, i am getting some tests failed.
Hi Nikesh,
To further figure out what's wrong, take a look at the c-vol, c-ap
Hi everyone,
Earlier today I went through the documentation requirements for graduation
[0] and it looks like there is some work do to.
The structure we should follow is detailed in
https://etherpad.openstack.org/p/marconi-graduation.
It would be nice to do an all-hands documentation day next we
Yes
Henry Fourie wrote on 07/31/2014 12:32:23 PM:
> From: Henry Fourie
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Cc: Subrahmanyam Ongole
> Date: 07/31/2014 12:33 PM
> Subject: Re: [openstack-dev] [neutron][policy] Bridging the 2-group
> gap in group policy
>
> R
On 07/28/2014 01:51 AM, Thierry Carrez wrote:
> This is a great set of questions. When we have answers, we should
> consolidate them into a "contributors expectations" wiki page (in the
> same vein as the ML Etiquette one[1] or the Reviewers expectations one[2])
Given the amount of google juice th
On Thu, Jul 31, 2014 at 7:11 AM, Yuriy Taraday wrote:
> On Wed, Jul 30, 2014 at 11:52 AM, Kyle Mestery wrote:
>> and even less
>> possibly rootwrap [3] if the security implications can be worked out.
>
> Can you please provide some input on those security implications that are
> not worked out ye
On 7/31/14, 1:06 AM, Eoghan Glynn wrote:
Swift is already emitting those numbers[1] in statsd format; could
ceilometer consume those metrics and convert them to whatever
notification format it uses?
The problem with that approach, IIUC, is that the statsd metrics
provide insufficient context
Ryan,
So this is intended to associate a contract with a source EPG and a
destination EPG – right?
- Louis
From: Mandeep Dhami [mailto:dh...@noironetworks.com]
Sent: Wednesday, July 30, 2014 12:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Subrahmanyam O
> As a curiosity, are there any ballpark numbers around the volume of
> notifications ceilometers can handle? Thinking about large scale swift
> deployments I expect to see thousands or even 10s of thousands of events per
> second. And that's with today's technology. Looking longer term I woul
On Thu, 31 Jul 2014, Dmitry Tantsur wrote:
It would be my 2nd wanted feature in our test system (after getting
reasonable error message (at least not binary) in case of import
errors :)
I managed to figure out a way to exit on first failure so added a
FAQ section to the Testr page on the wiki:
Hi Madhu,
Sounds like you’re doing some good stuff! We’d love to have you involved.
Here’s the status of the items you mentioned.
- We’re about to merge a keystone/devstack integration.
- We have an HTTP API merged.
- arosen was working on a python-client; not sure how far along that is.
- A
On Thu, 31 Jul 2014, Julien Danjou wrote:
I'm just thinking out loud and did not push that through, but I wonder
if we should not try to use the oslo.messaging notifier middleware for
that. It would be more standard (as it's the one usable on all HTTP
pipelines) and rely on notification and gene
Jeremy Stanley wrote:
> On 2014-07-31 10:17:16 +0200 (+0200), Thierry Carrez wrote:
>> That's a good idea. We would probably switch to $PROJECT-stable-maint
>> teams then (each including $PROJECT-core and the general stable-maint
>> team) since we don't have a group in Gerrit for *-core anyway.
> [
Anne Gentle wrote:
> On Wed, Jul 30, 2014 at 7:22 AM, Thierry Carrez
>> The procedure for TC matters is the following:
>>
>> 1. create a thread on -dev so that we can all openly discuss the request
>> 2. make sure the TC notices the thread on -dev by posting a pointer to
>> the -dev thread to open
I agree with Hemanth also - that this suggestion should be a different
patch. And we should proceed with the current CLI patch.
Thanks,
- Stephen
On Wed, Jul 30, 2014 at 11:13 AM, Hemanth Ravi
wrote:
> Hi,
>
> Adding this CLI command seems to be a good way to provide support for the
> second m
Disclaimer: I'm not fully vested on ceilometer internals, so bear with me.
For consumers wanting to leverage ceilometer as a telemetry service atop
non-OpenStack Clouds or infrastructure they don't own, some edge cases
crop up. Most notably the consumer may not have access to the hypervisor
ho
Howdy!
Our feature "Snabb NFV mech driver" has become controversial on Gerrit.
Mark and Maru suspect that it is fundamentally ill-conceived. This mail is
to explain the background and advertise that we are available for
discussion. (No pressure, I just want to volunteer relevant information.)
Blu
On 2014-07-31 10:17:16 +0200 (+0200), Thierry Carrez wrote:
> That's a good idea. We would probably switch to $PROJECT-stable-maint
> teams then (each including $PROJECT-core and the general stable-maint
> team) since we don't have a group in Gerrit for *-core anyway.
[...]
I think we can actually
-Original Message-
From: Thierry Carrez
Reply: OpenStack Development Mailing List (not for usage questions)
>
Date: July 30, 2014 at 05:20:28
To: openstack-dev@lists.openstack.org >
Subject: Re: [openstack-dev] [Keystone] Survey on Token Provider Usage
> Morgan Fainberg wrote:
> > The
Yes, it's a change in default client-side behavior (the client can
explicitly request ?nocatalog). The default server-side behavior is to
continue returning catalogs in requests unless the client requests
otherwise. Before the client adopts the new default, we need
well-established support in auth_
Hello,
I've written spec for PCS support in nova/libvirt:
==
Parallels Cloud Server support in nova/libvirt driver
==
https://blueprints.launchpad.net/nova/+spec/pcs-support
This specification proposes to make cha
Hi,
I am building a congress-based demo and setting up server exposed as API.
Can somebody clarify a couple of my questions:
1. What is the port that is planned to be used for Congress to listen to
API calls ?
2. What is the Web Framework model that is planned to be adapted
(Pecan/WSME) does it f
On Thursday, July 31, 2014, Russell Bryant wrote:
> On 07/30/2014 10:57 AM, Dolph Mathews wrote:
> > We recently merged an implementation for GET /v3/catalog which finally
> > enables POST /v3/auth/tokens?nocatalog to be a reasonable default
> > behavior, at the cost of an extra HTTP call from re
On Thu, Jul 31, 2014 at 1:43 AM, YAMAMOTO Takashi
wrote:
>> On Wed, Jul 30, 2014 at 12:17 PM, YAMAMOTO Takashi
>> wrote:
>>> hi,
>>>
>>> what's the right procedure to deprecate a plugin? we (ryu team) are
>>> considering deprecating ryu plugin, in favor of ofagent. probably in
>>> K-timeframe,
Hi folks,
We'll be having the Sahara team meeting as usual in
#openstack-meeting-alt channel.
Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings
http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meeting&iso=20140731T18
--
Sincerely yours,
Sergey Lukjanov
On Wed, Jul 30, 2014 at 7:22 AM, Thierry Carrez
wrote:
> Swartzlander, Ben wrote:
> > On Tue, 2014-07-29 at 13:38 +0200, Thierry Carrez wrote:
> >> Swartzlander, Ben a écrit :
> >>> Manila has come a long way since we proposed it for incubation last
> autumn. Below are the formal requests.
> >>>
On Thu, Jul 31, 2014 at 12:30 PM, Thierry Carrez
wrote:
> Carl Baldwin wrote:
> > Let me know if I can help resolve the concerns around rootwrap. I
> > think in this case, the return on investment could be high with a
> > relatively low investment.
>
> I agree the daemon work around oslo.rootwra
On Wed, Jul 30, 2014 at 11:52 AM, Kyle Mestery wrote:
> and even less
> possibly rootwrap [3] if the security implications can be worked out.
Can you please provide some input on those security implications that are
not worked out yet?
I'm really surprised to see such comments in some ML thread n
On 07/30/2014 10:57 AM, Dolph Mathews wrote:
> We recently merged an implementation for GET /v3/catalog which finally
> enables POST /v3/auth/tokens?nocatalog to be a reasonable default
> behavior, at the cost of an extra HTTP call from remote service back to
> keystone where necessary.
Is that re
On 07/30/2014 05:10 PM, Russell Bryant wrote:
> On 07/30/2014 05:02 PM, Michael Still wrote:
>> Greetings,
>>
>> I would like to nominate Jay Pipes for the nova-core team.
>>
>> Jay has been involved with nova for a long time now. He's previously
>> been a nova core, as well as a glance core (and
+1
From: Christopher Yeoh [cbky...@gmail.com]
Sent: Thursday, July 31, 2014 3:13 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] Nominating Jay Pipes for nova-core
On Wed, 30 Jul 2014 14:02:38 -0700
Michael Still wrote:
> Gree
I don't think another extension is needed. Beyond the CLI, very limited
changes (additions) in the model/db such as those I suggested in [1] can be
helpful and will minimize the changes needed on the client side.
Best,
Mohammad
[1] https://review.openstack.org/#/c/103755/ (Patch Set 3)
From:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 31/07/14 12:46, Yuriy Taraday wrote:
> On Thu, Jul 31, 2014 at 2:23 PM, Ihar Hrachyshka
> mailto:ihrac...@redhat.com>> wrote:
>
> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
>
> Hi all,
>
> in Gerrit UI, I would like to be able to see a sep
As a curiosity, are there any ballpark numbers around the volume of
notifications ceilometers can handle? Thinking about large scale swift
deployments I expect to see thousands or even 10s of thousands of events per
second. And that's with today's technology. Looking longer term I wouldn't be
I have developed a new kind of agent (used to remote-configure
heterogeneous legacy switches) and it would definitely benefit from
interacting with, e.g., the ovs agent.
Igor Duarte Cardoso.
http://igordcard.com
Sent from mobile.
On Jul 31, 2014 2:49 AM, "loy wolfe" wrote:
> openstack is designe
On Sun, 2014-07-27 at 07:57 -0700, Sean Dague wrote:
> On 07/26/2014 05:51 PM, Hayes, Graham wrote:
> > On Tue, 2014-07-22 at 12:18 -0400, Sean Dague wrote:
> >> On 07/22/2014 11:58 AM, David Kranz wrote:
> >>> On 07/22/2014 10:44 AM, Sean Dague wrote:
> Honestly, I'm really not sure I see thi
Hi!
This list is not for usage question, it's for OpenStack developers. The
best way to get a quick help should be using
https://ask.openstack.org/en/questions/ or joining #openstack on
Freenode and asking there.
Good luck!
On Thu, 2014-07-31 at 15:59 +0530, shailendra acharya wrote:
> hello fol
On Thu, Jul 31, 2014 at 2:23 PM, Ihar Hrachyshka
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi all,
>
> in Gerrit UI, I would like to be able to see a separate column with my
> votes, so that I have a clear view of what was missed from my eye.
> I've looked in settings, and fa
On 31/07/14 12:39, shailendra acharya wrote:
plz give responce i m stuck
On Thu, Jul 31, 2014 at 3:59 PM, shailendra acharya
mailto:acharyashailend...@gmail.com>> wrote:
Please keep in mind, this list is a development list, not intended for
end user questions.
The correct one would be:
open
plz give responce i m stuck
On Thu, Jul 31, 2014 at 3:59 PM, shailendra acharya <
acharyashailend...@gmail.com> wrote:
> hello folks,
> this is shailendra acharya. i m trying to install openstack
> icehouse in centos6.5. but i got stuck and tried almost every link which
> was suggested
Hi everyone!
I want to pay attention for all people who use alembic --autogeneration for
creating migrations from models. Creation of foreign keys is not fully
implemented [1] so you should check carefully that your migration contain
all foreign keys your tables need.
Also I want to ask developer
hello folks,
this is shailendra acharya. i m trying to install openstack
icehouse in centos6.5. but i got stuck and tried almost every link which
was suggested to me by google. i have last hope to u.
when i come to create user using keystone cmd as written in openstack
installation manual
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi all,
in Gerrit UI, I would like to be able to see a separate column with my
votes, so that I have a clear view of what was missed from my eye.
I've looked in settings, and failed to find an option for this.
Is there a way to achieve this?
Cheer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 30/07/14 19:22, Kevin L. Mitchell wrote:
> On Wed, 2014-07-30 at 09:01 +0200, Flavio Percoco wrote:
>> As a stable-maint, I'm always hesitant to review patches I've no
>> understanding on, hence I end up just checking how big is the
>> patch, whe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
openstack-dev is for development discussions, not user discussions. A
better place to ask is probably openstack@ [1] or even corresponding
Foreman/RDO community mailing lists.
[1]: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Hi!
On Thu, 2014-07-31 at 10:45 +0100, Chris Dent wrote:
> One of the things I like to be able to do when in the middle of making
> changes is sometimes run all the tests to make sure I haven't accidentally
> caused some unexpected damage in the neighborhood. If I have I don't
> want the tests to
Zitat von Sylvain Bauza :
Le 30/07/2014 22:13, Boris Pavlovic a écrit :
Hi all,
This thread is very useful. We've detect issue related to the mission
statement and name of proposed program on early steps. Seems like
mission statement and name are totally unclear and don't present in
the right
One of the things I like to be able to do when in the middle of making
changes is sometimes run all the tests to make sure I haven't accidentally
caused some unexpected damage in the neighborhood. If I have I don't
want the tests to all run, I'd like to exit on first failure. This
is a common fea
On Wed, 30 Jul 2014 14:02:38 -0700
Michael Still wrote:
> Greetings,
>
> I would like to nominate Jay Pipes for the nova-core team.
>
> Jay has been involved with nova for a long time now. He's previously
> been a nova core, as well as a glance core (and PTL). He's been around
> so long that t
+1
On Thu, Jul 31, 2014 at 1:31 AM, Aaron Rosen wrote:
> +1!
>
>
> On Thu, Jul 31, 2014 at 12:40 AM, Nikola Đipanov
> wrote:
>
>> On 07/30/2014 11:02 PM, Michael Still wrote:
>> > Greetings,
>> >
>> > I would like to nominate Jay Pipes for the nova-core team.
>> >
>> > Jay has been involved wi
On Wed, Jul 30 2014, Chris Dent wrote:
> What are other options? Of those above which are best or most
> realistic?
I'm just thinking out loud and did not push that through, but I wonder
if we should not try to use the oslo.messaging notifier middleware for
that. It would be more standard (as it'
+1!
On Thu, Jul 31, 2014 at 12:40 AM, Nikola Đipanov
wrote:
> On 07/30/2014 11:02 PM, Michael Still wrote:
> > Greetings,
> >
> > I would like to nominate Jay Pipes for the nova-core team.
> >
> > Jay has been involved with nova for a long time now. He's previously
> > been a nova core, as wel
Carl Baldwin wrote:
> Let me know if I can help resolve the concerns around rootwrap. I
> think in this case, the return on investment could be high with a
> relatively low investment.
I agree the daemon work around oslo.rootwrap is very promising, but this
is a bit sensitive so we can't rush it.
Thanks Kevin and others for the input here. We have put this on
today's Group Policy IRC meeting agenda:
https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy#July_31st.2C_2014
On Wed, Jul 30, 2014 at 11:59 PM, Kevin Benton wrote:
> I agree. Ryan, can you propose a patch based off of the
Russell Bryant wrote:
> On 07/30/2014 01:22 PM, Kevin L. Mitchell wrote:
>> Maybe what we need to do is give *-core permission to +2 the patches,
>> but only stable/maint team has *approval* permission. Then, the cores
>> can review the code, and stable/maint only has to verify applicability
>> to
Few month ago we have created repository on github to where we moved
several applications that were bundled with Murano previously. That
repository was created as a place where we could gather all
applications and packages that we had created for Murano, update them
at the same time and as place wh
> Swift is already emitting those numbers[1] in statsd format; could
> ceilometer consume those metrics and convert them to whatever
> notification format it uses?
The problem with that approach, IIUC, is that the statsd metrics
provide insufficient context.
Ceilometer wants to meter usage on a
On 07/30/2014 11:02 PM, Michael Still wrote:
> Greetings,
>
> I would like to nominate Jay Pipes for the nova-core team.
>
> Jay has been involved with nova for a long time now. He's previously
> been a nova core, as well as a glance core (and PTL). He's been around
> so long that there are prob
hi,
> In Nova we have done the following:
> - add a warning in the current version that this will be deprecated in K
> - start of K drop the code
> It is also important to have an upgrade path. What happens if I have my
> RYU plugin in production and I upgrade to the next version. That should be
>
I agree. Ryan, can you propose a patch based off of the existing group
policy work so we can get an idea of what changes are required to implement
this level of abstraction?
It sounds like this is work that can be built entirely on top of the
existing abstractions and APIs offered by the current G
79 matches
Mail list logo