Testing Ansible roles with Molecule on OpenShift?

[Andrew Feller]

I've spent a few hours digging around for solid documentation on the molecule
site  or
examples of people doing this, however I've come up with nothing
definitive.  OpenShift documentation

rightly
advocates to limit privileged container access to dockerd daemon, which is
the default driver for molecule.  Tools like redhat-cop/openshift-applier
 and
other Red Hat projects seem to be managing ephemeral VMs for CI via
TravisCI rather than doing this in OpenShift itself with any of it's
BuildConfig / Jenkins support.

Would appreciate anyone pointing out some pre-existing projects out there
running on OpenShift that drive this or highlight why that is a no go.

Thanks

-- 

[image: BandwidthMaroon.png]

Andy Feller  •  Sr DevOps Engineer

900 Main Campus Drive, Suite 500, Raleigh, NC 27606


e: afel...@bandwidth.com
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: BuildConfigs failedBuildsHistoryLimit and successfulBuildsHistoryLimit fields being defaulted in OpenShift v3.11 cluster

[Andrew Feller]

Thanks Ben and Adam for the follow up and filing bugs!  I will follow up
regarding the RFE; thanks for the direction

On Thu, Mar 28, 2019 at 9:34 AM Adam Kaplan  wrote:

> Yup, thanks, that doc definitely needs to be fixed.  Adam can you make
>> sure that happens?  (Along w/ fixing the api doc)
>>
>
> Bug has been filed against our 3.11 docs:
> https://bugzilla.redhat.com/show_bug.cgi?id=1693685
>
> On Thu, Mar 28, 2019 at 9:01 AM Ben Parees  wrote:
>
>>
>>
>> On Thu, Mar 28, 2019 at 6:48 AM Andrew Feller 
>> wrote:
>>
>>> Thanks for the follow up, Ben.
>>>
>>> I suppose we haven't created any new BuildConfigs from scratch since our
>>> v3.9 => v3.11 upgrade, however there is no mention within OCP 3.11
>>> release notes
>>> <https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html>
>>>  about
>>> this change of behavior
>>>
>>
>> We introduced this new behavior when we introduced the groupified apis, i
>> think that was before 3.11.  But I can't guarantee it made the release
>> notes for whatever release it was done in.
>>
>> I suspect what happened here though is that you are defining your
>> buildconfigs using the legacy apiversion and, up until 3.11, that meant
>> your oc creates went through the legacy api.  In 3.11 (I think) changes
>> were made that sent all api calls through the groupified path even if the
>> api type specified legacy, so that would have caused you to start seeing
>> the new behavior.
>>
>> Regardless, we clearly didn't get the docs right and I apologize for it
>> impacting you.
>>
>>
>>
>>> and the Advanced Build Operations > Build Pruning
>>> <https://docs.openshift.com/container-platform/3.11/dev_guide/builds/advanced_build_operations.html#build-pruning>
>>>  documentation
>>> implies default behavior is that no history limit is enforced on creation.
>>>
>>
>> Yup, thanks, that doc definitely needs to be fixed.  Adam can you make
>> sure that happens?  (Along w/ fixing the api doc)
>>
>>
>>
>>> We just happened to have someone accidentally delete a project's
>>> contents and discovered this after losing builds and their history
>>> unknowingly.  Ideally, I would rather prefer BuildConfig pruning gave us
>>> the option of specifying a number of days to keep old Builds, but we'll
>>> make due as we don't have hard and fast retention requirements yet.
>>>
>>
>> We went with number because the primary concern was controlling the
>> amount/size of content being retained in etcd, which you don't get with a
>> time-bound constraint.  But certainly offering both options is a reasonable
>> RFE (no promises it would get a high priority though)
>>
>>
>>
>>
>>>
>>> On Wed, Mar 27, 2019 at 2:14 PM Ben Parees  wrote:
>>>
>>>>
>>>>
>>>> On Wed, Mar 27, 2019 at 11:58 AM Andrew Feller 
>>>> wrote:
>>>>
>>>>> Using a simple documented BuildConfig
>>>>> <https://docs.openshift.com/container-platform/3.11/dev_guide/builds/index.html>,
>>>>> we're seeing every newly created BuildConfig resource
>>>>> defaulting failedBuildsHistoryLimit and successfulBuildsHistoryLimit when
>>>>> documentation specifies BuildConfig not having default values and honoring
>>>>> preserving all builds.
>>>>>
>>>>
>>>> i'm assuming you're basing your statement on the api doc:
>>>>
>>>> https://github.com/openshift/api/blob/release-3.11/build/v1/types.go#L904
>>>>
>>>> (if you saw it somewhere else, please let us know).
>>>>
>>>> Unfortunately that doc is wrong...  when we moved from legacy resource
>>>> types to grouped resource types, we introduced a default retention of 5 for
>>>> each type(successful and failed).  If you created a buildconfig via the
>>>> legacy resource you got no limit, but if you create it via the grouped
>>>> resource (which is the default and what everyone should be doing now), you
>>>> got a default of 5 applied to your object.  If you look at the
>>>> buildconfig.yaml (oc get bc/foo -o yaml) you will see that value appear
>>>> because it's actually applied to your object during creation.
>>>>
>>>> you can edit the bc and delete the field to switch to no retention, or
>>>> you can create your BCs with a ve

Re: BuildConfigs failedBuildsHistoryLimit and successfulBuildsHistoryLimit fields being defaulted in OpenShift v3.11 cluster

[Andrew Feller]

Thanks for the follow up, Ben.

I suppose we haven't created any new BuildConfigs from scratch since our
v3.9 => v3.11 upgrade, however there is no mention within OCP 3.11 release
notes
<https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html>
about
this change of behavior and the Advanced Build Operations > Build Pruning
<https://docs.openshift.com/container-platform/3.11/dev_guide/builds/advanced_build_operations.html#build-pruning>
documentation
implies default behavior is that no history limit is enforced on creation.
We just happened to have someone accidentally delete a project's contents
and discovered this after losing builds and their history unknowingly.
Ideally, I would rather prefer BuildConfig pruning gave us the option of
specifying a number of days to keep old Builds, but we'll make due as we
don't have hard and fast retention requirements yet.

