Hi John, On Sun, Mar 11, 2018 at 12:55 PM, John Spray <jspray@xxxxxxxxxx> wrote: > On Sat, Mar 10, 2018 at 12:21 AM, Gregory Farnum <gfarnum@xxxxxxxxxx> wrote: >> On Fri, Mar 9, 2018 at 3:44 PM, Sage Weil <sweil@xxxxxxxxxx> wrote: >>> On Fri, 9 Mar 2018, Casey Bodley wrote: >>>> On 03/09/2018 11:55 AM, Sage Weil wrote: >>>> > On Fri, 9 Mar 2018, Casey Bodley wrote: >>>> > > I haven't done much with ceph-ansible, but I'm imagining it looking like >>>> > > this: >>>> > > >>>> > > In the rgw configuration, we'd have a variable like >>>> > > radosgw_management_user >>>> > > that would trigger a 'radosgw-admin user create' command to create it and >>>> > > remember its keys for use during the ceph-mgr deployment. >>>> > > >>>> > > If the ceph-mgr deployment has to happen first, it could always generate >>>> > > its >>>> > > own secret/access keys (which is trivial to do), and supply them later >>>> > > during >>>> > > rgw deployment via 'radosgw-admin user create --access-key=X --secret=Y'. >>>> > I think this is missing the bigger picture. Setting aside the key issue >>>> > for a minute, there needs to be some API endpoint that allows you to >>>> > manipulate the zones/zone groups/realms (e.g., to create the radosgw >>>> > cluster to begin with). Creating an initial key for that zone is just one >>>> > piece of that. >>>> > >>>> > For example, a dashboard user should be able to click on the RGW tab and >>>> > create a new realm or zone and then kick off work to instantiate the >>>> > radosgw daemons to serve it (via kubernetes, ansible, or whatever). >>>> >>>> Hi Sage, >>>> >>>> I didn't know that we were looking to drive new cluster deployments through >>>> ceph-mgr. But I think that the multisite configuration steps to make that work >>>> belong in the deployment tool itself. Ali has done work on this for >>>> ceph-ansible at https://github.com/ceph/ceph-ansible/pull/1944, which runs all >>>> of the radosgw-admin commands on the new cluster to add it to an existing >>>> multisite realm. >>> >>> I think the general goal is that any management functions beyond the >>> initial bootstrap of the cluster (mon + mgr) can be driven via the >>> management ui. But even setting aside the multi-cluster parts, the very >>> first thing I would expect to see on the RGW pane of the dashboard is a >>> via of the realms, zonegroups, and zones, with a bunch of 'create' >>> buttons. And the first thing you'd see on a fresh cluster is no zones--I >>> don't think we want to force the user to predeclare that they will be >>> creating a new realm/zg/zone when they create the cluster. >>> >>> Even for the multi-cluster parts, I would expect to see a limited view of >>> that state. The RBD panel, for instance, shows all the rbd-mirror >>> daemons and their state. Operations like switching masters or >>> triggering a period change or whatever seem like a natural fit here. >>> >>> Even if we decide these operations don't fit or don't belong in the >>> per-cluster dashboard, we'll want them in some meta-dashbaord (e.g., >>> cloudforms), and we'll want an API that that system can trigger to make >>> things happen. That could be ansible, yes, but it seems like we'd want >>> to keep our options open. >> >> Wanted to pull this out a little more and see if everybody's on the same page. >> >> John, your initial email was very specific (so much though that I'm >> not entirely sure what actual problem you're interested in here, >> though I think the admin API being discussed is how we create RGW >> users?). >> >> But I'd assume one of the most basic functions the manager is >> interested in is creating new RGW instances within a cluster, whether >> there's already an RGW zone or whether the admin just clicked a >> "create S3 service" button. > > Yep. While this thread was prompted by a very specific issue > (dashboard uses admin rest api, but needs a way to learn where the API > is and how to authenticate), the general context is that we would like > to create a user interface that enables people to manage their Ceph > clusters with a minimum of typing. > +1 > We already have the interfaces the UI needs for CephFS (libcephfs and > mon commands) and RBD (librbd), and *most* of RGW (admin rest api). > I'd like RGW to be just as much of a first class citizen in the UI as > everything else, which is my motivation for looking for ways to avoid > requiring extra out-of-band configuration before users can do RGW > stuff in the UI. > I think we can have a very small library for just the initial bootstrap phase, this won't require to wrap all radosgw-admin code but to cut a small section out that can be shared as a library between the radosgw-admin, ceph-mgr and the dashboard. As for the realms/zone groups/zones (multisite) configuration I would suggest using Rest API as there are users that need such rest API anyway (they use their own in house management UI). Will that work for you? Regards, Orit > John > >> As a comparison, the ongoing work to integrate CephFS, NFS-Ganesha, >> and OpenStack is planning to have the manager automatically generate >> new Ganesha instances as needed (by calling in to Kubernetes container >> creation, which it will rely on). ceph-ansible might or might not have >> something to do with that cluster having existed, but as far as the >> admin is concerned ansible does not matter when creating cloud shares. >> >> Presumably we want to eventually be able to deploy RGW on existing >> clusters the same way, via push buttons and automatic scaling where >> appropriate, instead of having admins responsible for running a CLI to >> enable each instance? Or am I just completely misunderstanding the >> goals here? :) >> -Greg -- 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
