On Mon, Jun 19, 2017 at 11:37 AM, Willem Jan Withagen <w...@digiware.nl> wrote:
> On 19-6-2017 16:13, Alfredo Deza wrote:
>> On Mon, Jun 19, 2017 at 9:27 AM, John Spray <jsp...@redhat.com> wrote:
>>> On Fri, Jun 16, 2017 at 7:23 PM, Alfredo Deza <ad...@redhat.com> wrote:
>>>> On Fri, Jun 16, 2017 at 2:11 PM, Warren Wang - ISD
>>>> <warren.w...@walmart.com> wrote:
>>>>> I would prefer that this is something more generic, to possibly support
>>>>> other backends one day, like ceph-volume. Creating one tool per backend
>>>>> seems silly.
>>>>>
>>>>> Also, ceph-lvm seems to imply that ceph itself has something to do with
>>>>> lvm, which it really doesn’t. This is simply to deal with the underlying
>>>>> disk. If there’s resistance to something more generic like ceph-volume,
>>>>> then it should at least be called something like ceph-disk-lvm.
>>>>
>>>> Sage, you had mentioned the need for "composable" tools for this, and
>>>> I think that if we go with `ceph-volume` we could allow plugins for
>>>> each strategy. We are starting with `lvm` support so that would look
>>>> like: `ceph-volume lvm`
>>>>
>>>> The `lvm` functionality could be implemented as a plugin itself, and
>>>> when we start working with supporting regular disks, then `ceph-volume
>>>> disk` can come along, etc...
>>>>
>>>> It would also open the door for anyone to be able to write a plugin to
>>>> `ceph-volume` to implement their own logic, while at the same time
>>>> re-using most of what we are implementing today: logging, reporting,
>>>> systemd support, OSD metadata, etc...
>>>>
>>>> If we were to separate these into single-purpose tools, all those
>>>> would need to be re-done.
>>>
>>> Couple of thoughts:
>>> - let's keep this in the Ceph repository unless there's a strong
>>> reason not to -- it'll enable the tool's branching to automatically
>>> happen in line with Ceph's.
>>
>> For initial development this is easier to have as a separate tool from
>> the Ceph source tree. There are some niceties about being in-source,
>> like
>> not being required to deal with what features we are supporting on what
>> version.
>
> Just my observation, need not be true at all, but ...
>
> As long as you do not have it interact with the other tools, that is
> true. But as soon as you start depending on ceph-{disk-new,volume} in
> other parts of the mainstream ceph-code you have created a ty-in with
> the versioning and will require it to be maintained in the same way.
>
>
>> Although there is no code yet, I consider the project in an "unstable"
>> state, it will move incredibly fast (it has to!) and that puts it at
>> odds with the cadence
>> of Ceph. Specifically, these two things are very important right now:
>>
>> * faster release cycles
>> * easier and faster to test
>>
>> I am not ruling out going into Ceph at some point though, ideally when
>> things slow down and become stable.
>>
>> Is your argument only to have parity in Ceph's branching? That was
>> never a problem with out-of-tree tools like ceph-deploy for example.
>
> Some of the external targets move so fast (ceph-asible) that I have
> given up on trying to see what is going on. For this tool I'd like it to
> do the ZFS/FreeBSD stuff as a plugin-module.
> In the expectation that it will supersede the current ceph-disk,
> otherwise there are 2 place to maintain this type of code.
Yes, the idea is that it will be pluggable from the start, and that it
will supersede current ceph-disk (but not immediately)
>
>>> - I agree with others that a single entrypoint (i.e. executable) will
>>> be more manageable than having conspicuously separate tools, but we
>>> shouldn't worry too much about making things "plugins" as such -- they
>>> can just be distinct code inside one tool, sharing as much or as
>>> little as they need.
>>>
>>> What if we delivered this set of LVM functionality as "ceph-disk lvm
>>> ..." commands to minimise the impression that the tooling is changing,
>>> even if internally it's all new/distinct code?
>>
>> That sounded appealing initially, but because we are introducing a
>> very different API, it would look odd to interact
>> with other subcommands without a normalized interaction. For example,
>> for 'prepare' this would be:
>>
>> ceph-disk prepare [...]
>>
>> And for LVM it would possible be
>>
>> ceph-disk lvm prepare [...]
>>
>> The level at which these similar actions are presented imply that one
>> may be a preferred (or even default) one, while the other one
>> isn't.
>
> Is this about API "cosmetics"? Because there is a lot of examples
> suggestions and other stuff out there that is using the old syntax.
>
> And why not do a hybrid? it will require a bit more commandline parsing,
> but that is not a major dealbreaker.
>
> so the line would look like
> ceph-disk [lvm,zfs,disk,partition] prepare [...]
> and the first parameter is optional reverting to the current supported
> systems.
>
> You can always start warning users that their API usage is old style,
> and that it is going to go away in a next release.
>
>> At one point we are going to add regular disk worfklows (replacing
>> ceph-disk functionality) and then it would become even more
>> confusing to keep it there (or do you think at that point we could split?)
>
> The more separate you go, the more akward it is going to be when things
> start to melt together.
>
>>> At the risk of being a bit picky about language, I don't like calling
>>> this anything with "volume" in the name, because afaik we've never
>>> ever called OSDs or the drives they occupy "volumes", so we're
>>> introducing a whole new noun, and a widely used (to mean different
>>> things) one at that.
>>>
>>
>> We have never called them 'volumes' because there was never anything
>> to support something other than regular disks, the approach
>> has always been disks and partitions.
>>
>> A "volume" can be a physical volume (e.g. a disk) or a logical one
>> (lvm, dmcache). It is an all-encompassing name to allow different
>> device-like to work with.
>
> ZFS talks about volumes, vdev, partitions, .... and perhaps even more.
> Being picky: ceph-disk now also works on pre-build trees to build filestore.
>
Naming will continue to be the hardest part to get consensus on :) Of
course we could've just gone the other
way and pick something that has a nice ring to it, and nothing that
even hints at what it does :)
> I would just try to glue it into ceph-disk in the most flexible way
We can't "glue it into ceph-disk" because we are proposing a
completely new way of doing things that
go against how ceph-disk works.
> possible.
> --WjW
>
>>
>>
>>> John
>>>
>>>>
>>>>
>>>>>
>>>>> 2 cents from one of the LVM for Ceph users,
>>>>> Warren Wang
>>>>> Walmart ✻
>>>>>
>>>>> On 6/16/17, 10:25 AM, "ceph-users on behalf of Alfredo Deza"
>>>>> <ceph-users-boun...@lists.ceph.com on behalf of ad...@redhat.com> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> At the last CDM [0] we talked about `ceph-lvm` and the ability to
>>>>> deploy OSDs from logical volumes. We have now an initial draft for the
>>>>> documentation [1] and would like some feedback.
>>>>>
>>>>> The important features for this new tool are:
>>>>>
>>>>> * parting ways with udev (new approach will rely on LVM functionality
>>>>> for discovery)
>>>>> * compatibility/migration for existing LVM volumes deployed as
>>>>> directories
>>>>> * dmcache support
>>>>>
>>>>> By documenting the API and workflows first we are making sure that
>>>>> those look fine before starting on actual development.
>>>>>
>>>>> It would be great to get some feedback, specially if you are currently
>>>>> using LVM with ceph (or planning to!).
>>>>>
>>>>> Please note that the documentation is not complete and is missing
>>>>> content on some parts.
>>>>>
>>>>> [0] http://tracker.ceph.com/projects/ceph/wiki/CDM_06-JUN-2017
>>>>> [1] http://docs.ceph.com/ceph-lvm/
>>>>> _______________________________________________
>>>>> ceph-users mailing list
>>>>> ceph-users@lists.ceph.com
>>>>> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
>>>>>
>>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>>>> the body of a message to majord...@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
_______________________________________________
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
