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). Once we have a radosgw running and a key installed, then we can talk to the radosgw admin API. Relying on ansible to run CLI commands feels very backward here. If the radosgw-admin CLI is the only tool that can manipulate the realm and zone maps then it seems like that is the piece to fix? Am I missing something? sage > > On 03/09/2018 10:44 AM, Matt Benjamin wrote: > > What I think is being said is, "we need to create an RGW admin user in > > the default zone." > > > > Matt > > > > On Fri, Mar 9, 2018 at 10:40 AM, Alfredo Deza <adeza@xxxxxxxxxx> wrote: > > > On Fri, Mar 9, 2018 at 9:21 AM, Matt Benjamin <mbenjami@xxxxxxxxxx> wrote: > > > > Hi John, > > > > > > > > It's easy to build RGW as a library (we already do), but after > > > > discussion with many stakeholders, the strong preference was not to > > > > take this approach to integrate admin functions into ceph-mgr. > > > > Rather, we'd like to use the already-defined and supported admin rest > > > > interface. > > > > > > > > Casey and I had thought that a more extrinsic workflow, more like how > > > > keytabs and Ceph keyrings are managed, integrated into deployment > > > > logic, would be more the way key distribuion would work. I'd like to > > > > be part of a more complete discussion on why this wouldn't be the > > > > preferred approach. > > > Would this keyring workflow be something similar or *in addition to* > > > the current key management? > > > > > > From a deployment and configuration management perspective it would be > > > far easier to keep as close as current standards > > > vs. having a one off for just this one situation. > > > > > > > > > > I've personally gone back and forth on whether loading RGW logic in to > > > > ceph-mgr was useful, but I'm pretty well convinced of the case for not > > > > doing it for the main admin workflow, and find this workflow not much > > > > of a motivation for loading RGW, on the surface, at least. > > > > > > > > Matt > > > > > > > > On Fri, Mar 9, 2018 at 8:44 AM, John Spray <jspray@xxxxxxxxxx> wrote: > > > > > Hi Orit, > > > > > > > > > > Currently the dashboard folks (consuming RGW admin rest api) have > > > > > enough information in the ServiceMap to find the address of an RGW > > > > > service, but the authentication still requires the admin to configure > > > > > dashboard explicitly with some credentials. > > > > > > > > > > From chatting to Yehuda the other day, it seems like maybe this is a > > > > > good starting point for a librgw type thing that we can access from > > > > > python, where the initial functionality would just be sufficient to > > > > > configure authentication to talk to the admin rest api. > > > > > > > > > > Does this sound like a sensible approach? > > > > > > > > > > John > > > > > > > > > > > > -- > > > > > > > > Matt Benjamin > > > > Red Hat, Inc. > > > > 315 West Huron Street, Suite 140A > > > > Ann Arbor, Michigan 48103 > > > > > > > > http://www.redhat.com/en/technologies/storage > > > > > > > > tel. 734-821-5101 > > > > fax. 734-769-8938 > > > > cel. 734-216-5309 > > > > -- > > > > 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 > > -- 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
