[jira] [Commented] (YUNIKORN-14) Add rest API to retrieve app/container history info
[ https://issues.apache.org/jira/browse/YUNIKORN-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17067390#comment-17067390 ] Wilfred Spiegelenburg commented on YUNIKORN-14: --- Providing two sets of metrics that are not in sync or can show highly different numbers is a bad idea. We'll get questions and new jiras raised about the fact that the provided web UI is out of sync with metrics collected. We should either leverage the metrics implementation or not provide the web UI metrics. Doing two things is asking for problems. > Add rest API to retrieve app/container history info > --- > > Key: YUNIKORN-14 > URL: https://issues.apache.org/jira/browse/YUNIKORN-14 > Project: Apache YuniKorn > Issue Type: New Feature > Components: core - scheduler >Reporter: Wilfred Spiegelenburg >Assignee: Adam Antal >Priority: Major > Labels: pull-request-available > Attachments: Yunikorn_UI.png > > Time Spent: 10m > Remaining Estimate: 0h > > As part of the web UI we can show application and container history. > The current pages are mocked up and do not show the real history. Before the > changes can be made on the web UI side we need to provide the history via a > REST interface so it can be consumed by the UI. > All web service code is located in package > [https://github.com/apache/incubator-yunikorn-core/tree/master/pkg/webservice]. > When running the scheduler locally (from K8shim using "make run"), the REST > APIs can be accessed via > * [http://localhost:9080/ws/v1/apps] > * [http://localhost:9080/ws/v1/queues] > * [http://localhost:9080/ws/v1/nodes] > We need to add another endpoint to provide data to yunikorn-web to render the > app/container history page. Please check with [~akhilpb] for the desired data > format, etc. That issue is tracked via YUNIKORN-8. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@yunikorn.apache.org For additional commands, e-mail: issues-h...@yunikorn.apache.org
[jira] [Created] (YUNIKORN-55) Add pod labels and annotations to allocation ask attributes
Weiwei Yang created YUNIKORN-55: --- Summary: Add pod labels and annotations to allocation ask attributes Key: YUNIKORN-55 URL: https://issues.apache.org/jira/browse/YUNIKORN-55 Project: Apache YuniKorn Issue Type: Bug Components: core - scheduler, shim - kubernetes, webapp Reporter: Weiwei Yang In YUNIKORN-54, we simplify the way to generate application IDs. The side effect is when we look at info from web UI, we lose some info about the pod info such as pod name, namespace, etc. A proper way to handle this is to get this info from pod and add labels, annotations info to allocation ask as attributes, and then send to scheduler-core. Also on web rest API, we need to display these attributes too. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@yunikorn.apache.org For additional commands, e-mail: issues-h...@yunikorn.apache.org
[jira] [Updated] (YUNIKORN-54) admission-controller: the generated applicationID should not exceed 64 chars
[ https://issues.apache.org/jira/browse/YUNIKORN-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated YUNIKORN-54: --- Labels: pull-request-available (was: ) > admission-controller: the generated applicationID should not exceed 64 chars > > > Key: YUNIKORN-54 > URL: https://issues.apache.org/jira/browse/YUNIKORN-54 > Project: Apache YuniKorn > Issue Type: Bug > Components: shim - kubernetes >Reporter: Weiwei Yang >Assignee: Weiwei Yang >Priority: Major > Labels: pull-request-available > > If a label exceeds 64 chars, it will be rejected by some K8s clients. > Currently, we composite a generated name by -- > which might exceed 64 chars. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@yunikorn.apache.org For additional commands, e-mail: issues-h...@yunikorn.apache.org
[jira] [Assigned] (YUNIKORN-54) admission-controller: the generated applicationID should not exceed 64 chars
[ https://issues.apache.org/jira/browse/YUNIKORN-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Weiwei Yang reassigned YUNIKORN-54: --- Assignee: Weiwei Yang > admission-controller: the generated applicationID should not exceed 64 chars > > > Key: YUNIKORN-54 > URL: https://issues.apache.org/jira/browse/YUNIKORN-54 > Project: Apache YuniKorn > Issue Type: Bug > Components: shim - kubernetes >Reporter: Weiwei Yang >Assignee: Weiwei Yang >Priority: Major > > If a label exceeds 64 chars, it will be rejected by some K8s clients. > Currently, we composite a generated name by -- > which might exceed 64 chars. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@yunikorn.apache.org For additional commands, e-mail: issues-h...@yunikorn.apache.org
[jira] [Created] (YUNIKORN-54) admission-controller: the generated applicationID should not exceed 64 chars
Weiwei Yang created YUNIKORN-54: --- Summary: admission-controller: the generated applicationID should not exceed 64 chars Key: YUNIKORN-54 URL: https://issues.apache.org/jira/browse/YUNIKORN-54 Project: Apache YuniKorn Issue Type: Bug Components: shim - kubernetes Reporter: Weiwei Yang If a label exceeds 64 chars, it will be rejected by some K8s clients. Currently, we composite a generated name by -- which might exceed 64 chars. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@yunikorn.apache.org For additional commands, e-mail: issues-h...@yunikorn.apache.org
[jira] [Created] (YUNIKORN-53) Use asserts for nil error checks in test code
Wilfred Spiegelenburg created YUNIKORN-53:
-
Summary: Use asserts for nil error checks in test code
Key: YUNIKORN-53
URL: https://issues.apache.org/jira/browse/YUNIKORN-53
Project: Apache YuniKorn
Issue Type: Bug
Components: test - smoke, test - unit
Reporter: Wilfred Spiegelenburg
In a lot of tests we use the construct:
{code}
if err != nil {
t.Fatal("some text"
}{code}
We should replace that with the simple:
{code}
assert.NilError(t, err, "some text"){code}
that is part of the standard assert package we already use in the test code
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@yunikorn.apache.org
For additional commands, e-mail: issues-h...@yunikorn.apache.org
[jira] [Commented] (YUNIKORN-14) Add rest API to retrieve app/container history info
[ https://issues.apache.org/jira/browse/YUNIKORN-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17067350#comment-17067350 ] Weiwei Yang commented on YUNIKORN-14: - Hi [~wilfreds] Thanks for the comments. The history info here just provides very basic info about the cluster, e.g # of containers/apps in the last 12h. I think we can leverage this simple solution to give a basic impression for users. For comprehensive metrics, we have Prometheus integration so we can push that to its store for persistent. Here, we just need a small time-bound cache just like [~adam.antal] has implemented. It is a pull mode, but that's fine. We are doing the pull once per minute (or maybe 30s), since the data is cached, no matter how many requests from web UI, it will not lock partition and damage scheduler performance. For the moment where write happens, it simply gets the data from partition without any calculation, the impact is trivial. The push mode is the Prometheus metrics, which we already have so I don't think we need to build anything similar. > Add rest API to retrieve app/container history info > --- > > Key: YUNIKORN-14 > URL: https://issues.apache.org/jira/browse/YUNIKORN-14 > Project: Apache YuniKorn > Issue Type: New Feature > Components: core - scheduler >Reporter: Wilfred Spiegelenburg >Assignee: Adam Antal >Priority: Major > Labels: pull-request-available > Attachments: Yunikorn_UI.png > > Time Spent: 10m > Remaining Estimate: 0h > > As part of the web UI we can show application and container history. > The current pages are mocked up and do not show the real history. Before the > changes can be made on the web UI side we need to provide the history via a > REST interface so it can be consumed by the UI. > All web service code is located in package > [https://github.com/apache/incubator-yunikorn-core/tree/master/pkg/webservice]. > When running the scheduler locally (from K8shim using "make run"), the REST > APIs can be accessed via > * [http://localhost:9080/ws/v1/apps] > * [http://localhost:9080/ws/v1/queues] > * [http://localhost:9080/ws/v1/nodes] > We need to add another endpoint to provide data to yunikorn-web to render the > app/container history page. Please check with [~akhilpb] for the desired data > format, etc. That issue is tracked via YUNIKORN-8. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@yunikorn.apache.org For additional commands, e-mail: issues-h...@yunikorn.apache.org
[jira] [Comment Edited] (YUNIKORN-14) Add rest API to retrieve app/container history info
[ https://issues.apache.org/jira/browse/YUNIKORN-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17067350#comment-17067350 ] Weiwei Yang edited comment on YUNIKORN-14 at 3/26/20, 4:31 AM: --- Hi [~wilfreds] Thanks for the comments. The history info here just provides very basic info about the cluster, e.g # of containers/apps in the last 12h. I think we can leverage this simple solution to give a basic impression for users. For comprehensive metrics, we have Prometheus integration so we can push that to its store for persistent. Here, we just need a small time-bound cache just like [~adam.antal] has implemented. It is a pull mode, but that's fine. We are doing the pull once per minute (or maybe 30s), since the data is cached, no matter how many requests from web UI, it will not lock partition and damage scheduler performance. For the moment where write happens, it simply gets the data from partition without any calculation, the impact is trivial. The push mode is the Prometheus metrics, which we already have so I don't think we need to build anything similar. was (Author: wwei): Hi [~wilfreds] Thanks for the comments. The history info here just provides very basic info about the cluster, e.g # of containers/apps in the last 12h. I think we can leverage this simple solution to give a basic impression for users. For comprehensive metrics, we have Prometheus integration so we can push that to its store for persistent. Here, we just need a small time-bound cache just like [~adam.antal] has implemented. It is a pull mode, but that's fine. We are doing the pull once per minute (or maybe 30s), since the data is cached, no matter how many requests from web UI, it will not lock partition and damage scheduler performance. For the moment where write happens, it simply gets the data from partition without any calculation, the impact is trivial. The push mode is the Prometheus metrics, which we already have so I don't think we need to build anything similar. > Add rest API to retrieve app/container history info > --- > > Key: YUNIKORN-14 > URL: https://issues.apache.org/jira/browse/YUNIKORN-14 > Project: Apache YuniKorn > Issue Type: New Feature > Components: core - scheduler >Reporter: Wilfred Spiegelenburg >Assignee: Adam Antal >Priority: Major > Labels: pull-request-available > Attachments: Yunikorn_UI.png > > Time Spent: 10m > Remaining Estimate: 0h > > As part of the web UI we can show application and container history. > The current pages are mocked up and do not show the real history. Before the > changes can be made on the web UI side we need to provide the history via a > REST interface so it can be consumed by the UI. > All web service code is located in package > [https://github.com/apache/incubator-yunikorn-core/tree/master/pkg/webservice]. > When running the scheduler locally (from K8shim using "make run"), the REST > APIs can be accessed via > * [http://localhost:9080/ws/v1/apps] > * [http://localhost:9080/ws/v1/queues] > * [http://localhost:9080/ws/v1/nodes] > We need to add another endpoint to provide data to yunikorn-web to render the > app/container history page. Please check with [~akhilpb] for the desired data > format, etc. That issue is tracked via YUNIKORN-8. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@yunikorn.apache.org For additional commands, e-mail: issues-h...@yunikorn.apache.org
[jira] [Commented] (YUNIKORN-14) Add rest API to retrieve app/container history info
[
https://issues.apache.org/jira/browse/YUNIKORN-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17067342#comment-17067342
]
Wilfred Spiegelenburg commented on YUNIKORN-14:
---
I looked at the PR and want to propose a different approach as I see a number
of issues.
I have mentioned tracking applications details in the text but I am not sure if
that is needed in the first instance. It would still fit in the design if we
want to add that in the second step.
History should be part of {{common}} or the {{scheduler}} not the {{cache}} I
think. I would expect that we have multiple generic collectors that can collect
history data. One generic collector is started per partition like the
{{PartitionManager}} in its own go routine. History and all tracking is always
per partition and will not go over that level at any point.
The current implementation uses a pull mechanism to collect the data from the
partition. That requires locking the partition on retrieval (locks are missing
currently in the solution) and could thus impact scheduling performance if the
web interface gets lots of requests. We should not need to impact the partition
to retrieve the history. The data should be kept in the collector and retrieved
from there.
A change going deeper: why is the history just getting top level partition
data? Getting info out for queues or nodes is as important going forward. I
also see an omission here: we lose history data as soon as we remove the
partition. It will thus not show us real history for a time period just the
history for the current state going back a fixed time. That would become even
more important when we look at queues, nodes or applications. If we go forward
we need to be able to track and maintain the history data for a period of time
independent of the removal of the partition/node/queue/application.
Tracking history should not be limited by the number of entries but by time
range that we need to keep (24 hours as an example). Having a history per
minute is what we need at least. Maybe we even need to go to a 30 or 15 second
split. Longer periods means we could too easily miss short running containers
or applications. The other solution would be to use a push from the different
tracked objects into a channel that is read by the history collector. That
would mean we do not miss info but the implementation becomes a bit trickier.
We can still sum up to give stats per time range but that would then become
easier to manage for small intervals. That would also not be "on demand" but
based on an internal timing of the history collector.
All changes for things we need to track run through the partition info already
so we would just need to instrument one object to keep track of all these
things.
Thoughts?
> Add rest API to retrieve app/container history info
> ---
>
> Key: YUNIKORN-14
> URL: https://issues.apache.org/jira/browse/YUNIKORN-14
> Project: Apache YuniKorn
> Issue Type: New Feature
> Components: core - scheduler
>Reporter: Wilfred Spiegelenburg
>Assignee: Adam Antal
>Priority: Major
> Labels: pull-request-available
> Attachments: Yunikorn_UI.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As part of the web UI we can show application and container history.
> The current pages are mocked up and do not show the real history. Before the
> changes can be made on the web UI side we need to provide the history via a
> REST interface so it can be consumed by the UI.
> All web service code is located in package
> [https://github.com/apache/incubator-yunikorn-core/tree/master/pkg/webservice].
> When running the scheduler locally (from K8shim using "make run"), the REST
> APIs can be accessed via
> * [http://localhost:9080/ws/v1/apps]
> * [http://localhost:9080/ws/v1/queues]
> * [http://localhost:9080/ws/v1/nodes]
> We need to add another endpoint to provide data to yunikorn-web to render the
> app/container history page. Please check with [~akhilpb] for the desired data
> format, etc. That issue is tracked via YUNIKORN-8.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@yunikorn.apache.org
For additional commands, e-mail: issues-h...@yunikorn.apache.org
[jira] [Commented] (YUNIKORN-28) Support validating yunikorn-configs before admitting it
[ https://issues.apache.org/jira/browse/YUNIKORN-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17067284#comment-17067284 ] Tao Yang commented on YUNIKORN-28: -- Thanks [~wilfreds], [~wwei] for the review and commit! > Support validating yunikorn-configs before admitting it > --- > > Key: YUNIKORN-28 > URL: https://issues.apache.org/jira/browse/YUNIKORN-28 > Project: Apache YuniKorn > Issue Type: Improvement > Components: shim - kubernetes >Reporter: Tao Yang >Assignee: Tao Yang >Priority: Major > Labels: pull-request-available > Fix For: 0..8 > > Time Spent: 40m > Remaining Estimate: 0h > > Currently queues configuration are managed as ConfigMap, it can be easily > updated via kubectl commands but won't be validated for now, thus this > configmap may be inconsistent after been updated with invalid content, in > this state, configmap is updated successfully while the scheduler is still > using the previous configs, and the client doesn't know whether or not this > update is succeed. This may leads to many unexpected results, for example, > scheduler may not be successfully launched after restart. > To improve the management for configs, we can add validations for yunikorn > configs via admission-controller mechanism in K8S which is already used for > mutations on pod's spec/metadata in yunikorn-k8shim. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@yunikorn.apache.org For additional commands, e-mail: issues-h...@yunikorn.apache.org
[jira] [Resolved] (YUNIKORN-52) Update queue/app screenshots in README
[ https://issues.apache.org/jira/browse/YUNIKORN-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wangda Tan resolved YUNIKORN-52. Fix Version/s: 0.8 Resolution: Fixed Merged, thanks [~wwei] > Update queue/app screenshots in README > -- > > Key: YUNIKORN-52 > URL: https://issues.apache.org/jira/browse/YUNIKORN-52 > Project: Apache YuniKorn > Issue Type: Bug > Components: documentation >Reporter: Weiwei Yang >Assignee: Weiwei Yang >Priority: Major > Labels: pull-request-available > Fix For: 0.8 > > Time Spent: 20m > Remaining Estimate: 0h > > We have some updates in UI, let's refresh the screenshots as well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@yunikorn.apache.org For additional commands, e-mail: issues-h...@yunikorn.apache.org
[jira] [Updated] (YUNIKORN-52) Update queue/app screenshots in README
[ https://issues.apache.org/jira/browse/YUNIKORN-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated YUNIKORN-52: --- Labels: pull-request-available (was: ) > Update queue/app screenshots in README > -- > > Key: YUNIKORN-52 > URL: https://issues.apache.org/jira/browse/YUNIKORN-52 > Project: Apache YuniKorn > Issue Type: Bug > Components: documentation >Reporter: Weiwei Yang >Assignee: Weiwei Yang >Priority: Major > Labels: pull-request-available > > We have some updates in UI, let's refresh the screenshots as well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@yunikorn.apache.org For additional commands, e-mail: issues-h...@yunikorn.apache.org
[jira] [Created] (YUNIKORN-52) Update queue/app screenshots in README
Weiwei Yang created YUNIKORN-52: --- Summary: Update queue/app screenshots in README Key: YUNIKORN-52 URL: https://issues.apache.org/jira/browse/YUNIKORN-52 Project: Apache YuniKorn Issue Type: Bug Components: documentation Reporter: Weiwei Yang Assignee: Weiwei Yang We have some updates in UI, let's refresh the screenshots as well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@yunikorn.apache.org For additional commands, e-mail: issues-h...@yunikorn.apache.org
[jira] [Updated] (YUNIKORN-14) Add rest API to retrieve app/container history info
[ https://issues.apache.org/jira/browse/YUNIKORN-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated YUNIKORN-14: --- Labels: pull-request-available (was: ) > Add rest API to retrieve app/container history info > --- > > Key: YUNIKORN-14 > URL: https://issues.apache.org/jira/browse/YUNIKORN-14 > Project: Apache YuniKorn > Issue Type: New Feature > Components: core - scheduler >Reporter: Wilfred Spiegelenburg >Assignee: Adam Antal >Priority: Major > Labels: pull-request-available > Attachments: Yunikorn_UI.png > > > As part of the web UI we can show application and container history. > The current pages are mocked up and do not show the real history. Before the > changes can be made on the web UI side we need to provide the history via a > REST interface so it can be consumed by the UI. > All web service code is located in package > [https://github.com/apache/incubator-yunikorn-core/tree/master/pkg/webservice]. > When running the scheduler locally (from K8shim using "make run"), the REST > APIs can be accessed via > * [http://localhost:9080/ws/v1/apps] > * [http://localhost:9080/ws/v1/queues] > * [http://localhost:9080/ws/v1/nodes] > We need to add another endpoint to provide data to yunikorn-web to render the > app/container history page. Please check with [~akhilpb] for the desired data > format, etc. That issue is tracked via YUNIKORN-8. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@yunikorn.apache.org For additional commands, e-mail: issues-h...@yunikorn.apache.org
[jira] [Closed] (YUNIKORN-50) Yunikorn logo changes in yunikorn-web
[ https://issues.apache.org/jira/browse/YUNIKORN-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wilfred Spiegelenburg closed YUNIKORN-50. - Fix Version/s: 0.8 Resolution: Fixed committed the PR, thank you for the contribution > Yunikorn logo changes in yunikorn-web > - > > Key: YUNIKORN-50 > URL: https://issues.apache.org/jira/browse/YUNIKORN-50 > Project: Apache YuniKorn > Issue Type: Improvement >Reporter: Akhil PB >Assignee: Akhil PB >Priority: Major > Labels: pull-request-available > Fix For: 0.8 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@yunikorn.apache.org For additional commands, e-mail: issues-h...@yunikorn.apache.org
[jira] [Assigned] (YUNIKORN-44) Pass scheduler startup options from environment variables
[ https://issues.apache.org/jira/browse/YUNIKORN-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kinga Marton reassigned YUNIKORN-44: Assignee: Kinga Marton > Pass scheduler startup options from environment variables > - > > Key: YUNIKORN-44 > URL: https://issues.apache.org/jira/browse/YUNIKORN-44 > Project: Apache YuniKorn > Issue Type: Improvement > Components: shim - kubernetes >Reporter: Weiwei Yang >Assignee: Kinga Marton >Priority: Major > > Currently, we have built the command line options directly into the docker > image, > [https://github.com/apache/incubator-yunikorn-k8shim/blob/master/deployments/image/configmap/Dockerfile]. > instead, we should pass them as environment variables, this allows us to > tweak some configurations without rebuilt the docker image. Please see > example here: > [https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@yunikorn.apache.org For additional commands, e-mail: issues-h...@yunikorn.apache.org
[jira] [Created] (YUNIKORN-51) cast failures are not handled correctly
Wilfred Spiegelenburg created YUNIKORN-51:
-
Summary: cast failures are not handled correctly
Key: YUNIKORN-51
URL: https://issues.apache.org/jira/browse/YUNIKORN-51
Project: Apache YuniKorn
Issue Type: Bug
Components: core - scheduler
Reporter: Wilfred Spiegelenburg
Attachments: cast_panic.go
While reviewing the code for YUNIKORN-47 I noticed that we are not correctly
handling cast errors which could cause panics.
In all cases we use the proper cast like this:
{code:java}
obj, ok := i.(*T)
{code}
We check the value of ok but do not handle the fact correctly that we can get a
nil back which could cause a panic later when we us it.
examples: {{scheduler.processNodeEvent()}}
test code attached to show the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@yunikorn.apache.org
For additional commands, e-mail: issues-h...@yunikorn.apache.org
[jira] [Closed] (YUNIKORN-28) Support validating yunikorn-configs before admitting it
[ https://issues.apache.org/jira/browse/YUNIKORN-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wilfred Spiegelenburg closed YUNIKORN-28. - Fix Version/s: 0..8 Resolution: Fixed I have just committed PR#81. PR#103 was already committed. That should be all for this jira. [~taoyang] please reopen if there was more that needed to be done. > Support validating yunikorn-configs before admitting it > --- > > Key: YUNIKORN-28 > URL: https://issues.apache.org/jira/browse/YUNIKORN-28 > Project: Apache YuniKorn > Issue Type: Improvement > Components: shim - kubernetes >Reporter: Tao Yang >Assignee: Tao Yang >Priority: Major > Labels: pull-request-available > Fix For: 0..8 > > Time Spent: 40m > Remaining Estimate: 0h > > Currently queues configuration are managed as ConfigMap, it can be easily > updated via kubectl commands but won't be validated for now, thus this > configmap may be inconsistent after been updated with invalid content, in > this state, configmap is updated successfully while the scheduler is still > using the previous configs, and the client doesn't know whether or not this > update is succeed. This may leads to many unexpected results, for example, > scheduler may not be successfully launched after restart. > To improve the management for configs, we can add validations for yunikorn > configs via admission-controller mechanism in K8S which is already used for > mutations on pod's spec/metadata in yunikorn-k8shim. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@yunikorn.apache.org For additional commands, e-mail: issues-h...@yunikorn.apache.org
[jira] [Closed] (YUNIKORN-41) Update YuniKorn main README.md to make user can better get focus of the project
[ https://issues.apache.org/jira/browse/YUNIKORN-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wilfred Spiegelenburg closed YUNIKORN-41. - Fix Version/s: 0.8 Resolution: Fixed Just committed PR#106 Thank you [~wangda] for the update Follow up jira to be logged to update the screenshots when the web UI update is done > Update YuniKorn main README.md to make user can better get focus of the > project > --- > > Key: YUNIKORN-41 > URL: https://issues.apache.org/jira/browse/YUNIKORN-41 > Project: Apache YuniKorn > Issue Type: Task >Reporter: Wangda Tan >Assignee: Wangda Tan >Priority: Major > Labels: pull-request-available > Fix For: 0.8 > > Time Spent: 20m > Remaining Estimate: 0h > > The message from the Apache YuniKorn Github is a bit confusing when we put > YARN, and “general scheduler” together. > For most of the companies we spoke to, initially, they’re confused with: Is > it a K8s scheduler, or it is a YARN RM but hook up with K8s. I think we need > to do massive work to make the marketing message correct. > To me, the #1 use case YuniKorn trying to solve now is to be the best > scheduler in K8s to solve batch workload problems. > It is nicely designed to allow yunikorn-core to hook up with other RMs, but > that is the next step. > We can also include other items like highlights of K8s integration, perf > test, and community sync ups to the same README. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@yunikorn.apache.org For additional commands, e-mail: issues-h...@yunikorn.apache.org
[jira] [Updated] (YUNIKORN-50) Yunikorn logo changes in yunikorn-web
[ https://issues.apache.org/jira/browse/YUNIKORN-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated YUNIKORN-50: --- Labels: pull-request-available (was: ) > Yunikorn logo changes in yunikorn-web > - > > Key: YUNIKORN-50 > URL: https://issues.apache.org/jira/browse/YUNIKORN-50 > Project: Apache YuniKorn > Issue Type: Improvement >Reporter: Akhil PB >Assignee: Akhil PB >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@yunikorn.apache.org For additional commands, e-mail: issues-h...@yunikorn.apache.org
