On Sun, Mar 8, 2015 at 1:37 PM, Mike Bayer mba...@redhat.com wrote:
can you elaborate on your reasoning that FK constraints should be used less
overall? or do you just mean that the client side should be mirroring the
same
rules that would be enforced by the FKs?
I don't think he means
On March 8, 2015 at 11:24:37 AM, David Stanek (dsta...@dstanek.com) wrote:
On Sun, Mar 8, 2015 at 1:37 PM, Mike Bayer mba...@redhat.com wrote:
can you elaborate on your reasoning that FK constraints should be used less
overall? or do you just mean that the client side should be mirroring the
Hi all,
This is a gentle reminder on the ML regarding Kilo-3 related reviews. Similar
announcements have been made in the past few weeks during the Glance meetings
[2].
A small summary of what the current status looks like for k-3 Glance:
1. Feature freeze for Glance is Mar 12th.
2.
On 6 March 2015 at 13:16, Sławek Kapłoński sla...@kaplonski.pl wrote:
Hello,
Today I found bug https://bugs.launchpad.net/neutron/+bug/1314614 because
I
have such problem on my infra.
(For reference, if you delete a port that a Nova is using - it just goes
ahead and deletes the port from
Oh, it means 3:00AM for me :-(
On 09/03/15 09:07, Nikhil Komawar wrote:
Hi all,
Currently, we've alternating time for Glance meetings. Now, with the
Daylight savings being implemented in some parts of the world, we're
thinking of moving the meeting time to just one slot i.e. earlier
Hi all,
Currently, we've alternating time for Glance meetings. Now, with the Daylight
savings being implemented in some parts of the world, we're thinking of moving
the meeting time to just one slot i.e. earlier in the day(night). This solves
the original conflicting times issue that a
On Sun, Mar 08, 2015 at 08:07:33PM +, Nikhil Komawar wrote:
So, the new proposal is:
Glance meetings [1] to be conducted weekly on Thursdays at 1400UTC [2] on
#openstack-meeting-4
+1
It was nice to try out the alternating meeting times. However, I don't think it
brought many benefits,
Morgan Fainberg morgan.fainb...@gmail.com wrote:
In general I'd say that cascade is the right approach. There are some very
limited cases where restrict should be used. Overall, I'd like to see less
reliance on FK constraints anywhere.
can you elaborate on your reasoning that FK
Ian Wells ijw.ubu...@cack.org.uk wrote:
With apologies for derailing the question, but would you care to tell us what
evil you're planning on doing? I find it's always best to be informed about
these things.
All of us, every day, do lots of things that someone is going to think is
evil.
Thank you for the feedback Flavio and Gary!
I've noted down your concerns and will address them in a separate thread. So, I
think we'd go ahead with nominations mentioned here (by Monday) and start the
core-member discussion later.
Thanks,
-Nikhil
Hi all.
We got several feedbacks about Sahara EDP's future from some China customers.
Here are some ideas we would like to share with you and need your input if we
can implement them in Sahara(Liberty).
1. Add a schedule feature to run the jobs on time:
This request comes from the customer,
Okay, how's it fixed? Just updating setup.cfg for each project.
Packaging is pretty much a blackbox to me (and I don't think I'm the only
one with
that view). Letting us know about a problem is great, but a way to resolve
this
would be even better.
Thanks,
Steve Martinelli
Keystone Core
Thomas
Works for me, but the previous one worked as well. So, consider my vote as
+1 unless the majority is against this :)
--
Regards,
Alexander Tivelkov
On Mon, Mar 9, 2015 at 12:36 AM, Fei Long Wang feil...@catalyst.net.nz
wrote:
Oh, it means 3:00AM for me :-(
On 09/03/15 09:07, Nikhil
+1,
I am fan of checking the constraints in the controller level instead of relying
on FK constraints itself, thanks.
Best Regards,
Dave Chen
From: Morgan Fainberg [mailto:morgan.fainb...@gmail.com]
Sent: Monday, March 09, 2015 2:29 AM
To: David Stanek; OpenStack Development
Sorry guys, for writing it this way, but really... I'm sick and tired of
the absence of relevant short and long description on almost every
component we produce. Look at this one:
https://pypi.python.org/pypi/oslo.policy
Is it so hard to produce 3 lines of long description? Can't we have a
rule
Zhi Yan is all set now. Welcome !
Nikhil Komawar wrote:
Thank you, Thierry!
-Nikhil
From: Thierry Carrez thie...@openstack.org
Sent: Tuesday, March 3, 2015 10:26 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [stable]
Port changes will result in an update message being sent on the AMQP
message bus. When the agent receives it, it will affect the communications
then. If that notification is lost, the agent will eventually resynchronize.
So during normal operations, the change should take effect within a few
I agree, we need a discussion asap.
I think below things can mitigate the unexpected behavior of python client and
this is borrow from object model.
1. Python client should have its own version and attributes like supported api
version.
2. It should be able to recognize the server's version and
On 07/03/15 23:16 +, Nikhil Komawar wrote:
Thank you for the response, Hemanth! Those are some excellent questions.
In order to avoid diverging the conversation, I would like to give my general
sense of direction. Please do keep in mind that a lot of these thoughts need to
be better
Thank you. I am looking to read this state and compare it with neutron DB.
If there are agents that do it already, I would like only to learn if I can
change the polling period. Can you advise about the most efficient way to
learn which agent does it and which doesn't?
Leonid
On Sun, Mar 8, 2015
On 18/02/15 10:07 -0500, Doug Hellmann wrote:
On Wed, Feb 18, 2015, at 05:40 AM, Daniel P. Berrange wrote:
On Tue, Feb 17, 2015 at 09:29:19AM -0800, Clint Byrum wrote:
Excerpts from Daniel P. Berrange's message of 2015-02-17 02:37:50 -0800:
On Wed, Feb 11, 2015 at 03:14:39PM +0100, Stefano
Thanks for Jay point this out! If we have agreement on this and document
it, that will be great for guiding developer how to add new API.
I know we didn't want extension for API. But I think we still
need modularity. I don't think we should put everything in a single file,
that file will become
On 03/08/2015 06:34 PM, Mike Bayer wrote:
Ian Wells ijw.ubu...@cack.org.uk wrote:
With apologies for derailing the question, but would you care to tell us
what evil you're planning on doing? I find it's always best to be informed
about these things.
All of us, every day, do lots of
The L3 agent uses ARP and static routes like a normal router would. The L2
agent is where there might be differences depending on the network type
used. If it's a tunnel overlay, the L2 agent may perform an ARP offload
from information it has learned via the L2 population mechanism.
On Sat, Mar
Thanks Nikhil,
To have a single whiteboard for all the Artifacts reviews we've created an
etherpad [1]
Here we track the progress of all the 7 artifact-releated changesets and
all the unresolved issues found there. As agreed earlier, non-critical
issues (i.e. the issues which do not affect
On 2015-03-08 08:20:31 -0430 (-0430), Flavio Percoco wrote:
I'm pretty sure this was discussed already in a TC meeting, which
I did not attend unfortunately. In the spite of keeoing things
open - not only the issues but also the solutions found - would
someone from the TC (or Stefano) mind
On 3/8/15, 2:34 PM, Flavio Percoco fla...@redhat.com wrote:
On 07/03/15 23:16 +, Nikhil Komawar wrote:
Thank you for the response, Hemanth! Those are some excellent questions.
In order to avoid diverging the conversation, I would like to give my
general
sense of direction. Please do keep
27 matches
Mail list logo
