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 krotsch...@gmail.com wrote:
On Sat, Mar 7, 2015 at 8:15 AM 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.
Me? What? Me? Evil? None, of course. Nope. Nothing
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
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, 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?
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,
after
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
On Sun, Mar 1, 2015 at 8:45 AM, Clint Byrum cl...@fewbar.com 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
On Sun, 8 Mar 2015 at 04:59 Michael Krotscheck krotsch...@gmail.com 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
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.
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*
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
Possibly a better venue would be the legal-discuss@ mailing list?
-- dims
On Sat, Mar 7, 2015 at 12:57 PM, Michael Krotscheck
krotsch...@gmail.com wrote:
On Sat, Mar 7, 2015 at 8:15 AM Ian Wells ijw.ubu...@cack.org.uk wrote:
With apologies for derailing the question, but would you care to
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 jaypi...@gmail.com
mailto:jaypi...@gmail.com wrote:
Added [swift] to
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 jaypi...@gmail.com wrote:
Added [swift] to topic.
On 03/03/2015 07:41 AM, Matthew Farina wrote:
Radoslaw,
Unfortunately the documentation for OpenStack has some
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
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
18 matches
Mail list logo