On Wed, Mar 27, 2019 at 2:14 PM Ben Parees  wrote:

>
>
> On Wed, Mar 27, 2019 at 11:58 AM Andrew Feller 
> wrote:
>
>> Using a simple documented BuildConfig
>> <https://docs.openshift.com/container-platform/3.11/dev_guide/builds/index.html>,
>> we're seeing every newly created BuildConfig resource
>> defaulting failedBuildsHistoryLimit and successfulBuildsHistoryLimit when
>> documentation specifies BuildConfig not having default values and honoring
>> preserving all builds.
>>
>
> i'm assuming you're basing your statement on the api doc:
> https://github.com/openshift/api/blob/release-3.11/build/v1/types.go#L904
>
> (if you saw it somewhere else, please let us know).
>
> Unfortunately that doc is wrong...  when we moved from legacy resource
> types to grouped resource types, we introduced a default retention of 5 for
> each type(successful and failed).  If you created a buildconfig via the
> legacy resource you got no limit, but if you create it via the grouped
> resource (which is the default and what everyone should be doing now), you
> got a default of 5 applied to your object.  If you look at the
> buildconfig.yaml (oc get bc/foo -o yaml) you will see that value appear
> because it's actually applied to your object during creation.
>
> you can edit the bc and delete the field to switch to no retention, or you
> can create your BCs with a very high retention.  I don't think you can
> actually create a BC w/ no retention limit, though, given how the system
> works.
>
>
>
>
>
>>
>> My knee jerk thought was to talk with my OCP administrators to see
>> whether nodes were configured to default aspects of specific resource
>> types, however we didn't see anything readily within master-config.yaml
>> file on one of the masters.
>>
>> Any assistance is appreciated!
>>
>>
>>> me@me-mbp ~ $ oc version
>>
>> oc v3.11.0+0cbc58b
>>
>> kubernetes v1.11.0+d4cacc0
>>
>> features: Basic-Auth
>>
>>
>>> Server ...
>>
>> openshift v3.11.43
>>
>> kubernetes v1.11.0+d4cacc0
>>
>>
>>
>> me@me-mbp ~ $ oc new-project ruby-sample
>>
>>
>>> me@me-mbp ~ $ cat << EOF | oc apply -f - -n ruby-sample
>>> > kind: "BuildConfig"
>>> > apiVersion: "v1"
>>> > metadata:
>>> >   name: "ruby-sample-build"
>>> > spec:
>>> >   runPolicy: "Serial"
>>> >   triggers: []
>>> >   source:
>>> > git:
>>> >   uri: "https://github.com/openshift/ruby-hello-world;
>>> >   strategy:
>>> > sourceStrategy:
>>> >   from:
>>> > kind: "ImageStreamTag"
>>> > name: "ruby-20-centos7:latest"
>>> > EOF
>>> buildconfig.build.openshift.io/ruby-sample-build created
>>
>>
>>> me@me-mbp ~ $ oc get -o yaml bc ruby-sample-build
>>> apiVersion: build.openshift.io/v1
>>> kind: BuildConfig
>>> metadata:
>>>   annotations:
>>> kubectl.kubernetes.io/last-applied-configuration: |
>>>   {"apiVersion":"build.openshift.io/v1
>>> ","kind":"BuildConfig","metadata":{"annotations":{},"name":"ruby-sample-build","namespace":"ruby-sample"},"spec":{"runPolicy":"Serial","source":{"git":{"uri":"
>>> https://github.com/openshift/ruby-hello-world
>>> "}},"strategy":{"sourceStrategy":{"from":{"kind":"ImageStreamTag","name":"

BuildConfigs failedBuildsHistoryLimit and successfulBuildsHistoryLimit fields being defaulted in OpenShift v3.11 cluster

[Andrew Feller]

Using a simple documented BuildConfig
,
we're seeing every newly created BuildConfig resource
defaulting failedBuildsHistoryLimit and successfulBuildsHistoryLimit when
documentation specifies BuildConfig not having default values and honoring
preserving all builds.

My knee jerk thought was to talk with my OCP administrators to see whether
nodes were configured to default aspects of specific resource types,
however we didn't see anything readily within master-config.yaml file on
one of the masters.

Any assistance is appreciated!


> me@me-mbp ~ $ oc version

oc v3.11.0+0cbc58b

kubernetes v1.11.0+d4cacc0

features: Basic-Auth


> Server ...

openshift v3.11.43

kubernetes v1.11.0+d4cacc0



me@me-mbp ~ $ oc new-project ruby-sample


> me@me-mbp ~ $ cat << EOF | oc apply -f - -n ruby-sample
> > kind: "BuildConfig"
> > apiVersion: "v1"
> > metadata:
> >   name: "ruby-sample-build"
> > spec:
> >   runPolicy: "Serial"
> >   triggers: []
> >   source:
> > git:
> >   uri: "https://github.com/openshift/ruby-hello-world;
> >   strategy:
> > sourceStrategy:
> >   from:
> > kind: "ImageStreamTag"
> > name: "ruby-20-centos7:latest"
> > EOF
> buildconfig.build.openshift.io/ruby-sample-build created


> me@me-mbp ~ $ oc get -o yaml bc ruby-sample-build
> apiVersion: build.openshift.io/v1
> kind: BuildConfig
> metadata:
>   annotations:
> kubectl.kubernetes.io/last-applied-configuration: |
>   {"apiVersion":"build.openshift.io/v1
> ","kind":"BuildConfig","metadata":{"annotations":{},"name":"ruby-sample-build","namespace":"ruby-sample"},"spec":{"runPolicy":"Serial","source":{"git":{"uri":"
> https://github.com/openshift/ruby-hello-world
> "}},"strategy":{"sourceStrategy":{"from":{"kind":"ImageStreamTag","name":"ruby-20-centos7:latest"}}},"triggers":[]}}
>   creationTimestamp: 2019-03-27T15:49:28Z
>   name: ruby-sample-build
>   namespace: ruby-sample
>   resourceVersion: "268668901"
>   selfLink: /apis/
> build.openshift.io/v1/namespaces/ruby-sample/buildconfigs/ruby-sample-build
>   uid: e7a55eaa-50a7-11e9-982c-001a4aa86606
> spec:
>   failedBuildsHistoryLimit: 5
>   nodeSelector: null
>   output: {}
>   postCommit: {}
>   resources: {}
>   runPolicy: Serial
>   source:
> git:
>   uri: https://github.com/openshift/ruby-hello-world
> type: Git
>   strategy:
> sourceStrategy:
>   from:
> kind: ImageStreamTag
> name: ruby-20-centos7:latest
> type: Source
>   successfulBuildsHistoryLimit: 5
>   triggers: []
> status:
>   lastVersion: 0



-- 

[image: BandwidthMaroon.png]

Andy Feller  •  Sr DevOps Engineer

900 Main Campus Drive, Suite 500, Raleigh, NC 27606


e: afel...@bandwidth.com
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: Jenkins with OpenShift login enabled, how to enable webhooks?

[Andrew Feller]

Was doing some asking around and remembered the reason we don't use
BuildConfig GitHub Trigger was because it doesn't checkout the branch
specified in the webhook event, which has been in place since DEVEXP-391
<https://github.com/openshift/origin/commit/9b96292077b14419f83566de96339b548dabd1fe>
and
thus unlikely to change.

On Mon, Nov 26, 2018 at 1:11 PM Andrew Feller  wrote:

> Mark:
>
> Since this was done before my recent tenure, I need to revisit
> BuildConfig GitHub Trigger
> <https://docs.openshift.com/container-platform/3.11/dev_guide/builds/triggering_builds.html#github-webhooks>
>  versus
> what we've done.  Have you looked at this?
>
> Regards,
> Andy
>
> On Mon, Nov 26, 2018 at 9:39 AM Marc Boorshtein 
> wrote:
>
>>
>>>
>>> If you're referring to using a GitHub webhook, we ended up having to
>>> create a simple application that would receive GitHub webhook events,
>>> verify the request against the webhook secret, and trigger the desired
>>> OpenShift build or Jenkins job.  This is primarily because GitHub webhooks
>>> don't really support authentication mechanisms other than the webhook
>>> secret.
>>>
>>>
>>>
>> Thanks Andy, we went a somewhat different (but similar) route. We created
>> a reverse proxy that only accepts requests to the build url and injects the
>> oauth2 service account token in the call to our jenkins.  I like the idea
>> of verifying the token first but don't think its necessary.  It could cut
>> down if there was a vulnerability found in jenkins but i can also cut that
>> down in other ways too (i might clear all content from the request).
>>
>> Thanks
>> Marc
>>
>>
>
>
> --
>
> [image: BandwidthMaroon.png]
>
> Andy Feller  •  Sr DevOps Engineer
>
> 900 Main Campus Drive, Suite 500, Raleigh, NC 27606
>
>
> e: afel...@bandwidth.com
>


-- 

[image: BandwidthMaroon.png]

Andy Feller  •  Sr DevOps Engineer

900 Main Campus Drive, Suite 500, Raleigh, NC 27606


e: afel...@bandwidth.com
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: Jenkins with OpenShift login enabled, how to enable webhooks?

[Andrew Feller]

Mark:

Since this was done before my recent tenure, I need to revisit BuildConfig
GitHub Trigger

versus
what we've done.  Have you looked at this?

Regards,
Andy

On Mon, Nov 26, 2018 at 9:39 AM Marc Boorshtein 
wrote:

>
>>
>> If you're referring to using a GitHub webhook, we ended up having to
>> create a simple application that would receive GitHub webhook events,
>> verify the request against the webhook secret, and trigger the desired
>> OpenShift build or Jenkins job.  This is primarily because GitHub webhooks
>> don't really support authentication mechanisms other than the webhook
>> secret.
>>
>>
>>
> Thanks Andy, we went a somewhat different (but similar) route. We created
> a reverse proxy that only accepts requests to the build url and injects the
> oauth2 service account token in the call to our jenkins.  I like the idea
> of verifying the token first but don't think its necessary.  It could cut
> down if there was a vulnerability found in jenkins but i can also cut that
> down in other ways too (i might clear all content from the request).
>
> Thanks
> Marc
>
>


-- 

[image: BandwidthMaroon.png]

Andy Feller  •  Sr DevOps Engineer

900 Main Campus Drive, Suite 500, Raleigh, NC 27606


e: afel...@bandwidth.com
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

RE: Jenkins with OpenShift login enabled, how to enable webhooks?

[Andrew Feller]

Marc:

If you're referring to using a GitHub webhook, we ended up having to create
a simple application that would receive GitHub webhook events, verify the
request against the webhook secret, and trigger the desired OpenShift build
or Jenkins job.  This is primarily because GitHub webhooks don't really
support authentication mechanisms other than the webhook secret.

If you end up having to go this route, then would point out a few other
things:

   1. openshift-sync Jenkins plugin will create a corresponding OpenShift
   Build for Jenkins job builds kicked off from Jenkins and vice versa from
   OpenShift BuildConfig within OpenShift UX, so you have more options over
   what you trigger

   2. openshift-login will require OpenShift edit or admin role to
   translate into Jenkins permissions to trigger Jenkins job; newer version
   of openshift-login supports customized OpenShift role to Jenkins permission
   assignment
   

   3. Have your app return diagnostic text within the body of the response
   so you can figure out whether/why a webhook didn't work correctly.

HTH,
Andy

I'm trying to use a webhook to trigger a job.  When I'm authenticated it
> works great, but coming from an anonymous point the request always takes me
> to the openshift login.  Is there a way to exclude specific URLs from
> having to authenticate via openshift?  I see that I can create a bearer
> token using a service account, but given RBAC's granularity i'd rather not
> do that.  I specifically am trying to get a webhook setup that will trigger
> a jenkins job to run when a source container is pushed.
>
> Thanks
> Marc

-- 

[image: BandwidthMaroon.png]

Andy Feller  •  Sr DevOps Engineer

900 Main Campus Drive, Suite 500, Raleigh, NC 27606


e: afel...@bandwidth.com
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: Automating overriding of openshift-sync Jenkins plugin configuration

[Andrew Feller]

After a bit of trial with the Groovy init script for configuring
namespaces, which technically works, the act of redeploying Jenkins and
disrupting jobs to onboard a new application is undesirable and has us
thinking about dynamically reconfiguring the openshift-sync plugin via a
pod that discovers namespaces and calls out to Jenkins script console.  The
major problem is triggering GlobalPluginConfiguration.configChange()
<https://github.com/jenkinsci/openshift-sync-plugin/blob/master/src/main/java/io/fabric8/jenkins/openshiftsync/GlobalPluginConfiguration.java#L248>
such that the existing runnables are reset as it is a private method.

Has anyone successfully configured this outside of a Groovy init script
such that it is reflected correctly in the Jenkins >> Manage >> Configure
System and resets the existing runnable task?

#1 via GlobalPluginConfiguration setter
<https://github.com/jenkinsci/openshift-sync-plugin/blob/master/src/main/java/io/fabric8/jenkins/openshiftsync/GlobalPluginConfiguration.java#L153>
and getter
<https://github.com/jenkinsci/openshift-sync-plugin/blob/master/src/main/java/io/fabric8/jenkins/openshiftsync/GlobalPluginConfiguration.java#L106>

import io.fabric8.jenkins.openshiftsync.GlobalPluginConfiguration;

def plugin
= 
Jenkins.instance.getDescriptor('io.fabric8.jenkins.openshiftsync.GlobalPluginConfiguration')
plugin.setNamespace("A B C D ...")
plugin.save()

#2 via GlobalPluginConfiguration.configure(StaplerRequest, JSONObject)
<https://github.com/jenkinsci/openshift-sync-plugin/blob/master/src/main/java/io/fabric8/jenkins/openshiftsync/GlobalPluginConfiguration.java#L116>

import jenkins.model.Jenkins

import io.fabric8.jenkins.openshiftsync.GlobalPluginConfiguration
import net.sf.json.JSONObject
import net.sf.json.JSONArray
import org.kohsuke.stapler.Stapler
import org.kohsuke.stapler.RequestImpl
import javax.servlet.http.HttpServletRequest

def httpServletRequest = [
  getRequestURI: { null }
] as javax.servlet.http.HttpServletRequest

def servletConfig = [
  getServletContext: { Jenkins.getInstance().servletContext },
  getInitParameter: { null },
  getServletName: { "" }
] as javax.servlet.ServletConfig

Stapler stapler = new Stapler()
stapler.init(servletConfig)

RequestImpl requestImpl = new RequestImpl(stapler, httpServletRequest, []
as java.util.List, null)

def plugin =
Jenkins.getInstance().getDescriptor("io.fabric8.jenkins.openshiftsync.GlobalPluginConfiguration")
plugin.configure(requestImpl, [
"namespaces": "A B C D ...",
] as JSONObject)




On Thu, Aug 16, 2018 at 2:43 PM Gabe Montero  wrote:

>
>
> On Thu, Aug 16, 2018 at 2:37 PM Andrew Feller 
> wrote:
>
>> Yeah, I think it's this one
>> <https://trello.com/c/V1mtI7bi/1518-3-allow-the-use-of-environment-variables-to-specify-namespaces-sync-plugin-should-monitor-jenkinsintegrationpipelineintegration>.
>> Depending on the level of effort, I might be able to potentially contribute
>> on a fix for it.  I didn't know if anyone has a workaround other than
>> mounting a Groovy script for Jenkins to load.
>>
>
> Yeah a groovy init script is the best workaround until the referenced RFE
> happens.
>
>
>> On Thu, Aug 16, 2018 at 1:41 PM Ben Parees  wrote:
>>
>>>
>>>
>>> On Thu, Aug 16, 2018 at 10:52 AM, Andrew Feller 
>>> wrote:
>>>
>>>> Is anyone familiar with overriding the openshift-sync plugin namespace
>>>> property?
>>>>
>>>> I'm working to condense the Jenkins instances we have running with a
>>>> central Jenkins running in OpenShift pulling BuildConfigs from remote
>>>> namespaces.  However, I rather not manually configure Jenkins
>>>> openshift-sync plugin on the namespaces it should be monitoring and hoping
>>>> there is a better way than crafting a Groovy script to be loaded by Jenkins
>>>> on startup to override this.
>>>>
>>>
>>> Pretty sure this has come up before and might even exist as an RFE
>>> (namely the ability to set the list of namespaces to watch via an env var)
>>> but i don't think anything has been implemented yet.  Gabe would know for
>>> sure.
>>>
>>>
>>>
>>>>
>>>> Thanks!
>>>> --
>>>>
>>>> [image: BandwidthMaroon.png]
>>>>
>>>> Andy Feller  •  Sr DevOps Engineer
>>>>
>>>> 900 Main Campus Drive, Suite 500, Raleigh, NC 27606
>>>> <https://maps.google.com/?q=900+Main+Campus+Drive,+Suite+500,+Raleigh,+NC+27606=gmail=g>
>>>>
>>>>
>>>> e: afel...@bandwidth.com
>>>>
>>>> 

Re: Reducing toil in resource quota bumping

[Andrew Feller]

Yeah, we have heterogenous trust levels between production and
non-production environments.  This discussion was focused solely on
non-production environment where project default template is minimal
footprint and system administrators are in line for increasing project
resource quotes per developer per project.  Since some projects require
more resources than others, we want to prevent non-administrators from
blowing up the cluster with wasteful resource usage but not so confined
they need someone holding their hands on a regular basis.

On Tue, Sep 4, 2018 at 8:54 AM Clayton Coleman  wrote:

>
>
> On Sep 4, 2018, at 8:30 AM, Andrew Feller  wrote:
>
> While that is a fair assessment of the situations where this pain point
> arises, there should be a better option for facilitating #3 without
> allowing #1 or #2 as this is a common problem disrupting both sides of the
> situation.
>
> Knee jerk thought would be to modify the ProjectRequest API to allow
> requestor to specify anything the ClusterResourceQuota object can control.
> This would allow new projects being created to sized right until some
> situation to support resizing existing projects can be developed.
>
>
> If you trust your developers to resize, create a role that you bind to the
> namespace / account when you trust them.  Or just add it to edit and they’d
> have it by default.
>
> The complicated scenarios are usually when your trust domains are
> heterogeneous - it didn’t sound like that was your case.
>
>
> On Thu, Aug 30, 2018 at 2:46 PM Clayton Coleman 
> wrote:
>
>> Ultimately you need to ask what you are trying to prevent:
>>
>> 1. a user from accidentally blowing up the cluster
>> 2. malicious users
>> 3. an application breaking at runtime because it needs more resources
>> than it is allotted
>>
>> The second one is more what we've been discussing here - being draconian
>> up front.  1 is usually where you'd have two quotas - initial, and
>> generous, and then just swap them out as needed, possibly via some
>> automation.  3 is what most people are most afraid of (failing to meet your
>> SLA because you didn't allocate resources).
>>
>>
>>
>>
>>
>> On Thu, Aug 30, 2018 at 2:17 PM Andrew Feller 
>> wrote:
>>
>>> Thanks for the feedback Jessica!
>>>
>>> Limiting # of projects users can create is definitely one of the things
>>> expected, however the question was mostly focused on reducing toil due to
>>> changing resource quotas for projects.  The idea with option #1 was
>>> restricting devs to 1 project with heftier resources allocated whereas the
>>> hope with option #2 was ClusterResourceQuota per developer might relax
>>> other options for developers to modify project resource quotas without
>>> waiting on system administrators.
>>>
>>> On Thu, Aug 30, 2018 at 10:14 AM Jessica Forrester 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Aug 30, 2018 at 8:18 AM Andrew Feller 
>>>> wrote:
>>>>
>>>>> Has anyone found an effective way to minimize toil between developers
>>>>> and system administrators regarding project resource quotas *without
>>>>> resorting to letting people do whatever they want unrestrained*?
>>>>>
>>>>> There are only 2 ideas I can see to address this issue:
>>>>>
>>>>>1. Removing self-provisioning access, provisioning a single
>>>>>project per developer, and giving them admin access to it.
>>>>>
>>>>>
>>>> You can limit the number of self-provisioned projects they can have
>>>>
>>>> https://docs.openshift.com/container-platform/3.10/admin_guide/managing_projects.html#limit-projects-per-user
>>>>
>>>>
>>>>>
>>>>>1. Create ClusterResourceQuota per developer restricting total
>>>>>resources allowed
>>>>>
>>>>> I don't know how ClusterResourceQuota handle a system administrator
>>>>> increasing a project's quotas for a user who is already met their total.
>>>>>
>>>>
>>>> If either a cluster resource quota or a resource quota has been
>>>> exceeded, then you you've exceeded quota for that resource and can't make
>>>> more.
>>>>
>>>>
>>>>>
>>>>> Any feedback is welcomed and appreciated!
>>>>> --
>>>>>
>>>>> [image: BandwidthMaroon.png]
>>>>>
>>>>> Andy Fel

Re: Reducing toil in resource quota bumping

[Andrew Feller]

While that is a fair assessment of the situations where this pain point
arises, there should be a better option for facilitating #3 without
allowing #1 or #2 as this is a common problem disrupting both sides of the
situation.

Knee jerk thought would be to modify the ProjectRequest API to allow
requestor to specify anything the ClusterResourceQuota object can control.
This would allow new projects being created to sized right until some
situation to support resizing existing projects can be developed.

On Thu, Aug 30, 2018 at 2:46 PM Clayton Coleman  wrote:

> Ultimately you need to ask what you are trying to prevent:
>
> 1. a user from accidentally blowing up the cluster
> 2. malicious users
> 3. an application breaking at runtime because it needs more resources than
> it is allotted
>
> The second one is more what we've been discussing here - being draconian
> up front.  1 is usually where you'd have two quotas - initial, and
> generous, and then just swap them out as needed, possibly via some
> automation.  3 is what most people are most afraid of (failing to meet your
> SLA because you didn't allocate resources).
>
>
>
>
>
> On Thu, Aug 30, 2018 at 2:17 PM Andrew Feller 
> wrote:
>
>> Thanks for the feedback Jessica!
>>
>> Limiting # of projects users can create is definitely one of the things
>> expected, however the question was mostly focused on reducing toil due to
>> changing resource quotas for projects.  The idea with option #1 was
>> restricting devs to 1 project with heftier resources allocated whereas the
>> hope with option #2 was ClusterResourceQuota per developer might relax
>> other options for developers to modify project resource quotas without
>> waiting on system administrators.
>>
>> On Thu, Aug 30, 2018 at 10:14 AM Jessica Forrester 
>> wrote:
>>
>>>
>>>
>>> On Thu, Aug 30, 2018 at 8:18 AM Andrew Feller 
>>> wrote:
>>>
>>>> Has anyone found an effective way to minimize toil between developers
>>>> and system administrators regarding project resource quotas *without
>>>> resorting to letting people do whatever they want unrestrained*?
>>>>
>>>> There are only 2 ideas I can see to address this issue:
>>>>
>>>>1. Removing self-provisioning access, provisioning a single project
>>>>per developer, and giving them admin access to it.
>>>>
>>>>
>>> You can limit the number of self-provisioned projects they can have
>>>
>>> https://docs.openshift.com/container-platform/3.10/admin_guide/managing_projects.html#limit-projects-per-user
>>>
>>>
>>>>
>>>>1. Create ClusterResourceQuota per developer restricting total
>>>>resources allowed
>>>>
>>>> I don't know how ClusterResourceQuota handle a system administrator
>>>> increasing a project's quotas for a user who is already met their total.
>>>>
>>>
>>> If either a cluster resource quota or a resource quota has been
>>> exceeded, then you you've exceeded quota for that resource and can't make
>>> more.
>>>
>>>
>>>>
>>>> Any feedback is welcomed and appreciated!
>>>> --
>>>>
>>>> [image: BandwidthMaroon.png]
>>>>
>>>> Andy Feller  •  Sr DevOps Engineer
>>>>
>>>> 900 Main Campus Drive, Suite 500, Raleigh, NC 27606
>>>>
>>>>
>>>> e: afel...@bandwidth.com
>>>> ___
>>>> users mailing list
>>>> users@lists.openshift.redhat.com
>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>>
>>>
>>
>> --
>>
>> [image: BandwidthMaroon.png]
>>
>> Andy Feller  •  Sr DevOps Engineer
>>
>> 900 Main Campus Drive, Suite 500, Raleigh, NC 27606
>>
>>
>> e: afel...@bandwidth.com
>> ___
>> users mailing list
>> users@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>

-- 

[image: BandwidthMaroon.png]

Andy Feller  •  Sr DevOps Engineer

900 Main Campus Drive, Suite 500, Raleigh, NC 27606


e: afel...@bandwidth.com
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: Reducing toil in resource quota bumping

[Andrew Feller]

Thanks for the feedback Jessica!

Limiting # of projects users can create is definitely one of the things
expected, however the question was mostly focused on reducing toil due to
changing resource quotas for projects.  The idea with option #1 was
restricting devs to 1 project with heftier resources allocated whereas the
hope with option #2 was ClusterResourceQuota per developer might relax
other options for developers to modify project resource quotas without
waiting on system administrators.

On Thu, Aug 30, 2018 at 10:14 AM Jessica Forrester 
wrote:

>
>
> On Thu, Aug 30, 2018 at 8:18 AM Andrew Feller 
> wrote:
>
>> Has anyone found an effective way to minimize toil between developers and
>> system administrators regarding project resource quotas *without
>> resorting to letting people do whatever they want unrestrained*?
>>
>> There are only 2 ideas I can see to address this issue:
>>
>>1. Removing self-provisioning access, provisioning a single project
>>per developer, and giving them admin access to it.
>>
>>
> You can limit the number of self-provisioned projects they can have
>
> https://docs.openshift.com/container-platform/3.10/admin_guide/managing_projects.html#limit-projects-per-user
>
>
>>
>>1. Create ClusterResourceQuota per developer restricting total
>>resources allowed
>>
>> I don't know how ClusterResourceQuota handle a system administrator
>> increasing a project's quotas for a user who is already met their total.
>>
>
> If either a cluster resource quota or a resource quota has been exceeded,
> then you you've exceeded quota for that resource and can't make more.
>
>
>>
>> Any feedback is welcomed and appreciated!
>> --
>>
>> [image: BandwidthMaroon.png]
>>
>> Andy Feller  •  Sr DevOps Engineer
>>
>> 900 Main Campus Drive, Suite 500, Raleigh, NC 27606
>>
>>
>> e: afel...@bandwidth.com
>> ___
>> users mailing list
>> users@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>

-- 

[image: BandwidthMaroon.png]

Andy Feller  •  Sr DevOps Engineer

900 Main Campus Drive, Suite 500, Raleigh, NC 27606


e: afel...@bandwidth.com
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Reducing toil in resource quota bumping

[Andrew Feller]

Has anyone found an effective way to minimize toil between developers and
system administrators regarding project resource quotas *without resorting
to letting people do whatever they want unrestrained*?

There are only 2 ideas I can see to address this issue:

   1. Removing self-provisioning access, provisioning a single project per
   developer, and giving them admin access to it.
   2. Create ClusterResourceQuota per developer restricting total resources
   allowed

I don't know how ClusterResourceQuota handle a system administrator
increasing a project's quotas for a user who is already met their total.

Any feedback is welcomed and appreciated!
-- 

[image: BandwidthMaroon.png]

Andy Feller  •  Sr DevOps Engineer

900 Main Campus Drive, Suite 500, Raleigh, NC 27606


e: afel...@bandwidth.com
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: Utilizing Jenkins linter with Jenkins hosted within OpenShift

[Andrew Feller]

Sorry for the update to older thread but it turns out this process can
actually be much easier by using the token from your OC session, which
doesn't require decoding or multiple calls to retrieve:

curl -X POST -H "Authorization: Bearer $(oc whoami -t)" -F
"jenkinsfile=
wrote:

> Thanks to Gabe for a little bit of help on the side, I was able to figure
> out a few more particulars for others looking to do this and opened a PR
> <https://github.com/openshift/jenkins-openshift-login-plugin/pull/43> to
> enhance the jenkins-openshift-login-plugin documentation for others looking
> to do the same.  I've created a Bash script that makes this trivial but
> haven't received permission to contribute yet; this is the least I can do
> for now for others.
>
> On Thu, Jul 5, 2018 at 9:23 AM Gabe Montero  wrote:
>
>> We support passing in a valid OpenShift token as a bearer token with curl
>> requests against
>> a deployment of the OpenShift Jenkins image.
>>
>> You should be able to leverage the curl based accessed noted at the link
>> you posted.
>>
>> See
>>
>> https://github.com/openshift/jenkins-openshift-login-plugin#non-browser-access
>> https://github.com/openshift/jenkins#jenkins-admin-user
>>
>> https://docs.openshift.org/latest/using_images/other_images/jenkins.html#jenkins-openshift-oauth-authentication
>>
>>
>>
>> On Thu, Jul 5, 2018 at 7:51 AM, Andrew Feller 
>> wrote:
>>
>>> I imagine developers leveraging Jenkins declarative linter
>>> <https://jenkins.io/doc/book/pipeline/development/#linter> from Jenkins
>>> hosted within OpenShift is more difficult because OpenShift is handling
>>> identity management, but has anyone had luck with supporting this?  I
>>> realize the nature of Jenkins makes this complicated so don't expect there
>>> to be a great solution here.
>>>
>>> Thanks!
>>>
>>> --
>>>
>>> [image: BandwidthMaroon.png]
>>>
>>> Andy Feller  •  Sr DevOps Engineer
>>>
>>> 900 Main Campus Drive, Suite 500, Raleigh, NC 27606
>>>
>>>
>>> e: afel...@bandwidth.com
>>>
>>> ___
>>> users mailing list
>>> users@lists.openshift.redhat.com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>
>>>
>>
>
> --
>
> [image: BandwidthMaroon.png]
>
> Andy Feller  •  Sr DevOps Engineer
>
> 900 Main Campus Drive, Suite 500, Raleigh, NC 27606
>
>
> e: afel...@bandwidth.com
>


-- 

[image: BandwidthMaroon.png]

Andy Feller  •  Sr DevOps Engineer

900 Main Campus Drive, Suite 500, Raleigh, NC 27606


e: afel...@bandwidth.com
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: Automating overriding of openshift-sync Jenkins plugin configuration

[Andrew Feller]

Yeah, I think it's this one
<https://trello.com/c/V1mtI7bi/1518-3-allow-the-use-of-environment-variables-to-specify-namespaces-sync-plugin-should-monitor-jenkinsintegrationpipelineintegration>.
Depending on the level of effort, I might be able to potentially contribute
on a fix for it.  I didn't know if anyone has a workaround other than
mounting a Groovy script for Jenkins to load.

On Thu, Aug 16, 2018 at 1:41 PM Ben Parees  wrote:

>
>
> On Thu, Aug 16, 2018 at 10:52 AM, Andrew Feller 
> wrote:
>
>> Is anyone familiar with overriding the openshift-sync plugin namespace
>> property?
>>
>> I'm working to condense the Jenkins instances we have running with a
>> central Jenkins running in OpenShift pulling BuildConfigs from remote
>> namespaces.  However, I rather not manually configure Jenkins
>> openshift-sync plugin on the namespaces it should be monitoring and hoping
>> there is a better way than crafting a Groovy script to be loaded by Jenkins
>> on startup to override this.
>>
>
> Pretty sure this has come up before and might even exist as an RFE (namely
> the ability to set the list of namespaces to watch via an env var) but i
> don't think anything has been implemented yet.  Gabe would know for sure.
>
>
>
>>
>> Thanks!
>> --
>>
>> [image: BandwidthMaroon.png]
>>
>> Andy Feller  •  Sr DevOps Engineer
>>
>> 900 Main Campus Drive, Suite 500, Raleigh, NC 27606
>>
>>
>> e: afel...@bandwidth.com
>>
>> ___
>> users mailing list
>> users@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>>
>
>
> --
> Ben Parees | OpenShift
>
>

-- 

[image: BandwidthMaroon.png]

Andy Feller  •  Sr DevOps Engineer

900 Main Campus Drive, Suite 500, Raleigh, NC 27606


e: afel...@bandwidth.com
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Automating overriding of openshift-sync Jenkins plugin configuration

[Andrew Feller]

Is anyone familiar with overriding the openshift-sync plugin namespace
property?

I'm working to condense the Jenkins instances we have running with a
central Jenkins running in OpenShift pulling BuildConfigs from remote
namespaces.  However, I rather not manually configure Jenkins
openshift-sync plugin on the namespaces it should be monitoring and hoping
there is a better way than crafting a Groovy script to be loaded by Jenkins
on startup to override this.

Thanks!
-- 

[image: BandwidthMaroon.png]

Andy Feller  •  Sr DevOps Engineer

900 Main Campus Drive, Suite 500, Raleigh, NC 27606


e: afel...@bandwidth.com
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: Utilizing Jenkins linter with Jenkins hosted within OpenShift

[Andrew Feller]

Thanks to Gabe for a little bit of help on the side, I was able to figure
out a few more particulars for others looking to do this and opened a PR
<https://github.com/openshift/jenkins-openshift-login-plugin/pull/43> to
enhance the jenkins-openshift-login-plugin documentation for others looking
to do the same.  I've created a Bash script that makes this trivial but
haven't received permission to contribute yet; this is the least I can do
for now for others.

On Thu, Jul 5, 2018 at 9:23 AM Gabe Montero  wrote:

> We support passing in a valid OpenShift token as a bearer token with curl
> requests against
> a deployment of the OpenShift Jenkins image.
>
> You should be able to leverage the curl based accessed noted at the link
> you posted.
>
> See
>
> https://github.com/openshift/jenkins-openshift-login-plugin#non-browser-access
> https://github.com/openshift/jenkins#jenkins-admin-user
>
> https://docs.openshift.org/latest/using_images/other_images/jenkins.html#jenkins-openshift-oauth-authentication
>
>
>
> On Thu, Jul 5, 2018 at 7:51 AM, Andrew Feller 
> wrote:
>
>> I imagine developers leveraging Jenkins declarative linter
>> <https://jenkins.io/doc/book/pipeline/development/#linter> from Jenkins
>> hosted within OpenShift is more difficult because OpenShift is handling
>> identity management, but has anyone had luck with supporting this?  I
>> realize the nature of Jenkins makes this complicated so don't expect there
>> to be a great solution here.
>>
>> Thanks!
>>
>> --
>>
>> [image: BandwidthMaroon.png]
>>
>> Andy Feller  •  Sr DevOps Engineer
>>
>> 900 Main Campus Drive, Suite 500, Raleigh, NC 27606
>>
>>
>> e: afel...@bandwidth.com
>>
>> ___
>> users mailing list
>> users@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>>
>

-- 

[image: BandwidthMaroon.png]

Andy Feller  •  Sr DevOps Engineer

900 Main Campus Drive, Suite 500, Raleigh, NC 27606


e: afel...@bandwidth.com
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Creating choice-based parameters for Jenkins Pipeline strategy

[Andrew Feller]

Can anyone confirm if non-string typed parameters (for example: choice) can
be declared for Jenkins Pipeline strategy?

jenkins-sync-plugin issue 131
 appears to
add support for them except there appears to be a bug due to a typo
*(ChoiceParameterDefintion
probably should be **ChoiceParameterDefinition)* and I can't really find
anyone talking about this.

Thanks!
-- 

[image: BandwidthMaroon.png]

Andy Feller  •  Sr DevOps Engineer

900 Main Campus Drive, Suite 500, Raleigh, NC 27606


e: afel...@bandwidth.com
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Utilizing Jenkins linter with Jenkins hosted within OpenShift

[Andrew Feller]

I imagine developers leveraging Jenkins declarative linter
 from Jenkins
hosted within OpenShift is more difficult because OpenShift is handling
identity management, but has anyone had luck with supporting this?  I
realize the nature of Jenkins makes this complicated so don't expect there
to be a great solution here.

Thanks!

-- 

[image: BandwidthMaroon.png]

Andy Feller  •  Sr DevOps Engineer

900 Main Campus Drive, Suite 500, Raleigh, NC 27606


e: afel...@bandwidth.com
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: Escaping OpenShift template parameter for literal string

[Andrew Feller]

Thanks for the feedback, Ben!

Unfortunately this is something we wanted populated later down the line
based on external webhooks triggering builds in an environment that can't
have external SCM trigger directly.  For now, we've had to document the
scenario but would love support for the same $$ syntax supported elsewhere;
just to ensure nothing borks it up again.

Cheers!

On Tue, Jul 3, 2018 at 1:05 PM Ben Parees  wrote:

>
>
> On Tue, Jul 3, 2018 at 12:56 PM, Andrew Feller 
> wrote:
>
>> I see there is a way to escape environment variable references
>> <https://docs.openshift.com/container-platform/3.6/dev_guide/downward_api.html#dapi-escaping-environment-variable-references>,
>> however I wanted to see if there was a way to escape OpenShift template
>> parameter references as I wanted to pass Jenkins environment variable
>> references to BuildConfig SCM attributes to be evaluated later in a way
>> that someone couldn't break them by declaring an OpenShift template
>> parameter of the same name.  Looking at the oc process logic
>> <https://github.com/openshift/origin/blob/master/pkg/template/templateprocessing/template.go>,
>> it doesn't appear this is supported but thought would ask.
>>
>
> no i'm afraid not.  You could forestall such problems by defining a
> parameter with a default value that is the env reference, though.
>
>
>> Thanks!
>>
>> --
>>
>> [image: BandwidthMaroon.png]
>>
>> Andy Feller  •  Sr DevOps Engineer
>>
>> 900 Main Campus Drive, Suite 500, Raleigh, NC 27606
>>
>>
>> e: afel...@bandwidth.com
>>
>> ___
>> users mailing list
>> users@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>>
>
>
> --
> Ben Parees | OpenShift
>
>

-- 

[image: BandwidthMaroon.png]

Andy Feller  •  Sr DevOps Engineer

900 Main Campus Drive, Suite 500, Raleigh, NC 27606


e: afel...@bandwidth.com
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Escaping OpenShift template parameter for literal string

[Andrew Feller]

I see there is a way to escape environment variable references
,
however I wanted to see if there was a way to escape OpenShift template
parameter references as I wanted to pass Jenkins environment variable
references to BuildConfig SCM attributes to be evaluated later in a way
that someone couldn't break them by declaring an OpenShift template
parameter of the same name.  Looking at the oc process logic
,
it doesn't appear this is supported but thought would ask.

Thanks!

-- 

[image: BandwidthMaroon.png]

Andy Feller  •  Sr DevOps Engineer

900 Main Campus Drive, Suite 500, Raleigh, NC 27606


e: afel...@bandwidth.com
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: Using OpenShift default service accounts in ephemeral and persistent Jenkins images

[Andrew Feller]

Thanks for the feedback, Ben!

I don't have any specific issues with the current Jenkins SA being created
within the templates; simply trying to understand the discrepancy and
intention of these default SAs as one could be led to believe they should
be utilized.

Regards,
Andy

On Mon, Jun 25, 2018 at 3:51 PM Ben Parees  wrote:

>
>
> On Mon, Jun 25, 2018 at 12:09 PM, Andrew Feller 
> wrote:
>
>> Is there any reason not to use the OpenShift default service accounts
>> (builder and deployer)
>> <https://docs.openshift.com/container-platform/3.9/dev_guide/service_accounts.html#default-service-accounts-and-roles>
>>  with
>> OpenShift jenkins-ephemeral
>> <https://github.com/openshift/origin/blob/master/examples/jenkins/jenkins-ephemeral-template.json>
>> and jenkins-persistent
>> <https://github.com/openshift/origin/blob/master/examples/jenkins/jenkins-persistent-template.json>
>> templates aside from the templates aren't setup to support it well?
>>
>
> the template creates its own service account so we can grant it a
> reasonable set of permissions to ensure that the default credentials the
> jenkins jobs run with, can perform typical actions in your namespace (thus
> we give it edit permission).
>
> The builder SA actually has more permissions than that(namely around
> running privileged pods), so letting jenkins jobs leverage those
> credentials could allow jobs to escalate permissions.
>
> Is there a reason you don't want to use the SA the template creates?
>
>
>
>>
>> We haven't found any decisive content around the subject as the Developer
>> Guide presents these as the intended direction, however it doesn't really
>> elaborate why and what potential problems it could cause.  We haven't tried
>> customizing these templates to see if it's feasible as it'll take some
>> alterations.
>>
>> Appreciate any feedback!
>> Andy
>> --
>>
>> [image: BandwidthMaroon.png]
>>
>> Andy Feller  •  Sr DevOps Engineer
>>
>> 900 Main Campus Drive, Suite 500, Raleigh, NC 27606
>>
>>
>> e: afel...@bandwidth.com
>>
>> ___
>> users mailing list
>> users@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>>
>
>
> --
> Ben Parees | OpenShift
>
>

-- 

[image: BandwidthMaroon.png]

Andy Feller  •  Sr DevOps Engineer

900 Main Campus Drive, Suite 500, Raleigh, NC 27606


e: afel...@bandwidth.com
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Using OpenShift default service accounts in ephemeral and persistent Jenkins images

[Andrew Feller]

Is there any reason not to use the OpenShift default service accounts
(builder and deployer)

with
OpenShift jenkins-ephemeral

and jenkins-persistent

templates aside from the templates aren't setup to support it well?

We haven't found any decisive content around the subject as the Developer
Guide presents these as the intended direction, however it doesn't really
elaborate why and what potential problems it could cause.  We haven't tried
customizing these templates to see if it's feasible as it'll take some
alterations.

Appreciate any feedback!
Andy
-- 

[image: BandwidthMaroon.png]

Andy Feller  •  Sr DevOps Engineer

900 Main Campus Drive, Suite 500, Raleigh, NC 27606


e: afel...@bandwidth.com
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users