jenkins official kubernetes operator

[夏润泽]

Hi dev:

   In the cloud native domain, kubernetes is an important part, and now many software are using kubernetes operator to manage applications in kubernetes.

   Now we can manage jenkins through groovy scripts, casc plugins, etc.In particular, the casc plugin allows us to manage jenkins with declarative code.

   But I think there are still some problems in it. I deployed my jenkins in the kubernetes cluster and managed my jenkins through the groovy script and the casc plugin. But once the jenkins is started, I need to modify the configuration of the casc, then I need to submit the configuration to the jenkins dashborad, and the submitted configuration is not necessarily successful, and there is no failure record. In other words, although I have a casc configuration file, it is difficult for me to ensure that my environment is consistent with the casc configuration. Or at least let me know that my current configuration is incorrect, I need to fix it.

   If we can provide an official jenkins operator to manage jenkins in kubernetes, it must be great.

   I hope to hear your opinions.

Best wishes 

RunzeXia

[Carlos Sanchez]

I thought about it, and yes it would be interesting to have an operator that watches a configmap and ensures jenkins is always updated.

However with serverless jenkins[1] you wouldn't need to worry about that anymore (if you can use serverless).

[1] https://medium.com/@jdrawlings/serverless-jenkins-with-jenkins-x-9134cbfe6870

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7939b7df-2935-4aeb-a1f5-3f300990119f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[nicolas de loof]

Introducing a watcher to reload changes has been proposed for Configuration-as-Code: https://github.com/jenkinsci/configuration-as-code-plugin/issues/76

just need to be implemented ...

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALHFn6OYTfn4Bn_qJvtimvggJcSpHERm1m%2BTrqyV%2BVrEfYYDPg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Nicolas De Loof

[夏润泽]

CasC support observer mode is a very powerful and useful function. But we could use the k8s jenkins operator to do more things, such as the health status of jenkins (whether the configuration is consistent and the necessary components are normal)、 automatic update based on Jenkins Evergreen…………

[夏润泽]

Jenkins of serverless cannot meet my needs at present, but I have to say that when it becomes more perfect, it will be a very cool features.

[Jesse Glick]

On Tue, Jan 15, 2019 at 7:56 AM 夏润泽 <junw...@gmail.com> wrote:
> we could use the k8s jenkins operator to do more things, such as the health status of jenkins (whether the configuration is consistent and the necessary components are normal)、 automatic update based on Jenkins Evergreen…

There is nothing being done in this area currently. Sounds like a
sensible addition to

https://jenkins.io/sigs/cloud-native/#areas-for-improvement

[Marky Jackson]

I’ve done some current operator work and have submitted an upcoming talk on operators. 

I would love to even just tinker with this idea

{     
   "regards" : {
        "name" : “marky”,
        "phone" : "+1 (408) 464 2965”,
        "email" : “marky.r...@gmail.com",
        "team" : "jackson5“
    }
}

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr24Y6Vpq2YnUXT3BubDuuzpTXmw-fCgoeeVpM0PTMx%3Dsw%40mail.gmail.com.

[夏润泽]

Recently there are a lot of things in the company, I will submit relevant PR on the weekend.

[nicolas de loof]

I guess you might be interested by https://github.com/VirtusLab/jenkins-operator

Le jeu. 17 janv. 2019 à 15:06, 夏润泽 <junw...@gmail.com> a écrit :

非常好，我想我们可以从您的运营商开始工作

周一，2019年1月16日星期三上午12:42:38 UTC + 8，Marky Jackson写道：

我已完成了一些当前的操作员工作，并提交了关于操作员的即将到来的演讲。 

我很想甚至只是修补这个想法

{     
   “问候”：{
        “name”：“marky”，
        “phone”：“ + 1（408）464 2965 ”，
        “email”：“ marky.r ... @ gmail.com ”，
        “team”：“杰克逊5“
    }
}

在2019年1月15日上午8:38，Jesse Glick < jgl ... @ cloudbees.com >写道：

在2019年1月15日星期二上午7:56夏润泽< junw ... @ gmail.com >写道：

