Thank you, yes, probably not a good idea to not write my name there, but it'll come
later. So, yeah, I'm trying to talk about open cloud and software-defined storage and what
we are kind, the aspects of storage that we are consuming, and for that I would really like
to ask a few questions, but they're not here. Oh, I've started the wrong. So, before I get
started, who knows, or who's using some kind of software-defined storage at home, at home,
really, I don't think. Okay, like 15 people, okay, who's using it at the, at the, on the job?
Everyone, or nearly everyone, okay, maybe two hands-in-go-out, okay, cool. Who year-knows
what open cloud is? That's pretty good, okay, like 12 people, 13. Who of you knows
that open cloud has different storage drivers? 1, 2, 3, 4, 5. Okay, who of you knows that open cloud
can actually synchronize files when they are changed on the storage, on the software-defined
storage? The guy from Sirn, and you are from, I didn't know, okay, but, okay, cool. So, maybe
you will get to know a few more things that what open cloud can do. Who am I? I am, my name's
you Andrea. I have been employee number seven at on cloud. It was like ages ago, and I stayed
there until on cloud was bought by kiteworks, and then found myself at open cloud, where
we continued the work on open cloud infinite scale, which is a rewrite of the backend of
own cloud that was started by Sirn, but by us. So, they just made an offer that we couldn't
refuse, and we actually tried to collaborate on that and continue it, and adapted to our
needs, to the needs of our end users. And now I'm trying to deploy this in Q&A text and
find a good software-defined storage that works well in that scenario. Okay, so our end users
really have a few things that they got used to, what you all know, like from the days that
Dropbox started, when somebody changes something, if I should be synchronized, the discipline
should pick up files, and that's the normal synchronization stuff that has some requirements
on the storage, as we will see later. And the other things, if I send a public link to
someone, that link should not break when somebody renames files in the storage. Okay, so we cannot
do path-based sharing links. So, an idea is important. We have the typical things that people
see, so we currently show the full tree size of a folder with all the files in it, which is
not what you see in a POSIX file system, but that's what people got used to. We have a trash
that works automatically. We have filed individual revisions, so if you write anything, you can
always restore a version, and our end user actually now used to that. And it's all about self-service
and enabling end users to take care of the files without having to talk to an administrator.
And the last thing is, okay, the user's at metadata like tags, favorites, and whatnot,
and they want to be able to search and find these things based on these metadata tags or based on
file content, so we actually have to index files and look inside that. Now, if you recognize this,
I hope so. I mean, this looks like the average software defined storage. You have some kind of
metadata storage that is replicated. You have some kind of bucket storage where all the blocks are,
you have some kind of system that's translating all this stuff and some side services. They all look
the same. And actually, on Cloud 10 looks like this. You have your patchy service, your PHP code,
Galaera Cluster, to be clear or often, or Postgres or whatever, and you have a POSIX storage,
or even a three storage. So all these systems look the same. Next slide looks like this.
Surface looks like this. Surface looks like this. Surface looks like this.
Lay a son of as looks like this. And for a Samba, I think, also looks like this.
He's not hitting me, okay. Okay. So basically, you can press all your stuff,
it defines storage solutions into this kind of architecture. And I find it pretty sad that we are all
kind of re-implementing these things. And as Open Cloud, we don't really want to become the
next software-defined storage, but in effect, we are. And I would like to change that and just
expose whatever software-defined storage is. They are make it accessible. That's the whole idea.
We should not be our, me should not be a storage. We should make storage accessible.
So regarding the two or the different storage drivers, I will only use two as an example. We have
decomposed of S, which kind of puts the POSIX file system on top of its head.
Because as I said, we need to address files by their ID. And the POSIX of S, which tries to integrate
with the underlying storage as good as it can. So back to properties that we need, or that our
end users are used to. Our sync algorithm is based on e-tech changes. And we need the storage
side to propagate the e-tech from a leaf that changed up to the root. Because that's how our
sync line detects and where it should navigate to to actually find the changes and synchronize them.
Indicum POSIFS, or when we just POSIX of S without watching, we have everything in our control,
all the requests go through our stack. We can propagate the changes ourselves, everything's nice,
but if we want to allow other processes to interact with our files in the POSIX scenario,
we need to be notified somehow. I mean, SFS has a recursive change time. We can use that.
That it's internally propagates slowly and then we can use that to synchronize that work.
Here's a three modification time TM time property that they are actually built for
own cloud 10 back in the day because they have their own back end. But local filesystems, well,
I'm not aware of any local filesystem that uses has this kind of property. Of course,
you can use change notifications, like I notify that allow us to then do the E-tech propagation
ourselves. We also need it for other things like the size tree aggregation, if we have something
changes, we can actually calculate the new size and propagate that up to the root so that end
users see in the web UI are. This is so many bytes in it. But I notify only works for one machine.
There are integrations like Samba that does expose this, but then we need to, if we now have
two or three instances of our software that all mount the same storage, they will all see
these notifications. So we get them even three times more. So it would be nicer if there was
some kind of queue that we could digest to see what happens on the storage. And that already exists.
So GPS has it as a Kafka queue. They have a file lock that we could also consume. That is
that is implemented. SFFFS, there is a company CROIT that built an event queue based on the metadata
service that we can consume. The guys from Lail storage, the SFFFS also have something for the metadata
service. Samba has no defy that we could use. So there are things we have a generic
not stream that we can consume. But yeah, this is something that we would really like to
like to have. Being notified of something changes so that we can actually populate ourselves.
The second most crucial thing, which goes back to being able to share links, is that fires
need to be addressable by ID. We need to be able to look them up by ID, not only for links,
but also for metadata. So every the data that we index has a file ID and we need to be able to look
up the file of the search result from the search index by ID because if somebody moves files around
these links should still work. There are some more details here, but I think I don't need to go
into the difference between decouples and POSIX. Maybe a little bit because the decouples
the file system since it stores files by their ID, that works without any other
and because all the requests go through our stack, we don't need to rely on any other system.
We don't need to be notified nothing, but if there is an external file system, we cannot use
the native properties of POSIX files because I know are typically reused. If you think about that,
we could just use the I know, no, if you delete a file and then create a new file, it might be
that the new file gets an older file ID that has been shared and now you would point to a new file
with completely different data and so that's not an option. So what we do is we write an extra
ID as an extended entry in the file and that's how we keep track of these files. So if you're using
the change notifications to detect if a file was renamed or if it's new or if it was deleted
and then we clean up our cache. Our cache, which we need to populate on start because it's really
a cache, it's not persisted, we just keep it and nuts for now. There are, we have ideas to actually
make it persistent, but then we would really be a software defined storage because then we would keep
all the metadata and we would no longer need to access files at all. We have trash, fire,
vision, snapshots and they all in the decomposed file systems, since we are in full control,
we can write new files to a new location, we can keep track of older visions that's all easy,
and we can keep track of trash, but in a POSIX file system, yes we can follow the free
desktop org trash specification, so we put files in a special location and that follows standards
that works, but fire revisions, the only fire system that has fire revisions is Windows and TFS.
So if somebody knows the fire system that has revisions looking at you, some Bob. No,
okay that would be cool. So and but a lot of fire system supports snapshots.
SEPFS, actually you can use the SEPFS with snapshots without us doing anything, if you know how
that works, but it might be a good idea for us to expose that, oh by the way you could do a snapshot
on this fire system, that's something that we haven't explored yet because end users are still
used to the file individual revisions that we have. Tree size aggregation is the idea of being able
to see how deep how many bytes are below this tree, and again endigopol service since we have
we are in control, everything's fine, but in POSIX service we have to actually maintain that,
but we can do that with the change notifications, which we need as well for the e-tech or change
propagation or the ten-time propagation, and we do that in the same step. So when something changes,
we not only propagate the change time, but also the new size of the folder up to the root.
SEPFS and EOS both have recursive change, time, a recursive size, what do they call it?
SEPFS calls it recursive counting, and it's the mount option that you have to set, but then it
actually does that. So a lot of software defines dodges, have properties already out there,
and we are kind of re-implementing them. That's annoying. The last point, metadata indexing
is probably not something that software defined storages will implement because it might be out of
their domain, but whenever a finds a file change, we actually index them, we look at the metadata,
and eventually we can index them via TKA, and expect content also to OCR, which takes a while,
if you have thousands of pictures, but that's actually nice because we can search for anything.
But it would be great if the software defined storage, if there is a software defined search,
that has some kind of metadata index that we can query. I mean, yeah, that means so we are using
a badger DB or open search, which was the elastic search, for this reverse lookup and metadata
but I guess we could combine there. If there is something used in the storage system,
if there is a reverse index somewhere, maybe we can integrate there. And then there is wishful thinking,
I thought, because our end users are using the web UI, they can only probably see 30 files or so,
which is a performance bottleneck when you have a directory with 10,000 files,
it doesn't sound much, but in the web UI, we have to fetch that via web DAF, and dozens of properties,
and then this request of please give me this folder becomes like megabytes big and that is really annoying.
So I would really like to save some time and only get the files that we need to have a
paginated directory listing, and I already heard that the Sambi can do that, so I will look
it to that, but are there any other software defined storage solutions that can give me a paginated
directory listing, probably even only specific properties sorted by namesize or change time,
that would be my wishful thinking. So if there is nothing out there, where would I propose that,
where would I go to? I can come here next year, so if you have any ideas, ping me.
And then the question is how do we interact with these systems? Currently, we are using
POSICS, CISCOLDS, which is kind of slow, at least when we compare it,
when we're talking about network file systems, because they have to do caching, and then we get caching
consistency, which we don't want, so we actually cache all the metadata of files in nuts and
talking, and we're doing a directory listing and doing 1,000 calls to nuts as faster than
doing 1,000 CISCOLDS in our case. And I think is there is a software defined storage that
actually has some other kind of API, deals from a certain, for example, has a GRPC API that we could use,
I think CIFFS has lipsIFFS, which we can use, so there are other options, and I would really
like to hear of those. Yeah, maybe the idea was, if somebody is working on software behind
storage, shouldn't we all organize, or should we come together and define some kind of API that
we all implement, or that you all implement, that we then can consume, not only we, but maybe others as
well, and be notified of change notifications, and these things like files as to maybe I call it.
I don't know if maybe this is 3 API, which is an API which is GRPC based, that's developed in
the scientific world, is an option there, and I can only invite you to come to the talk and
awesome, of the CISC conference, but trying to find ideas and ways forward to better connect these things
together. So, yeah, we don't want to become the next software defined storage, because there are
good solutions up there, and I really want to expose them and make them accessible to the outside
world with a nice UI, and there's so client's mobile clients, so yeah, let's get in contact,
and talk to me, find me, you will add putonic, basically everywhere you see, add putonic, let's me,
and my email address is here as well, so you will know how to find me, that's all good, doesn't
make sense. Thank you.
Happy to dive into any questions.
Have I just talked about sharing?
Only about, yeah, I haven't talked about sharing, I was mentioning public links, that's the
part that is, that works with every POSICS file system, because we can always make files accessible
via public links, and that they don't, they mustn't break if something changes on the
POSICS file system, if paths change, if you're talking about sharing between users on an instance,
the interesting thing is that requires even more integration with the underlying storage,
not only the storage, but the user management system, so we can integrate and allow people,
we can actually support using the group ID of a user to change on the files that are written by
him, so you can configure a space to say, okay, or you can configure open cloud, to always change
on the files in a specific space, to be owned by the owner of the root of that space, so that
all the files that are written in that space will always are grouped on by the same user, but that
it always requires a better integration with the underlying storage system, and the user management,
and for guest users, that's then the question, how do you organize that if a user is provisioned?
Do you have, do we have the permission to create a new user and the customer's
identity management system on the fly kind of? That's rarely the case, they usually have processes
that they follow to onboard new users, but then it's possible to actually integrate and take
existing users and make files on the files system, visually be owned by the user and group,
that actually is in the system, but it's the full circle, the identity provider needs to actually
tie to the elder server, needs to be tied to the storage system, needs to be available in the systems,
so that's cool, it does work, but yeah, it's challenging. Thank you, more questions.
So the question is if we work without that scope, we absolutely require not, we require some kind of
cash, and I'm aware of the jeps and report, yes. I'm aware of the jeps and report on not, yes.
Thank you. What is not actually? Not as a key value store, actually it's a streaming
solution that is native to Kubernetes, cloud-nated environments, and built on streaming, they implemented
a key value store and an object store, and we only use it for cashing. We could have used it,
we are using it like radius, and we are using it as our event queue internally, and it's
it's a really nice, it works really well in Kubernetes, and if you deploy it on via compose,
then we are just using a build and nuts, you can embed it, so for us it's a really nice solution.
Any more questions?
Yes, please. I think that's the comment, because if you want to cash back, I think that for
the record listings, I can recommend talking to S&E store, the cloud-nated director uses, which means
that you open the end of the record to list it, and to hold on this record even any big changes,
but that's called again cashing. Nice. Yeah, we should definitely talk now, right?
Yeah, the question was, if the comment was that if I want to use a look into some
cashing and notifications, some of us has even more nice things, that's really cool. Yeah, thank you.
Any other thing? Any other self-defined storage solutions that I don't know of?
Okay, I guess that's it, and then let's begin.
Thank you.