Open Stack

I'm sorry about my slow responses. For some reason, gmail didn't think
this was an important e-mail :(

2014-09-30 18:41 GMT+02:00 Jay Pipes <jaypipes at gmail.com>:
> On 09/30/2014 08:03 AM, Soren Hansen wrote:
>> 2014-09-12 1:05 GMT+02:00 Jay Pipes <jaypipes at gmail.com>:
> How would I go about getting the associated fixed IPs for a network?
> The query to get associated fixed IPs for a network [1] in Nova looks
> like this:
>
> SELECT
>  fip.address,
>  fip.instance_uuid,
[...]
> AND fip.instance_uuid IS NOT NULL
> AND i.host = :host
>
> would I have a Riak container for virtual_interfaces that would also
> have instance information, network information, fixed_ip information?
> How would I accomplish the query against a derived table that gets the
> minimum virtual interface ID for each instance UUID?

What's a minimum virtual interface ID?

Anyway, I think Clint answered this quite well.

>>> I've said it before, and I'll say it again. In Nova at least, the
>>> SQL schema is complex because the problem domain is complex. That
>>> means lots of relations, lots of JOINs, and that means the best way
>>> to query for that data is via an RDBMS.
[...]
>> I don't think relying on a central data store is in any conceivable
>> way appropriate for a project like OpenStack. Least of all Nova.
>>
>> I don't see how we can build a highly available, distributed service
>> on top of a centralized data store like MySQL.
[...]
> I don't disagree with anything you say above. At all.

Really? How can you agree that we can't "build a highly available,
distributed service on top of a centralized data store like MySQL" while
also saying that the best way to handle data in Nova is in an RDBMS?

>>> For complex control plane software like Nova, though, an RDBMS is
>>> the best tool for the job given the current lay of the land in open
>>> source data storage solutions matched with Nova's complex query and
>>> transactional requirements.
>> What transactional requirements?
> https://github.com/openstack/nova/blob/stable/icehouse/nova/db/sqlalchemy/api.py#L1654
> When you delete an instance, you don't want the delete to just stop
> half-way through the transaction and leave around a bunch of orphaned
> children.  Similarly, when you reserve something, it helps to not have
> a half-finished state change that you need to go clean up if something
> goes boom.

Looking at that particular example, it's about deleting an instance and
all its associated metadata. As we established earlier, these are things
that would just be in the same key as the instance itself, so it'd just
be a single key that would get deleted. Easy.

That said, there will certainly be situations where there'll be a need
for some sort of anti-entropy mechanism. It just so happens that those
situations already exist. We're dealing with about a complex distributed
system.  We're kidding ourselves if we think that any kind of
consistency is guaranteed, just because our data store favours
consistency over availability.

> https://github.com/openstack/nova/blob/stable/icehouse/nova/db/sqlalchemy/api.py#L3054

Sure, quotas will require stronger consistency. Any NoSQL data store
worth its salt gives you primitives to implement that.

>>> Folks in these other programs have actually, you know, thought about
>>> these kinds of things and had serious discussions about
>>> alternatives.  It would be nice to have someone acknowledge that
>>> instead of snarky comments implying everyone else "has it wrong".
>> I'm terribly sorry, but repeating over and over that an RDBMS is "the
>> best tool" without further qualification than "Nova's data model is
>> really complex" reads *exactly* like a snarky comment implying
>> everyone else "has it wrong".
> Sorry if I sound snarky. I thought your blog post was the definition
> of snark.

I don't see the relevance of the tone of my blog post?

You say it would be nice if people did something other than offer snarky
comments implying everyone else "has it wrong".  I'm just pointing out
that such requests ring really hollow when put forth in the very e-mail
where you snarkily tell everyone else that they have it wrong.

Since you did bring up my blog post, I really am astounded you find it
snarky.  It was intended to be constructive and forward looking. The
first one in the series, perhaps, but certainly not the one linked in
this thread.

Perhaps I need to take writing classes.

-- 
Soren Hansen             | http://linux2go.dk/
Ubuntu Developer         | http://www.ubuntu.com/
OpenStack Developer      | http://www.openstack.org/