我们可以使用k8s jenkins运算符来做更多的事情，比如jenkins的健康状态（配置是否一致以及必要的组件是否正常），基于Jenkins Evergreen的自动更新......

目前在这个领域没有做任何事情。听起来像是一个
明智的补充

https://jenkins.io/sigs/cloud-native/#areas-for-improvement

-
您收到此邮件是因为您订阅了Google网上论坛“Jenkins Developers”群组。
要取消订阅此论坛并停止接收来自该论坛的电子邮件，请发送电子邮件至jenkinsci-de ... @ googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/ msgid / jenkinsci-dev / CANfRfr24Y6Vpq2YnUXT3BubDuuzpT Xmw-fCgoeeVpM0PTMx％3Dsw％40mail.gmail.com。
有关更多选项，请访问https://groups.google.com/d/ optout。

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/57f120ee-2691-4668-ae37-afa5ef0b8748%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Nicolas De Loof

[夏润泽]

Very good, I think we can start working from your operator

[marky.r...@gmail.com]

Who/how can we go about starting this? I will gladly upload my code but it might be best to have some guidelines or plan

[Oleg Nenashev]

Hi all,

After reading the proposal from RunzeXia in this pull request, I think that the official Kubernetes Operator could be built on the top of the Custom WAR/Docker Packager which already supports managing Jenkins versions, plugins and configurations via JCasC/Groovy (blog). It's configured via YAML and it can already produce Docker images and standalone WAR files.

I believe that CWP could be adjusted to support the Kubernetes Operator mode, even for Kubernetes deployments without Docker. The same Custom War Packager is used in Jenkins X Serverless, so we can make the configurations somewhat portable between "Serverless Jenkins" modes and more classic K8s operators. What do you think?

Who/how can we go about starting this? I will gladly upload my code but it might be best to have some guidelines or plan

If the Kubernetes Operator requires a lot of design and requires long-term compatibility, it might be reasonable to create a prototype, agree on that in this thread and then to create a specification Jenkins Enhancement Proposal to document YAML formats and the command line options.

Best regards,

Oleg

[Marky Jackson]

I agree that creating a prototype is the best path forward.

We can split the work up for documenting that yaml format and the cli options.

I will wait to hear from RunzeXia and we can have further discussion (please reach out to me on gitter or via email).

Thanks kindly.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/9ea9a62b-382d-48c0-8ed0-28e930198086%40googlegroups.com.

[夏润泽]

I also think that creating a prototype is a good suggestion, we can contact on gitter

[marky.r...@gmail.com]

夏润泽 and I started documenting this JEP and initial code. If anyone is interested in helping let us know. 

[Rick]

I'm in

[nicolas de loof]

Have you checked overlap with https://github.com/VirtusLab/jenkins-operator ?

I was discussing with the authors to get this contributed in jenkinsci organization. Should avoid a concurrent effort to happen on same topic.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7ad5a2bf-067c-4ef8-9149-ad9207f25af6%40googlegroups.com.

[夏润泽]

I have checked this repo, I think some of the function points are coincident, such as the integration of CasC.

But the final features may not be consistent, perhaps we should discuss their ideas about  the operator?

[Tomasz Sęk]

Hi all,

My name is Tomasz Sęk and I work in Virtuslab company as a senior DevOps engineer. I'm the main maintainer of https://github.com/VirtusLab/jenkins-operator project.

We've been provide Jenkins for customers(programmer teams) in our custom Kubernetes distribution for two years. 

As we discussed with Nicolas I would like to describe our implementation and talk about plans, and possible improvements we can make.

Architecture:

- how it's works

- language golang 1.10(Kubernetes uses it)

- we use operator-sdk

- try to not use custom docker images and support jenkins/jenkins:lts, of course user can define own docker master image

- use plugins to manage Jenkins(jcasc, job backups - to store on AWS S3 we use aws-java-sdk ...)

- every single plugin and it's depended plugins have to be installed with specific version, auto update have to be turn off(we had many situations where after plugins update Jenkins can't build any job)

- use Kubernetes plugin to build jobs(every new job spins up new pod in Kubernetes, you can scale yours build through Kubernetes)

- make backup of jobs history before Jenkins master pod deletion and restore it in new pod

