Hi,
On 9/13/18 1:42 PM, Jason Dillaman wrote:
On Thu, Sep 13, 2018 at 6:39 AM Lenz Grimmer <lgrimmer@xxxxxxxx> wrote:
Hi all,
$SUBJECT is one of the features that we would like to tackle for the
Nautilus release, in order to reach feature parity with openATTIC.
I filed a feature issue on the tracker about this here:
https://tracker.ceph.com/issues/35903
FYI, I'm currently assigned to this task.
I would like to briefly summarize our approach, to verify we're on the
right track and we're in alignment with other ongoing upstream efforts.
For the initial implementation, we assume that an iSCSI target node has
already been deployed and set up by some installation/orchestration tool
(e.g. Ceph-Ansible, DeepSea).
For creating and managing the actual iSCSI targets, we intend to
communicate with the REST API provided by the ceph-iscsi-cli tool:
https://github.com/ceph/ceph-iscsi-cli/blob/master/rbd-target-api.py
Great. Since this REST API isn't currently versioned (for the same
reasons as the dashboard REST API), I think there might be some value
in having the dashboard interact w/ a "rbd-target-client"-like module
that abstracts away all the REST calls under a clean and mockable API.
Otherwise, I think we would want to make sure we keep an up-to-date
test case in the ceph-iscsi-cli repo against all the REST APIs that
the dashboard is invoking.
Yes, having a dedicated API in `ceph-iscsi-cli` that is used by
dashboard to abstract the underlying REST calls, may be easier to
maintain. I'll try this approach.
Anyway, currently `ceph-iscsi-cli` only supports one iSCSI target, so
I'm afraid we will have to change the underlying configuration schema
(`gateway.conf`) to support multiple targets, in order to reach feature
parity with the openATTIC UI.
The UI will be derived from the openATTIC iSCSI target management
implementation, using a different backend approach.
As far as I know, there is currently some ongoing discussion about
choosing between the userland iSCSI service (TCMU runner) and the kernel
based implementation. Does anyone know which direction this discussion
is heading and if it will have any impact on our implementation?
The custom kernel patches in SUSE to support the kernel-based
implementation is still blocked from being merged into the upstream
kernel until a "librbd"-like kernel module is developed to provide
shared RBD handling between the krbd block driver and LIO target
backend. I know David Disseldorp had expressed some interest in
tackling this, but I don't know its current status.
Regardless, I think the existing ceph-iscsi-XYX userland tooling can
be quickly adapted to transparently support both the SUSE
implementation and the upstream implementation of RBD over iSCSI.
I hope that the RBD target API will sufficiently encapsulate this
implementation detail, so we don't have to change anything major
depending on where things are heading, but it would be nice to have some
confirmation about this.
One downstream concern that we have to address is that we require all
Python code to be Python 3 ready. We haven't tested this yet, but I have
the suspicion that the two required Python projects (ceph-iscsi-cli and
ceph-iscsi-config) haven't been ported to Python 3 yet, correct?
They have previously passed python3 flake8 tests, so I wouldn't expect
too many issues.
Thanks,
Lenz
--
SUSE Linux GmbH - Maxfeldstr. 5 - 90409 Nuernberg (Germany)
GF:Felix Imendörffer,Jane Smithard,Graham Norton,HRB 21284 (AG Nürnberg)
--
Jason
--
Best Regards,
Ricardo Marques
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)
