#magnetodb

ajayaa looks really cool, have you just removed keystone integration?

isviridov, yes. needed to.

otherwise we would be stuck in a loop. :)

Unexpected usage actually

actually, we have plans to move all of OS components to mdb in the future.

#What are your plans, about it?

I see

The real problem is OS apis were written initially assuming relational db as a backend.

But we are trying our best to support all the apis.

We have started to move glance as well.

Nova is the real challenge.

ajayaa what is feedback?

Also I wanted to let you people know that dynamodb api is a bit limited.

I mena from glance and other you have tried already

We are designing schema for glance now. But we have a working Keystone as I showed in the demo.

ajayaa, looks like mdb is not really good backend for glance, it needs to store huge images

dukhlov, it does not store images on its own.

only metadata?

dukhlov, yes.

ah, ok

The backend is swift or any object store.

The fact that mdb allows at maximum two columns per key is quite limiting btw.

especially when you are denormalizing data and storing it into a single table.

we can change it now I guess

But C* allows that. Can we by any chance allow more than two columns per key?

I would propose a spec for that if everyone is in favour of this?

now yes, after index LSI redesign I think we can extend our functionality

ajayaa I think we can, if we don't see performance impact

isviridov, dukhlov, C* already allows that.

and still support DDB API

We will just be a superset of ddb api.

ok, you can start to write spec

dukhlov, cool.

I can't guarantee now that we don't have anty problem there

anty?

but I think we will figure out this during reviewing spec

any

ajayaa have you shared your results with community?

I will write a spec.

isviridov, not yet. not the results. Just the spec with Keystone community.

I think it is important, to spread the info. NoSQL and Java always causes huge discussions

Looks like no other status. Next topic?

isviridov, I am doing that.

I am also attending the glance meeting now.

time clash.

#topic Open discussion isviridov

The last topic

dukhlov charlesw do you think we a done for today?

Thank you guys for attending today meeting

#endmeeting

Meeting ended Thu Mar 26 14:47:03 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)

Minutes: http://eavesdrop.openstack.org/meetings/magneto...

Minutes (text): http://eavesdrop.openstack.org/meetings/magneto...

Log: http://eavesdrop.openstack.org/meetings/magneto...

ajayaa some ideas abotu reasoning.There is a set of problems because of openstack cluster connectivity. Each OS component relies on always available MySQL, but in reality it is not always avaialble. So, I knwo about custom wrappers, what makes tries to save data in mysql.

ajayaa so cloud in distributed system and periodical faults are natural, so NoSQL storage as eventually consistent fits the use case

From other hand it should be handled on client side with additional logic. However we see zeromq drived develoment, what brings the same problems

Sory for typos

isviridov, I see.

I didn't understand the third point. The one with "client side" in it.

isviridov, That's exactly we are trying to solve. We are trying to move Openstack to an always available datastore.

ajayaa I mean, you have to expect that yor data is not available from other client reading it immidiatelly. Alos you can receive outdated info. And it should be handled

The applications, yes!

They should be fine with eventual consistency.

+1 for that.

As it stands today, not all OS applications are fine with that. It's a long battle, I suppose.

;)

ajayaa some promotion of your demo https://twitter.com/zaletniy/status/58110288411...

isviridov, Thanks! My twitter handle is aj_agr btw. :)

Vivek Dhayaal proposed stackforge/magnetodb: unstack.sh should not clean data in magnetodb https://review.openstack.org/168031