- use job-dsl-plugin for managing jobs definitions

- encapsulate configuration of Jenkins in jobs(it make errors visible to users)

Plans:

- implement more backup mechanisms(PVC, Azure Blob Storage, GCP)

- TLS/SSL for Jenkins Master(to secure connection jenkins-operator->jenkins master API)

- improve JNLP agent to handle Jenkins master pod restarts

Improvements:

In current solution only one Jenkins master can be run at the same time, the old goes down then the new one can be created.

I thought we can spin up new Jenkins master pod when the old one have to be killed and then switch traffic to the new one.

Feel free to ask questions. I will prepare JEP draft.

Best regards,

Tomasz

[Jesse Glick]

It sounds nice (I have not tried it). Some technical questions / comments:

On Wed, Jan 23, 2019 at 9:16 AM Tomasz Sęk <tomasz...@gmail.com> wrote:
> every single plugin and it's depended plugins have to be installed with specific version

Good, I have long fought against plugin management scripts/tools which
try to be helpful by picking the latest plugins from the update
center, or adding dependencies automatically! A complete and explicit
list of plugins is safer, but you then run the risk of leaving lots of
unused plugins behind after configuration changes. Thoughts:

https://issues.jenkins-ci.org/browse/JENKINS-53506?focusedCommentId=348904&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-348904

(And it would be great if we could get your system synchronized with
Evergreen, at least optionally.)

