6 May
2021
6 May
'21
2:58 a.m.
Hi all,
Highlights from this weeks' CLT meeting:
- Can we deprecate ceph-nano?
- Yes; it is no longer maintained. Josh will note as much in the
README and archive this and other old repos in the github org.
- ceph-adm replaces most use cases since it supports
containerization and deployment onto a single host. Team will explore
supporting OSDs on loopback devices, which is the main differentiator.
- Discussed the Redmine tracker triage process and considered removing
the top-level "Ceph" project from the list of available new ticket
destinations. I and others pushed back on this since we need a place
to put non-subproject-specific issues, so we agreed that going forward
project leads will scrub the top-level Ceph project for new relevant
issues during their regular bug scrubs. I took an action item to go
through the existing back log and sort it appropriately (though I also
think Sage did a bunch this morning).
- We added a COSI repository in the Ceph org for working with RGW.
- Pacific v16.2.2 needed release notes review, which it got so the
release is out now.
- We got a question about new options for the dashboard and other
component communication, following on from the CDS sessions. Ernesto
will follow up on this.
-Greg
6 May
6 May
11:21 a.m.
Inline:
Thanks!
–––––––––
Sébastien Han
Senior Principal Software Engineer, Storage Architect
"Always give 100%. Unless you're giving blood."
On Thu, May 6, 2021 at 12:29 AM Gregory Farnum <gfarnum(a)redhat.com> wrote:
Hi all,
Highlights from this weeks' CLT meeting:
- Can we deprecate ceph-nano?
- Yes; it is no longer maintained. Josh will note as much in the
README and archive this and other old repos in the github org.
- ceph-adm replaces most use cases since it supports
containerization and deployment onto a single host. Team will explore
supporting OSDs on loopback devices, which is the main differentiator.
Small correction, ceph-nano does not use loopback devices, it runs
"ceph-osd --mkfs" on a directory and optionally can take block device
if provided.
As gaps I can see:
* cephadm does not have multi-clusters support. With cn you can run as
many clusters with any Ceph version.
* cephadm only runs on Linux, where cn can run on any OS that has a
Docker daemon running
Otherwise, I'm fine with archiving the repository. However, there is
still a lot of interest, I'm frequently getting e-mail about it so we
should make it clear that cephadm replaces it.
Also, are we ok to lose the audience of non-Linux users? I believe it
makes a good portion of the user base.
FYI I just archived https://github.com/ceph/cn-core which goal was to
use a Golang based bootstrapper instead of the demo.sh script from
ceph-container.
- Discussed the Redmine tracker triage process and considered removing
the top-level "Ceph" project from the list of available new ticket
destinations. I and others pushed back on this since we need a place
to put non-subproject-specific issues, so we agreed that going forward
project leads will scrub the top-level Ceph project for new relevant
issues during their regular bug scrubs. I took an action item to go
through the existing back log and sort it appropriately (though I also
think Sage did a bunch this morning).
- We added a COSI repository in the Ceph org for working with RGW.
- Pacific v16.2.2 needed release notes review, which it got so the
release is out now.
- We got a question about new options for the dashboard and other
component communication, following on from the CDS sessions. Ernesto
will follow up on this.
-Greg
_______________________________________________
Dev mailing list -- dev(a)ceph.io
To unsubscribe send an email to dev-leave(a)ceph.io
1:49 p.m.
Hi Sebastien!
Am 06.05.21 um 08:51 schrieb Sebastien Han:
Inline:
Thanks!
–––––––––
Sébastien Han
Senior Principal Software Engineer, Storage Architect
"Always give 100%. Unless you're giving blood."
On Thu, May 6, 2021 at 12:29 AM Gregory Farnum <gfarnum(a)redhat.com> wrote:
cephadm is not a 100% replacement for ceph-nano, indeed. My
idea was to consolidate things a bit and provide a fully supported
alternative.
Hi all,
Highlights from this weeks' CLT meeting:
- Can we deprecate ceph-nano?
- Yes; it is no longer maintained. Josh will note as much in the
README and archive this and other old repos in the github org.
- ceph-adm replaces most use cases since it supports
containerization and deployment onto a single host. Team will explore
supporting OSDs on loopback devices, which is the main differentiator.
Small
correction, ceph-nano does not use loopback devices, it runs
"ceph-osd --mkfs" on a directory and optionally can take block device
if provided. As gaps I can see:
* cephadm does not have multi-clusters support.
It does actually. If you're a
bit careful with the bootstrap arguments (like
avoding port conflicts), you can have more than a single cluster.
* With cn you can run as many clusters with any Ceph
version.
Right, we have a dependency on the major Ceph version.
* cephadm only runs on Linux, where cn can run on any
OS that has a
Docker daemon running
Accidentally, I had a discussion with someone who was
interested in
porting cephadm to FreeBSD. But yes, cephadm makes use of systemd.
Otherwise, I'm fine with archiving the repository. However, there is
still a lot of interest, I'm frequently getting e-mail about it so we
should make it clear that cephadm replaces it.
Also, are we ok to lose the audience of non-Linux users? I believe it
makes a good portion of the user base.
That's Windows, right?
FYI I just archived https://github.com/ceph/cn-core which goal was to
use a Golang based bootstrapper instead of the demo.sh script from
ceph-container.
- Discussed the Redmine tracker triage process
and considered removing
the top-level "Ceph" project from the list of available new ticket
destinations. I and others pushed back on this since we need a place
to put non-subproject-specific issues, so we agreed that going forward
project leads will scrub the top-level Ceph project for new relevant
issues during their regular bug scrubs. I took an action item to go
through the existing back log and sort it appropriately (though I also
think Sage did a bunch this morning).
- We added a COSI repository in the Ceph org for working with RGW.
- Pacific v16.2.2 needed release notes review, which it got so the
release is out now.
- We got a question about new options for the dashboard and other
component communication, following on from the CDS sessions. Ernesto
will follow up on this.
-Greg
_______________________________________________
Dev mailing list -- dev(a)ceph.io
To unsubscribe send an email to dev-leave(a)ceph.io
_______________________________________________
Dev mailing list -- dev(a)ceph.io
To unsubscribe send an email to dev-leave(a)ceph.io
2:52 p.m.
Hi Sebastian!
Thanks!
–––––––––
Sébastien Han
Senior Principal Software Engineer, Storage Architect
"Always give 100%. Unless you're giving blood."
On Thu, May 6, 2021 at 11:19 AM Sebastian Wagner <sewagner(a)redhat.com> wrote:
Both Windows and MacOS, have Docker on {Mac|Window}, which are really popular.
Losing such an audience wouldn't be good, since a lot of non-technical
people are still using cn for demos I believe, regardless of which
platform they are running on.
Hi Sebastien!
Am 06.05.21 um 08:51 schrieb Sebastien Han:
Agreed, however, cn's goal was to be frictionless, assuming people do
not need to know about port conflicting or internal details.
it'd be nice if cephadm could change the port automatically if a mon
is already running (which I assume is the most problematic issue).
Inline:
Thanks!
–––––––––
Sébastien Han
Senior Principal Software Engineer, Storage Architect
"Always give 100%. Unless you're giving blood."
On Thu, May 6, 2021 at 12:29 AM Gregory Farnum <gfarnum(a)redhat.com> wrote:
cephadm is not a 100% replacement for ceph-nano, indeed. My
idea was to consolidate things a bit and provide a fully supported
alternative.
Hi all,
Highlights from this weeks' CLT meeting:
- Can we deprecate ceph-nano?
- Yes; it is no longer maintained. Josh will note as much in the
README and archive this and other old repos in the github org.
- ceph-adm replaces most use cases since it supports
containerization and deployment onto a single host. Team will explore
supporting OSDs on loopback devices, which is the main differentiator.
Small
correction, ceph-nano does not use loopback devices, it runs
"ceph-osd --mkfs" on a directory and optionally can take block device
if provided. As gaps I can see:
* cephadm does not have multi-clusters support.
It does actually. If you're a
bit careful with the bootstrap arguments (like
avoding port conflicts), you can have more than a single cluster. * With cn you can run as many clusters with any
Ceph version.
Right, we have a dependency on the major Ceph version.
* cephadm only runs on Linux, where cn can run on
any OS that has a
Docker daemon running
Accidentally, I had a discussion with someone who was
interested in
porting cephadm to FreeBSD. But yes, cephadm makes use of systemd.
Otherwise, I'm fine with archiving the repository. However, there is
still a lot of interest, I'm frequently getting e-mail about it so we
should make it clear that cephadm replaces it.
Also, are we ok to lose the audience of non-Linux users? I believe it
makes a good portion of the user base.
That's Windows, right?
FYI I just archived https://github.com/ceph/cn-core which goal was to
use a Golang based bootstrapper instead of the demo.sh script from
ceph-container.
- Discussed the Redmine tracker triage process
and considered removing
the top-level "Ceph" project from the list of available new ticket
destinations. I and others pushed back on this since we need a place
to put non-subproject-specific issues, so we agreed that going forward
project leads will scrub the top-level Ceph project for new relevant
issues during their regular bug scrubs. I took an action item to go
through the existing back log and sort it appropriately (though I also
think Sage did a bunch this morning).
- We added a COSI repository in the Ceph org for working with RGW.
- Pacific v16.2.2 needed release notes review, which it got so the
release is out now.
- We got a question about new options for the dashboard and other
component communication, following on from the CDS sessions. Ernesto
will follow up on this.
-Greg
_______________________________________________
Dev mailing list -- dev(a)ceph.io
To unsubscribe send an email to dev-leave(a)ceph.io
_______________________________________________
Dev mailing list -- dev(a)ceph.io
To unsubscribe send an email to dev-leave(a)ceph.io
4:28 p.m.
Hi Sebastien
Am 06.05.21 um 12:22 schrieb Sebastien Han:
Both Windows and MacOS, have Docker on {Mac|Window},
which are really popular.
Losing such an audience wouldn't be good, since a lot of non-technical
people are still using cn for demos I believe, regardless of which
platform they are running on.
Do you have any idea? Porting cephadm to Windows isn't going to be
trivial. Wait, what? AFAIK we don't have native ceph binaries for
Windows. Guess it's WSL then?
Hi Sebastian!
Thanks!
–––––––––
Sébastien Han
Senior Principal Software Engineer, Storage Architect
"Always give 100%. Unless you're giving blood."
On Thu, May 6, 2021 at 11:19 AM Sebastian Wagner <sewagner(a)redhat.com> wrote:
Yeah, multi-cluster support requires some love indeed. We had different
priorities.
Hi Sebastien!
Am 06.05.21 um 08:51 schrieb Sebastien Han:
Agreed, however,
cn's goal was to be frictionless, assuming people do
not need to know about port conflicting or internal details.
it'd be nice if cephadm could change the port automatically if a mon
is already running (which I assume is the most problematic issue). Inline:
Thanks!
–––––––––
Sébastien Han
Senior Principal Software Engineer, Storage Architect
"Always give 100%. Unless you're giving blood."
On Thu, May 6, 2021 at 12:29 AM Gregory Farnum <gfarnum(a)redhat.com> wrote:
cephadm is not a 100% replacement for ceph-nano, indeed. My
idea was to consolidate things a bit and provide a fully supported
alternative.
Hi all,
Highlights from this weeks' CLT meeting:
- Can we deprecate ceph-nano?
- Yes; it is no longer maintained. Josh will note as much in the
README and archive this and other old repos in the github org.
- ceph-adm replaces most use cases since it supports
containerization and deployment onto a single host. Team will explore
supporting OSDs on loopback devices, which is the main differentiator.
Small
correction, ceph-nano does not use loopback devices, it runs
"ceph-osd --mkfs" on a directory and optionally can take block device
if provided. As gaps I can see:
* cephadm does not have multi-clusters support.
It does actually. If you're a
bit careful with the bootstrap arguments (like
avoding port conflicts), you can have more than a single cluster. * With cn you can run as many clusters with any
Ceph version.
Right, we have a dependency on the major Ceph version.
* cephadm only runs on Linux, where cn can run on
any OS that has a
Docker daemon running
Accidentally, I had a discussion with someone who was
interested in
porting cephadm to FreeBSD. But yes, cephadm makes use of systemd.
Otherwise, I'm fine with archiving the
repository. However, there is
still a lot of interest, I'm frequently getting e-mail about it so we
should make it clear that cephadm replaces it.
Also, are we ok to lose the audience of non-Linux users? I believe it
makes a good portion of the user base.
That's Windows, right?
>> FYI I just archived https://github.com/ceph/cn-core which goal was to
>> use a Golang based bootstrapper instead of the demo.sh script from
>> ceph-container.
>>
>>> - Discussed the Redmine tracker triage process and considered removing
>>> the top-level "Ceph" project from the list of available new ticket
>>> destinations. I and others pushed back on this since we need a place
>>> to put non-subproject-specific issues, so we agreed that going forward
>>> project leads will scrub the top-level Ceph project for new relevant
>>> issues during their regular bug scrubs. I took an action item to go
>>> through the existing back log and sort it appropriately (though I also
>>> think Sage did a bunch this morning).
>>>
>>> - We added a COSI repository in the Ceph org for working with RGW.
>>> - Pacific v16.2.2 needed release notes review, which it got so the
>>> release is out now.
>>> - We got a question about new options for the dashboard and other
>>> component communication, following on from the CDS sessions. Ernesto
>>> will follow up on this.
>>>
>>> -Greg
>>> _______________________________________________
>>> Dev mailing list -- dev(a)ceph.io
>>> To unsubscribe send an email to dev-leave(a)ceph.io
>>>
>> _______________________________________________
>> Dev mailing list -- dev(a)ceph.io
>> To unsubscribe send an email to dev-leave(a)ceph.io
4:41 p.m.
Thanks!
–––––––––
Sébastien Han
Senior Principal Software Engineer, Storage Architect
"Always give 100%. Unless you're giving blood."
On Thu, May 6, 2021 at 1:59 PM Sebastian Wagner <sewagner(a)redhat.com> wrote:
Hi Sebastien
Am 06.05.21 um 12:22 schrieb Sebastien Han:
Both Windows and MacOS, have Docker on {Mac|Window},
which are really popular.
Losing such an audience wouldn't be good, since a lot of non-technical
people are still using cn for demos I believe, regardless of which
platform they are running on.
Do you have any idea? Porting cephadm to Windows isn't going to be
trivial. Wait, what? AFAIK we don't have native ceph binaries for
Windows. Guess it's WSL then?
Yes yes it's the WSL 2 driver, Docker runs inside a VM :)
cn internally uses the Docker API to manipulate the container(s), so
we don't even need a docker binary on Windows!
Hi Sebastian!
Thanks!
–––––––––
Sébastien Han
Senior Principal Software Engineer, Storage Architect
"Always give 100%. Unless you're giving blood."
On Thu, May 6, 2021 at 11:19 AM Sebastian Wagner <sewagner(a)redhat.com> wrote:
Yeah, multi-cluster support requires some love indeed. We had different
priorities.
Hi Sebastien!
Am 06.05.21 um 08:51 schrieb Sebastien Han:
Agreed, however,
cn's goal was to be frictionless, assuming people do
not need to know about port conflicting or internal details.
it'd be nice if cephadm could change the port automatically if a mon
is already running (which I assume is the most problematic issue). Inline:
Thanks!
–––––––––
Sébastien Han
Senior Principal Software Engineer, Storage Architect
"Always give 100%. Unless you're giving blood."
On Thu, May 6, 2021 at 12:29 AM Gregory Farnum <gfarnum(a)redhat.com> wrote:
> Hi all,
>
> Highlights from this weeks' CLT meeting:
>
> - Can we deprecate ceph-nano?
> - Yes; it is no longer maintained. Josh will note as much in the
> README and archive this and other old repos in the github org.
> - ceph-adm replaces most use cases since it supports
> containerization and deployment onto a single host. Team will explore
> supporting OSDs on loopback devices, which is the main differentiator.
Small correction, ceph-nano does not use loopback devices, it runs
"ceph-osd --mkfs" on a directory and optionally can take block device
if provided.
cephadm is not a 100% replacement for ceph-nano, indeed. My
idea was to consolidate things a bit and provide a fully supported
alternative.
As gaps I can see:
* cephadm does not have multi-clusters support.
It does actually. If you're a
bit careful with the bootstrap arguments (like
avoding port conflicts), you can have more than a single cluster. * With cn you can run as many clusters with any
Ceph version.
Right, we have a dependency on the major Ceph version.
* cephadm only runs on Linux, where cn can run on
any OS that has a
Docker daemon running
Accidentally, I had a discussion with someone who was
interested in
porting cephadm to FreeBSD. But yes, cephadm makes use of systemd.
Otherwise, I'm fine with archiving the
repository. However, there is
still a lot of interest, I'm frequently getting e-mail about it so we
should make it clear that cephadm replaces it.
Also, are we ok to lose the audience of non-Linux users? I believe it
makes a good portion of the user base.
That's Windows, right?
>> FYI I just archived https://github.com/ceph/cn-core which goal was to
>> use a Golang based bootstrapper instead of the demo.sh script from
>> ceph-container.
>>
>>> - Discussed the Redmine tracker triage process and considered removing
>>> the top-level "Ceph" project from the list of available new ticket
>>> destinations. I and others pushed back on this since we need a place
>>> to put non-subproject-specific issues, so we agreed that going forward
>>> project leads will scrub the top-level Ceph project for new relevant
>>> issues during their regular bug scrubs. I took an action item to go
>>> through the existing back log and sort it appropriately (though I also
>>> think Sage did a bunch this morning).
>>>
>>> - We added a COSI repository in the Ceph org for working with RGW.
>>> - Pacific v16.2.2 needed release notes review, which it got so the
>>> release is out now.
>>> - We got a question about new options for the dashboard and other
>>> component communication, following on from the CDS sessions. Ernesto
>>> will follow up on this.
>>>
>>> -Greg
>>> _______________________________________________
>>> Dev mailing list -- dev(a)ceph.io
>>> To unsubscribe send an email to dev-leave(a)ceph.io
>>>
>> _______________________________________________
>> Dev mailing list -- dev(a)ceph.io
>> To unsubscribe send an email to dev-leave(a)ceph.io
1103
days inactive
1104
days old
5 comments
3 participants
participants (3)
-
Gregory Farnum -
Sebastian Wagner -
Sebastien Han