On Tue, Jun 20, 2017 at 4:40 PM, Nathan Cutler <ncutler@xxxxxxx> wrote:
>> For upstream testing of ceph-volume (if it
>> existed outside ceph.git) you'd simply install it with pip.
>
>
> Like, e.g., setuptools? Always use the latest version, and you're fine?
>
> Seriously, this would be OK if the ceph-volume maintainers ensure that every
> new release is thoroughly regression-tested against all stable versions of
> Ceph that are in maintenance at the time and agree not to roll out any
> non-backward-compatible features (?).
>
> I recall that with ceph-deploy we did get into a situation where the latest
> version did not support hammer, so hammer users could not simply grab the
> latest version of ceph-deploy. (I guess that has been fixed in the
> meantime?) Users had to "know" which version played nice with hammer and
> grab that one specifically. Also, whatever bugs were in that version, they
> were stuck with because nothing is backported.
ceph-deploy always supported up until the EOL'd versions. Not sure
what specific issue you are referring to.
I wasn't implying that there were no bugs in ceph-deploy :)
>
> I suppose the Ceph project could do the same - just maintain a single
> codestream ("master") and cut releases from time to time. It would be a lot
> simpler! And if a distro wanted to backport fixes to a previous release,
> nothing to stop them, right? But for some reason the Ceph project goes
> through the trouble to maintain multiple codestreams. And doesn't the Linux
> kernel project maintains stable branches, too?
>
Bummer, again, I wasn't implying such a thing (sarcasm?)
> Maintaining stable branches is a lot of work, so there must be good reasons
> for it. One reason I can think of is that it becomes possible to implement
> non-backward-compatible features in mainline/master, yet folks who value
> stability (i.e. distros and the vast majority of users) can continue to use
> the older codestreams and benefit from bugfixes that get backported.
>
I agree with you, stable branches is a lot of work, and the ceph
backporting team does a lot of excellent
work here. None of my comments should be read otherwise.
My position is that a small, python-only, with no direct bindings to
Ceph other than the CLI, should probably have the
freedom of staying out of tree, and that it can keep up with older
versions, and release often when bugs come up (as you've mentioned
happened
with ceph-deploy)
> Nathan
>
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