> use Kubernetes plugin to build jobs (every new job spins up new pod in Kubernetes

With master executor count set to zero, I hope.

> make backup of jobs history before Jenkins master pod deletion and restore it in new pod

You do not just set a custom build record directory (IIRC this is a
system property) and use a persistent volume claim? See Evergreen for
example. (Beware however that there is some more true state besides
build history; it is safest to persist the entire `$JENKINS_HOME`, and
let JCasC + `job-dsl` overwrite old configurations.)

> improve JNLP agent to handle Jenkins master pod restarts

Not sure where you are going with this. An agent cannot connect to two
different master sessions; it is just not possible without completely
rewriting Remoting. Pipeline builds do however attempt to continue
running, even in the middle of a `sh` step, across master restarts so
long as the actual machine / VM / container running a “JNLP” agent
survives: the agent will try to reconnect to the same master URL at
intervals and start a new Remoting channel, at which point the
Pipeline logic detects a connected agent with the same name as the
build was using before and the same filesystem layout and proceeds.

https://github.com/jenkinsci/kubernetes-plugin/blob/ef177b3b1297a928b22292644afabb1556b5da68/src/test/java/org/csanchez/jenkins/plugins/kubernetes/pipeline/RestartPipelineTest.java#L179-L195

Similarly, a build using an agent launched from the master can be
resumed so long as the new master session can reconnect to the same
container somehow.

> In current solution only one Jenkins master can be run at the same time, the old goes down then the new one can be created.
> I thought we can spin up new Jenkins master pod when the old one have to be killed and then switch traffic to the new one.

This is a very hard problem in Jenkins generally, since many features
in core & plugins assume that the Jenkins service is stateful, the
`$JENKINS_HOME` directory is that state, and only one process accesses
it. While workarounds are certainly possible if you accept
restrictions on the features in use, providing a satisfactory and
general solution is one of the goals of the SIG:

https://jenkins.io/sigs/cloud-native/#cloud-native-jenkins

[夏润泽]

Sounds great, I can help the JEP process.

[Tomasz Sęk]

On Wednesday, 23 January 2019 16:06:03 UTC+1, Jesse Glick wrote:

> It sounds nice (I have not tried it). Some technical questions / comments: 

> make backup of jobs history before Jenkins master pod deletion and restore it in new pod 

> You do not just set a custom build record directory (IIRC this is a 

> system property) and use a persistent volume claim? See Evergreen for 

> example. (Beware however that there is some more true state besides 

> build history; it is safest to persist the entire `$JENKINS_HOME`, and 

> let JCasC + `job-dsl` overwrite old configurations.) 

Making backup of ~50GB is not good idea. I don't want to make snowflake. When new Jenkins master comes up it should starts with empty `$JENKINS_HOME` and jenkins-operator have to configure it to desire state. Backup is triggered before Jenkins master pod deletion and it have to be quick as possible. It have impact on how quick new Jenkins master can start up.

> every single plugin and it's depended plugins have to be installed with specific version 

> Good, I have long fought against plugin management scripts/tools which 

> try to be helpful by picking the latest plugins from the update 

> center, or adding dependencies automatically! A complete and explicit 

> list of plugins is safer, but you then run the risk of leaving lots of 

> unused plugins behind after configuration changes. Thoughts: 

> https://issues.jenkins-ci.org/browse/JENKINS-53506?focusedCommentId=348904&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-348904 

> (And it would be great if we could get your system synchronized with Evergreen, at least optionally.) 

I forgot to mention that plugins are separated in two groups: required by jenkins-operator(used to configure Jenkins)(A) and required by user(B).

A:

- they are installed by jenkins-operator before Jenkins can start up

- every single change requires restart of Jenkins master pod(which I want to avoid)

- user can override versions

- user can add more plugins but it cause restart of Jenkins master pod

B:

- they are installed by jcasc plugins

- requires restart of Jenkins but no Kubernetes pod

- it should be used by users to install plugins

> use Kubernetes plugin to build jobs (every new job spins up new pod in Kubernetes 

> With master executor count set to zero, I hope.

Jenkins builds runs on slaves only(Kubernetes pods), so master agent is not used. However we have to run some jobs on master to configure it(apply grovy scripts, restore/backup and seed jobs creation).

> improve JNLP agent to handle Jenkins master pod restarts 

> Not sure where you are going with this. An agent cannot connect to two 

> different master sessions; it is just not possible without completely 

> rewriting Remoting. Pipeline builds do however attempt to continue 

> running, even in the middle of a `sh` step, across master restarts so 

> long as the actual machine / VM / container running a “JNLP” agent 

> survives: the agent will try to reconnect to the same master URL at 

> intervals and start a new Remoting channel, at which point the 

> Pipeline logic detects a connected agent with the same name as the 

> build was using before and the same filesystem layout and proceeds. 

> https://github.com/jenkinsci/kubernetes-plugin/blob/ef177b3b1297a928b22292644afabb1556b5da68/src/test/java/org/csanchez/jenkins/plugins/kubernetes/pipeline/RestartPipelineTest.java#L179-L195 

> Similarly, a build using an agent launched from the master can be 

> resumed so long as the new master session can reconnect to the same 

> container somehow. 

We had problems when Jenkins master goes down and JNLP agent try to reconnect and it fails after timeout. Maybe increasing timeout in agent could solve this issue.

> In current solution only one Jenkins master can be run at the same time, the old goes down then the new one can be created. 

> I thought we can spin up new Jenkins master pod when the old one have to be killed and then switch traffic to the new one. 

> This is a very hard problem in Jenkins generally, since many features 

> in core & plugins assume that the Jenkins service is stateful, the 

> `$JENKINS_HOME` directory is that state, and only one process accesses 

> it. While workarounds are certainly possible if you accept 

> restrictions on the features in use, providing a satisfactory and 

> general solution is one of the goals of the SIG: 

> https://jenkins.io/sigs/cloud-native/#cloud-native-jenkins 

I aware of this limitation. My idea:

- Jenkins master goes down

- disconnect all slaves from the master

- perform new backup

- spin up new master

- configure it, restore backup

- reconnect slaves to new Jenkins

- Jenkins will resume builds from old Jenkins

[nicolas de loof]

I forgot to mention that plugins are separated in two groups: required by jenkins-operator(used to configure Jenkins)(A) and required by user(B).

A:

- they are installed by jenkins-operator before Jenkins can start up

- every single change requires restart of Jenkins master pod(which I want to avoid)

- user can override versions

- user can add more plugins but it cause restart of Jenkins master pod

B:

- they are installed by jcasc plugins

- requires restart of Jenkins but no Kubernetes pod

- it should be used by users to install plugins

JCasC do support plugin installation but this is pretty hack-ish and demonstrated to come with some troubles. I strongly recommend you use external tool to install users' plugin. As you already have one for A-plugins, better to do the same for B-plugins.

 

also consider https://issues.jenkins-ci.org/browse/JENKINS-53767: a general plugin management tool would be helpful here.

[Jesse Glick]

On Thu, Jan 24, 2019 at 11:32 AM Tomasz Sęk <tomasz...@gmail.com> wrote:
>>> make backup of jobs history before Jenkins master pod deletion and restore it in new pod
>

>> You do not just set a custom build record directory […] and use a persistent volume claim? […]

>> Beware however that there is some more true state besides
>> build history; it is safest to persist the entire `$JENKINS_HOME`, and
>> let JCasC + `job-dsl` overwrite old configurations.
>

> Making backup of ~50GB is not good idea. […] Backup is triggered before Jenkins master pod deletion and it have to be quick as possible.

Which is why I suggested a PVC rather than a backup per se. Anyway the
vast majority of the disk usage in `$JENKINS_HOME` is likely to be
build records (`*/jobs/**/builds/**`), especially if you are not using
any of the other “pluggable storage” features mentioned in the SIG to
externalize big files like artifacts or logs. Or do you mean something
else by “jobs history”?

> plugins are separated in two groups: required by jenkins-operator(used to configure Jenkins)(A) and required by user(B)

I would agree with Nicolas here that you should not use Jenkins code
to manage installed plugins. (You can mandate the inclusion of some
minimum version of certain plugins, such as `configuration-as-code`,
known to be needed for managing _other_ configuration.)

> we have to run some jobs on master to configure it(apply grovy scripts, restore/backup and seed jobs creation).

This seems inadvisable and is generally insecure. Better for these
tasks to be externalized.

(In the case of the `job-dsl` plugin, no master executor should be
required as it runs in-process. That in itself is a major headache and
we ought to prefer systems which run externally.)

> We had problems when Jenkins master goes down and JNLP agent try to reconnect and it fails after timeout. Maybe increasing timeout in agent could solve this issue.

Yes, that could be.

> My idea:
> - Jenkins master goes down
> - disconnect all slaves from the master
> - perform new backup
> - spin up new master
> - configure it, restore backup
> - reconnect slaves to new Jenkins
> - Jenkins will resume builds from old Jenkins

Yes, this is what works today without any particular issue. I thought
you were referring to a scenario in which two masters would be running
at once, which could not be supported without major surgery.

[夏润泽]

Making backup of ~50GB is not good idea. I don't want to make snowflake. When new Jenkins master comes up it should starts with empty `$JENKINS_HOME` and jenkins-operator have to configure it to desire state. Backup is triggered before Jenkins master pod deletion and it have to be quick as possible. It have impact on how quick new Jenkins master can start up.

I think pvc may be more suitable for the public than backup. You mentioned using aws s3 for backup. I don't think all users can use this solution. For example, using other cloud vendors or deploying in a private environment, etc.

I don't know much about the backup mechanism, it sounds like some state will be lost. In my scenario, I didn't use casc to manage all the configurations, such as role-strangy. Because this part of the configuration will change frequently, I will use the REST API provided by the plugin for processing. I believe there will be other users and other plugins that are not managed using the casc/groovy init script.

In addition to the comments on pvc, I think the custom update center address is needed, my environment could not access Internet (maybe there are many such cases in China), we will build a private update center in our own environment, To complete the update and download of the plugin

[Tomasz Sęk]

On Thursday, 24 January 2019 20:41:02 UTC+1, Jesse Glick wrote:

>> make backup of jobs history before Jenkins master pod deletion and restore it in new pod 

>> You do not just set a custom build record directory […] and use a persistent volume claim? […] 

>> Beware however that there is some more true state besides 

>> build history; it is safest to persist the entire `$JENKINS_HOME`, and 

>> let JCasC + `job-dsl` overwrite old configurations. 

>> Making backup of ~50GB is not good idea. […] Backup is triggered before Jenkins master pod deletion and it have to be quick as possible. 

> Which is why I suggested a PVC rather than a backup per se. Anyway the 

> vast majority of the disk usage in `$JENKINS_HOME` is likely to be 

> build records (`*/jobs/**/builds/**`), especially if you are not using 

> any of the other “pluggable storage” features mentioned in the SIG to 

> externalize big files like artifacts or logs. Or do you mean something 

> else by “jobs history”?

tar -C ${jenkinsHome} -z --exclude jobs/*/config.xml --exclude jobs/*/workspace* --exclude jobs/*/simulation.log -c config-history jobs  -f ${tmpBackupPath}

The biggest team have 400MB backup(*.tar.gz), after unpack it is 2GB. When using Kubernetes plugin build workspace is located in another pod and it is not saved in JENKINS_HOME.

Teams save artifacts explicity what they want to store(test/performance results ...). Kubernetes clusters have troubles with attach/detach of PVC(one exception is NFS).

We had a lot of issues when Kubernetes coudn't detach PVC after pod restart and the new one coudn't be loaded. PVC should be added as backup strategy but is hightly not recommended.

Moreover detach and attach takes a lot of time and it increases time when master will be offline.

>> plugins are separated in two groups: required by jenkins-operator(used to configure Jenkins)(A) and required by user(B) 

> I would agree with Nicolas here that you should not use Jenkins code 

> to manage installed plugins. (You can mandate the inclusion of some 

> minimum version of certain plugins, such as `configuration-as-code`, 

> known to be needed for managing _other_ configuration.)

Yes, you are right. I need to think on solution where:

- plugins are defined in one place

- plugin can be set with version or the last version should be picked

- where dependend plugins can be set

To avoid Jenkins master pod restart when some plugins have changed and Jenkins is running I can install missing plugins, delete unused and restart Jenkins inside pod.

>> we have to run some jobs on master to configure it(apply groovy scripts, restore/backup and seed jobs creation). 

> This seems inadvisable and is generally insecure. Better for these 

> tasks to be externalized. 

I'm understand the risk, however encapsulation configuration tasks into jobs give view what is wrong with configuration provided by user.

Maybe there is a solution where we can restrict which jobs can be run on master?

> (In the case of the `job-dsl` plugin, no master executor should be 

> required as it runs in-process. That in itself is a major headache and 

> we ought to prefer systems which run externally.)

Thanks for the tip, I will try this.

[Tomasz Sęk]

On Friday, 25 January 2019 04:35:05 UTC+1, 夏润泽 wrote:

>> Making backup of ~50GB is not good idea. I don't want to make snowflake. When new Jenkins master comes up it should starts with empty `$JENKINS_HOME` and jenkins-operator have to configure it to desire >> state. Backup is triggered before Jenkins master pod deletion and it have to be quick as possible. It have impact on how quick new Jenkins master can start up.

> I think pvc may be more suitable for the public than backup. You mentioned using aws s3 for backup. I don't think all users can use this solution. For example, using other cloud vendors or deploying in > a private environment, etc.

PVC backup will be in options but it is not recommended.

> I don't know much about the backup mechanism, it sounds like some state will be lost. In my scenario, I didn't use casc to manage all the configurations, such as role-strangy. Because this part of the > > configuration will change frequently, I will use the REST API provided by the plugin for processing. I believe there will be other users and other plugins that are not managed using the casc/groovy init script.

I think you can do everthing with Jenkins via groovy scripts. Every single change in Jenkins configuration will be automatically applied by jenkins-operator.

> In addition to the comments on pvc, I think the custom update center address is needed, my environment could not access Internet (maybe there are many such cases in China), we will build a private > update center in our own environment, To complete the update and download of the plugin

I'm adding this feature to my TODO list.

[Jesse Glick]

On Fri, Jan 25, 2019 at 8:51 AM Tomasz Sęk <tomasz...@gmail.com> wrote:
> We had a lot of issues when Kubernetes coudn't detach PVC after pod restart and the new one coudn't be loaded.

I see. Thanks for clearing this up.

>>> we have to run some jobs on master to configure it(apply groovy scripts, restore/backup and seed jobs creation).
>
>> This seems inadvisable and is generally insecure. Better for these tasks to be externalized.
>

> encapsulati[ng] configuration tasks into jobs give view what is wrong with configuration provided by user.

Perhaps these tasks could be made into K8s batch jobs instead?

> Maybe there is a solution where we can restrict which jobs can be run on master?

It is possible with some plugins and core extension points, but not
currently well supported. See discussion in JENKINS-24513. If you can
avoid it and run operator subtasks in separate pods, it would be
better.

[Tomasz Sęk]

On Friday, 25 January 2019 19:26:41 UTC+1, Jesse Glick wrote:

>>> we have to run some jobs on master to configure it(apply groovy scripts, restore/backup and seed jobs creation).
>
>> This seems inadvisable and is generally insecure. Better for these tasks to be externalized.
>
> encapsulati[ng] configuration tasks into jobs give view what is wrong with configuration provided by user.

> Perhaps these tasks could be made into K8s batch jobs instead?

>> Maybe there is a solution where we can restrict which jobs can be run on master?

> It is possible with some plugins and core extension points, but not
> currently well supported. See discussion in JENKINS-24513. If you can
> avoid it and run operator subtasks in separate pods, it would be
> better.

I've came up with new solution:

- don't use jobs to apply configuration/make backup

- set master executors to zero

- apply configuration groovy scripts via "/scriptText" endpoint

- use https://javadoc.jenkins.io/hudson/model/AdministrativeMonitor.html to inform about configuration process and it's errors

- add static agent as Kubernetes pod to run seed jobs

 

Sorry for a late response.

[Tomasz Sęk]

Hi all,

I've created PR with JEP.

Best regards,

Tomasz

[Tomasz Sęk]

Hi all,

My JEP has been approved as a Draft so I've raised JIRA ticket to fork jenkins-operator to jenkinsci organization HOSTING-708.

Best regards,

Tomasz

[Oleg Nenashev]

Hi,

Thanks for doing it! Would you prefer the repo to be forked or moved? The process is slightly different

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/GmnXsHduQfU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/88936305-32a3-4510-9333-76196514b6df%40googlegroups.com.

[Tomasz Sęk]

Hi,

I would prefer fork.

Regards,

Tomasz

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLC1MnPiW--1VLHbU5vQY-PZuE7XF8sB7U8MpkhHJ-up7A%40mail.gmail.com.

[Tomasz Sęk]

Hi all,

How can I request new docker hub repository "jenkins/kubernetes-operator"?

Regards,
Tomasz 

[Tomasz Sęk]

Hi all,

I've raised ticket INFRA-2013 for Docker Hub repository.

Regards,
Tomasz

[Oleg Nenashev]

Hi Tomasz,

Before I proceed with this request, would you like to start from an Experimental DocherHub organization?

https://github.com/jenkinsci/jep/tree/master/jep/217

BR, Oleg

[Carlos Sanchez]

Would Tomasz or anyone else working on the operator like to introduce it at the next Cloud Native SIG meeting the week of February 25th?

--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/f3f55c14-8197-4ec0-8963-27c6301e7d24%40googlegroups.com.

[Tomasz Sęk]

Hi Carlos,

I can introduce operator at the next Cloud Native SIG meeting. Cloud you provide more information about meeting itself(agenda, video link etc.)?

Regards,
Tomasz

[Carlos Sanchez]

I'll be sending a note to the group soon to close the dates

https://groups.google.com/forum/#!forum/jenkins-cloud-native-sig

--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/a2fd940c-f5ce-4928-b244-4e976d5e183c%40googlegroups.com.

[Olblak]

I created the repository jenkins4eval/kubernetes-operator and gave admin permission to tomasz cfr [INFRA-2013]

Once this docker image is considered  as stable enough and so can be promoted widely, I would be happy to replicate or move it to the jenkins organization. 

---

-> gpg --keyserver keys.gnupg.net --recv-key 52210D3D

---

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALHFn6M6ja8LVjtcwLCqR%3D5Y%3DpviOGAGX_hUgwFWimuKxwitdQ%40mail.gmail.com.

[Tomasz Sęk]

Hi all,

It's been a while. I've just submitted abstract for Jenkins World 2019 in Lisbon. My reference number is JNXM6DMR0M. Could someone check if everything is ok with it?

We've gathered a lot of feedback from the community. I think we are close to promote the project to beta.

Regards,

Tomasz

Jenkins World 2019

Jenkins World 2019