On Thu, Jul 3, 2014 at 5:00 AM, Jeremy Stanley wrote:
> On 2014-07-02 22:19:29 +0400 (+0400), Yuriy Taraday wrote:
> [...]
> > It looks like mirrors will have to bear having a number of dead branches
> in
> > them - one for each release.
>
> A release manager will delete proposed/juno when stable
Can anyone kindly help me here? When the volume type is created and I try
starting volume service via coverage, I get "coverage_manager not found"
error.
On Wed, Jul 2, 2014 at 6:57 AM, iKhan wrote:
> I have manually deployed cinder and it is up and running. Now I wanted to
> get the live code
On 3 July 2014 02:44, Michael Still wrote:
> I have seen both. Normally there's a failure, reviewers notice, and
> then the developer spins trying out fixes by uploading new patch sets.
>
Interesting. Yes, I can see that you need fast response from CIs to support
that scenario. 12-hour edit-comp
>> making this change is going to be a high bar to get over.
Yes, I agree.
>> Most of the screen usage is in the set of functions that handle
>> process start and stop in functions-common.
This is exactly what I am saying. It's already abstracted up to some
extent. May be we can leverage it.
>> I
Good job! zhenguo
On Wed, Jul 2, 2014 at 9:55 AM, Zhenguo Niu wrote:
> Thank you everyone, I'll do my best!
>
> 发自我的 iPhone
>
> > 在 Jul 1, 2014,22:37,"Lyle, David" 写道:
> >
> > Welcome Zhenguo and Ana to Horizon core.
> >
> > David
> >
> >
> >> On 6/20/14, 3:17 PM, "Lyle, David" wrote:
> >>
>
Although the SNAT DVR has some trade off, I still think it is
necessary. Here is pros and cons for consideration:
pros:
save W-E bandwidth
high availability (distributed, no single point failure)
cons:
waste public ips (one ip per compute node vs one ip per l3-agent, if
double-SNAT implemented)
Hi,
As announced:
http://lists.openstack.org/pipermail/openstack-dev/2014-June/038475.html
The nova-specs dates:
* all juno nova-specs ready for review by the end of today, 3rd July
(in local time for you)
* all blueprints we can take for juno (yes juno-2 and juno-3) approved
by 10th July
We wil
Thanks Scott, that is a nice topic
In theory, I would prefer to have both owner_tenant and owner_user to be
persisted with an image, and to have a policy rule which allows to specify
if the users of a tenant have access to images owned by or shared with
other users of their tenant. But this will r
> Looks like many are in Paris midcycle meet-up. Do we have the weekly IRC
> meeting today?
Hi Lianhao,
We'll do a very short meeeting just to review juno-2 status, and remind
folks about the upcoming spec deadlines for Juno. Shouldn't take more
than a few minutes.
Cheers,
Eoghan
___
FWIW, I've just registered
https://blueprints.launchpad.net/tripleo/+spec/re-assert-system-state and I'm
about to start work on the spec.
Matt
> -Original Message-
> From: Clint Byrum [mailto:cl...@fewbar.com]
> Sent: 27 June 2014 17:01
> To: openstack-dev
> Subject: Re: [openstack-dev]
> -Original Message-
> From: Anita Kuno [mailto:ante...@anteaya.info]
> Sent: 01 July 2014 14:42
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [third-party-ci][neutron] What is "Success"
> exactly?
>
> On 06/30/2014 09:13 PM, Jay Pipes wrote:
> > On 06/30/2014 07:0
Hi,
Just a reminder that the weekly Nova API meeting is being held tomorrow
Friday UTC .
We encourage cloud operators and those who use the REST API such as
SDK developers and others who and are interested in the future of the
API to participate.
In other timezones the meeting is at:
EST
I would just add that if I'm not mistaken the DVR work would also include
the features currently offered by nova network's 'multi-host' capability.
While DVR clearly does a lot more than multi host, keeping SNAT centralized
only might not fully satisfy this requirement.
Indeed nova-network offers S
Apologies for quoting again the top post of the thread.
Comments inline (mostly thinking aloud)
Salvatore
On 30 June 2014 22:22, Jay Pipes wrote:
> Hi Stackers,
>
> Some recent ML threads [1] and a hot IRC meeting today [2] brought up some
> legitimate questions around how a newly-proposed Sta
I have created a separate spec for the RPC part.
https://review.openstack.org/104522
On 07/02/2014 05:52 PM, Kyle Mestery wrote:
On Wed, Jul 2, 2014 at 3:43 AM, Ihar Hrachyshka wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/07/14 10:12, Miguel Angel Ajo wrote:
Shihazhang,
I
And the spec is now up at https://review.openstack.org/104524 for everyone to
pull apart... ;)
Matt
> -Original Message-
> From: Macdonald-Wallace, Matthew
> Sent: 03 July 2014 11:18
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Triple
Hi,
As you surely now, in Juno oslo.db will graduate [1]
I am currently working on the port. It's been already cleared that making
alembic migrations "idempotent" and healing the DB schema is a requirement
for this task.
These two activities are tracked by the blueprints [2] and [3].
I think we've
Hi,
Due to maintenance reasons, our CI results server has been moved to a new
machine.
As we didn't use a dns name before, previous links posted on the
review.openstack.org will appear as broken but they're still available
changing the previous hardcoded ip: 119.15.112.63 by the new dns name:
3rdp
On 2014-07-03 11:20:43 +0400 (+0400), Yuriy Taraday wrote:
> I mean other mirrors like we have in our local net. Given not so
> good connection to upstream repos (the reason we have this mirror
> in the first place) I can't think of reliable way to clean them
> up. Where can I find scripts that pro
On 07/02/2014 09:11 PM, Doug Hellmann wrote:
> The Oslo team is pleased to announce the first release of oslo.i18n,
> the library that replaces the gettextutils module from oslo-incubator.
>
> The new library has been uploaded to PyPI, and there is a changeset in
> the queue update the global requ
Hi Salvatore,
I must be missing something. Hasn't it been done in
https://review.openstack.org/#/c/103519/? :)
Thanks,
Roman
On Thu, Jul 3, 2014 at 2:51 PM, Salvatore Orlando wrote:
> Hi,
>
> As you surely now, in Juno oslo.db will graduate [1]
> I am currently working on the port. It's been al
No I was missing everything and kept wasting time because of alembic.
This will teach me to keep my mouth shut and don't distract people who are
actually doing good work.
Thanks for doings this work.
Salvatore
On 3 July 2014 14:15, Roman Podoliaka wrote:
> Hi Salvatore,
>
> I must be missing
On 07/03/2014 07:54 AM, Lucas Eznarriaga wrote:
> Hi,
>
> Due to maintenance reasons, our CI results server has been moved to a new
> machine.
> As we didn't use a dns name before, previous links posted on the
> review.openstack.org will appear as broken but they're still available
> changing the
On 3 July 2014 02:44, Michael Still wrote:
> The main purpose is to let change reviewers know that a change might
> be problematic for a piece of code not well tested by the gate
Just a thought:
A "sampling" approach could be a reasonable way to stay responsive under
heavy load and still give
So, our releases will have following versions of releases on UI:
5.0) "2014.1"
5.0.1) "2014.1.1-5.0.1"
5.1) "2014.1.1-5.1"
And if someone install 5.0, upgrade it to 5.0.1 and then upgrade to 5.1, he
will have three releases for each OS. I think we should allow user to
delete unneeded releases. It
On 07/03/2014 06:22 AM, Sullivan, Jon Paul wrote:
>> -Original Message-
>> From: Anita Kuno [mailto:ante...@anteaya.info]
>> Sent: 01 July 2014 14:42
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [third-party-ci][neutron] What is "Success"
>> exactly?
>>
>> On 06/
On 07/03/2014 07:12 AM, Salvatore Orlando wrote:
> Apologies for quoting again the top post of the thread.
>
> Comments inline (mostly thinking aloud)
> Salvatore
>
>
> On 30 June 2014 22:22, Jay Pipes wrote:
>
>> Hi Stackers,
>>
>> Some recent ML threads [1] and a hot IRC meeting today [2] br
> -Original Message-
> From: Anita Kuno [mailto:ante...@anteaya.info]
> Sent: 03 July 2014 13:53
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [third-party-ci][neutron] What is "Success"
> exactly?
>
> On 07/03/2014 06:22 AM, Sullivan, Jon Paul wrote:
> >> -Ori
+1
On Wed, Jul 2, 2014 at 10:12 PM, Kyle Mestery
wrote:
> We're coming down to the wire here with regards to Neutron BPs in
> Juno, and I wanted to bring up the topic of the flavor framework BP.
> This is a critical BP for things like LBaaS, FWaaS, etc. We need this
> work to land in Juno, as t
On Thu, Jul 3, 2014 at 2:59 AM, Anant Patil wrote:
>
> >> If we did move from screen to tmux.
> We aren't moving away... I have emphasized this enough. One should be
> able just "choose" tmux explicitly otherwise things will run in screen
> by default, as usual.
>
And I am saying due to the natur
On 07/03/2014 09:52 AM, Sullivan, Jon Paul wrote:
>> -Original Message-
>> From: Anita Kuno [mailto:ante...@anteaya.info]
>> Sent: 03 July 2014 13:53
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [third-party-ci][neutron] What is "Success"
>> exactly?
>>
>> On 07/
Hi,
> I think we should allow user to delete unneeded releases.
In this case user won't be able to add new nodes to the existing
environments of the same version. So we should check and warn user about
it, or simply not allow to delete releases if there are live envs with the
same version.
On
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Oh, so you have the enhancement implemented? Great! Any numbers that
shows how much we gain from that?
/Ihar
On 03/07/14 02:49, shihanzhang wrote:
> Hi, Miguel Angel Ajo! Yes, the ipset implementation is ready, today
> I will modify my spec, when t
> -Original Message-
> From: Anita Kuno [mailto:ante...@anteaya.info]
> Sent: 03 July 2014 15:06
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [third-party-ci][neutron] What is "Success"
> exactly?
I guess you missed this last time - the mail had gotten quite long
If your like me, launchpads wrapping of paragraphs in comment boxes gets
under your skin, making it very difficult to follow tracebacks, logs,
etc see
https://bugs.launchpad.net/launchpad/+bug/545125
I finally got motivated to try and do something about it (at least in
chrome), as the above b
Salvatore,
There is FIP distribution at the agent level, in the sense the N/S of FIP for a
VM will be hosted on the same compute node. We centralized SNAT from feedback
by others. The current design and code only supports centralized SNAT for DVR
routers. The design could be modified to allo
I'm on Paris mid-cycle sprint, so, Alex Ignatov and Dmitry
Mescheryakov will chair the meeting today.
On Wed, Jul 2, 2014 at 4:35 PM, Sergey Lukjanov wrote:
> Hi folks,
>
> We'll be having the Sahara team meeting as usual in
> #openstack-meeting-alt channel.
>
> Agenda: https://wiki.openstack.org
I¹m seeing similar. Instances launch, they show as having Ips in
`neutron list` but I cannot access them via IP.
Other thing I¹ve notices is that doing a `neutron agent-list` gives me an
empty list, I would assume it should at least show the dhcp agent ?
On 7/1/14, 12:00 PM, "Kyle Mestery"
Hey
This is an attempt to summarize a really useful discussion that Victor,
Flavio and I have been having today. At the bottom are some background
links - basically what I have open in my browser right now thinking
through all of this.
We're attempting to take baby-steps towards moving completely
With the new API and object model refactor there have been some issues
arising dealing with the status of entities. The main issue is that
Listener, Pool, Member, and Health Monitor can exist independent of a
Load Balancer. The Load Balancer is the entity that will contain the
information about w
Hi,
Mark and me has spent some time today discussing existing proposals and I
think we got to a consensus.
Initially I had two concerns about Mark's proposal which are
- extension list attribute on the flavor
- driver entry point on the service profile
The first idea (ext list) need to be clarifi
If the objects remain in 'PENDING_CREATE' until provisioned it would seem
that the process got stuck in that status and may be in a bad state from
user perspective. I like the idea of QUEUED or similar to reference that
the object has been accepted but not provisioned.
Phil
On 7/3/14 10:28 AM, "B
Hi, All!
As far as I know, there are some requirements, which virt driver must meet to
use Openstack 'label'. For example, it's not allowed to mount cinder volumes
inside host OS.
Are there any documents, describing all such things? How can I determine, if
my virtualization driver for nova (de
On 07/03/2014 10:31 AM, Sullivan, Jon Paul wrote:
>> -Original Message-
>> From: Anita Kuno [mailto:ante...@anteaya.info]
>> Sent: 03 July 2014 15:06
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [third-party-ci][neutron] What is "Success"
>> exactly?
>
> I guess
On 07/03/2014 10:48 AM, Derek Higgins wrote:
If your like me, launchpads wrapping of paragraphs in comment boxes gets
under your skin, making it very difficult to follow tracebacks, logs,
etc see
https://bugs.launchpad.net/launchpad/+bug/545125
I finally got motivated to try and do somethin
On 07/03/2014 03:49 AM, Luke Gorrie wrote:
On 3 July 2014 02:44, Michael Still mailto:mi...@stillhq.com>> wrote:
I have seen both. Normally there's a failure, reviewers notice, and
then the developer spins trying out fixes by uploading new patch sets.
Interesting. Yes, I can see that y
On 1 July 2014 19:12, Luke Gorrie wrote:
> It does not yet run devstack/tempest and I hope to reuse that part from
> somebody else's efforts.
>
shellci is happily voting on the sandbox with the Snabb NFV CI account so
far: http://egg.snabb.co:81/shellci/shellci.log
Time to make it start running
On 07/03/2014 08:42 AM, Luke Gorrie wrote:
On 3 July 2014 02:44, Michael Still mailto:mi...@stillhq.com>> wrote:
The main purpose is to let change reviewers know that a change might
be problematic for a piece of code not well tested by the gate
Just a thought:
A "sampling" approach co
+27, -2401
Wow, that's pretty painless. Were there earlier patches to Neutron to
prepare for the transition or was it really that easy?
On 07/03/2014 07:34 AM, Salvatore Orlando wrote:
> No I was missing everything and kept wasting time because of alembic.
>
> This will teach me to keep my mout
On Thu, Jul 3, 2014 at 11:27 AM, Mark McLoughlin wrote:
> Hey
>
> This is an attempt to summarize a really useful discussion that Victor,
> Flavio and I have been having today. At the bottom are some background
> links - basically what I have open in my browser right now thinking
> through all of
Ben,
As I know the API of oslo.db and oslo-incubator/db are almost the same.
So why it should be complicated?
Best regards,
Boris Pavlovic
On Thu, Jul 3, 2014 at 9:10 PM, Ben Nemec wrote:
> +27, -2401
>
> Wow, that's pretty painless. Were there earlier patches to Neutron to
> prepare for t
>This allows the viewer to see categories of reviews based upon their
>divergence from OpenStack's Jenkins results. I think evaluating
>divergence from Jenkins might be a metric worth consideration.
I think the only thing this really reflects though is how much the third
party CI system is mirrori
On Mon, Jun 30, 2014 at 12:56 PM, Mike Bayer wrote:
> Hi all -
>
> For those who don't know me, I'm Mike Bayer, creator/maintainer of
> SQLAlchemy, Alembic migrations and Dogpile caching. In the past month
> I've become a full time Openstack developer working for Red Hat, given
> the task of car
Looks like there are no objections to this nomination so I have made Marc
and Darragh Jenkins Job Builder Core reviewers. Congrats guys and keep the
reviews rolling.
On Mon, Jun 30, 2014 at 10:52 AM, Darragh Bailey
wrote:
>
>
> On 20 June 2014 22:01, James E. Blair wrote:
>
>> Hi,
>>
>> The J
Hi All and Ihar,
As part of blueprint oslo-messaging the neutron/openstack/common/rpc tree
is removed. I was using impl_kombu module to process notification from
keystone with this following code sample:
...
from neutron.openstack.common.rpc import impl_kombu
try:
conf = impl_kom
You'll find the documentation for using oslo.messaging at
http://docs.openstack.org/developer/oslo.messaging/
Based on the fact that you mention listening for notifications, you
probably want to look at the notification listener documentation in
particular
(http://docs.openstack.org/developer/osl
On Mon, Jun 30, 2014 at 9:00 AM, Sean Dague wrote:
> Every time I crack open a nova logs in detail, at least 2 new olso
> incubator log issues have been introduced.
>
> The current ones is clearly someone is over exploding arrays, as we're
> getting things like:
> 2014-06-29 13:36:41.403 19459 DEB
On 30/06/14 13:02 -0400, Jordan OMara wrote:
On 25/06/14 14:32 -0400, Jordan OMara wrote:
On 25/06/14 18:20 +, Carlino, Chuck (OpenStack TripleO, Neutron) wrote:
Is $179/day the expected rate?
Thanks,
Chuck
Yes, that's the best rate available from both of the downtown
(walkable) hotels.
Hi,
==
tl; dr: A decision has been made to split out the scheduler to a
separate project not on a feature parity basis with nova-scheduler, your
comments are welcome.
==
As it has been agreed now a cycle ago, the nova-scheduler will be ported
to a separate OpenStack project, called Gantt [1]. The
Hi,
You can use /oslo.messaging._drivers.impl_rabbit/ instead of impl_kombu
It was renamed and slightly change but I think it will work as you expect.
Regards,
Alexei Kornienko
On 07/03/2014 08:47 PM, Nader Lahouti wrote:
Hi All and Ihar,
As part of blueprint oslo-messaging the neutron/openst
On 07/03/2014 01:27 PM, Kevin Benton wrote:
>> This allows the viewer to see categories of reviews based upon their
>> divergence from OpenStack's Jenkins results. I think evaluating
>> divergence from Jenkins might be a metric worth consideration.
>
> I think the only thing this really reflects t
The reason I thought it changed was that this is the first cycle where I
have encountered scenarios where my unit tests for the patch run fine
locally, but then they fail when they are checked by Jenkins (caused by a
change after the parent of my patch). I suppose I was just lucky before and
never
>In short, you need to test every single proposed patch to the system fully
and consistently, otherwise there's simply no point in running any tests at
all, as you will spend an inordinate amount of time tracking down what
broke what.
I agree that every patch should be tested. However, since third
On 07/03/2014 02:10 PM, Kevin Benton wrote:
The reason I thought it changed was that this is the first cycle where I
have encountered scenarios where my unit tests for the patch run fine
locally, but then they fail when they are checked by Jenkins (caused by
a change after the parent of my patch)
Maybe we can require period checks against the head of the master
branch (which should always pass) and build statistics based on the results
of that. Otherwise it seems like we have to take a CI system's word for it
that a particular patch indeed broke that system.
--
Kevin Benton
On Thu, Jul 3
I agree.
Also, since we are planning on having two different API versions run in
parallel the only driver that needs to be worked on initially is the reference
implementation. I'm guessing we will have two reference implementations, one
for v1 and one for v2. The v2 implementation currently see
On Thu, Jul 3, 2014 at 10:27 AM, Kevin Benton wrote:
> >This allows the viewer to see categories of reviews based upon their
> >divergence from OpenStack's Jenkins results. I think evaluating
> >divergence from Jenkins might be a metric worth consideration.
>
> I think the only thing this really
On 07/03/2014 02:33 PM, Kevin Benton wrote:
> Maybe we can require period checks against the head of the master
> branch (which should always pass) and build statistics based on the results
> of that.
I like this suggestion. I really like this suggestion.
H, what to do with a good suggestion?
Hey German,
We have similar statuses. I have been wanting to add a 'QUEUED' status
however. The reason is that we currently use 'BUILD' which indicates
active provisioning when in reality it is actually queued first and then
provisioned. Thus, there are potential issues when trying to determine
av
+1 to QUEUED status.
For entities that have the concept of being attached/detached why not have
a 'DETACHED' status to indicate that the entity is not provisioned at all
(i.e. The config is just stored in the DB). When it is attached during
provisioning then we can set it to 'ACTIVE' or any of the
On Thu, Jul 3, 2014 at 1:58 PM, Alexei Kornienko
wrote:
> Hi,
>
> You can use oslo.messaging._drivers.impl_rabbit instead of impl_kombu
> It was renamed and slightly change but I think it will work as you expect.
You should not depend on using any API defined in that module. The
_drivers package
Again, thanks everyone who have joined Sahara meeting. Below are the
logs from the meeting.
Minutes:
http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-07-03-18.06.html
Logs:
http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-07-03-18.06.log.html
Thanks,
Dmitry
_
At yesterday's Trove team meeting [1] there was significant discussion around
the Capabilities [2] feature. While the community previously approved a BP and
some of the initial implementation, it is apparent now that there is no
agreement in the community around the requirements, use cases or pr
On 07/03/2014 01:53 PM, Sylvain Bauza wrote:
> Hi,
>
> ==
> tl; dr: A decision has been made to split out the scheduler to a
> separate project not on a feature parity basis with nova-scheduler, your
> comments are welcome.
> ==
...
> During the last Gantt meeting held Tuesday, we discussed abou
Matthew Treinish writes:
> Hi Everyone,
>
> Just a quick update, we have to close registration for the Infra/QA mid-cycle
> meet-up. Based on the number of people who have signed up on the wiki page [1]
> we are basically at the maximum capacity for the rooms we reserved. So if you
> had intended
Yes I know that, but we need the big patch in order to get our V2 REST
API working, so I asked to review this patch instead of submitting a new
one.
On Wed, 2014-07-02 at 17:24 -0400, Ryan Petrello wrote:
> That's a pretty notable review to accommodate the pecan change. In the
> meantime, wouldn'
I am pleased to announce git-review 1.24 is officially released
today (Thursday, July 3, 2014). This version brings together 77 new
changes from 20 different collaborators including fixes for 15
bugs and a variety of other improvements:
https://git.openstack.org/cgit/openstack-infra/git-review/log
Here is the list of patches pending to resolve this issue (Keystone Master,
Keystone Stable/Icehouse, and Tempest)
https://review.openstack.org/#/q/status:open+topic:bug/1334368,n,z
—
Morgan Fainberg
--
From: Nathan Kinder nkin...@redhat.co
On Thu, Jul 3, 2014 at 7:05 AM, Aleksandr Didenko wrote:
>> I think we should allow user to delete unneeded releases.
>
> In this case user won't be able to add new nodes to the existing
> environments of the same version. So we should check and warn user about it,
> or simply not allow to delete
Hey Doug,
Thank you so much for putting this together. I have some
questions/clarifications(inline) which would be useful to be addressed in the
spec.
From: Doug Shelley mailto:d...@tesora.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@list
> I also don't think it is fair for certain drivers to hold other drivers
"hostage"
For some time there was a policy (openstack-wide) that public API should
have a free open source implementation.
In this sense open source driver may hold other drivers as "hostages".
Eugene.
On Thu, Jul 3, 2014
Are these zuul refs publicly accessible so that the third party CI systems
could reference then to guarantee they are testing the same thing?
On Thu, Jul 3, 2014 at 11:31 AM, Jay Pipes wrote:
> On 07/03/2014 02:10 PM, Kevin Benton wrote:
>
>> The reason I thought it changed was that this is the
Yes, I can propose a spec for that. It probably won't be until Monday.
Is that okay?
On Thu, Jul 3, 2014 at 11:42 AM, Anita Kuno wrote:
> On 07/03/2014 02:33 PM, Kevin Benton wrote:
> > Maybe we can require period checks against the head of the master
> > branch (which should always pass) and b
The most challenge part for me for the past few days is understanding the
how SDN can reduce the burden on Neutron.
A single SDN plugin consider OpenDayLight controller plugin deployed on
neutron. I have physical and virtual switches which support open flow. I
know OpenFlow will install the flow t
While moving success response code checking in tempest to the client, I
noticed that exactly one of the calls to list users for a tenant checked
for 200 or 203. Looking at
http://docs.openstack.org/api/openstack-identity-service/2.0/content/,
it seems that most of the list apis can return 203.
Hi,
This is very similar to an issue I encountered with Glance. For some
unknown reason, we were adding a Location header for 200 responses.
When served behind apache+mod_fcgid, the module saw the Location
header and has a hard coded conversion to 302 Redirect. This caused
glanceclient to follo
Hi Folks - I have taken a script from the infra folks and jogo, made some
tweaks and have put it into a web page. Please see it here
http://54.201.139.117/demo.html
This is all of the new, confirmed, triaged, and in progress bugs that we have
in nova as of a couple of hours ago. I have added
Awesome, thanks for working on this Eugene and Mark! I'll still leave
an item on Monday's meeting agenda to discuss this, hopefully it can
be brief.
Thanks,
Kyle
On Thu, Jul 3, 2014 at 10:32 AM, Eugene Nikanorov
wrote:
> Hi,
>
> Mark and me has spent some time today discussing existing proposals
On Thu, Jul 3, 2014 at 10:14 AM, Paul Czarkowski
wrote:
> I¹m seeing similar. Instances launch, they show as having Ips in
> `neutron list` but I cannot access them via IP.
>
> Other thing I¹ve notices is that doing a `neutron agent-list` gives me an
> empty list, I would assume it should a
On Thu, Jul 3, 2014 at 3:48 PM, David Kranz wrote:
> While moving success response code checking in tempest to the client, I
> noticed that exactly one of the calls to list users for a tenant checked
> for 200 or 203. Looking at http://docs.openstack.org/api/
> openstack-identity-service/2.0/cont
I was implying that it applies to all drivers.
Cheers,
--Jorge
From: Eugene Nikanorov mailto:enikano...@mirantis.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, July 3, 2014 3:30 PM
To: "OpenStack Developme
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 03/07/14 19:47, Nader Lahouti wrote:
> Hi All and Ihar,
>
> As part of blueprint oslo-messaging the
> neutron/openstack/common/rpc tree is removed. I was using
> impl_kombu module to process notification from keystone with this
> following code s
On 07/03/2014 04:34 PM, Kevin Benton wrote:
> Yes, I can propose a spec for that. It probably won't be until Monday.
> Is that okay?
>
Sure, that's fine. Thanks Kevin, I look forward to your spec once it is
up. Enjoy tomorrow. :D
Thanks Kevin,
Anita.
>
> On Thu, Jul 3, 2014 at 11:42 AM, Anita Ku
Is this still the right repo for this:
https://github.com/openstack/neutron-specs
The latest commit on the master branch shows June 25th timestamp, but
we have had a lots of patches merging after that. Where are those
going?
Thanks,
~Sumit.
___
OpenSta
Iccha,
Thanks for the feedback. I guess I should have been more specific - my intent
here was to layout use cases and requirements and not talk about specific
implementations. I believe that if we can get agreement on the requirements, it
will be easier to review/discuss design/implementation c
Thanks a lot Doug and Alexei for your prompt response.
I used what Doug suggested and worked.
Thanks again for the help.
Nader.
On Thu, Jul 3, 2014 at 12:04 PM, Doug Hellmann
wrote:
> On Thu, Jul 3, 2014 at 1:58 PM, Alexei Kornienko
> wrote:
> > Hi,
> >
> > You can use oslo.messaging._drivers
Thanks Nader for the extra effort and I am glad you made progress here.
Milton
From: Nader Lahouti [mailto:nader.laho...@gmail.com]
Sent: Thursday, July 03, 2014 3:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][oslo.messaging]
Thanks
Hi Jorge,
+1 for QUEUED and DETACHED
I would suggest to make the time how long we keep entities in DELETED state
configurable. We use something like 30 days, too, but we have made it
configurable to adapt to changes...
German
-Original Message-
From: Jorge Miramontes [mailto:jorge.mir
I am actually a bit bummed that Extensions are postponed. In LBaaS we are
working hard on L7 and TLS extensions which we (the operators) like to switch
on and off with different flavors...
German
-Original Message-
From: Kyle Mestery [mailto:mest...@noironetworks.com]
Sent: Thursday,
git.openstack.org has an up-to-date log:
http://git.openstack.org/cgit/openstack/neutron-specs/log/
Unfortunately I don't know what the policy is for syncing repos with github.
Salvatore
On 4 July 2014 00:34, Sumit Naiksatam wrote:
> Is this still the right repo for this:
> https://github.com
1 - 100 of 109 matches
Mail list logo