From stewhite at redhat.com Sun Apr 10 12:16:03 2016 From: stewhite at redhat.com (stewhite at redhat.com) Date: Sun, 10 Apr 2016 08:16:03 -0400 Subject: [Kontinuity-dev-public] test msg to kontinuity-dev-public Message-ID: <201604101216.u3ACG39p006852@int-mx09.intmail.prod.int.phx2.redhat.com> test From alr at redhat.com Sun Apr 10 16:47:21 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Sun, 10 Apr 2016 12:47:21 -0400 Subject: [Kontinuity-dev-public] Test from Unsubscribed Message-ID: ALR test, ignore :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From alr at alrubinger.com Sun Apr 10 16:52:35 2016 From: alr at alrubinger.com (Andrew Lee Rubinger) Date: Sun, 10 Apr 2016 12:52:35 -0400 Subject: [Kontinuity-dev-public] Test from outside domain unsubscribed Message-ID: Ignore. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From alr at redhat.com Fri Apr 15 00:11:07 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Thu, 14 Apr 2016 20:11:07 -0400 Subject: [kontinuity-dev-public] Creating a Project on Behalf of Users Message-ID: So the Catapult project will be creating OpenShift projects for its users. At the moment we're doing this by logging in *as* the user, but really what we want to do is create projects *on behalf of* users. Clayton advises that we're unlikely to be granted cluster-admin rights to OpenShift Online (or even in some dedicated instance we run), so perhaps we need some other role that has permissions to create projects and a rolebinding to the user in question. Associated Catapult issue is: https://github.com/redhat-kontinuity/catapult/issues/18 Thoughts from the OpenShift team? S, ALR -------------- next part -------------- An HTML attachment was scrubbed... URL: From bparees at redhat.com Fri Apr 15 00:24:32 2016 From: bparees at redhat.com (Ben Parees) Date: Thu, 14 Apr 2016 20:24:32 -0400 Subject: [kontinuity-dev-public] Creating a Project on Behalf of Users In-Reply-To: References: Message-ID: Might be better to ask on the openshift dev list, but i'm told David Eads is working on this so you could ping him directly as well. Ben Parees | OpenShift On Apr 14, 2016 20:11, "Andrew Lee Rubinger" wrote: > So the Catapult project will be creating OpenShift projects for its users. > > At the moment we're doing this by logging in *as* the user, but really > what we want to do is create projects *on behalf of* users. > > Clayton advises that we're unlikely to be granted cluster-admin rights to > OpenShift Online (or even in some dedicated instance we run), so perhaps we > need some other role that has permissions to create projects and a > rolebinding to the user in question. > > Associated Catapult issue is: > > https://github.com/redhat-kontinuity/catapult/issues/18 > > Thoughts from the OpenShift team? > > S, > ALR > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alr at redhat.com Fri Apr 15 00:36:49 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Thu, 14 Apr 2016 20:36:49 -0400 Subject: [kontinuity-dev-public] Creating a Project on Behalf of Users In-Reply-To: References: Message-ID: Thanks! David, would you mind advising how we might go about handling $subject? S, ALR On Thu, Apr 14, 2016 at 8:24 PM, Ben Parees wrote: > Might be better to ask on the openshift dev list, but i'm told David Eads > is working on this so you could ping him directly as well. > > Ben Parees | OpenShift > On Apr 14, 2016 20:11, "Andrew Lee Rubinger" wrote: > >> So the Catapult project will be creating OpenShift projects for its users. >> >> At the moment we're doing this by logging in *as* the user, but really >> what we want to do is create projects *on behalf of* users. >> >> Clayton advises that we're unlikely to be granted cluster-admin rights to >> OpenShift Online (or even in some dedicated instance we run), so perhaps we >> need some other role that has permissions to create projects and a >> rolebinding to the user in question. >> >> Associated Catapult issue is: >> >> https://github.com/redhat-kontinuity/catapult/issues/18 >> >> Thoughts from the OpenShift team? >> >> S, >> ALR >> >> _______________________________________________ >> kontinuity-dev-public mailing list >> kontinuity-dev-public at redhat.com >> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From deads at redhat.com Fri Apr 15 12:01:00 2016 From: deads at redhat.com (David Eads) Date: Fri, 15 Apr 2016 08:01:00 -0400 Subject: [kontinuity-dev-public] Creating a Project on Behalf of Users In-Reply-To: References: Message-ID: We currently have an endpoint where a user can request a project: https://docs.openshift.org/latest/admin_guide/managing_projects.html#selfprovisioning-projects. It works by using this endpoint: https://docs.openshift.org/latest/rest_api/openshift_v1.html#create-a-projectrequest. If you have access (on by default), then the user is escalated and a project is created on their behalf by the system. The shape of the project is determined by the cluster-admin through the use of a template. If you try the client-side command with `--loglevel=8`, you can see the details of the request. I think that flow is what your issue is talking about. However, if you're interested in general impersonation there is a pull ( https://github.com/openshift/origin/pull/8006) that adds a `Impersonate-User` header for requests. If that header is set to "bob", then the authenticated users is checked to see if they have rights to "impersonate" the "users" named "bob". If they are allowed, then the user context of the request is changed to "bob" and the request is checked. That gives perfect impersonation for the API server, but I think its unlikely that the users you're impersonating will be allowed to create projects directly. On Thu, Apr 14, 2016 at 8:36 PM, Andrew Lee Rubinger wrote: > Thanks! > > David, would you mind advising how we might go about handling $subject? > > S, > ALR > > On Thu, Apr 14, 2016 at 8:24 PM, Ben Parees wrote: > >> Might be better to ask on the openshift dev list, but i'm told David Eads >> is working on this so you could ping him directly as well. >> >> Ben Parees | OpenShift >> On Apr 14, 2016 20:11, "Andrew Lee Rubinger" wrote: >> >>> So the Catapult project will be creating OpenShift projects for its >>> users. >>> >>> At the moment we're doing this by logging in *as* the user, but really >>> what we want to do is create projects *on behalf of* users. >>> >>> Clayton advises that we're unlikely to be granted cluster-admin rights >>> to OpenShift Online (or even in some dedicated instance we run), so perhaps >>> we need some other role that has permissions to create projects and a >>> rolebinding to the user in question. >>> >>> Associated Catapult issue is: >>> >>> https://github.com/redhat-kontinuity/catapult/issues/18 >>> >>> Thoughts from the OpenShift team? >>> >>> S, >>> ALR >>> >>> _______________________________________________ >>> kontinuity-dev-public mailing list >>> kontinuity-dev-public at redhat.com >>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmartine at redhat.com Fri Apr 15 14:41:09 2016 From: rmartine at redhat.com (Ricardo Martinelli de Oliveira) Date: Fri, 15 Apr 2016 11:41:09 -0300 Subject: [kontinuity-dev-public] Creating a Project on Behalf of Users In-Reply-To: References: Message-ID: David, For Project request workflow I see no problems with it, but for application creation (either from the s2i images and templates) is the main concern from my viewpoint since the templates are in openshift project. I tried to develop the app creation part and I had some problems with template processing because hitting the template endpoint causes Permission issues. Could you please explains how to do that? On Fri, Apr 15, 2016 at 9:01 AM, David Eads wrote: > We currently have an endpoint where a user can request a project: > https://docs.openshift.org/latest/admin_guide/managing_projects.html#selfprovisioning-projects. > It works by using this endpoint: > https://docs.openshift.org/latest/rest_api/openshift_v1.html#create-a-projectrequest. > If you have access (on by default), then the user is escalated and a > project is created on their behalf by the system. The shape of the project > is determined by the cluster-admin through the use of a template. If you > try the client-side command with `--loglevel=8`, you can see the details of > the request. > > I think that flow is what your issue is talking about. However, if you're > interested in general impersonation there is a pull ( > https://github.com/openshift/origin/pull/8006) that adds a > `Impersonate-User` header for requests. If that header is set to "bob", > then the authenticated users is checked to see if they have rights to > "impersonate" the "users" named "bob". If they are allowed, then the user > context of the request is changed to "bob" and the request is checked. > That gives perfect impersonation for the API server, but I think its > unlikely that the users you're impersonating will be allowed to create > projects directly. > > On Thu, Apr 14, 2016 at 8:36 PM, Andrew Lee Rubinger > wrote: > >> Thanks! >> >> David, would you mind advising how we might go about handling $subject? >> >> S, >> ALR >> >> On Thu, Apr 14, 2016 at 8:24 PM, Ben Parees wrote: >> >>> Might be better to ask on the openshift dev list, but i'm told David >>> Eads is working on this so you could ping him directly as well. >>> >>> Ben Parees | OpenShift >>> On Apr 14, 2016 20:11, "Andrew Lee Rubinger" wrote: >>> >>>> So the Catapult project will be creating OpenShift projects for its >>>> users. >>>> >>>> At the moment we're doing this by logging in *as* the user, but really >>>> what we want to do is create projects *on behalf of* users. >>>> >>>> Clayton advises that we're unlikely to be granted cluster-admin rights >>>> to OpenShift Online (or even in some dedicated instance we run), so perhaps >>>> we need some other role that has permissions to create projects and a >>>> rolebinding to the user in question. >>>> >>>> Associated Catapult issue is: >>>> >>>> https://github.com/redhat-kontinuity/catapult/issues/18 >>>> >>>> Thoughts from the OpenShift team? >>>> >>>> S, >>>> ALR >>>> >>>> _______________________________________________ >>>> kontinuity-dev-public mailing list >>>> kontinuity-dev-public at redhat.com >>>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>>> >>>> >> > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bparees at redhat.com Fri Apr 15 15:23:14 2016 From: bparees at redhat.com (Ben Parees) Date: Fri, 15 Apr 2016 11:23:14 -0400 Subject: [kontinuity-dev-public] Creating a Project on Behalf of Users In-Reply-To: References: Message-ID: On Fri, Apr 15, 2016 at 10:41 AM, Ricardo Martinelli de Oliveira < rmartine at redhat.com> wrote: > David, > > For Project request workflow I see no problems with it, but for > application creation (either from the s2i images and templates) is the main > concern from my viewpoint since the templates are in openshift project. I > tried to develop the app creation part and I had some problems with > template processing because hitting the template endpoint causes Permission > issues. > > Could you please explains how to do that? > ?I thought we discussed this on IRC, so i'm not sure what issue you're having? Your client needs to: 1) retrieve the template object from the openshift namespace (Everyone has view access, not a problem) 2) post the template (with parameter values if supplied by the user) to the processedTemplates endpoint in the user's namespace 3) you'll get back a processed template which is basically a list of api objects 4) your client needs to iteratively make a create api call on each api object. we've implemented this flow 2-3 times (CLI, web console, eclipse tooling, maybe fabric too), so there ought to be somewhere you can borrow it from. ? > > On Fri, Apr 15, 2016 at 9:01 AM, David Eads wrote: > >> We currently have an endpoint where a user can request a project: >> https://docs.openshift.org/latest/admin_guide/managing_projects.html#selfprovisioning-projects. >> It works by using this endpoint: >> https://docs.openshift.org/latest/rest_api/openshift_v1.html#create-a-projectrequest. >> If you have access (on by default), then the user is escalated and a >> project is created on their behalf by the system. The shape of the project >> is determined by the cluster-admin through the use of a template. If you >> try the client-side command with `--loglevel=8`, you can see the details of >> the request. >> >> I think that flow is what your issue is talking about. However, if >> you're interested in general impersonation there is a pull ( >> https://github.com/openshift/origin/pull/8006) that adds a >> `Impersonate-User` header for requests. If that header is set to "bob", >> then the authenticated users is checked to see if they have rights to >> "impersonate" the "users" named "bob". If they are allowed, then the user >> context of the request is changed to "bob" and the request is checked. >> That gives perfect impersonation for the API server, but I think its >> unlikely that the users you're impersonating will be allowed to create >> projects directly. >> >> On Thu, Apr 14, 2016 at 8:36 PM, Andrew Lee Rubinger >> wrote: >> >>> Thanks! >>> >>> David, would you mind advising how we might go about handling $subject? >>> >>> S, >>> ALR >>> >>> On Thu, Apr 14, 2016 at 8:24 PM, Ben Parees wrote: >>> >>>> Might be better to ask on the openshift dev list, but i'm told David >>>> Eads is working on this so you could ping him directly as well. >>>> >>>> Ben Parees | OpenShift >>>> On Apr 14, 2016 20:11, "Andrew Lee Rubinger" wrote: >>>> >>>>> So the Catapult project will be creating OpenShift projects for its >>>>> users. >>>>> >>>>> At the moment we're doing this by logging in *as* the user, but really >>>>> what we want to do is create projects *on behalf of* users. >>>>> >>>>> Clayton advises that we're unlikely to be granted cluster-admin rights >>>>> to OpenShift Online (or even in some dedicated instance we run), so perhaps >>>>> we need some other role that has permissions to create projects and a >>>>> rolebinding to the user in question. >>>>> >>>>> Associated Catapult issue is: >>>>> >>>>> https://github.com/redhat-kontinuity/catapult/issues/18 >>>>> >>>>> Thoughts from the OpenShift team? >>>>> >>>>> S, >>>>> ALR >>>>> >>>>> _______________________________________________ >>>>> kontinuity-dev-public mailing list >>>>> kontinuity-dev-public at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>>>> >>>>> >>> >> >> _______________________________________________ >> kontinuity-dev-public mailing list >> kontinuity-dev-public at redhat.com >> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >> >> > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > > -- Ben Parees | OpenShift -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmartine at redhat.com Fri Apr 15 15:29:15 2016 From: rmartine at redhat.com (Ricardo Martinelli de Oliveira) Date: Fri, 15 Apr 2016 12:29:15 -0300 Subject: [kontinuity-dev-public] Creating a Project on Behalf of Users In-Reply-To: References: Message-ID: Ben, Yes, sorry for not mentioned that we already discussed this. To be honest, only step 2 was unclear to me and still is. I'll take a look again at the Fabric8 code to see how they are handling this and I'll send a reply to confirm if that helped or not. On Fri, Apr 15, 2016 at 12:23 PM, Ben Parees wrote: > > > On Fri, Apr 15, 2016 at 10:41 AM, Ricardo Martinelli de Oliveira < > rmartine at redhat.com> wrote: > >> David, >> >> For Project request workflow I see no problems with it, but for >> application creation (either from the s2i images and templates) is the main >> concern from my viewpoint since the templates are in openshift project. I >> tried to develop the app creation part and I had some problems with >> template processing because hitting the template endpoint causes Permission >> issues. >> >> Could you please explains how to do that? >> > > ?I thought we discussed this on IRC, so i'm not sure what issue you're > having? > > Your client needs to: > 1) retrieve the template object from the openshift namespace (Everyone has > view access, not a problem) > 2) post the template (with parameter values if supplied by the user) to > the processedTemplates endpoint in the user's namespace > 3) you'll get back a processed template which is basically a list of api > objects > 4) your client needs to iteratively make a create api call on each api > object. > > we've implemented this flow 2-3 times (CLI, web console, eclipse tooling, > maybe fabric too), so there ought to be somewhere you can borrow it from. > ? > > > >> >> On Fri, Apr 15, 2016 at 9:01 AM, David Eads wrote: >> >>> We currently have an endpoint where a user can request a project: >>> https://docs.openshift.org/latest/admin_guide/managing_projects.html#selfprovisioning-projects. >>> It works by using this endpoint: >>> https://docs.openshift.org/latest/rest_api/openshift_v1.html#create-a-projectrequest. >>> If you have access (on by default), then the user is escalated and a >>> project is created on their behalf by the system. The shape of the project >>> is determined by the cluster-admin through the use of a template. If you >>> try the client-side command with `--loglevel=8`, you can see the details of >>> the request. >>> >>> I think that flow is what your issue is talking about. However, if >>> you're interested in general impersonation there is a pull ( >>> https://github.com/openshift/origin/pull/8006) that adds a >>> `Impersonate-User` header for requests. If that header is set to "bob", >>> then the authenticated users is checked to see if they have rights to >>> "impersonate" the "users" named "bob". If they are allowed, then the user >>> context of the request is changed to "bob" and the request is checked. >>> That gives perfect impersonation for the API server, but I think its >>> unlikely that the users you're impersonating will be allowed to create >>> projects directly. >>> >>> On Thu, Apr 14, 2016 at 8:36 PM, Andrew Lee Rubinger >>> wrote: >>> >>>> Thanks! >>>> >>>> David, would you mind advising how we might go about handling $subject? >>>> >>>> S, >>>> ALR >>>> >>>> On Thu, Apr 14, 2016 at 8:24 PM, Ben Parees wrote: >>>> >>>>> Might be better to ask on the openshift dev list, but i'm told David >>>>> Eads is working on this so you could ping him directly as well. >>>>> >>>>> Ben Parees | OpenShift >>>>> On Apr 14, 2016 20:11, "Andrew Lee Rubinger" wrote: >>>>> >>>>>> So the Catapult project will be creating OpenShift projects for its >>>>>> users. >>>>>> >>>>>> At the moment we're doing this by logging in *as* the user, but >>>>>> really what we want to do is create projects *on behalf of* users. >>>>>> >>>>>> Clayton advises that we're unlikely to be granted cluster-admin >>>>>> rights to OpenShift Online (or even in some dedicated instance we run), so >>>>>> perhaps we need some other role that has permissions to create projects and >>>>>> a rolebinding to the user in question. >>>>>> >>>>>> Associated Catapult issue is: >>>>>> >>>>>> https://github.com/redhat-kontinuity/catapult/issues/18 >>>>>> >>>>>> Thoughts from the OpenShift team? >>>>>> >>>>>> S, >>>>>> ALR >>>>>> >>>>>> _______________________________________________ >>>>>> kontinuity-dev-public mailing list >>>>>> kontinuity-dev-public at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>>>>> >>>>>> >>>> >>> >>> _______________________________________________ >>> kontinuity-dev-public mailing list >>> kontinuity-dev-public at redhat.com >>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>> >>> >> >> _______________________________________________ >> kontinuity-dev-public mailing list >> kontinuity-dev-public at redhat.com >> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >> >> > > > -- > Ben Parees | OpenShift > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bparees at redhat.com Fri Apr 15 15:35:27 2016 From: bparees at redhat.com (Ben Parees) Date: Fri, 15 Apr 2016 11:35:27 -0400 Subject: [kontinuity-dev-public] Creating a Project on Behalf of Users In-Reply-To: References: Message-ID: you can also talk to jeff cantrill who implemented the flow for the eclipse tooling. On Fri, Apr 15, 2016 at 11:29 AM, Ricardo Martinelli de Oliveira < rmartine at redhat.com> wrote: > Ben, > > Yes, sorry for not mentioned that we already discussed this. To be honest, > only step 2 was unclear to me and still is. > > I'll take a look again at the Fabric8 code to see how they are handling > this and I'll send a reply to confirm if that helped or not. > > > > On Fri, Apr 15, 2016 at 12:23 PM, Ben Parees wrote: > >> >> >> On Fri, Apr 15, 2016 at 10:41 AM, Ricardo Martinelli de Oliveira < >> rmartine at redhat.com> wrote: >> >>> David, >>> >>> For Project request workflow I see no problems with it, but for >>> application creation (either from the s2i images and templates) is the main >>> concern from my viewpoint since the templates are in openshift project. I >>> tried to develop the app creation part and I had some problems with >>> template processing because hitting the template endpoint causes Permission >>> issues. >>> >>> Could you please explains how to do that? >>> >> >> ?I thought we discussed this on IRC, so i'm not sure what issue you're >> having? >> >> Your client needs to: >> 1) retrieve the template object from the openshift namespace (Everyone >> has view access, not a problem) >> 2) post the template (with parameter values if supplied by the user) to >> the processedTemplates endpoint in the user's namespace >> 3) you'll get back a processed template which is basically a list of api >> objects >> 4) your client needs to iteratively make a create api call on each api >> object. >> >> we've implemented this flow 2-3 times (CLI, web console, eclipse tooling, >> maybe fabric too), so there ought to be somewhere you can borrow it from. >> ? >> >> >> >>> >>> On Fri, Apr 15, 2016 at 9:01 AM, David Eads wrote: >>> >>>> We currently have an endpoint where a user can request a project: >>>> https://docs.openshift.org/latest/admin_guide/managing_projects.html#selfprovisioning-projects. >>>> It works by using this endpoint: >>>> https://docs.openshift.org/latest/rest_api/openshift_v1.html#create-a-projectrequest. >>>> If you have access (on by default), then the user is escalated and a >>>> project is created on their behalf by the system. The shape of the project >>>> is determined by the cluster-admin through the use of a template. If you >>>> try the client-side command with `--loglevel=8`, you can see the details of >>>> the request. >>>> >>>> I think that flow is what your issue is talking about. However, if >>>> you're interested in general impersonation there is a pull ( >>>> https://github.com/openshift/origin/pull/8006) that adds a >>>> `Impersonate-User` header for requests. If that header is set to "bob", >>>> then the authenticated users is checked to see if they have rights to >>>> "impersonate" the "users" named "bob". If they are allowed, then the user >>>> context of the request is changed to "bob" and the request is checked. >>>> That gives perfect impersonation for the API server, but I think its >>>> unlikely that the users you're impersonating will be allowed to create >>>> projects directly. >>>> >>>> On Thu, Apr 14, 2016 at 8:36 PM, Andrew Lee Rubinger >>>> wrote: >>>> >>>>> Thanks! >>>>> >>>>> David, would you mind advising how we might go about handling $subject? >>>>> >>>>> S, >>>>> ALR >>>>> >>>>> On Thu, Apr 14, 2016 at 8:24 PM, Ben Parees >>>>> wrote: >>>>> >>>>>> Might be better to ask on the openshift dev list, but i'm told David >>>>>> Eads is working on this so you could ping him directly as well. >>>>>> >>>>>> Ben Parees | OpenShift >>>>>> On Apr 14, 2016 20:11, "Andrew Lee Rubinger" wrote: >>>>>> >>>>>>> So the Catapult project will be creating OpenShift projects for its >>>>>>> users. >>>>>>> >>>>>>> At the moment we're doing this by logging in *as* the user, but >>>>>>> really what we want to do is create projects *on behalf of* users. >>>>>>> >>>>>>> Clayton advises that we're unlikely to be granted cluster-admin >>>>>>> rights to OpenShift Online (or even in some dedicated instance we run), so >>>>>>> perhaps we need some other role that has permissions to create projects and >>>>>>> a rolebinding to the user in question. >>>>>>> >>>>>>> Associated Catapult issue is: >>>>>>> >>>>>>> https://github.com/redhat-kontinuity/catapult/issues/18 >>>>>>> >>>>>>> Thoughts from the OpenShift team? >>>>>>> >>>>>>> S, >>>>>>> ALR >>>>>>> >>>>>>> _______________________________________________ >>>>>>> kontinuity-dev-public mailing list >>>>>>> kontinuity-dev-public at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>>>>>> >>>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> kontinuity-dev-public mailing list >>>> kontinuity-dev-public at redhat.com >>>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>>> >>>> >>> >>> _______________________________________________ >>> kontinuity-dev-public mailing list >>> kontinuity-dev-public at redhat.com >>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>> >>> >> >> >> -- >> Ben Parees | OpenShift >> >> > -- Ben Parees | OpenShift -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcantril at redhat.com Fri Apr 15 16:42:49 2016 From: jcantril at redhat.com (Jeff Cantrill) Date: Fri, 15 Apr 2016 12:42:49 -0400 Subject: [kontinuity-dev-public] Creating a Project on Behalf of Users In-Reply-To: References: Message-ID: On Fri, Apr 15, 2016 at 11:35 AM, Ben Parees wrote: > you can also talk to jeff cantrill who implemented the flow for the > eclipse tooling. > > The openshift-restclient-java and subsequently JBosstools processes templates using this class: https://github.com/openshift/openshift-restclient-java/blob/master/src/main/java/com/openshift/internal/restclient/capability/server/ServerTemplateProcessing.java#L50 consumed here: https://github.com/jbosstools/jbosstools-openshift/blob/master/plugins/org.jboss.tools.openshift.ui/src/org/jboss/tools/openshift/internal/ui/job/CreateApplicationFromTemplateJob.java#L58 > > On Fri, Apr 15, 2016 at 11:29 AM, Ricardo Martinelli de Oliveira < > rmartine at redhat.com> wrote: > >> Ben, >> >> Yes, sorry for not mentioned that we already discussed this. To be >> honest, only step 2 was unclear to me and still is. >> >> I'll take a look again at the Fabric8 code to see how they are handling >> this and I'll send a reply to confirm if that helped or not. >> >> >> >> On Fri, Apr 15, 2016 at 12:23 PM, Ben Parees wrote: >> >>> >>> >>> On Fri, Apr 15, 2016 at 10:41 AM, Ricardo Martinelli de Oliveira < >>> rmartine at redhat.com> wrote: >>> >>>> David, >>>> >>>> For Project request workflow I see no problems with it, but for >>>> application creation (either from the s2i images and templates) is the main >>>> concern from my viewpoint since the templates are in openshift project. I >>>> tried to develop the app creation part and I had some problems with >>>> template processing because hitting the template endpoint causes Permission >>>> issues. >>>> >>>> Could you please explains how to do that? >>>> >>> >>> ?I thought we discussed this on IRC, so i'm not sure what issue you're >>> having? >>> >>> Your client needs to: >>> 1) retrieve the template object from the openshift namespace (Everyone >>> has view access, not a problem) >>> 2) post the template (with parameter values if supplied by the user) to >>> the processedTemplates endpoint in the user's namespace >>> 3) you'll get back a processed template which is basically a list of api >>> objects >>> 4) your client needs to iteratively make a create api call on each api >>> object. >>> >>> we've implemented this flow 2-3 times (CLI, web console, eclipse >>> tooling, maybe fabric too), so there ought to be somewhere you can borrow >>> it from. >>> ? >>> >>> >>> >>>> >>>> On Fri, Apr 15, 2016 at 9:01 AM, David Eads wrote: >>>> >>>>> We currently have an endpoint where a user can request a project: >>>>> https://docs.openshift.org/latest/admin_guide/managing_projects.html#selfprovisioning-projects. >>>>> It works by using this endpoint: >>>>> https://docs.openshift.org/latest/rest_api/openshift_v1.html#create-a-projectrequest. >>>>> If you have access (on by default), then the user is escalated and a >>>>> project is created on their behalf by the system. The shape of the project >>>>> is determined by the cluster-admin through the use of a template. If you >>>>> try the client-side command with `--loglevel=8`, you can see the details of >>>>> the request. >>>>> >>>>> I think that flow is what your issue is talking about. However, if >>>>> you're interested in general impersonation there is a pull ( >>>>> https://github.com/openshift/origin/pull/8006) that adds a >>>>> `Impersonate-User` header for requests. If that header is set to "bob", >>>>> then the authenticated users is checked to see if they have rights to >>>>> "impersonate" the "users" named "bob". If they are allowed, then the user >>>>> context of the request is changed to "bob" and the request is checked. >>>>> That gives perfect impersonation for the API server, but I think its >>>>> unlikely that the users you're impersonating will be allowed to create >>>>> projects directly. >>>>> >>>>> On Thu, Apr 14, 2016 at 8:36 PM, Andrew Lee Rubinger >>>>> wrote: >>>>> >>>>>> Thanks! >>>>>> >>>>>> David, would you mind advising how we might go about handling >>>>>> $subject? >>>>>> >>>>>> S, >>>>>> ALR >>>>>> >>>>>> On Thu, Apr 14, 2016 at 8:24 PM, Ben Parees >>>>>> wrote: >>>>>> >>>>>>> Might be better to ask on the openshift dev list, but i'm told David >>>>>>> Eads is working on this so you could ping him directly as well. >>>>>>> >>>>>>> Ben Parees | OpenShift >>>>>>> On Apr 14, 2016 20:11, "Andrew Lee Rubinger" wrote: >>>>>>> >>>>>>>> So the Catapult project will be creating OpenShift projects for its >>>>>>>> users. >>>>>>>> >>>>>>>> At the moment we're doing this by logging in *as* the user, but >>>>>>>> really what we want to do is create projects *on behalf of* users. >>>>>>>> >>>>>>>> Clayton advises that we're unlikely to be granted cluster-admin >>>>>>>> rights to OpenShift Online (or even in some dedicated instance we run), so >>>>>>>> perhaps we need some other role that has permissions to create projects and >>>>>>>> a rolebinding to the user in question. >>>>>>>> >>>>>>>> Associated Catapult issue is: >>>>>>>> >>>>>>>> https://github.com/redhat-kontinuity/catapult/issues/18 >>>>>>>> >>>>>>>> Thoughts from the OpenShift team? >>>>>>>> >>>>>>>> S, >>>>>>>> ALR >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> kontinuity-dev-public mailing list >>>>>>>> kontinuity-dev-public at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>>>>>>> >>>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> kontinuity-dev-public mailing list >>>>> kontinuity-dev-public at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> kontinuity-dev-public mailing list >>>> kontinuity-dev-public at redhat.com >>>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>>> >>>> >>> >>> >>> -- >>> Ben Parees | OpenShift >>> >>> >> > > > -- > Ben Parees | OpenShift > > -- -- Jeff Cantrill Senior Software Engineer, Red Hat Engineering OpenShift Integration Services Red Hat, Inc. *Office*: 703-748-4420 | 866-546-8970 ext. 8162420 jcantril at redhat.com http://www.redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From alr at redhat.com Fri Apr 15 18:40:40 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Fri, 15 Apr 2016 14:40:40 -0400 Subject: [kontinuity-dev-public] Creating a Project on Behalf of Users In-Reply-To: References: Message-ID: Thanks, David! Bear with me as I catch up on this thread after commitments this AM. :) So we're currently doing the ProjectRequest approach (via the fabric8-openshift-client), acting directly as the user. What we really need is some "admin"-level user or other role which we can authenticate as, and then create projects for others. If Impersonation is the recommended way to do that, we can go that route; but we're not really looking to impersonate anyone -- we're acting as our system account but making projects to be owned by users. A *nix parallel might be something like the root account creating a folder and then assigning the owner to a user along with appropriate rwx permissions. To Ricardo's point: On Fri, Apr 15, 2016 at 10:41 AM, Ricardo Martinelli de Oliveira < rmartine at redhat.com> wrote: > David, > > For Project request workflow I see no problems with it, but for > application creation (either from the s2i images and templates) is the main > concern from my viewpoint since the templates are in openshift project. I > tried to develop the app creation part and I had some problems with > template processing because hitting the template endpoint causes Permission > issues. > How do the templates relate to project creation and permissions, Ricardo? Are you just thinking a few steps ahead of me or are we intermingling issues here? S, ALR On Fri, Apr 15, 2016 at 8:01 AM, David Eads wrote: > We currently have an endpoint where a user can request a project: > https://docs.openshift.org/latest/admin_guide/managing_projects.html#selfprovisioning-projects. > It works by using this endpoint: > https://docs.openshift.org/latest/rest_api/openshift_v1.html#create-a-projectrequest. > If you have access (on by default), then the user is escalated and a > project is created on their behalf by the system. The shape of the project > is determined by the cluster-admin through the use of a template. If you > try the client-side command with `--loglevel=8`, you can see the details of > the request. > > I think that flow is what your issue is talking about. However, if you're > interested in general impersonation there is a pull ( > https://github.com/openshift/origin/pull/8006) that adds a > `Impersonate-User` header for requests. If that header is set to "bob", > then the authenticated users is checked to see if they have rights to > "impersonate" the "users" named "bob". If they are allowed, then the user > context of the request is changed to "bob" and the request is checked. > That gives perfect impersonation for the API server, but I think its > unlikely that the users you're impersonating will be allowed to create > projects directly. > > On Thu, Apr 14, 2016 at 8:36 PM, Andrew Lee Rubinger > wrote: > >> Thanks! >> >> David, would you mind advising how we might go about handling $subject? >> >> S, >> ALR >> >> On Thu, Apr 14, 2016 at 8:24 PM, Ben Parees wrote: >> >>> Might be better to ask on the openshift dev list, but i'm told David >>> Eads is working on this so you could ping him directly as well. >>> >>> Ben Parees | OpenShift >>> On Apr 14, 2016 20:11, "Andrew Lee Rubinger" wrote: >>> >>>> So the Catapult project will be creating OpenShift projects for its >>>> users. >>>> >>>> At the moment we're doing this by logging in *as* the user, but really >>>> what we want to do is create projects *on behalf of* users. >>>> >>>> Clayton advises that we're unlikely to be granted cluster-admin rights >>>> to OpenShift Online (or even in some dedicated instance we run), so perhaps >>>> we need some other role that has permissions to create projects and a >>>> rolebinding to the user in question. >>>> >>>> Associated Catapult issue is: >>>> >>>> https://github.com/redhat-kontinuity/catapult/issues/18 >>>> >>>> Thoughts from the OpenShift team? >>>> >>>> S, >>>> ALR >>>> >>>> _______________________________________________ >>>> kontinuity-dev-public mailing list >>>> kontinuity-dev-public at redhat.com >>>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmartine at redhat.com Fri Apr 15 18:47:30 2016 From: rmartine at redhat.com (Ricardo Martinelli de Oliveira) Date: Fri, 15 Apr 2016 15:47:30 -0300 Subject: [kontinuity-dev-public] Creating a Project on Behalf of Users In-Reply-To: References: Message-ID: Planning one step ahead, since project creation doesn't necessarily mean you are creating the application. Know the app creation workflow is also important and that's why the steps described by Ben is important too. At last, if we change the way catapult will create projects to users then we need to know if impacts the next step (application creation). On Fri, Apr 15, 2016 at 3:40 PM, Andrew Lee Rubinger wrote: > Thanks, David! Bear with me as I catch up on this thread after > commitments this AM. :) > > So we're currently doing the ProjectRequest approach (via the > fabric8-openshift-client), acting directly as the user. What we really > need is some "admin"-level user or other role which we can authenticate as, > and then create projects for others. If Impersonation is the recommended > way to do that, we can go that route; but we're not really looking to > impersonate anyone -- we're acting as our system account but making > projects to be owned by users. A *nix parallel might be something like the > root account creating a folder and then assigning the owner to a user along > with appropriate rwx permissions. > > To Ricardo's point: > > On Fri, Apr 15, 2016 at 10:41 AM, Ricardo Martinelli de Oliveira < > rmartine at redhat.com> wrote: > >> David, >> >> For Project request workflow I see no problems with it, but for >> application creation (either from the s2i images and templates) is the main >> concern from my viewpoint since the templates are in openshift project. I >> tried to develop the app creation part and I had some problems with >> template processing because hitting the template endpoint causes Permission >> issues. >> > > How do the templates relate to project creation and permissions, Ricardo? > Are you just thinking a few steps ahead of me or are we intermingling > issues here? > > S, > ALR > > On Fri, Apr 15, 2016 at 8:01 AM, David Eads wrote: > >> We currently have an endpoint where a user can request a project: >> https://docs.openshift.org/latest/admin_guide/managing_projects.html#selfprovisioning-projects. >> It works by using this endpoint: >> https://docs.openshift.org/latest/rest_api/openshift_v1.html#create-a-projectrequest. >> If you have access (on by default), then the user is escalated and a >> project is created on their behalf by the system. The shape of the project >> is determined by the cluster-admin through the use of a template. If you >> try the client-side command with `--loglevel=8`, you can see the details of >> the request. >> >> I think that flow is what your issue is talking about. However, if >> you're interested in general impersonation there is a pull ( >> https://github.com/openshift/origin/pull/8006) that adds a >> `Impersonate-User` header for requests. If that header is set to "bob", >> then the authenticated users is checked to see if they have rights to >> "impersonate" the "users" named "bob". If they are allowed, then the user >> context of the request is changed to "bob" and the request is checked. >> That gives perfect impersonation for the API server, but I think its >> unlikely that the users you're impersonating will be allowed to create >> projects directly. >> >> On Thu, Apr 14, 2016 at 8:36 PM, Andrew Lee Rubinger >> wrote: >> >>> Thanks! >>> >>> David, would you mind advising how we might go about handling $subject? >>> >>> S, >>> ALR >>> >>> On Thu, Apr 14, 2016 at 8:24 PM, Ben Parees wrote: >>> >>>> Might be better to ask on the openshift dev list, but i'm told David >>>> Eads is working on this so you could ping him directly as well. >>>> >>>> Ben Parees | OpenShift >>>> On Apr 14, 2016 20:11, "Andrew Lee Rubinger" wrote: >>>> >>>>> So the Catapult project will be creating OpenShift projects for its >>>>> users. >>>>> >>>>> At the moment we're doing this by logging in *as* the user, but really >>>>> what we want to do is create projects *on behalf of* users. >>>>> >>>>> Clayton advises that we're unlikely to be granted cluster-admin rights >>>>> to OpenShift Online (or even in some dedicated instance we run), so perhaps >>>>> we need some other role that has permissions to create projects and a >>>>> rolebinding to the user in question. >>>>> >>>>> Associated Catapult issue is: >>>>> >>>>> https://github.com/redhat-kontinuity/catapult/issues/18 >>>>> >>>>> Thoughts from the OpenShift team? >>>>> >>>>> S, >>>>> ALR >>>>> >>>>> _______________________________________________ >>>>> kontinuity-dev-public mailing list >>>>> kontinuity-dev-public at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>>>> >>>>> >>> >> > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From deads at redhat.com Fri Apr 15 18:57:00 2016 From: deads at redhat.com (David Eads) Date: Fri, 15 Apr 2016 14:57:00 -0400 Subject: [kontinuity-dev-public] Creating a Project on Behalf of Users In-Reply-To: References: Message-ID: Why must the user be the "owner"? Why isn't it sufficient to grant that user access to the project you're creating? Once we introduce the concept of a roll-up quota associated with a user, allowing userA to dump projects on userB without userB's consent is going to be a big no-no. See https://github.com/openshift/origin/pull/8181 as a proposal for this concept. On Fri, Apr 15, 2016 at 2:40 PM, Andrew Lee Rubinger wrote: > Thanks, David! Bear with me as I catch up on this thread after > commitments this AM. :) > > So we're currently doing the ProjectRequest approach (via the > fabric8-openshift-client), acting directly as the user. What we really > need is some "admin"-level user or other role which we can authenticate as, > and then create projects for others. If Impersonation is the recommended > way to do that, we can go that route; but we're not really looking to > impersonate anyone -- we're acting as our system account but making > projects to be owned by users. A *nix parallel might be something like the > root account creating a folder and then assigning the owner to a user along > with appropriate rwx permissions. > > To Ricardo's point: > > On Fri, Apr 15, 2016 at 10:41 AM, Ricardo Martinelli de Oliveira < > rmartine at redhat.com> wrote: > >> David, >> >> For Project request workflow I see no problems with it, but for >> application creation (either from the s2i images and templates) is the main >> concern from my viewpoint since the templates are in openshift project. I >> tried to develop the app creation part and I had some problems with >> template processing because hitting the template endpoint causes Permission >> issues. >> > > How do the templates relate to project creation and permissions, Ricardo? > Are you just thinking a few steps ahead of me or are we intermingling > issues here? > > S, > ALR > > On Fri, Apr 15, 2016 at 8:01 AM, David Eads wrote: > >> We currently have an endpoint where a user can request a project: >> https://docs.openshift.org/latest/admin_guide/managing_projects.html#selfprovisioning-projects. >> It works by using this endpoint: >> https://docs.openshift.org/latest/rest_api/openshift_v1.html#create-a-projectrequest. >> If you have access (on by default), then the user is escalated and a >> project is created on their behalf by the system. The shape of the project >> is determined by the cluster-admin through the use of a template. If you >> try the client-side command with `--loglevel=8`, you can see the details of >> the request. >> >> I think that flow is what your issue is talking about. However, if >> you're interested in general impersonation there is a pull ( >> https://github.com/openshift/origin/pull/8006) that adds a >> `Impersonate-User` header for requests. If that header is set to "bob", >> then the authenticated users is checked to see if they have rights to >> "impersonate" the "users" named "bob". If they are allowed, then the user >> context of the request is changed to "bob" and the request is checked. >> That gives perfect impersonation for the API server, but I think its >> unlikely that the users you're impersonating will be allowed to create >> projects directly. >> >> On Thu, Apr 14, 2016 at 8:36 PM, Andrew Lee Rubinger >> wrote: >> >>> Thanks! >>> >>> David, would you mind advising how we might go about handling $subject? >>> >>> S, >>> ALR >>> >>> On Thu, Apr 14, 2016 at 8:24 PM, Ben Parees wrote: >>> >>>> Might be better to ask on the openshift dev list, but i'm told David >>>> Eads is working on this so you could ping him directly as well. >>>> >>>> Ben Parees | OpenShift >>>> On Apr 14, 2016 20:11, "Andrew Lee Rubinger" wrote: >>>> >>>>> So the Catapult project will be creating OpenShift projects for its >>>>> users. >>>>> >>>>> At the moment we're doing this by logging in *as* the user, but really >>>>> what we want to do is create projects *on behalf of* users. >>>>> >>>>> Clayton advises that we're unlikely to be granted cluster-admin rights >>>>> to OpenShift Online (or even in some dedicated instance we run), so perhaps >>>>> we need some other role that has permissions to create projects and a >>>>> rolebinding to the user in question. >>>>> >>>>> Associated Catapult issue is: >>>>> >>>>> https://github.com/redhat-kontinuity/catapult/issues/18 >>>>> >>>>> Thoughts from the OpenShift team? >>>>> >>>>> S, >>>>> ALR >>>>> >>>>> _______________________________________________ >>>>> kontinuity-dev-public mailing list >>>>> kontinuity-dev-public at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>>>> >>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bparees at redhat.com Fri Apr 15 19:11:02 2016 From: bparees at redhat.com (Ben Parees) Date: Fri, 15 Apr 2016 15:11:02 -0400 Subject: [kontinuity-dev-public] Creating a Project on Behalf of Users In-Reply-To: References: Message-ID: On Thu, Apr 14, 2016 at 8:11 PM, Andrew Lee Rubinger wrote: > So the Catapult project will be creating OpenShift projects for its users. > > At the moment we're doing this by logging in *as* the user, but really > what we want to do is create projects *on behalf of* users. > ?can we take a step back and ask why logging in as the user and doing stuff for them is not a valid approach for you? ? > > Clayton advises that we're unlikely to be granted cluster-admin rights to > OpenShift Online (or even in some dedicated instance we run), so perhaps we > need some other role that has permissions to create projects and a > rolebinding to the user in question. > > Associated Catapult issue is: > > https://github.com/redhat-kontinuity/catapult/issues/18 > > Thoughts from the OpenShift team? > > S, > ALR > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > > -- Ben Parees | OpenShift -------------- next part -------------- An HTML attachment was scrubbed... URL: From alr at redhat.com Fri Apr 15 19:18:52 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Fri, 15 Apr 2016 15:18:52 -0400 Subject: [kontinuity-dev-public] Creating a Project on Behalf of Users In-Reply-To: References: Message-ID: On Fri, Apr 15, 2016 at 2:57 PM, David Eads wrote: > Why must the user be the "owner"? Why isn't it sufficient to grant that > user access to the project you're creating? > I suppose you're right, yep. So long as that access includes write and delete privs. > Once we introduce the concept of a roll-up quota associated with a user, > allowing userA to dump projects on userB without userB's consent is going > to be a big no-no. See https://github.com/openshift/origin/pull/8181 as a > proposal for this concept. > Which is kinda why I mention the idea of a SuperUser or system account which has rights that AverageJoeUser doesn't have. Or maybe something like the OAuth flow we use in GitHub, where we ask the user for permissions to perform actions and they grant us a token. I'm either missing some context from the PR or simply don't have the technical depth in OS to grok it correctly yet. ;) S, ALR > > On Fri, Apr 15, 2016 at 2:40 PM, Andrew Lee Rubinger > wrote: > >> Thanks, David! Bear with me as I catch up on this thread after >> commitments this AM. :) >> >> So we're currently doing the ProjectRequest approach (via the >> fabric8-openshift-client), acting directly as the user. What we really >> need is some "admin"-level user or other role which we can authenticate as, >> and then create projects for others. If Impersonation is the recommended >> way to do that, we can go that route; but we're not really looking to >> impersonate anyone -- we're acting as our system account but making >> projects to be owned by users. A *nix parallel might be something like the >> root account creating a folder and then assigning the owner to a user along >> with appropriate rwx permissions. >> >> To Ricardo's point: >> >> On Fri, Apr 15, 2016 at 10:41 AM, Ricardo Martinelli de Oliveira < >> rmartine at redhat.com> wrote: >> >>> David, >>> >>> For Project request workflow I see no problems with it, but for >>> application creation (either from the s2i images and templates) is the main >>> concern from my viewpoint since the templates are in openshift project. I >>> tried to develop the app creation part and I had some problems with >>> template processing because hitting the template endpoint causes Permission >>> issues. >>> >> >> How do the templates relate to project creation and permissions, >> Ricardo? Are you just thinking a few steps ahead of me or are we >> intermingling issues here? >> >> S, >> ALR >> >> On Fri, Apr 15, 2016 at 8:01 AM, David Eads wrote: >> >>> We currently have an endpoint where a user can request a project: >>> https://docs.openshift.org/latest/admin_guide/managing_projects.html#selfprovisioning-projects. >>> It works by using this endpoint: >>> https://docs.openshift.org/latest/rest_api/openshift_v1.html#create-a-projectrequest. >>> If you have access (on by default), then the user is escalated and a >>> project is created on their behalf by the system. The shape of the project >>> is determined by the cluster-admin through the use of a template. If you >>> try the client-side command with `--loglevel=8`, you can see the details of >>> the request. >>> >>> I think that flow is what your issue is talking about. However, if >>> you're interested in general impersonation there is a pull ( >>> https://github.com/openshift/origin/pull/8006) that adds a >>> `Impersonate-User` header for requests. If that header is set to "bob", >>> then the authenticated users is checked to see if they have rights to >>> "impersonate" the "users" named "bob". If they are allowed, then the user >>> context of the request is changed to "bob" and the request is checked. >>> That gives perfect impersonation for the API server, but I think its >>> unlikely that the users you're impersonating will be allowed to create >>> projects directly. >>> >>> On Thu, Apr 14, 2016 at 8:36 PM, Andrew Lee Rubinger >>> wrote: >>> >>>> Thanks! >>>> >>>> David, would you mind advising how we might go about handling $subject? >>>> >>>> S, >>>> ALR >>>> >>>> On Thu, Apr 14, 2016 at 8:24 PM, Ben Parees wrote: >>>> >>>>> Might be better to ask on the openshift dev list, but i'm told David >>>>> Eads is working on this so you could ping him directly as well. >>>>> >>>>> Ben Parees | OpenShift >>>>> On Apr 14, 2016 20:11, "Andrew Lee Rubinger" wrote: >>>>> >>>>>> So the Catapult project will be creating OpenShift projects for its >>>>>> users. >>>>>> >>>>>> At the moment we're doing this by logging in *as* the user, but >>>>>> really what we want to do is create projects *on behalf of* users. >>>>>> >>>>>> Clayton advises that we're unlikely to be granted cluster-admin >>>>>> rights to OpenShift Online (or even in some dedicated instance we run), so >>>>>> perhaps we need some other role that has permissions to create projects and >>>>>> a rolebinding to the user in question. >>>>>> >>>>>> Associated Catapult issue is: >>>>>> >>>>>> https://github.com/redhat-kontinuity/catapult/issues/18 >>>>>> >>>>>> Thoughts from the OpenShift team? >>>>>> >>>>>> S, >>>>>> ALR >>>>>> >>>>>> _______________________________________________ >>>>>> kontinuity-dev-public mailing list >>>>>> kontinuity-dev-public at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>>>>> >>>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alr at redhat.com Fri Apr 15 19:19:49 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Fri, 15 Apr 2016 15:19:49 -0400 Subject: [kontinuity-dev-public] Creating a Project on Behalf of Users In-Reply-To: References: Message-ID: On Fri, Apr 15, 2016 at 3:11 PM, Ben Parees wrote: > > > On Thu, Apr 14, 2016 at 8:11 PM, Andrew Lee Rubinger > wrote: > >> So the Catapult project will be creating OpenShift projects for its users. >> >> At the moment we're doing this by logging in *as* the user, but really >> what we want to do is create projects *on behalf of* users. >> > > ?can we take a step back and ask why logging in as the user and doing > stuff for them is not a valid approach for you? > Sure. 1) It's icky and has a weird audit trail, but more practically: 2) How do I get the user's login information (username and password)? S, ALR > ? > > > >> >> Clayton advises that we're unlikely to be granted cluster-admin rights to >> OpenShift Online (or even in some dedicated instance we run), so perhaps we >> need some other role that has permissions to create projects and a >> rolebinding to the user in question. >> >> Associated Catapult issue is: >> >> https://github.com/redhat-kontinuity/catapult/issues/18 >> >> Thoughts from the OpenShift team? >> >> S, >> ALR >> >> _______________________________________________ >> kontinuity-dev-public mailing list >> kontinuity-dev-public at redhat.com >> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >> >> > > > -- > Ben Parees | OpenShift > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bparees at redhat.com Fri Apr 15 19:27:04 2016 From: bparees at redhat.com (Ben Parees) Date: Fri, 15 Apr 2016 15:27:04 -0400 Subject: [kontinuity-dev-public] Creating a Project on Behalf of Users In-Reply-To: References: Message-ID: adding david back to the thread. On Fri, Apr 15, 2016 at 3:19 PM, Andrew Lee Rubinger wrote: > > > On Fri, Apr 15, 2016 at 3:11 PM, Ben Parees wrote: > >> >> >> On Thu, Apr 14, 2016 at 8:11 PM, Andrew Lee Rubinger >> wrote: >> >>> So the Catapult project will be creating OpenShift projects for its >>> users. >>> >>> At the moment we're doing this by logging in *as* the user, but really >>> what we want to do is create projects *on behalf of* users. >>> >> >> ?can we take a step back and ask why logging in as the user and doing >> stuff for them is not a valid approach for you? >> > > Sure. > > 1) It's icky and has a weird audit trail, but more practically: > 2) How do I get the user's login information (username and password)? > > S, > ALR > > >> ? >> >> >> >>> >>> Clayton advises that we're unlikely to be granted cluster-admin rights >>> to OpenShift Online (or even in some dedicated instance we run), so perhaps >>> we need some other role that has permissions to create projects and a >>> rolebinding to the user in question. >>> >>> Associated Catapult issue is: >>> >>> https://github.com/redhat-kontinuity/catapult/issues/18 >>> >>> Thoughts from the OpenShift team? >>> >>> S, >>> ALR >>> >>> _______________________________________________ >>> kontinuity-dev-public mailing list >>> kontinuity-dev-public at redhat.com >>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>> >>> >> >> >> -- >> Ben Parees | OpenShift >> >> > -- Ben Parees | OpenShift -------------- next part -------------- An HTML attachment was scrubbed... URL: From alr at redhat.com Wed Apr 20 01:36:21 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Tue, 19 Apr 2016 21:36:21 -0400 Subject: [kontinuity-dev-public] ARQ Support for k8s and OpenShift Message-ID: Hi, all: This discussion is spawned off from one that started on an internal RHT list. The gist is: We have work done by the Fabric8 team as an ARQ extension to test components running inside Kubernetes (including OpenShift) : https://github.com/fabric8io/fabric8/tree/master/components/fabric8-arquillian There is an Arquillian extension for testing components running inside Docker containers: https://github.com/arquillian/arquillian-cube And the Cloud Enablement team has been working on a bit called ce-arq (which I don't have reference to, actually). I'd like the ARQ, Fabric8, and Cloud Enablement teams to start work on defining scopes for each of these projects and figuring out: * Where there's overlap * If there's something we should do to mitigate overlap * If there's benefit in merging featuresets into a common project (or set of projects) The idea here is, sure to reduce overall work by not all addressing the same problem -- but also it'll really help with our user experience and testing story to have a toolset we're all rallying around. At the moment simple questions like, "hey, how should I execute integration tests on my app deployed on OpenShift" are yielding different answers depending upon our biases. :) This thread to kick off the discussion, and I'll leave it to the project leads to start to work through this and make recommendations. Thanks! S, ALR -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcernich at redhat.com Wed Apr 20 20:34:54 2016 From: rcernich at redhat.com (Rob Cernich) Date: Wed, 20 Apr 2016 16:34:54 -0400 (EDT) Subject: [kontinuity-dev-public] ARQ Support for k8s and OpenShift In-Reply-To: References: Message-ID: <143790136.7449906.1461184494395.JavaMail.zimbra@redhat.com> Hey Andrew, Thanks for starting the conversation... ----- Original Message ----- > Hi, all: > This discussion is spawned off from one that started on an internal RHT list. > The gist is: > We have work done by the Fabric8 team as an ARQ extension to test components > running inside Kubernetes (including OpenShift) : > https://github.com/fabric8io/fabric8/tree/master/components/fabric8-arquillian > There is an Arquillian extension for testing components running inside Docker > containers: > https://github.com/arquillian/arquillian-cube > And the Cloud Enablement team has been working on a bit called ce-arq (which > I don't have reference to, actually). https://github.com/jboss-openshift/ce-arq > I'd like the ARQ, Fabric8, and Cloud Enablement teams to start work on > defining scopes for each of these projects and figuring out: > * Where there's overlap Here's where I think there is overlap: * Client management (i.e. creating the k8s/ose client). Currently, ce-arq is using the client provided by arquillian-cube/openshift * Environment setup/teardown. ce-arq provides support for per test case, whereas fabric8-arquillian supports per execution. fabric8 has a nice mechanism for managing "sessions" which would be nice to glob onto, especially for things like per suite (which isn't really supported at all) > * If there's something we should do to mitigate overlap 1. We should be using a shared client (i.e. all three projects get a handle to the client from a single source). 2. Separate out the environment setup so that it too can be shared (e.g. so somebody (us) using ce-arq can use all the k8s assertion goodness that comes with fabric8), but still use their own mechanism for setup/teardown of the ose app under test. > * If there's benefit in merging featuresets into a common project (or set of > projects) I'm all for consolidation, but that might be a bit much to ask for out of the gate. I think it would be nice if the projects were collocated, but I don't know if that's a requirement. I also don't really have an opinion as to general project structure (one project, two, three, etc.). Arquillian has a pretty flexible extension mechanism, so I think it just comes down to how much effort folks want to put into reorganizing their code. > The idea here is, sure to reduce overall work by not all addressing the same > problem -- but also it'll really help with our user experience and testing > story to have a toolset we're all rallying around. At the moment simple > questions like, "hey, how should I execute integration tests on my app > deployed on OpenShift" are yielding different answers depending upon our > biases. :) Absolutely! > This thread to kick off the discussion, and I'll leave it to the project > leads to start to work through this and make recommendations. Thanks for getting the ball rolling!!! > Thanks! > S, > ALR -------------- next part -------------- An HTML attachment was scrubbed... URL: From aknutsen at redhat.com Thu Apr 21 07:12:01 2016 From: aknutsen at redhat.com (Aslak Knutsen) Date: Thu, 21 Apr 2016 09:12:01 +0200 Subject: [kontinuity-dev-public] ARQ Support for k8s and OpenShift In-Reply-To: References: Message-ID: Moved to Arquillian forum: http://discuss.arquillian.org/t/unify-arquillian-openshift-k8-projects/301/1 On Wed, Apr 20, 2016 at 3:36 AM, Andrew Lee Rubinger wrote: > Hi, all: > > This discussion is spawned off from one that started on an internal RHT > list. The gist is: > > We have work done by the Fabric8 team as an ARQ extension to test > components running inside Kubernetes (including OpenShift) : > > > https://github.com/fabric8io/fabric8/tree/master/components/fabric8-arquillian > > There is an Arquillian extension for testing components running inside > Docker containers: > > https://github.com/arquillian/arquillian-cube > > And the Cloud Enablement team has been working on a bit called ce-arq > (which I don't have reference to, actually). > > I'd like the ARQ, Fabric8, and Cloud Enablement teams to start work on > defining scopes for each of these projects and figuring out: > > * Where there's overlap > * If there's something we should do to mitigate overlap > * If there's benefit in merging featuresets into a common project (or set > of projects) > > The idea here is, sure to reduce overall work by not all addressing the > same problem -- but also it'll really help with our user experience and > testing story to have a toolset we're all rallying around. At the moment > simple questions like, "hey, how should I execute integration tests on my > app deployed on OpenShift" are yielding different answers depending upon > our biases. :) > > This thread to kick off the discussion, and I'll leave it to the project > leads to start to work through this and make recommendations. > > Thanks! > > S, > ALR > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcernich at redhat.com Thu Apr 21 19:36:39 2016 From: rcernich at redhat.com (Rob Cernich) Date: Thu, 21 Apr 2016 15:36:39 -0400 (EDT) Subject: [kontinuity-dev-public] ARQ Support for k8s and OpenShift In-Reply-To: References: Message-ID: <736728557.7956185.1461267399964.JavaMail.zimbra@redhat.com> Ok. I copied my reply to the arquillian forum post. ----- Original Message ----- > Moved to Arquillian forum: > http://discuss.arquillian.org/t/unify-arquillian-openshift-k8-projects/301/1 > On Wed, Apr 20, 2016 at 3:36 AM, Andrew Lee Rubinger < alr at redhat.com > > wrote: > > Hi, all: > > > This discussion is spawned off from one that started on an internal RHT > > list. > > The gist is: > > > We have work done by the Fabric8 team as an ARQ extension to test > > components > > running inside Kubernetes (including OpenShift) : > > > https://github.com/fabric8io/fabric8/tree/master/components/fabric8-arquillian > > > There is an Arquillian extension for testing components running inside > > Docker > > containers: > > > https://github.com/arquillian/arquillian-cube > > > And the Cloud Enablement team has been working on a bit called ce-arq > > (which > > I don't have reference to, actually). > > > I'd like the ARQ, Fabric8, and Cloud Enablement teams to start work on > > defining scopes for each of these projects and figuring out: > > > * Where there's overlap > > > * If there's something we should do to mitigate overlap > > > * If there's benefit in merging featuresets into a common project (or set > > of > > projects) > > > The idea here is, sure to reduce overall work by not all addressing the > > same > > problem -- but also it'll really help with our user experience and testing > > story to have a toolset we're all rallying around. At the moment simple > > questions like, "hey, how should I execute integration tests on my app > > deployed on OpenShift" are yielding different answers depending upon our > > biases. :) > > > This thread to kick off the discussion, and I'll leave it to the project > > leads to start to work through this and make recommendations. > > > Thanks! > > > S, > > > ALR > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alr at redhat.com Mon Apr 25 22:35:51 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Mon, 25 Apr 2016 18:35:51 -0400 Subject: [kontinuity-dev-public] Trello Board to Cover CI Work Message-ID: Hi all: I've created a Trello board, open to the public, to chart our work done in CI: https://trello.com/b/iv4wARaG/kontinuity-ci-environment Work here wasn't really appropriate for our issue tracker because it doesn't affect the codebase, and our Theremin Trello board is much too high-level for these tasks. So Dharmit and AndrewB can use this to track the work they're leading. :) S, ALR -------------- next part -------------- An HTML attachment was scrubbed... URL: From distortion-jenkins at redhat.com Tue Apr 26 19:34:24 2016 From: distortion-jenkins at redhat.com (distortion-jenkins at redhat.com) Date: Tue, 26 Apr 2016 19:34:24 +0000 (UTC) Subject: [kontinuity-dev-public] Jenkins build is still unstable: catapult #5 In-Reply-To: <248770746.5.1461623630161.JavaMail.root@jenkins-c7fj5> References: <248770746.5.1461623630161.JavaMail.root@jenkins-c7fj5> Message-ID: <1705254092.7.1461699264673.JavaMail.root@jenkins-c7fj5> See From distortion-jenkins at redhat.com Tue Apr 26 19:37:51 2016 From: distortion-jenkins at redhat.com (distortion-jenkins at redhat.com) Date: Tue, 26 Apr 2016 19:37:51 +0000 (UTC) Subject: [kontinuity-dev-public] Jenkins build is still unstable: catapult #5 In-Reply-To: <248770746.5.1461623630161.JavaMail.root@jenkins-c7fj5> References: <248770746.5.1461623630161.JavaMail.root@jenkins-c7fj5> Message-ID: <184719158.8.1461699471456.JavaMail.root@jenkins-c7fj5> See From alr at redhat.com Fri Apr 29 08:00:43 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Fri, 29 Apr 2016 04:00:43 -0400 Subject: [kontinuity-dev-public] Creating a Project on Behalf of Users In-Reply-To: References: Message-ID: Mind if I resurrect this one? Ideally I'd like to create projects *for* users from some account with the proper permissions. Failing that I'd need to know how to log in *as a user*, which I'm assuming has all sorts of security violations :) And obviously other approaches welcomed! S, ALR On Fri, Apr 15, 2016 at 3:27 PM, Ben Parees wrote: > adding david back to the thread. > > > On Fri, Apr 15, 2016 at 3:19 PM, Andrew Lee Rubinger > wrote: > >> >> >> On Fri, Apr 15, 2016 at 3:11 PM, Ben Parees wrote: >> >>> >>> >>> On Thu, Apr 14, 2016 at 8:11 PM, Andrew Lee Rubinger >>> wrote: >>> >>>> So the Catapult project will be creating OpenShift projects for its >>>> users. >>>> >>>> At the moment we're doing this by logging in *as* the user, but really >>>> what we want to do is create projects *on behalf of* users. >>>> >>> >>> ?can we take a step back and ask why logging in as the user and doing >>> stuff for them is not a valid approach for you? >>> >> >> Sure. >> >> 1) It's icky and has a weird audit trail, but more practically: >> 2) How do I get the user's login information (username and password)? >> >> S, >> ALR >> >> >>> ? >>> >>> >>> >>>> >>>> Clayton advises that we're unlikely to be granted cluster-admin rights >>>> to OpenShift Online (or even in some dedicated instance we run), so perhaps >>>> we need some other role that has permissions to create projects and a >>>> rolebinding to the user in question. >>>> >>>> Associated Catapult issue is: >>>> >>>> https://github.com/redhat-kontinuity/catapult/issues/18 >>>> >>>> Thoughts from the OpenShift team? >>>> >>>> S, >>>> ALR >>>> >>>> _______________________________________________ >>>> kontinuity-dev-public mailing list >>>> kontinuity-dev-public at redhat.com >>>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>>> >>>> >>> >>> >>> -- >>> Ben Parees | OpenShift >>> >>> >> > > > -- > Ben Parees | OpenShift > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From deads at redhat.com Fri Apr 29 11:35:26 2016 From: deads at redhat.com (David Eads) Date: Fri, 29 Apr 2016 07:35:26 -0400 Subject: [kontinuity-dev-public] Creating a Project on Behalf of Users In-Reply-To: References: Message-ID: If your user has sufficient power, you can create the namespace object directly, set the annotations, and add a rolebinding for the user. Take a look at `oadm new-project --loglevel=8` (note that its oadm, not oc). On Fri, Apr 29, 2016 at 4:00 AM, Andrew Lee Rubinger wrote: > Mind if I resurrect this one? > > Ideally I'd like to create projects *for* users from some account with the > proper permissions. Failing that I'd need to know how to log in *as a > user*, which I'm assuming has all sorts of security violations :) > > And obviously other approaches welcomed! > > S, > ALR > > On Fri, Apr 15, 2016 at 3:27 PM, Ben Parees wrote: > >> adding david back to the thread. >> >> >> On Fri, Apr 15, 2016 at 3:19 PM, Andrew Lee Rubinger >> wrote: >> >>> >>> >>> On Fri, Apr 15, 2016 at 3:11 PM, Ben Parees wrote: >>> >>>> >>>> >>>> On Thu, Apr 14, 2016 at 8:11 PM, Andrew Lee Rubinger >>>> wrote: >>>> >>>>> So the Catapult project will be creating OpenShift projects for its >>>>> users. >>>>> >>>>> At the moment we're doing this by logging in *as* the user, but really >>>>> what we want to do is create projects *on behalf of* users. >>>>> >>>> >>>> ?can we take a step back and ask why logging in as the user and doing >>>> stuff for them is not a valid approach for you? >>>> >>> >>> Sure. >>> >>> 1) It's icky and has a weird audit trail, but more practically: >>> 2) How do I get the user's login information (username and password)? >>> >>> S, >>> ALR >>> >>> >>>> ? >>>> >>>> >>>> >>>>> >>>>> Clayton advises that we're unlikely to be granted cluster-admin rights >>>>> to OpenShift Online (or even in some dedicated instance we run), so perhaps >>>>> we need some other role that has permissions to create projects and a >>>>> rolebinding to the user in question. >>>>> >>>>> Associated Catapult issue is: >>>>> >>>>> https://github.com/redhat-kontinuity/catapult/issues/18 >>>>> >>>>> Thoughts from the OpenShift team? >>>>> >>>>> S, >>>>> ALR >>>>> >>>>> _______________________________________________ >>>>> kontinuity-dev-public mailing list >>>>> kontinuity-dev-public at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>>>> >>>>> >>>> >>>> >>>> -- >>>> Ben Parees | OpenShift >>>> >>>> >>> >> >> >> -- >> Ben Parees | OpenShift >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstracha at redhat.com Fri Apr 29 11:38:17 2016 From: jstracha at redhat.com (James Strachan) Date: Fri, 29 Apr 2016 12:38:17 +0100 Subject: [kontinuity-dev-public] Creating a Project on Behalf of Users In-Reply-To: References: Message-ID: if you can create a project, can you always annotate it? I remember someone saying only cluster-admin could annotate a project? (Admittedly you can annotate it as you create it - just wanted to check ;) > On 29 Apr 2016, at 12:35, David Eads wrote: > > If your user has sufficient power, you can create the namespace object directly, set the annotations, and add a rolebinding for the user. Take a look at `oadm new-project --loglevel=8` (note that its oadm, not oc). > > On Fri, Apr 29, 2016 at 4:00 AM, Andrew Lee Rubinger > wrote: > Mind if I resurrect this one? > > Ideally I'd like to create projects *for* users from some account with the proper permissions. Failing that I'd need to know how to log in *as a user*, which I'm assuming has all sorts of security violations :) > > And obviously other approaches welcomed! > > S, > ALR > > On Fri, Apr 15, 2016 at 3:27 PM, Ben Parees > wrote: > adding david back to the thread. > > > On Fri, Apr 15, 2016 at 3:19 PM, Andrew Lee Rubinger > wrote: > > > On Fri, Apr 15, 2016 at 3:11 PM, Ben Parees > wrote: > > > On Thu, Apr 14, 2016 at 8:11 PM, Andrew Lee Rubinger > wrote: > So the Catapult project will be creating OpenShift projects for its users. > > At the moment we're doing this by logging in *as* the user, but really what we want to do is create projects *on behalf of* users. > > ?can we take a step back and ask why logging in as the user and doing stuff for them is not a valid approach for you? > > Sure. > > 1) It's icky and has a weird audit trail, but more practically: > 2) How do I get the user's login information (username and password)? > > S, > ALR > > ? > > > > Clayton advises that we're unlikely to be granted cluster-admin rights to OpenShift Online (or even in some dedicated instance we run), so perhaps we need some other role that has permissions to create projects and a rolebinding to the user in question. > > Associated Catapult issue is: > > https://github.com/redhat-kontinuity/catapult/issues/18 > > Thoughts from the OpenShift team? > > S, > ALR > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > > > > > -- > Ben Parees | OpenShift > > > > > > -- > Ben Parees | OpenShift > > > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public James ------- Red Hat Twitter: @jstrachan Email: jstracha at redhat.com Blog: https://medium.com/@jstrachan/ fabric8: http://fabric8.io/ open source microservices platform -------------- next part -------------- An HTML attachment was scrubbed... URL: From deads at redhat.com Fri Apr 29 11:43:04 2016 From: deads at redhat.com (David Eads) Date: Fri, 29 Apr 2016 07:43:04 -0400 Subject: [kontinuity-dev-public] Creating a Project on Behalf of Users In-Reply-To: References: Message-ID: The vast majority of users cannot create or annotate namespaces, but you'll have to in order to make the user the nominal "owner". On whatever cluster you're running, you'll need to convince the cluster admin to give you significantly elevated privileges in order to perform these actions. What you're asking to do is a privileged action: "put this project on this user" which we do not have a protected workflow to achieve. On Fri, Apr 29, 2016 at 7:38 AM, James Strachan wrote: > if you can create a project, can you always annotate it? I remember > someone saying only cluster-admin could annotate a project? > > (Admittedly you can annotate it as you create it - just wanted to check ;) > > > On 29 Apr 2016, at 12:35, David Eads wrote: > > If your user has sufficient power, you can create the namespace object > directly, set the annotations, and add a rolebinding for the user. Take a > look at `oadm new-project --loglevel=8` (note that its oadm, not oc). > > On Fri, Apr 29, 2016 at 4:00 AM, Andrew Lee Rubinger > wrote: > >> Mind if I resurrect this one? >> >> Ideally I'd like to create projects *for* users from some account with >> the proper permissions. Failing that I'd need to know how to log in *as a >> user*, which I'm assuming has all sorts of security violations :) >> >> And obviously other approaches welcomed! >> >> S, >> ALR >> >> On Fri, Apr 15, 2016 at 3:27 PM, Ben Parees wrote: >> >>> adding david back to the thread. >>> >>> >>> On Fri, Apr 15, 2016 at 3:19 PM, Andrew Lee Rubinger >>> wrote: >>> >>>> >>>> >>>> On Fri, Apr 15, 2016 at 3:11 PM, Ben Parees wrote: >>>> >>>>> >>>>> >>>>> On Thu, Apr 14, 2016 at 8:11 PM, Andrew Lee Rubinger >>>>> wrote: >>>>> >>>>>> So the Catapult project will be creating OpenShift projects for its >>>>>> users. >>>>>> >>>>>> At the moment we're doing this by logging in *as* the user, but >>>>>> really what we want to do is create projects *on behalf of* users. >>>>>> >>>>> >>>>> ?can we take a step back and ask why logging in as the user and doing >>>>> stuff for them is not a valid approach for you? >>>>> >>>> >>>> Sure. >>>> >>>> 1) It's icky and has a weird audit trail, but more practically: >>>> 2) How do I get the user's login information (username and password)? >>>> >>>> S, >>>> ALR >>>> >>>> >>>>> ? >>>>> >>>>> >>>>> >>>>>> >>>>>> Clayton advises that we're unlikely to be granted cluster-admin >>>>>> rights to OpenShift Online (or even in some dedicated instance we run), so >>>>>> perhaps we need some other role that has permissions to create projects and >>>>>> a rolebinding to the user in question. >>>>>> >>>>>> Associated Catapult issue is: >>>>>> >>>>>> https://github.com/redhat-kontinuity/catapult/issues/18 >>>>>> >>>>>> Thoughts from the OpenShift team? >>>>>> >>>>>> S, >>>>>> ALR >>>>>> >>>>>> _______________________________________________ >>>>>> kontinuity-dev-public mailing list >>>>>> kontinuity-dev-public at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Ben Parees | OpenShift >>>>> >>>>> >>>> >>> >>> >>> -- >>> Ben Parees | OpenShift >>> >>> >> > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > > > > James > ------- > Red Hat > > Twitter: @jstrachan > Email: jstracha at redhat.com > Blog: https://medium.com/@jstrachan/ > > fabric8: http://fabric8.io/ > open source microservices platform > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alr at redhat.com Fri Apr 29 13:44:49 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Fri, 29 Apr 2016 09:44:49 -0400 Subject: [kontinuity-dev-public] Creating a Project on Behalf of Users In-Reply-To: References: Message-ID: Cool, thanks David. If we take the assumption that our eventual deployment target is OpenShift Online, will we be able to have an account with "sufficient power"? Or do I need to pipe some request/requirements into dev to create the appropriate workflow/privilege set to both give us the features we need while providing enough security? S, ALR On Fri, Apr 29, 2016 at 7:43 AM, David Eads wrote: > The vast majority of users cannot create or annotate namespaces, but > you'll have to in order to make the user the nominal "owner". On whatever > cluster you're running, you'll need to convince the cluster admin to give > you significantly elevated privileges in order to perform these actions. > What you're asking to do is a privileged action: "put this project on this > user" which we do not have a protected workflow to achieve. > > On Fri, Apr 29, 2016 at 7:38 AM, James Strachan > wrote: > >> if you can create a project, can you always annotate it? I remember >> someone saying only cluster-admin could annotate a project? >> >> (Admittedly you can annotate it as you create it - just wanted to check ;) >> >> >> On 29 Apr 2016, at 12:35, David Eads wrote: >> >> If your user has sufficient power, you can create the namespace object >> directly, set the annotations, and add a rolebinding for the user. Take a >> look at `oadm new-project --loglevel=8` (note that its oadm, not oc). >> >> On Fri, Apr 29, 2016 at 4:00 AM, Andrew Lee Rubinger >> wrote: >> >>> Mind if I resurrect this one? >>> >>> Ideally I'd like to create projects *for* users from some account with >>> the proper permissions. Failing that I'd need to know how to log in *as a >>> user*, which I'm assuming has all sorts of security violations :) >>> >>> And obviously other approaches welcomed! >>> >>> S, >>> ALR >>> >>> On Fri, Apr 15, 2016 at 3:27 PM, Ben Parees wrote: >>> >>>> adding david back to the thread. >>>> >>>> >>>> On Fri, Apr 15, 2016 at 3:19 PM, Andrew Lee Rubinger >>>> wrote: >>>> >>>>> >>>>> >>>>> On Fri, Apr 15, 2016 at 3:11 PM, Ben Parees >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Thu, Apr 14, 2016 at 8:11 PM, Andrew Lee Rubinger >>>>>> wrote: >>>>>> >>>>>>> So the Catapult project will be creating OpenShift projects for its >>>>>>> users. >>>>>>> >>>>>>> At the moment we're doing this by logging in *as* the user, but >>>>>>> really what we want to do is create projects *on behalf of* users. >>>>>>> >>>>>> >>>>>> ?can we take a step back and ask why logging in as the user and doing >>>>>> stuff for them is not a valid approach for you? >>>>>> >>>>> >>>>> Sure. >>>>> >>>>> 1) It's icky and has a weird audit trail, but more practically: >>>>> 2) How do I get the user's login information (username and password)? >>>>> >>>>> S, >>>>> ALR >>>>> >>>>> >>>>>> ? >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Clayton advises that we're unlikely to be granted cluster-admin >>>>>>> rights to OpenShift Online (or even in some dedicated instance we run), so >>>>>>> perhaps we need some other role that has permissions to create projects and >>>>>>> a rolebinding to the user in question. >>>>>>> >>>>>>> Associated Catapult issue is: >>>>>>> >>>>>>> https://github.com/redhat-kontinuity/catapult/issues/18 >>>>>>> >>>>>>> Thoughts from the OpenShift team? >>>>>>> >>>>>>> S, >>>>>>> ALR >>>>>>> >>>>>>> _______________________________________________ >>>>>>> kontinuity-dev-public mailing list >>>>>>> kontinuity-dev-public at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Ben Parees | OpenShift >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Ben Parees | OpenShift >>>> >>>> >>> >> _______________________________________________ >> kontinuity-dev-public mailing list >> kontinuity-dev-public at redhat.com >> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >> >> >> >> James >> ------- >> Red Hat >> >> Twitter: @jstrachan >> Email: jstracha at redhat.com >> Blog: https://medium.com/@jstrachan/ >> >> fabric8: http://fabric8.io/ >> open source microservices platform >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From deads at redhat.com Fri Apr 29 14:08:11 2016 From: deads at redhat.com (David Eads) Date: Fri, 29 Apr 2016 10:08:11 -0400 Subject: [kontinuity-dev-public] Creating a Project on Behalf of Users In-Reply-To: References: Message-ID: I'm not certain what level of integration will be available there. I'll have to defer to *Clayton*. On Fri, Apr 29, 2016 at 9:44 AM, Andrew Lee Rubinger wrote: > Cool, thanks David. > > If we take the assumption that our eventual deployment target is OpenShift > Online, will we be able to have an account with "sufficient power"? > > Or do I need to pipe some request/requirements into dev to create the > appropriate workflow/privilege set to both give us the features we need > while providing enough security? > > S, > ALR > > On Fri, Apr 29, 2016 at 7:43 AM, David Eads wrote: > >> The vast majority of users cannot create or annotate namespaces, but >> you'll have to in order to make the user the nominal "owner". On whatever >> cluster you're running, you'll need to convince the cluster admin to give >> you significantly elevated privileges in order to perform these actions. >> What you're asking to do is a privileged action: "put this project on this >> user" which we do not have a protected workflow to achieve. >> >> On Fri, Apr 29, 2016 at 7:38 AM, James Strachan >> wrote: >> >>> if you can create a project, can you always annotate it? I remember >>> someone saying only cluster-admin could annotate a project? >>> >>> (Admittedly you can annotate it as you create it - just wanted to check >>> ;) >>> >>> >>> On 29 Apr 2016, at 12:35, David Eads wrote: >>> >>> If your user has sufficient power, you can create the namespace object >>> directly, set the annotations, and add a rolebinding for the user. Take a >>> look at `oadm new-project --loglevel=8` (note that its oadm, not oc). >>> >>> On Fri, Apr 29, 2016 at 4:00 AM, Andrew Lee Rubinger >>> wrote: >>> >>>> Mind if I resurrect this one? >>>> >>>> Ideally I'd like to create projects *for* users from some account with >>>> the proper permissions. Failing that I'd need to know how to log in *as a >>>> user*, which I'm assuming has all sorts of security violations :) >>>> >>>> And obviously other approaches welcomed! >>>> >>>> S, >>>> ALR >>>> >>>> On Fri, Apr 15, 2016 at 3:27 PM, Ben Parees wrote: >>>> >>>>> adding david back to the thread. >>>>> >>>>> >>>>> On Fri, Apr 15, 2016 at 3:19 PM, Andrew Lee Rubinger >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, Apr 15, 2016 at 3:11 PM, Ben Parees >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Apr 14, 2016 at 8:11 PM, Andrew Lee Rubinger >>>>>> > wrote: >>>>>>> >>>>>>>> So the Catapult project will be creating OpenShift projects for its >>>>>>>> users. >>>>>>>> >>>>>>>> At the moment we're doing this by logging in *as* the user, but >>>>>>>> really what we want to do is create projects *on behalf of* users. >>>>>>>> >>>>>>> >>>>>>> ?can we take a step back and ask why logging in as the user and >>>>>>> doing stuff for them is not a valid approach for you? >>>>>>> >>>>>> >>>>>> Sure. >>>>>> >>>>>> 1) It's icky and has a weird audit trail, but more practically: >>>>>> 2) How do I get the user's login information (username and password)? >>>>>> >>>>>> S, >>>>>> ALR >>>>>> >>>>>> >>>>>>> ? >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Clayton advises that we're unlikely to be granted cluster-admin >>>>>>>> rights to OpenShift Online (or even in some dedicated instance we run), so >>>>>>>> perhaps we need some other role that has permissions to create projects and >>>>>>>> a rolebinding to the user in question. >>>>>>>> >>>>>>>> Associated Catapult issue is: >>>>>>>> >>>>>>>> https://github.com/redhat-kontinuity/catapult/issues/18 >>>>>>>> >>>>>>>> Thoughts from the OpenShift team? >>>>>>>> >>>>>>>> S, >>>>>>>> ALR >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> kontinuity-dev-public mailing list >>>>>>>> kontinuity-dev-public at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Ben Parees | OpenShift >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Ben Parees | OpenShift >>>>> >>>>> >>>> >>> _______________________________________________ >>> kontinuity-dev-public mailing list >>> kontinuity-dev-public at redhat.com >>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>> >>> >>> >>> James >>> ------- >>> Red Hat >>> >>> Twitter: @jstrachan >>> Email: jstracha at redhat.com >>> Blog: https://medium.com/@jstrachan/ >>> >>> fabric8: http://fabric8.io/ >>> open source microservices platform >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alr at redhat.com Fri Apr 29 14:10:28 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Fri, 29 Apr 2016 10:10:28 -0400 Subject: [kontinuity-dev-public] Creating a Project on Behalf of Users In-Reply-To: References: Message-ID: Appreciate your help! For the time being I think this is good info to keep us moving. On Fri, Apr 29, 2016 at 10:08 AM, David Eads wrote: > I'm not certain what level of integration will be available there. I'll > have to defer to *Clayton*. > > On Fri, Apr 29, 2016 at 9:44 AM, Andrew Lee Rubinger > wrote: > >> Cool, thanks David. >> >> If we take the assumption that our eventual deployment target is >> OpenShift Online, will we be able to have an account with "sufficient >> power"? >> >> Or do I need to pipe some request/requirements into dev to create the >> appropriate workflow/privilege set to both give us the features we need >> while providing enough security? >> >> S, >> ALR >> >> On Fri, Apr 29, 2016 at 7:43 AM, David Eads wrote: >> >>> The vast majority of users cannot create or annotate namespaces, but >>> you'll have to in order to make the user the nominal "owner". On whatever >>> cluster you're running, you'll need to convince the cluster admin to give >>> you significantly elevated privileges in order to perform these actions. >>> What you're asking to do is a privileged action: "put this project on this >>> user" which we do not have a protected workflow to achieve. >>> >>> On Fri, Apr 29, 2016 at 7:38 AM, James Strachan >>> wrote: >>> >>>> if you can create a project, can you always annotate it? I remember >>>> someone saying only cluster-admin could annotate a project? >>>> >>>> (Admittedly you can annotate it as you create it - just wanted to check >>>> ;) >>>> >>>> >>>> On 29 Apr 2016, at 12:35, David Eads wrote: >>>> >>>> If your user has sufficient power, you can create the namespace object >>>> directly, set the annotations, and add a rolebinding for the user. Take a >>>> look at `oadm new-project --loglevel=8` (note that its oadm, not oc). >>>> >>>> On Fri, Apr 29, 2016 at 4:00 AM, Andrew Lee Rubinger >>>> wrote: >>>> >>>>> Mind if I resurrect this one? >>>>> >>>>> Ideally I'd like to create projects *for* users from some account with >>>>> the proper permissions. Failing that I'd need to know how to log in *as a >>>>> user*, which I'm assuming has all sorts of security violations :) >>>>> >>>>> And obviously other approaches welcomed! >>>>> >>>>> S, >>>>> ALR >>>>> >>>>> On Fri, Apr 15, 2016 at 3:27 PM, Ben Parees >>>>> wrote: >>>>> >>>>>> adding david back to the thread. >>>>>> >>>>>> >>>>>> On Fri, Apr 15, 2016 at 3:19 PM, Andrew Lee Rubinger >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Apr 15, 2016 at 3:11 PM, Ben Parees >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Apr 14, 2016 at 8:11 PM, Andrew Lee Rubinger < >>>>>>>> alr at redhat.com> wrote: >>>>>>>> >>>>>>>>> So the Catapult project will be creating OpenShift projects for >>>>>>>>> its users. >>>>>>>>> >>>>>>>>> At the moment we're doing this by logging in *as* the user, but >>>>>>>>> really what we want to do is create projects *on behalf of* users. >>>>>>>>> >>>>>>>> >>>>>>>> ?can we take a step back and ask why logging in as the user and >>>>>>>> doing stuff for them is not a valid approach for you? >>>>>>>> >>>>>>> >>>>>>> Sure. >>>>>>> >>>>>>> 1) It's icky and has a weird audit trail, but more practically: >>>>>>> 2) How do I get the user's login information (username and password)? >>>>>>> >>>>>>> S, >>>>>>> ALR >>>>>>> >>>>>>> >>>>>>>> ? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Clayton advises that we're unlikely to be granted cluster-admin >>>>>>>>> rights to OpenShift Online (or even in some dedicated instance we run), so >>>>>>>>> perhaps we need some other role that has permissions to create projects and >>>>>>>>> a rolebinding to the user in question. >>>>>>>>> >>>>>>>>> Associated Catapult issue is: >>>>>>>>> >>>>>>>>> https://github.com/redhat-kontinuity/catapult/issues/18 >>>>>>>>> >>>>>>>>> Thoughts from the OpenShift team? >>>>>>>>> >>>>>>>>> S, >>>>>>>>> ALR >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> kontinuity-dev-public mailing list >>>>>>>>> kontinuity-dev-public at redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Ben Parees | OpenShift >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Ben Parees | OpenShift >>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>>> kontinuity-dev-public mailing list >>>> kontinuity-dev-public at redhat.com >>>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>>> >>>> >>>> >>>> James >>>> ------- >>>> Red Hat >>>> >>>> Twitter: @jstrachan >>>> Email: jstracha at redhat.com >>>> Blog: https://medium.com/@jstrachan/ >>>> >>>> fabric8: http://fabric8.io/ >>>> open source microservices platform >>>> >>>> >>> >> > -- Red Hat Developer Programs Architecture @ALRubinger -------------- next part -------------- An HTML attachment was scrubbed... URL: From kohei at nozaki.me Sat Apr 30 02:12:17 2016 From: kohei at nozaki.me (Kohei Nozaki) Date: Sat, 30 Apr 2016 11:12:17 +0900 Subject: [kontinuity-dev-public] Integration test failure on catapult-service-openshift-impl Message-ID: <44ff6434-7cbc-6a43-8e63-7ce7f9b7c46f@nozaki.me> Hello, I'm trying to run Catapult's integration test cases following README, but it doesn't work for me. Build log: https://gist.github.com/lbtc-xxx/9aaddf84d11986e0dc84f979545a28e0 Relevant part of failsafe-reports: http://people.apache.org/~kohei/failsafe-reports-openshift-service-impl/ I'm newbie of Docker / OpenShift so maybe it's caused by easy mistake, but I don't know what it is. could you give me any hints to make it work? Thanks. Kohei From alr at redhat.com Sat Apr 30 05:47:14 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Sat, 30 Apr 2016 11:17:14 +0530 Subject: [kontinuity-dev-public] Integration test failure on catapult-service-openshift-impl In-Reply-To: <44ff6434-7cbc-6a43-8e63-7ce7f9b7c46f@nozaki.me> References: <44ff6434-7cbc-6a43-8e63-7ce7f9b7c46f@nozaki.me> Message-ID: Hey Kohel: Welcome! Though I haven't seen this error yet either locally or in our CI environments, let's see what we can do. So the relevant error is in your connecting to OpenShift: io.fabric8.kubernetes.client.KubernetesClientException: An error has occurred. Caused by: java.io.IOException: unexpected end of stream on com.squareup.okhttp.Address at e5a03a78 Caused by: java.io.EOFException: \n not found: size=7 content=15030100020216... I'm guessing you followed the instructions to get OpenShift running locally; if you hadn't I think you'd be seeing some variant of ConnectException: Caused by: io.fabric8.kubernetes.client.KubernetesClientException: An error has occurred. Caused by: java.net.ConnectException: Failed to connect to localhost/ 127.0.0.1:8443 Can you let us know which method you've chosen to run OpenShift? I've been testing here against a local build of OpenShift Origin master. Beyond that I see some similar complaints in the okhttp tracker: https://github.com/square/okhttp/issues/1741 ...perhaps the Fabric8 team has some better insights as they're consuming the lib; will ping @iocanel. S, ALR On Sat, Apr 30, 2016 at 7:42 AM, Kohei Nozaki wrote: > Hello, > > I'm trying to run Catapult's integration test cases following README, but > it doesn't work for me. > > Build log: > https://gist.github.com/lbtc-xxx/9aaddf84d11986e0dc84f979545a28e0 > > Relevant part of failsafe-reports: > http://people.apache.org/~kohei/failsafe-reports-openshift-service-impl/ > > I'm newbie of Docker / OpenShift so maybe it's caused by easy mistake, but > I don't know what it is. could you give me any hints to make it work? > > Thanks. > > Kohei > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > -- Red Hat Developer Programs Architecture @ALRubinger -------------- next part -------------- An HTML attachment was scrubbed... URL: