Time change for Jan 12's community sync up (U.S timezone)
Hi all I have rescheduled tomorrow's U.S timezone community sync up to 4:30 pm in the afternoon. Just to make it more convenient for some more people to join. This is a one-time change, but I guess we can also discuss the timeslot in the coming meeting and see if we want to move this permanently. Hope to meet you there, thanks!
Re: [DISCUSS] v0.12.2 release to allow K8s 1.22 and K8s 1.23 deployments
We have already run the e2e tests against k8s 1.22 and k8s 1.23. They all passed. Based on that result we do not expect any further work that is needed to run the scheduler on the later version(s). In the branch-0.12 we will update the e2e test matrix to include the new release(s). The release process will publish new helm charts automatically. That is part of what the release manager must do. I have logged the release umbrella jira YUNIKORN-1010 [1] The upgrade is the same as it has always been. A simple helm upgrade should trigger the upgrade as per normal. Wilfred [1] https://issues.apache.org/jira/browse/YUNIKORN-1010 On Wed, 12 Jan 2022 at 15:48, Weiwei Yang wrote: > > Apart from the issues that have been fixed. > Can we also make sure > >- Update e2e test matrix to include 1.22 >- Update the user doc to include guidelines of how to do upgrade >- Update and publish the new helm charts in the helm chart repo > > can we have an umbrella JIRA to track all the remaining issues for 1.22? > People can help out some of unfinished tasks. > > On Tue, Jan 11, 2022 at 8:44 PM Weiwei Yang wrote: > > > Fantastic, thank you, Wilfred, Craig for getting this solved! > > +1 of having a 1.22 release, to unblock people who use 1.22+ K8s versions. > > > > > > On Tue, Jan 11, 2022 at 8:40 PM Chaoran Yu > > wrote: > > > >> +1 because it unblocks some users. > >> > >> On Tue, Jan 11, 2022 at 4:35 PM Sunil Govindan wrote: > >> > >> > I think this will help our customers who are stuck with K8s 1.22 issue > >> > before 1.0 is out. > >> > > >> > +1 to the proposal > >> > > >> > Thanks > >> > Sunil > >> > > >> > On Tue, Jan 11, 2022 at 4:11 PM Wilfred Spiegelenburg < > >> wilfr...@apache.org > >> > > > >> > wrote: > >> > > >> > > Over the last weeks Craig and I have been working on getting the > >> > > admission controller deployment updated. These changes were committed > >> > > yesterday as YUNIKORN-941. The main goal was to move away from old K8s > >> > > objects and API calls and remove the scripts for certificate creation. > >> > > > >> > > With the changes committed deployments and e2e tests against K8s1.22 > >> > > and K8s 1.23 are no longer failing. > >> > > I would like to propose that we release v0.12.2 with just the changes > >> > > for the admission controller to allow deployments on the latest > >> > > versions of K8s. Since Craig is the person that has been driving this > >> > > code change I would like to propose him as the release manager. > >> > > > >> > > This is the list of changes related to YUNIKORN-941. It includes a > >> > > number of other jiras as they are all fixed by the new deployment: > >> > > * YUNIKORN-995 > >> > > * YUNIKORN-938 > >> > > * YUNIKORN-947 > >> > > * YUNIKORN-625 > >> > > * YUNIKORN-726 > >> > > It has one jira it dependents on: YUNIKORN-928 > >> > > > >> > > Wilfred > >> > > > >> > > - > >> > > To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org > >> > > For additional commands, e-mail: dev-h...@yunikorn.apache.org > >> > > > >> > > > >> > > >> > > - To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org For additional commands, e-mail: dev-h...@yunikorn.apache.org
Re: [DISCUSS] v0.12.2 release to allow K8s 1.22 and K8s 1.23 deployments
+1 thanks Wilfred and Craig for driving YUNIKORN-941! Look forward to the release! On Tue, Jan 11, 2022 at 8:48 PM Weiwei Yang wrote: > Apart from the issues that have been fixed. > Can we also make sure > >- Update e2e test matrix to include 1.22 >- Update the user doc to include guidelines of how to do upgrade >- Update and publish the new helm charts in the helm chart repo > > can we have an umbrella JIRA to track all the remaining issues for 1.22? > People can help out some of unfinished tasks. > > On Tue, Jan 11, 2022 at 8:44 PM Weiwei Yang wrote: > > > Fantastic, thank you, Wilfred, Craig for getting this solved! > > +1 of having a 1.22 release, to unblock people who use 1.22+ K8s > versions. > > > > > > On Tue, Jan 11, 2022 at 8:40 PM Chaoran Yu > > wrote: > > > >> +1 because it unblocks some users. > >> > >> On Tue, Jan 11, 2022 at 4:35 PM Sunil Govindan > wrote: > >> > >> > I think this will help our customers who are stuck with K8s 1.22 issue > >> > before 1.0 is out. > >> > > >> > +1 to the proposal > >> > > >> > Thanks > >> > Sunil > >> > > >> > On Tue, Jan 11, 2022 at 4:11 PM Wilfred Spiegelenburg < > >> wilfr...@apache.org > >> > > > >> > wrote: > >> > > >> > > Over the last weeks Craig and I have been working on getting the > >> > > admission controller deployment updated. These changes were > committed > >> > > yesterday as YUNIKORN-941. The main goal was to move away from old > K8s > >> > > objects and API calls and remove the scripts for certificate > creation. > >> > > > >> > > With the changes committed deployments and e2e tests against K8s1.22 > >> > > and K8s 1.23 are no longer failing. > >> > > I would like to propose that we release v0.12.2 with just the > changes > >> > > for the admission controller to allow deployments on the latest > >> > > versions of K8s. Since Craig is the person that has been driving > this > >> > > code change I would like to propose him as the release manager. > >> > > > >> > > This is the list of changes related to YUNIKORN-941. It includes a > >> > > number of other jiras as they are all fixed by the new deployment: > >> > > * YUNIKORN-995 > >> > > * YUNIKORN-938 > >> > > * YUNIKORN-947 > >> > > * YUNIKORN-625 > >> > > * YUNIKORN-726 > >> > > It has one jira it dependents on: YUNIKORN-928 > >> > > > >> > > Wilfred > >> > > > >> > > > - > >> > > To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org > >> > > For additional commands, e-mail: dev-h...@yunikorn.apache.org > >> > > > >> > > > >> > > >> > > >
[jira] [Created] (YUNIKORN-1013) Update the copyright years in NOTICE file to 2022
Wilfred Spiegelenburg created YUNIKORN-1013: --- Summary: Update the copyright years in NOTICE file to 2022 Key: YUNIKORN-1013 URL: https://issues.apache.org/jira/browse/YUNIKORN-1013 Project: Apache YuniKorn Issue Type: Sub-task Reporter: Wilfred Spiegelenburg Update the NOTICE file year in all repositories in the branch-0.12. We are releasing again from that branch and we thus need an update. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org For additional commands, e-mail: dev-h...@yunikorn.apache.org
[jira] [Created] (YUNIKORN-1012) Update website for v0.12.2 release
Wilfred Spiegelenburg created YUNIKORN-1012: --- Summary: Update website for v0.12.2 release Key: YUNIKORN-1012 URL: https://issues.apache.org/jira/browse/YUNIKORN-1012 Project: Apache YuniKorn Issue Type: Sub-task Reporter: Wilfred Spiegelenburg Assignee: Craig Condit Multiple tasks all need to be done at once: * create versioned docs * create release announcement * update downloads page * update roadmap doc all to be performed at release time. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org For additional commands, e-mail: dev-h...@yunikorn.apache.org
[jira] [Created] (YUNIKORN-1011) helm chart release v0.12.2
Wilfred Spiegelenburg created YUNIKORN-1011: --- Summary: helm chart release v0.12.2 Key: YUNIKORN-1011 URL: https://issues.apache.org/jira/browse/YUNIKORN-1011 Project: Apache YuniKorn Issue Type: Sub-task Reporter: Wilfred Spiegelenburg Assignee: Craig Condit The branch used for the release will remain branch-0.12. Release the helm charts in yunikorn-release repository with following steps: * update version to v0.12.2 in charts * update supported k8s versions in charts * add v0.12.2 to index.yaml (gh-pages) * tag v0.12.2 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org For additional commands, e-mail: dev-h...@yunikorn.apache.org
[jira] [Created] (YUNIKORN-1010) [UMBRELLA] YuniKorn 0.12.2 release efforts
Wilfred Spiegelenburg created YUNIKORN-1010: --- Summary: [UMBRELLA] YuniKorn 0.12.2 release efforts Key: YUNIKORN-1010 URL: https://issues.apache.org/jira/browse/YUNIKORN-1010 Project: Apache YuniKorn Issue Type: Task Reporter: Wilfred Spiegelenburg Assignee: Craig Condit This umbrella is to track the work items needed for 0.12.2 release. Release manager: Craig Condit Release for updated support for K8s releases. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org For additional commands, e-mail: dev-h...@yunikorn.apache.org
Re: [DISCUSS] v0.12.2 release to allow K8s 1.22 and K8s 1.23 deployments
Apart from the issues that have been fixed. Can we also make sure - Update e2e test matrix to include 1.22 - Update the user doc to include guidelines of how to do upgrade - Update and publish the new helm charts in the helm chart repo can we have an umbrella JIRA to track all the remaining issues for 1.22? People can help out some of unfinished tasks. On Tue, Jan 11, 2022 at 8:44 PM Weiwei Yang wrote: > Fantastic, thank you, Wilfred, Craig for getting this solved! > +1 of having a 1.22 release, to unblock people who use 1.22+ K8s versions. > > > On Tue, Jan 11, 2022 at 8:40 PM Chaoran Yu > wrote: > >> +1 because it unblocks some users. >> >> On Tue, Jan 11, 2022 at 4:35 PM Sunil Govindan wrote: >> >> > I think this will help our customers who are stuck with K8s 1.22 issue >> > before 1.0 is out. >> > >> > +1 to the proposal >> > >> > Thanks >> > Sunil >> > >> > On Tue, Jan 11, 2022 at 4:11 PM Wilfred Spiegelenburg < >> wilfr...@apache.org >> > > >> > wrote: >> > >> > > Over the last weeks Craig and I have been working on getting the >> > > admission controller deployment updated. These changes were committed >> > > yesterday as YUNIKORN-941. The main goal was to move away from old K8s >> > > objects and API calls and remove the scripts for certificate creation. >> > > >> > > With the changes committed deployments and e2e tests against K8s1.22 >> > > and K8s 1.23 are no longer failing. >> > > I would like to propose that we release v0.12.2 with just the changes >> > > for the admission controller to allow deployments on the latest >> > > versions of K8s. Since Craig is the person that has been driving this >> > > code change I would like to propose him as the release manager. >> > > >> > > This is the list of changes related to YUNIKORN-941. It includes a >> > > number of other jiras as they are all fixed by the new deployment: >> > > * YUNIKORN-995 >> > > * YUNIKORN-938 >> > > * YUNIKORN-947 >> > > * YUNIKORN-625 >> > > * YUNIKORN-726 >> > > It has one jira it dependents on: YUNIKORN-928 >> > > >> > > Wilfred >> > > >> > > - >> > > To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org >> > > For additional commands, e-mail: dev-h...@yunikorn.apache.org >> > > >> > > >> > >> >
Re: [DISCUSS] v0.12.2 release to allow K8s 1.22 and K8s 1.23 deployments
Fantastic, thank you, Wilfred, Craig for getting this solved! +1 of having a 1.22 release, to unblock people who use 1.22+ K8s versions. On Tue, Jan 11, 2022 at 8:40 PM Chaoran Yu wrote: > +1 because it unblocks some users. > > On Tue, Jan 11, 2022 at 4:35 PM Sunil Govindan wrote: > > > I think this will help our customers who are stuck with K8s 1.22 issue > > before 1.0 is out. > > > > +1 to the proposal > > > > Thanks > > Sunil > > > > On Tue, Jan 11, 2022 at 4:11 PM Wilfred Spiegelenburg < > wilfr...@apache.org > > > > > wrote: > > > > > Over the last weeks Craig and I have been working on getting the > > > admission controller deployment updated. These changes were committed > > > yesterday as YUNIKORN-941. The main goal was to move away from old K8s > > > objects and API calls and remove the scripts for certificate creation. > > > > > > With the changes committed deployments and e2e tests against K8s1.22 > > > and K8s 1.23 are no longer failing. > > > I would like to propose that we release v0.12.2 with just the changes > > > for the admission controller to allow deployments on the latest > > > versions of K8s. Since Craig is the person that has been driving this > > > code change I would like to propose him as the release manager. > > > > > > This is the list of changes related to YUNIKORN-941. It includes a > > > number of other jiras as they are all fixed by the new deployment: > > > * YUNIKORN-995 > > > * YUNIKORN-938 > > > * YUNIKORN-947 > > > * YUNIKORN-625 > > > * YUNIKORN-726 > > > It has one jira it dependents on: YUNIKORN-928 > > > > > > Wilfred > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org > > > For additional commands, e-mail: dev-h...@yunikorn.apache.org > > > > > > > > >
Re: [DISCUSS] v0.12.2 release to allow K8s 1.22 and K8s 1.23 deployments
+1 because it unblocks some users. On Tue, Jan 11, 2022 at 4:35 PM Sunil Govindan wrote: > I think this will help our customers who are stuck with K8s 1.22 issue > before 1.0 is out. > > +1 to the proposal > > Thanks > Sunil > > On Tue, Jan 11, 2022 at 4:11 PM Wilfred Spiegelenburg > > wrote: > > > Over the last weeks Craig and I have been working on getting the > > admission controller deployment updated. These changes were committed > > yesterday as YUNIKORN-941. The main goal was to move away from old K8s > > objects and API calls and remove the scripts for certificate creation. > > > > With the changes committed deployments and e2e tests against K8s1.22 > > and K8s 1.23 are no longer failing. > > I would like to propose that we release v0.12.2 with just the changes > > for the admission controller to allow deployments on the latest > > versions of K8s. Since Craig is the person that has been driving this > > code change I would like to propose him as the release manager. > > > > This is the list of changes related to YUNIKORN-941. It includes a > > number of other jiras as they are all fixed by the new deployment: > > * YUNIKORN-995 > > * YUNIKORN-938 > > * YUNIKORN-947 > > * YUNIKORN-625 > > * YUNIKORN-726 > > It has one jira it dependents on: YUNIKORN-928 > > > > Wilfred > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org > > For additional commands, e-mail: dev-h...@yunikorn.apache.org > > > > >
Reminder: today's community sync up meeting for APAC region (Chinese/中文)
Hi all For community folks in the APAC region speaking Chinese, we have a community sync-up meeting today. Please check the details in your calendar. Thanks!
[jira] [Created] (YUNIKORN-1009) add git sha as label to admission controller image
Wilfred Spiegelenburg created YUNIKORN-1009: --- Summary: add git sha as label to admission controller image Key: YUNIKORN-1009 URL: https://issues.apache.org/jira/browse/YUNIKORN-1009 Project: Apache YuniKorn Issue Type: New Feature Components: shim - kubernetes Reporter: Wilfred Spiegelenburg -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org For additional commands, e-mail: dev-h...@yunikorn.apache.org
[jira] [Resolved] (YUNIKORN-982) Handle placeholders that are different from real allocations
[ https://issues.apache.org/jira/browse/YUNIKORN-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wilfred Spiegelenburg resolved YUNIKORN-982. Fix Version/s: 1.0.0 Resolution: Fixed changes committed > Handle placeholders that are different from real allocations > > > Key: YUNIKORN-982 > URL: https://issues.apache.org/jira/browse/YUNIKORN-982 > Project: Apache YuniKorn > Issue Type: Bug > Components: core - scheduler >Affects Versions: 0.12 >Reporter: Wilfred Spiegelenburg >Assignee: Wilfred Spiegelenburg >Priority: Major > Labels: pull-request-available > Fix For: 1.0.0 > > > If a placeholder is not the same resource size as the real allocation that > replaces it YuniKorn will leak resources. In YUNIKORN-580 a log entry was > added to detect the case. It will still cause the out of sync state but we > can detect it. > Handling the issue in the code outright is a better solution. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org For additional commands, e-mail: dev-h...@yunikorn.apache.org
Re: [DISCUSS] v0.12.2 release to allow K8s 1.22 and K8s 1.23 deployments
I think this will help our customers who are stuck with K8s 1.22 issue before 1.0 is out. +1 to the proposal Thanks Sunil On Tue, Jan 11, 2022 at 4:11 PM Wilfred Spiegelenburg wrote: > Over the last weeks Craig and I have been working on getting the > admission controller deployment updated. These changes were committed > yesterday as YUNIKORN-941. The main goal was to move away from old K8s > objects and API calls and remove the scripts for certificate creation. > > With the changes committed deployments and e2e tests against K8s1.22 > and K8s 1.23 are no longer failing. > I would like to propose that we release v0.12.2 with just the changes > for the admission controller to allow deployments on the latest > versions of K8s. Since Craig is the person that has been driving this > code change I would like to propose him as the release manager. > > This is the list of changes related to YUNIKORN-941. It includes a > number of other jiras as they are all fixed by the new deployment: > * YUNIKORN-995 > * YUNIKORN-938 > * YUNIKORN-947 > * YUNIKORN-625 > * YUNIKORN-726 > It has one jira it dependents on: YUNIKORN-928 > > Wilfred > > - > To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org > For additional commands, e-mail: dev-h...@yunikorn.apache.org > >
[DISCUSS] v0.12.2 release to allow K8s 1.22 and K8s 1.23 deployments
Over the last weeks Craig and I have been working on getting the admission controller deployment updated. These changes were committed yesterday as YUNIKORN-941. The main goal was to move away from old K8s objects and API calls and remove the scripts for certificate creation. With the changes committed deployments and e2e tests against K8s1.22 and K8s 1.23 are no longer failing. I would like to propose that we release v0.12.2 with just the changes for the admission controller to allow deployments on the latest versions of K8s. Since Craig is the person that has been driving this code change I would like to propose him as the release manager. This is the list of changes related to YUNIKORN-941. It includes a number of other jiras as they are all fixed by the new deployment: * YUNIKORN-995 * YUNIKORN-938 * YUNIKORN-947 * YUNIKORN-625 * YUNIKORN-726 It has one jira it dependents on: YUNIKORN-928 Wilfred - To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org For additional commands, e-mail: dev-h...@yunikorn.apache.org
[GitHub] [incubator-yunikorn-release] craigcondit opened a new pull request #62: [YUNIKORN-1008] Allow admission controller to bypass pods in certain namespaces
craigcondit opened a new pull request #62: URL: https://github.com/apache/incubator-yunikorn-release/pull/62 # Description This is the helm changes required to customize the admission controller with blacklisted namespaces. # JIRA issue https://issues.apache.org/jira/browse/YUNIKORN-1008 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org For additional commands, e-mail: dev-h...@yunikorn.apache.org
Re: Apache YuniKorn (Incubating) - Community Graduation Vote
None of the security lists mentioned in the security page [1] are moderated. They are private lists, i.e. not openly available for browsing in an archive, but not moderated. Using the private@ for YuniKorn does not seem to line up with what other projects do either. None of the recently graduated projects mention anything like using the private@ mailing list on their sites. They all have just used the general security link mentioned on their site unless they have a specific security@ list. YuniKorn would be the one standing out from what seems to be the norm. Examples from the last 2 years of graduated projects using a simple link or a text pointing to [1]: Pinot, Dolphinscheduler, Ratis, Echarts, Gobblin, TVM, Superset and Datasketches. There are more but I think this provides an overview of what is expected on graduation. Wilfred [1] https://www.apache.org/security/ On Tue, 11 Jan 2022 at 18:21, Weiwei Yang wrote: > > Hi Wilfred > > Adding a security@ mailing list sounds like a good idea, but I do not think > that is required in the current stage. > We can do that post-graduate. For now, the Apache security doc said > > > We strongly encourage you to report potential security vulnerabilities to > > one of our private security mailing lists first, before disclosing them in > > a public forum. > > I do not see any issue if we use our private@ mailing list for this purpose. > > On Mon, Jan 10, 2022 at 11:01 PM Wilfred Spiegelenburg > wrote: >> >> The private@ is a moderated list. This has two issues: a moderator >> needs to approve any message not sent by a PMC member. This will slow >> down the process of interaction with the reporter. It would also not >> reach the YuniKorn committers group as not all committers are part of >> the PMC. Security issues should be handled and worked on by all >> committers not just by the PMC members. >> >> The security notification update made to the website I think does not >> line up with the security guidelines referenced in the link provided >> in the dropdown menu of the YuniKorn site [1]. In that link there is a >> well defined way to report security issues. If we need to enhance and >> extend what we do we either establish a security@ mailing list and >> provide a static page with security related information on our site or >> we leave it as is. My preference would be to establish a security@ >> list and make all committers a member of that list. >> >> I think we need to roll back the website changes part of YUNIKORN-1006 >> [2] in PR [3] for the website. >> >> Wilfred >> >> [1] https://www.apache.org/security/ >> [2] https://issues.apache.org/jira/browse/YUNIKORN-1006 >> [3] https://github.com/apache/incubator-yunikorn-site/pull/105 >> >> On Tue, 11 Jan 2022 at 04:45, Holden Karau wrote: >> > >> > For "The project provides a well-documented, secure and private channel to >> > report security issues, along with a documented way of responding to >> > them.' the standard that I've seen used is to tell people to e-mail >> > private@ when they think they might have a security related issue. I think >> > that would probably work well for Yunikorn too. >> > >> > >> > On Mon, Jan 10, 2022 at 7:04 AM Chenya Zhang >> > wrote: >> >> >> >> Hi Weiwei, >> >> >> >> Thanks for driving this! The evaluation is quite comprehensive overall. I >> >> checked our Apache project maturity guidelines and noticed the below >> >> three items. Not sure if we already have them but they are not blockers >> >> to our graduation. We could think more about them along the way. >> >> >> >> QU30 >> >> >> >> The project provides a well-documented, secure and private channel to >> >> report security issues, along with a documented way of responding to them. >> >> >> >> QU40 >> >> >> >> The project puts a high priority on backwards compatibility and aims to >> >> document any incompatible changes and provide tools and documentation to >> >> help users transition to new features. >> >> >> >> CO50 >> >> >> >> The project documents how contributors can earn more rights such as >> >> commit access or decision power, and applies these principles >> >> consistently. >> >> >> >> >> >> Thanks, >> >> >> >> Chenya >> >> >> >> >> >> >> >> On Mon, Jan 10, 2022 at 12:00 AM Weiwei Yang wrote: >> >>> >> >>> Hi YuniKorn community and mentors >> >>> >> >>> Based on the discussion thread [1], after 2 years time of incubating, it >> >>> is >> >>> considered that now is a good time to graduate YuniKorn from the ASF >> >>> incubator and become a top-level Apache project. We have reviewed the ASF >> >>> project maturity model [2] and provided some assessment of the project's >> >>> maturity based on the guidelines. Details are included as the following. >> >>> Please read this and share your thoughts by replying to this email, your >> >>> feedback will be much appreciated!!! >> >>> >> >>> *Code, License, and Copyright* >> >>> >> >>> All code is maintained on github, under Apache 2.0 license. We have
[jira] [Resolved] (YUNIKORN-995) Use v1 for ClusterRoleBinding rbac.authorization.k8s.io instead of v1beta1
[
https://issues.apache.org/jira/browse/YUNIKORN-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig Condit resolved YUNIKORN-995.
---
Assignee: Craig Condit (was: Anuraag Nalluri)
Resolution: Duplicate
Fixed as part of YUNIKORN-941 refactoring.
> Use v1 for ClusterRoleBinding rbac.authorization.k8s.io instead of v1beta1
> --
>
> Key: YUNIKORN-995
> URL: https://issues.apache.org/jira/browse/YUNIKORN-995
> Project: Apache YuniKorn
> Issue Type: Bug
>Reporter: Anuraag Nalluri
>Assignee: Craig Condit
>Priority: Critical
> Labels: newbie, pull-request-available
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Here's the following kubernetes client/server info on my local machine:
> {code:java}
> ➜ incubator-yunikorn-k8shim git:(master) ✗ kubectl version
> Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.4",
> GitCommit:"b695d79d4f967c403a96986f1750a35eb75e75f1", GitTreeState:"clean",
> BuildDate:"2021-11-17T15:48:33Z", GoVersion:"go1.16.10", Compiler:"gc",
> Platform:"darwin/arm64"}
> Server Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.4",
> GitCommit:"b695d79d4f967c403a96986f1750a35eb75e75f1", GitTreeState:"clean",
> BuildDate:"2021-11-17T15:42:41Z", GoVersion:"go1.16.10", Compiler:"gc",
> Platform:"linux/arm64"} {code}
> This results in the following error when running the `helm install` command
> from the docs:
> {code:java}
> ➜ incubator-yunikorn-k8shim git:(master) ✗ helm install yunikorn
> yunikorn/yunikorn --namespace yunikornError: INSTALLATION FAILED: failed
> pre-install: unable to build kubernetes object for deleting hook
> yunikorn/templates/rbac.yaml: unable to recognize "": no matches for kind
> "ClusterRoleBinding" in version "rbac.authorization.k8s.io/v1beta1"{code}
> I believe this is because ClusterRoleBinding is removed from
> rbac.authorization.k8s.io/v1beta1 as of version 1.22 of Kubernetes. We should
> instead use the following apiVersion for this resource in the yaml:
> rbac.authorization.k8s.io/v1.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org
For additional commands, e-mail: dev-h...@yunikorn.apache.org
[jira] [Created] (YUNIKORN-1008) Allow admission controller to bypass pods in certain namespaces
Craig Condit created YUNIKORN-1008:
--
Summary: Allow admission controller to bypass pods in certain
namespaces
Key: YUNIKORN-1008
URL: https://issues.apache.org/jira/browse/YUNIKORN-1008
Project: Apache YuniKorn
Issue Type: Sub-task
Components: shim - kubernetes
Reporter: Craig Condit
Assignee: Craig Condit
There are times when it is necessary to blacklist certain pods from being
processed by the YuniKorn admission controller (system-level pods come to
mind). We should add a the abillity to block pods in certain namespaces from
being processed. This could be a comma-separated list of regular expressions.
By default we should blacklist the kube-system namespace (i.e. use
*{{^kube-system$}}* as a default).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org
For additional commands, e-mail: dev-h...@yunikorn.apache.org
[jira] [Resolved] (YUNIKORN-726) Quick start results in admission controller crashloop back off.
[
https://issues.apache.org/jira/browse/YUNIKORN-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig Condit resolved YUNIKORN-726.
---
Assignee: Craig Condit
Resolution: Invalid
After YUNIKORN-941, this can no longer occur.
> Quick start results in admission controller crashloop back off.
> ---
>
> Key: YUNIKORN-726
> URL: https://issues.apache.org/jira/browse/YUNIKORN-726
> Project: Apache YuniKorn
> Issue Type: Sub-task
>Reporter: Holden Karau
>Assignee: Craig Condit
>Priority: Major
> Labels: pull-request-available
>
> Following the quick start guide at [https://yunikorn.apache.org/docs/] the
> admission controller fails start with an error indicating that it can't read
> the PEM data in the certificate input. Looking at the webhook-server-tls
> there is data in the key.pem but not cert.pem.
>
> It looks like it does generate a certificate signing request:
>
> {code:java}
> (base) holden@hkdesktop:~/repos/incubator-yunikorn-k8shim$ kubectl describe
> certificatesigningrequest --all-namespaces
> Name: yunikorn-admission-controller-service.yunikorn
> Labels:
> Annotations:
> CreationTimestamp: Wed, 23 Jun 2021 16:03:43 -0700
> Requesting User: system:serviceaccount:yunikorn:yunikorn-admin
> Signer: kubernetes.io/legacy-unknown
> Status: Pending
> Subject:
> Common Name: yunikorn-admission-controller-service.yunikorn.svc
> Serial Number:
> Subject Alternative Names:
> DNS Names: yunikorn-admission-controller-service
> yunikorn-admission-controller-service.yunikorn
> yunikorn-admission-controller-service.yunikorn.svc
> Events: {code}
>
> This is on K3s 1.21
>
> {code:java}
> 2021-06-23T23:09:33.107Z INFO log/logger.go:93 scheduler configuration,
> pretty print {"configs": "{\n \"clusterId\": \"my-kube-cluster\",\n
> \"clusterVersion\": \"0.1\",\n \"policyGroup\": \"queues\",\n
> \"schedulingIntervalSecond\": 10,\n \"absoluteKubeConfigFilePath\":
> \"\",\n \"loggingLevel\": 0,\n \"logEncoding\": \"console\",\n
> \"logFilePath\": \"\",\n \"volumeBindTimeout\": 100,\n \"testMode\":
> false,\n \"eventChannelCapacity\": 1048576,\n \"dispatchTimeout\":
> 3000,\n \"kubeQPS\": 1000,\n \"kubeBurst\": 1000,\n \"predicates\":
> \"\",\n \"operatorPlugins\": \"general,yunikorn-app\",\n
> \"enableConfigHotRefresh\": false\n}"}2021-06-23T23:09:33.107Z INFO
> log/logger.go:93 scheduler configuration, pretty print {"configs": "{\n
> \"clusterId\": \"my-kube-cluster\",\n \"clusterVersion\": \"0.1\",\n
> \"policyGroup\": \"queues\",\n \"schedulingIntervalSecond\": 10,\n
> \"absoluteKubeConfigFilePath\": \"\",\n \"loggingLevel\": 0,\n
> \"logEncoding\": \"console\",\n \"logFilePath\": \"\",\n
> \"volumeBindTimeout\": 100,\n \"testMode\": false,\n
> \"eventChannelCapacity\": 1048576,\n \"dispatchTimeout\": 3000,\n
> \"kubeQPS\": 1000,\n \"kubeBurst\": 1000,\n \"predicates\": \"\",\n
> \"operatorPlugins\": \"general,yunikorn-app\",\n \"enableConfigHotRefresh\":
> false\n}"}2021-06-23T23:09:33.107Z FATAL webhook/webhook.go:56 Failed to load
> key pair {"error": "tls: failed to find any PEM data in certificate
> input"}main.main
> /Users/boyuan/go/src/yunikorn-release-v0.10.0/incubator-yunikorn-release/staging/apache-yunikorn-0.10.0-incubating-src/k8shim/pkg/plugin/admissioncontrollers/webhook/webhook.go:56runtime.main
> /Users/boyuan/go/install/go1.14.14/src/runtime/proc.go:203{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org
For additional commands, e-mail: dev-h...@yunikorn.apache.org
[jira] [Resolved] (YUNIKORN-947) Add missing fields to the admission wehooks
[ https://issues.apache.org/jira/browse/YUNIKORN-947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig Condit resolved YUNIKORN-947. --- Resolution: Duplicate Resolved in favor of YUNIKORN-941. > Add missing fields to the admission wehooks > --- > > Key: YUNIKORN-947 > URL: https://issues.apache.org/jira/browse/YUNIKORN-947 > Project: Apache YuniKorn > Issue Type: Sub-task > Components: shim - kubernetes >Reporter: Kinga Marton >Assignee: Peter Bacsko >Priority: Major > Labels: pull-request-available > > v1 api has 2 extra mandatory fields: > admissionReviewVersions and sideEffects, what were not there in v1beta1 > bersion. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org For additional commands, e-mail: dev-h...@yunikorn.apache.org
[jira] [Resolved] (YUNIKORN-938) Admission controller: remove v1beta1 usage
[
https://issues.apache.org/jira/browse/YUNIKORN-938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig Condit resolved YUNIKORN-938.
---
Resolution: Duplicate
Closing in favor of YUNIKORN-941.
> Admission controller: remove v1beta1 usage
> --
>
> Key: YUNIKORN-938
> URL: https://issues.apache.org/jira/browse/YUNIKORN-938
> Project: Apache YuniKorn
> Issue Type: Sub-task
> Components: shim - kubernetes
>Reporter: Wilfred Spiegelenburg
>Assignee: Peter Bacsko
>Priority: Major
> Labels: newbie, pull-request-available
>
> The admission controller uses {{v1beta1.AdmissionReview}} and
> {{v1beta1.AdmissionResponse}} in the calls. This API is removed in K8s 1.22
> and we should proactively move to the v1 versions of both.
> This also affects the registration of the webhooks in the yaml stored int the
> templates.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org
For additional commands, e-mail: dev-h...@yunikorn.apache.org
[jira] [Resolved] (YUNIKORN-625) Use v1 for CertificateSigningRequest instead of v1beta1
[ https://issues.apache.org/jira/browse/YUNIKORN-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig Condit resolved YUNIKORN-625. --- Assignee: Craig Condit Resolution: Invalid Resolved in favor of YUNIKORN-941 as CertificateSigningRequests are no longer required. > Use v1 for CertificateSigningRequest instead of v1beta1 > --- > > Key: YUNIKORN-625 > URL: https://issues.apache.org/jira/browse/YUNIKORN-625 > Project: Apache YuniKorn > Issue Type: Sub-task >Reporter: Kinga Marton >Assignee: Craig Condit >Priority: Major > Labels: pull-request-available > > Starting from Kubernetes v. 1.19 the CertificateSigningRequest API is > promoted to certificates.k8s.io/v1 with the following changes: > * spec.signerName is now required, and requests for > kubernetes.io/legacy-unknown are not allowed to be created via the > certificates.k8s.io/v1 API > * spec.usages is now required, may not contain duplicate values, and must > only contain known usages > * status.conditions may not contain duplicate types > * status.conditions[*].status is now required > * status.certificate must be PEM-encoded, and contain only CERTIFICATE > blocks (#91685, @liggitt) [SIG API Machinery, Architecture, Auth, CLI and > Testing] > See more details at: > https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.19.md -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org For additional commands, e-mail: dev-h...@yunikorn.apache.org
[jira] [Resolved] (YUNIKORN-941) split scheduler and admission controller deployment
[ https://issues.apache.org/jira/browse/YUNIKORN-941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig Condit resolved YUNIKORN-941. --- Fix Version/s: 1.0.0 Resolution: Fixed Deployed to master in both release and k8shim repositories. > split scheduler and admission controller deployment > --- > > Key: YUNIKORN-941 > URL: https://issues.apache.org/jira/browse/YUNIKORN-941 > Project: Apache YuniKorn > Issue Type: Sub-task > Components: shim - kubernetes >Reporter: Kinga Marton >Assignee: Craig Condit >Priority: Major > Labels: pull-request-available > Fix For: 1.0.0 > > Attachments: logs_322.zip > > > To support proper YuniKorn upgrades and restarts we should move the admission > controller out of the scheduler deployment and make it a separate deployment. > This could also allow the admission controller to be made high available and > allow simpler no down time upgrades possible. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org For additional commands, e-mail: dev-h...@yunikorn.apache.org
[GitHub] [incubator-yunikorn-release] craigcondit commented on pull request #60: [YUNIKORN-941] Split scheduler and admission controller deployments
craigcondit commented on pull request #60: URL: https://github.com/apache/incubator-yunikorn-release/pull/60#issuecomment-1010128176 Merged to master, with minor updates for camel casing and embedAdmissionController checking. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org For additional commands, e-mail: dev-h...@yunikorn.apache.org
[GitHub] [incubator-yunikorn-release] craigcondit closed pull request #60: [YUNIKORN-941] Split scheduler and admission controller deployments
craigcondit closed pull request #60: URL: https://github.com/apache/incubator-yunikorn-release/pull/60 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org For additional commands, e-mail: dev-h...@yunikorn.apache.org
