Hello, I am looking to learn how neutron agent (probably L3) calculates a
new routing path when VM on compute node wants to communicate with some
destination. Does it use neutron API to learn about network topology or it
uses its internal structures to simulate path resolving like in real
network?
Hello,
Where within the code of neutron agents I can find structure(s) that store
network information? The agent has to know all current networks and ports
in use by all VMs that are running in its compute node. Does anyone know
where this information is stored except for neutron DB?
Thank you
__
Hello,
What happens when neutron DB is updated to change network settings (e.g.
via Dashboard or manually) when there are communication sessions opened in
compute nodes. Does it influence those sessions? When the update is
propagated to compute nodes?
Thank you
___
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.
--
Ian.
(Why yes, it *is* a Saturday morning.)
On 6 March 2015 at 12:23, Michael Krotscheck wrote:
> Heya!
>
> So, a while ag
On Sat, Mar 7, 2015 at 8:15 AM 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.
>
Me? What? Me? Evil? None, of course. Nope. Nothing at all. Do not look
On Fri, Mar 6, 2015, at 06:35 PM, xiaoyuan wrote:
> Hi everyone,
>
> I am Xiaoyuan Lu, a recipient oftheHP Helion OpenStack scholarship, and
> ElizabethK. Josephis my mentor from HP. I would like to work on projects
> related to Keystone. Considering the amount of work and tiime limit,
> afte
I know I'm arriving late to this thread, but I want to chime in with a
resounding "yes!" to this approach.
We've held to a fairly strict policy around maintaining compatibility
within the driver API since early on, and we'll continue to do that as
we add new interfaces (see the new ManagementInter
On Sun, Mar 1, 2015 at 8:45 AM, Clint Byrum wrote:
> Excerpts from Gary Kotton's message of 2015-03-01 02:32:37 -0800:
>> Hi,
>> I am just relaying pain-points that we encountered in neutron. As I have
>> said below it makes the development process a lot quicker for people
>> working on external d
Hi Leo,
Every agent keeps anyway an in-memory state throughout its execution.
The agents indeed have no persistent storage - at least not in the usual
form of a database. They however rely on data other than the neutron
database.
For instance for the l2 agent, ovsdb itself is a source of informat
I agree that Horizon should not be requiring optional headers. Changing
status of bug.
On Tue, Mar 3, 2015 at 5:51 PM, Jay Pipes wrote:
> Added [swift] to topic.
>
> On 03/03/2015 07:41 AM, Matthew Farina wrote:
>
>> Radoslaw,
>>
>> Unfortunately the documentation for OpenStack has some holes. W
On Sun, 8 Mar 2015 at 04:59 Michael Krotscheck wrote:
> Anyone wanna hack on a bower mirror puppet module with me?
>
BTW are you aware of this spec for bower/Horizon/infra?
https://review.openstack.org/#/c/154297/
Richard
___
Possibly a better venue would be the legal-discuss@ mailing list?
-- dims
On Sat, Mar 7, 2015 at 12:57 PM, Michael Krotscheck
wrote:
> On Sat, Mar 7, 2015 at 8:15 AM Ian Wells wrote:
>>
>> With apologies for derailing the question, but would you care to tell us
>> what evil you're planning on d
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 formulated, preferably on a different thread.
Core-m
Thanks very much, David, appreciated!
-jay
On 03/07/2015 02:25 PM, David Lyle wrote:
I agree that Horizon should not be requiring optional headers. Changing
status of bug.Â
On Tue, Mar 3, 2015 at 5:51 PM, Jay Pipes mailto:[email protected]>> wrote:
Added [swift] to topic.
On 03/03/2
Hi folks,
Recently, I've been thinking more of how users of our python client
will interact with the service, and in particular, how they might
expect different instances of Ironic to behave.
We added several extensions to the API this cycle, and along with
that, also landed microversion support
Hi Stackers,
Now that microversions have been introduced to the Nova API (meaning we
can now have novaclient request, say, version 2.3 of the Nova API using
the special X-OpenStack-Nova-API-Version HTTP header), is there any good
reason to require API extensions at all for *new* functionality.
Hi,
I did some homework to follow up the inline comment about on delete cascade
subclauses of the foreign key clause[1], when ' ON
DELETE CASCADE ' is given, delete a recode from parent table will DELETE all
the corresponding rows from the CHILD table
automatically *without any warning*. 'ON DEL
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. The reason for using Cascade is that
we should be very specific in our code to prevent deletion independent of
t
18 matches
Mail list logo
