+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 Maili
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
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 perfor
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
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 7,
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
secon
Zhi Yan is all set now. Welcome !
Nikhil Komawar wrote:
>
> Thank you, Thierry!
>
> -Nikhil
>
>
> From: Thierry Carrez
> Sent: Tuesday, March 3, 2015 10:26 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [stable] [Glance] Nomin
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 w
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
wrote:
> Oh, it means 3:00AM for me :-(
>
>
> On 09/03/15 09:07, Nikhil Komawar wrote:
>
>
> H
On 03/08/2015 06:34 PM, Mike Bayer wrote:
>
>
> Ian Wells 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 tha
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 in
On 6 March 2015 at 13:16, Sławek Kapłoński 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 Neutron and lea
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 benefit
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 subset
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. [1
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
From:
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 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
On Sun, Mar 8, 2015 at 1:37 PM, Mike Bayer 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 that we will use
Morgan Fainberg 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 constraints should be used less
Ian Wells 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. From eating meat, to
On 3/8/15, 2:34 PM, "Flavio Percoco" 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 in
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 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, Stefa
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 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 formula
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 hu
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, they
27 matches
Mail list logo
