[jira] [Created] (CLOUDSTACK-10443) CloudStack Terraform Provider - Add support for Kubernetes Clusters
David Jumani created CLOUDSTACK-10443: - Summary: CloudStack Terraform Provider - Add support for Kubernetes Clusters Key: CLOUDSTACK-10443 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10443 Project: CloudStack Issue Type: Improvement Reporter: David Jumani To provide easy access to VMs without the need for password-based authentication, Cloudstack provides users with the ability to set or reset an SSH key for their VMs. These SSH keys can either be uploaded to, or generated by cloudstack. As of now, it is limited to just a single SSH key. This requires the key to be shared amongst users with access to the VM and can be quite cumbersome when there are several VMs (perhaps across different projects), each with a different SSH key. It can also cause issues when a user is removed and the key needs to be reset since it's a common key, and shared to the remaining users all over again. This feature proposes extending the functionality to allow multiple SSH keys to be set / reset on a VM. This will allow users to add their own personal SSH key to the VM, thereby allowing them to directly access the VM without the need to manage multiple shared keys. New users can add their own keys to the list and access the VM instantly. It also solves the problem when a user is removed as their key can be removed from the list, thereby revoking their access without the need for a new key to be regenerated and shared. It proposes the following changes : # Modify the API to accept multiple SSH keys # Change the service layer that handles the request # Alter the database accordingly # Update the UI to align with the new API It requires the following relevant skills : * Java (basic) * SQL (basic) * Javascript (basic) * VueJS (Learning on the fly) Further details can be found here [https://github.com/apache/cloudstack/issues/4813] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CLOUDSTACK-10443) CloudStack Terraform Provider - Add support for Kubernetes Clusters
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jumani updated CLOUDSTACK-10443: -- Description: As of now the CloudStack Terraform Provider does not support managing CKS clusters This proposal aims to add support to the CloudStack Terraform Provider to manage CKS clusters This would involve supporting the following actions on CKS clusters : - Create - Stop / Start - Scale - Upgrade - Delete [Optional] Support the following actions on the binary ISOs : - Register - Enable / Disable - Delete ## Difficulty Medium ## Duration 175 hours ## Potential Mentors - Harikrishna Patnala - David Jumani ## References https://github.com/apache/cloudstack/issues/6040 was: To provide easy access to VMs without the need for password-based authentication, Cloudstack provides users with the ability to set or reset an SSH key for their VMs. These SSH keys can either be uploaded to, or generated by cloudstack. As of now, it is limited to just a single SSH key. This requires the key to be shared amongst users with access to the VM and can be quite cumbersome when there are several VMs (perhaps across different projects), each with a different SSH key. It can also cause issues when a user is removed and the key needs to be reset since it's a common key, and shared to the remaining users all over again. This feature proposes extending the functionality to allow multiple SSH keys to be set / reset on a VM. This will allow users to add their own personal SSH key to the VM, thereby allowing them to directly access the VM without the need to manage multiple shared keys. New users can add their own keys to the list and access the VM instantly. It also solves the problem when a user is removed as their key can be removed from the list, thereby revoking their access without the need for a new key to be regenerated and shared. It proposes the following changes : # Modify the API to accept multiple SSH keys # Change the service layer that handles the request # Alter the database accordingly # Update the UI to align with the new API It requires the following relevant skills : * Java (basic) * SQL (basic) * Javascript (basic) * VueJS (Learning on the fly) Further details can be found here [https://github.com/apache/cloudstack/issues/4813] > CloudStack Terraform Provider - Add support for Kubernetes Clusters > --- > > Key: CLOUDSTACK-10443 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10443 > Project: CloudStack > Issue Type: Improvement >Reporter: David Jumani >Priority: Major > Labels: gsoc2021, mentor > > As of now the CloudStack Terraform Provider does not support managing CKS > clusters > This proposal aims to add support to the CloudStack Terraform Provider to > manage CKS clusters > This would involve supporting the following actions on CKS clusters : > - Create > - Stop / Start > - Scale > - Upgrade > - Delete > [Optional] > Support the following actions on the binary ISOs : > - Register > - Enable / Disable > - Delete > ## Difficulty > Medium > ## Duration > 175 hours > ## Potential Mentors > - Harikrishna Patnala > - David Jumani > ## References > https://github.com/apache/cloudstack/issues/6040 > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CLOUDSTACK-10443) CloudStack Terraform Provider - Add support for Kubernetes Clusters
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jumani updated CLOUDSTACK-10443: -- Description: As of now the CloudStack Terraform Provider does not support managing CKS clusters This proposal aims to add support to the CloudStack Terraform Provider to manage CKS clusters This would involve supporting the following actions on CKS clusters : - Create - Stop / Start - Scale - Upgrade - Delete [Optional] Support the following actions on the binary ISOs : - Register - Enable / Disable - Delete *Duration* * 175 hours Potential Mentors - Harikrishna Patnala - David Jumani References * [https://github.com/apache/cloudstack/issues/6040] was: As of now the CloudStack Terraform Provider does not support managing CKS clusters This proposal aims to add support to the CloudStack Terraform Provider to manage CKS clusters This would involve supporting the following actions on CKS clusters : - Create - Stop / Start - Scale - Upgrade - Delete [Optional] Support the following actions on the binary ISOs : - Register - Enable / Disable - Delete ## Difficulty Medium ## Duration 175 hours ## Potential Mentors - Harikrishna Patnala - David Jumani ## References https://github.com/apache/cloudstack/issues/6040 > CloudStack Terraform Provider - Add support for Kubernetes Clusters > --- > > Key: CLOUDSTACK-10443 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10443 > Project: CloudStack > Issue Type: Improvement >Reporter: David Jumani >Priority: Major > Labels: gsoc2021, mentor > > As of now the CloudStack Terraform Provider does not support managing CKS > clusters > This proposal aims to add support to the CloudStack Terraform Provider to > manage CKS clusters > This would involve supporting the following actions on CKS clusters : > - Create > - Stop / Start > - Scale > - Upgrade > - Delete > [Optional] > Support the following actions on the binary ISOs : > - Register > - Enable / Disable > - Delete > > *Duration* > * 175 hours > > Potential Mentors > - Harikrishna Patnala > - David Jumani > References > * [https://github.com/apache/cloudstack/issues/6040] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CLOUDSTACK-10444) Make CloudStack aware of Unmanaged Kubernetes Clusters
David Jumani created CLOUDSTACK-10444: - Summary: Make CloudStack aware of Unmanaged Kubernetes Clusters Key: CLOUDSTACK-10444 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10444 Project: CloudStack Issue Type: Improvement Reporter: David Jumani As of now the CloudStack Terraform Provider does not support managing CKS clusters This proposal aims to add support to the CloudStack Terraform Provider to manage CKS clusters This would involve supporting the following actions on CKS clusters : - Create - Stop / Start - Scale - Upgrade - Delete [Optional] Support the following actions on the binary ISOs : - Register - Enable / Disable - Delete *Duration* * 175 hours Potential Mentors - Harikrishna Patnala - David Jumani References * [https://github.com/apache/cloudstack/issues/6040] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CLOUDSTACK-10444) Make CloudStack aware of Unmanaged Kubernetes Clusters
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jumani updated CLOUDSTACK-10444: -- Description: ClouStack Kubernetes Service [CKS] is CloudStack's own managed Kubernetes offering which users can use to deploy and manage Kubernetes Clusters from CloudStack. However, there might be cases in which users may want to deploy their own Virtual Machines and convert them into Kubernetes Nodes to run their own personally managed Kubernetes Clusters outside the scope of CloudStack. In such cases, CloudStack is unaware of these clusters and sees them as just a bunch of VMs running on its infrastructure. Although this might be acceptable, it would be a good idea for users to make CloudStack aware of the existing unmanaged Kubernetes Clusters and be able to view them in the UI or via an API Provide the ability to make CloudStack aware of these unmanaged Kubernetes Clusters Add / Modify existing API (and/or UI) support to : * Add an unmanaged Kubernetes Cluster * Update an unmanaged Kubernetes Cluster * Delete an unmanaged Kubernetes Cluster Duration * 175 hours Potential Mentors - David Jumani References * https://github.com/apache/cloudstack/issues/6036 was: As of now the CloudStack Terraform Provider does not support managing CKS clusters This proposal aims to add support to the CloudStack Terraform Provider to manage CKS clusters This would involve supporting the following actions on CKS clusters : - Create - Stop / Start - Scale - Upgrade - Delete [Optional] Support the following actions on the binary ISOs : - Register - Enable / Disable - Delete *Duration* * 175 hours Potential Mentors - Harikrishna Patnala - David Jumani References * [https://github.com/apache/cloudstack/issues/6040] > Make CloudStack aware of Unmanaged Kubernetes Clusters > -- > > Key: CLOUDSTACK-10444 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10444 > Project: CloudStack > Issue Type: Improvement >Reporter: David Jumani >Priority: Major > Labels: gsoc2021, mentor > > ClouStack Kubernetes Service [CKS] is CloudStack's own managed Kubernetes > offering which users can use to deploy and manage Kubernetes Clusters from > CloudStack. However, there might be cases in which users may want to deploy > their own Virtual Machines and convert them into Kubernetes Nodes to run > their own personally managed Kubernetes Clusters outside the scope of > CloudStack. > In such cases, CloudStack is unaware of these clusters and sees them as just > a bunch of VMs running on its infrastructure. Although this might be > acceptable, it would be a good idea for users to make CloudStack aware of the > existing unmanaged Kubernetes Clusters and be able to view them in the UI or > via an API > Provide the ability to make CloudStack aware of these unmanaged Kubernetes > Clusters > Add / Modify existing API (and/or UI) support to : > * Add an unmanaged Kubernetes Cluster > * Update an unmanaged Kubernetes Cluster > * Delete an unmanaged Kubernetes Cluster > > Duration > * 175 hours > > Potential Mentors > - David Jumani > > References > * https://github.com/apache/cloudstack/issues/6036 > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CLOUDSTACK-10445) Add the ability to Safely Shutdown / restart CloudStack
David Jumani created CLOUDSTACK-10445: - Summary: Add the ability to Safely Shutdown / restart CloudStack Key: CLOUDSTACK-10445 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10445 Project: CloudStack Issue Type: Improvement Reporter: David Jumani ClouStack Kubernetes Service [CKS] is CloudStack's own managed Kubernetes offering which users can use to deploy and manage Kubernetes Clusters from CloudStack. However, there might be cases in which users may want to deploy their own Virtual Machines and convert them into Kubernetes Nodes to run their own personally managed Kubernetes Clusters outside the scope of CloudStack. In such cases, CloudStack is unaware of these clusters and sees them as just a bunch of VMs running on its infrastructure. Although this might be acceptable, it would be a good idea for users to make CloudStack aware of the existing unmanaged Kubernetes Clusters and be able to view them in the UI or via an API Provide the ability to make CloudStack aware of these unmanaged Kubernetes Clusters Add / Modify existing API (and/or UI) support to : * Add an unmanaged Kubernetes Cluster * Update an unmanaged Kubernetes Cluster * Delete an unmanaged Kubernetes Cluster Duration * 175 hours Potential Mentors - David Jumani References * https://github.com/apache/cloudstack/issues/6036 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CLOUDSTACK-10446) View Logs in the UI
David Jumani created CLOUDSTACK-10446: - Summary: View Logs in the UI Key: CLOUDSTACK-10446 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10446 Project: CloudStack Issue Type: Improvement Reporter: David Jumani Shutting down / Restarting Cloudstack is a necessary step in upgrades, system maintenance, etc. As of now, there is no way to safely shutdown or restart CloudStack. It is directly terminated via systemd. Since this is the case, any asyncronous job or background task is abrubptly terminated and can fail. As of now, CloudStack maintains a list of asynchronous jobs wihtin it's database along with their status. This idea aims to provide a way to safely shutdown CloudStack. It involves two parts : * Prevent new asynchronous jobs from being added to CloudStack when a safe shutdown is triggered * Check the status of the async jobs and Shut down CloudStack when all the jobs have been completed Provide the ability to safely shutdown CloudStack Add API (and/or UI) support to : * Trigger a safe shutdown * (Optional) Support restarts * (Optional) Support a forced shutdown when CloudStack will quit even if there are async jobs running Duration * Some Experience : 175 hours * Newbie : 350 hours Potential Mentors - David Jumani References * https://github.com/apache/cloudstack/issues/6021 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CLOUDSTACK-10445) Add the ability to Safely Shutdown / restart CloudStack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jumani updated CLOUDSTACK-10445: -- Description: Shutting down / Restarting Cloudstack is a necessary step in upgrades, system maintenance, etc. As of now, there is no way to safely shutdown or restart CloudStack. It is directly terminated via systemd. Since this is the case, any asyncronous job or background task is abrubptly terminated and can fail. As of now, CloudStack maintains a list of asynchronous jobs wihtin it's database along with their status. This idea aims to provide a way to safely shutdown CloudStack. It involves two parts : * Prevent new asynchronous jobs from being added to CloudStack when a safe shutdown is triggered * Check the status of the async jobs and Shut down CloudStack when all the jobs have been completed Provide the ability to safely shutdown CloudStack Add API (and/or UI) support to : * Trigger a safe shutdown * (Optional) Support restarts * (Optional) Support a forced shutdown when CloudStack will quit even if there are async jobs running Duration * Some Experience : 175 hours * Newbie : 350 hours Potential Mentors - David Jumani References * https://github.com/apache/cloudstack/issues/6021 was: ClouStack Kubernetes Service [CKS] is CloudStack's own managed Kubernetes offering which users can use to deploy and manage Kubernetes Clusters from CloudStack. However, there might be cases in which users may want to deploy their own Virtual Machines and convert them into Kubernetes Nodes to run their own personally managed Kubernetes Clusters outside the scope of CloudStack. In such cases, CloudStack is unaware of these clusters and sees them as just a bunch of VMs running on its infrastructure. Although this might be acceptable, it would be a good idea for users to make CloudStack aware of the existing unmanaged Kubernetes Clusters and be able to view them in the UI or via an API Provide the ability to make CloudStack aware of these unmanaged Kubernetes Clusters Add / Modify existing API (and/or UI) support to : * Add an unmanaged Kubernetes Cluster * Update an unmanaged Kubernetes Cluster * Delete an unmanaged Kubernetes Cluster Duration * 175 hours Potential Mentors - David Jumani References * https://github.com/apache/cloudstack/issues/6036 > Add the ability to Safely Shutdown / restart CloudStack > --- > > Key: CLOUDSTACK-10445 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10445 > Project: CloudStack > Issue Type: Improvement >Reporter: David Jumani >Priority: Major > Labels: gsoc2021, mentor > > Shutting down / Restarting Cloudstack is a necessary step in upgrades, system > maintenance, etc. As of now, there is no way to safely shutdown or restart > CloudStack. It is directly terminated via systemd. Since this is the case, > any asyncronous job or background task is abrubptly terminated and can fail. > As of now, CloudStack maintains a list of asynchronous jobs wihtin it's > database along with their status. > This idea aims to provide a way to safely shutdown CloudStack. It involves > two parts : > * Prevent new asynchronous jobs from being added to CloudStack when a safe > shutdown is triggered > * Check the status of the async jobs and Shut down CloudStack when all the > jobs have been completed > > Provide the ability to safely shutdown CloudStack > Add API (and/or UI) support to : > * Trigger a safe shutdown > * (Optional) Support restarts > * (Optional) Support a forced shutdown when CloudStack will quit even if > there are async jobs running > > Duration > * Some Experience : 175 hours > * Newbie : 350 hours > > Potential Mentors > - David Jumani > > References > * https://github.com/apache/cloudstack/issues/6021 > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CLOUDSTACK-10446) View Logs in the UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jumani updated CLOUDSTACK-10446: -- Description: As of now, when an admin encounters an issue or error in CloudStack, the maximum information they can immediately get is the API failure response which provides a reason for the failure. At times this might not be sufficinet to diagnose the error and would require the admin to investiage the CloudStack logs. This would require the admin or the sysadmin to log into the VM running CloudStack and either view or export the logs, and then dive into identifying the issue. This idea aims to eiliminate that step. The goal of this is to provide admins the ability to view the logs directly in the UI. This would make diagnosing failures and RCAs much quicker. Provide the ability display the logs in the UI Add an API / WebSocket (and UI) support to : * View the logs * Live follow the logs (similar to 'tail -f') Duration * 175 hours Potential Mentors - David Jumani References * https://github.com/apache/cloudstack/issues/6011 was: Shutting down / Restarting Cloudstack is a necessary step in upgrades, system maintenance, etc. As of now, there is no way to safely shutdown or restart CloudStack. It is directly terminated via systemd. Since this is the case, any asyncronous job or background task is abrubptly terminated and can fail. As of now, CloudStack maintains a list of asynchronous jobs wihtin it's database along with their status. This idea aims to provide a way to safely shutdown CloudStack. It involves two parts : * Prevent new asynchronous jobs from being added to CloudStack when a safe shutdown is triggered * Check the status of the async jobs and Shut down CloudStack when all the jobs have been completed Provide the ability to safely shutdown CloudStack Add API (and/or UI) support to : * Trigger a safe shutdown * (Optional) Support restarts * (Optional) Support a forced shutdown when CloudStack will quit even if there are async jobs running Duration * Some Experience : 175 hours * Newbie : 350 hours Potential Mentors - David Jumani References * https://github.com/apache/cloudstack/issues/6021 > View Logs in the UI > --- > > Key: CLOUDSTACK-10446 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10446 > Project: CloudStack > Issue Type: Improvement >Reporter: David Jumani >Priority: Major > Labels: gsoc2021, mentor > > As of now, when an admin encounters an issue or error in CloudStack, the > maximum information they can immediately get is the API failure response > which provides a reason for the failure. At times this might not be > sufficinet to diagnose the error and would require the admin to investiage > the CloudStack logs. This would require the admin or the sysadmin to log into > the VM running CloudStack and either view or export the logs, and then dive > into identifying the issue. This idea aims to eiliminate that step. > The goal of this is to provide admins the ability to view the logs directly > in the UI. This would make diagnosing failures and RCAs much quicker. > Provide the ability display the logs in the UI > Add an API / WebSocket (and UI) support to : > * View the logs > * Live follow the logs (similar to 'tail -f') > > Duration > * 175 hours > > Potential Mentors > - David Jumani > > References > * https://github.com/apache/cloudstack/issues/6011 > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CLOUDSTACK-10429) Support Multiple SSH Keys for VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jumani updated CLOUDSTACK-10429: -- Labels: gsoc2022 mentor (was: gsoc2021 mentor) > Support Multiple SSH Keys for VMs > - > > Key: CLOUDSTACK-10429 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10429 > Project: CloudStack > Issue Type: Improvement >Reporter: David Jumani >Priority: Major > Labels: gsoc2022, mentor > > To provide easy access to VMs without the need for password-based > authentication, Cloudstack provides users with the ability to set or reset an > SSH key for their VMs. These SSH keys can either be uploaded to, or generated > by cloudstack. > As of now, it is limited to just a single SSH key. This requires the key to > be shared amongst users with access to the VM and can be quite cumbersome > when there are several VMs (perhaps across different projects), each with a > different SSH key. It can also cause issues when a user is removed and the > key needs to be reset since it's a common key, and shared to the remaining > users all over again. > This feature proposes extending the functionality to allow multiple SSH keys > to be set / reset on a VM. This will allow users to add their own personal > SSH key to the VM, thereby allowing them to directly access the VM without > the need to manage multiple shared keys. New users can add their own keys to > the list and access the VM instantly. It also solves the problem when a user > is removed as their key can be removed from the list, thereby revoking their > access without the need for a new key to be regenerated and shared. > It proposes the following changes : > # Modify the API to accept multiple SSH keys > # Change the service layer that handles the request > # Alter the database accordingly > # Update the UI to align with the new API > It requires the following relevant skills : > * Java (basic) > * SQL (basic) > * Javascript (basic) > * VueJS (Learning on the fly) > Further details can be found here > [https://github.com/apache/cloudstack/issues/4813] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CLOUDSTACK-10443) CloudStack Terraform Provider - Add support for Kubernetes Clusters
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jumani updated CLOUDSTACK-10443: -- Labels: gsoc2022 mentor (was: gsoc2021 mentor) > CloudStack Terraform Provider - Add support for Kubernetes Clusters > --- > > Key: CLOUDSTACK-10443 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10443 > Project: CloudStack > Issue Type: Improvement >Reporter: David Jumani >Priority: Major > Labels: gsoc2022, mentor > > As of now the CloudStack Terraform Provider does not support managing CKS > clusters > This proposal aims to add support to the CloudStack Terraform Provider to > manage CKS clusters > This would involve supporting the following actions on CKS clusters : > - Create > - Stop / Start > - Scale > - Upgrade > - Delete > [Optional] > Support the following actions on the binary ISOs : > - Register > - Enable / Disable > - Delete > > *Duration* > * 175 hours > > Potential Mentors > - Harikrishna Patnala > - David Jumani > References > * [https://github.com/apache/cloudstack/issues/6040] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CLOUDSTACK-10446) View Logs in the UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jumani updated CLOUDSTACK-10446: -- Labels: gsoc2022 mentor (was: gsoc2021 mentor) > View Logs in the UI > --- > > Key: CLOUDSTACK-10446 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10446 > Project: CloudStack > Issue Type: Improvement >Reporter: David Jumani >Priority: Major > Labels: gsoc2022, mentor > > As of now, when an admin encounters an issue or error in CloudStack, the > maximum information they can immediately get is the API failure response > which provides a reason for the failure. At times this might not be > sufficinet to diagnose the error and would require the admin to investiage > the CloudStack logs. This would require the admin or the sysadmin to log into > the VM running CloudStack and either view or export the logs, and then dive > into identifying the issue. This idea aims to eiliminate that step. > The goal of this is to provide admins the ability to view the logs directly > in the UI. This would make diagnosing failures and RCAs much quicker. > Provide the ability display the logs in the UI > Add an API / WebSocket (and UI) support to : > * View the logs > * Live follow the logs (similar to 'tail -f') > > Duration > * 175 hours > > Potential Mentors > - David Jumani > > References > * https://github.com/apache/cloudstack/issues/6011 > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CLOUDSTACK-10445) Add the ability to Safely Shutdown / restart CloudStack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jumani updated CLOUDSTACK-10445: -- Labels: gsoc2022 mentor (was: gsoc2021 mentor) > Add the ability to Safely Shutdown / restart CloudStack > --- > > Key: CLOUDSTACK-10445 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10445 > Project: CloudStack > Issue Type: Improvement >Reporter: David Jumani >Priority: Major > Labels: gsoc2022, mentor > > Shutting down / Restarting Cloudstack is a necessary step in upgrades, system > maintenance, etc. As of now, there is no way to safely shutdown or restart > CloudStack. It is directly terminated via systemd. Since this is the case, > any asyncronous job or background task is abrubptly terminated and can fail. > As of now, CloudStack maintains a list of asynchronous jobs wihtin it's > database along with their status. > This idea aims to provide a way to safely shutdown CloudStack. It involves > two parts : > * Prevent new asynchronous jobs from being added to CloudStack when a safe > shutdown is triggered > * Check the status of the async jobs and Shut down CloudStack when all the > jobs have been completed > > Provide the ability to safely shutdown CloudStack > Add API (and/or UI) support to : > * Trigger a safe shutdown > * (Optional) Support restarts > * (Optional) Support a forced shutdown when CloudStack will quit even if > there are async jobs running > > Duration > * Some Experience : 175 hours > * Newbie : 350 hours > > Potential Mentors > - David Jumani > > References > * https://github.com/apache/cloudstack/issues/6021 > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CLOUDSTACK-10444) Make CloudStack aware of Unmanaged Kubernetes Clusters
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jumani updated CLOUDSTACK-10444: -- Labels: gsoc2022 mentor (was: gsoc2021 mentor) > Make CloudStack aware of Unmanaged Kubernetes Clusters > -- > > Key: CLOUDSTACK-10444 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10444 > Project: CloudStack > Issue Type: Improvement >Reporter: David Jumani >Priority: Major > Labels: gsoc2022, mentor > > ClouStack Kubernetes Service [CKS] is CloudStack's own managed Kubernetes > offering which users can use to deploy and manage Kubernetes Clusters from > CloudStack. However, there might be cases in which users may want to deploy > their own Virtual Machines and convert them into Kubernetes Nodes to run > their own personally managed Kubernetes Clusters outside the scope of > CloudStack. > In such cases, CloudStack is unaware of these clusters and sees them as just > a bunch of VMs running on its infrastructure. Although this might be > acceptable, it would be a good idea for users to make CloudStack aware of the > existing unmanaged Kubernetes Clusters and be able to view them in the UI or > via an API > Provide the ability to make CloudStack aware of these unmanaged Kubernetes > Clusters > Add / Modify existing API (and/or UI) support to : > * Add an unmanaged Kubernetes Cluster > * Update an unmanaged Kubernetes Cluster > * Delete an unmanaged Kubernetes Cluster > > Duration > * 175 hours > > Potential Mentors > - David Jumani > > References > * https://github.com/apache/cloudstack/issues/6036 > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CLOUDSTACK-10429) Support Multiple SSH Keys for VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jumani updated CLOUDSTACK-10429: -- Labels: gsoc2021 mentor (was: gsoc2022 mentor) > Support Multiple SSH Keys for VMs > - > > Key: CLOUDSTACK-10429 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10429 > Project: CloudStack > Issue Type: Improvement >Reporter: David Jumani >Priority: Major > Labels: gsoc2021, mentor > > To provide easy access to VMs without the need for password-based > authentication, Cloudstack provides users with the ability to set or reset an > SSH key for their VMs. These SSH keys can either be uploaded to, or generated > by cloudstack. > As of now, it is limited to just a single SSH key. This requires the key to > be shared amongst users with access to the VM and can be quite cumbersome > when there are several VMs (perhaps across different projects), each with a > different SSH key. It can also cause issues when a user is removed and the > key needs to be reset since it's a common key, and shared to the remaining > users all over again. > This feature proposes extending the functionality to allow multiple SSH keys > to be set / reset on a VM. This will allow users to add their own personal > SSH key to the VM, thereby allowing them to directly access the VM without > the need to manage multiple shared keys. New users can add their own keys to > the list and access the VM instantly. It also solves the problem when a user > is removed as their key can be removed from the list, thereby revoking their > access without the need for a new key to be regenerated and shared. > It proposes the following changes : > # Modify the API to accept multiple SSH keys > # Change the service layer that handles the request > # Alter the database accordingly > # Update the UI to align with the new API > It requires the following relevant skills : > * Java (basic) > * SQL (basic) > * Javascript (basic) > * VueJS (Learning on the fly) > Further details can be found here > [https://github.com/apache/cloudstack/issues/4813] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CLOUDSTACK-10446) View Logs in the UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jumani updated CLOUDSTACK-10446: -- Issue Type: New Feature (was: Improvement) > View Logs in the UI > --- > > Key: CLOUDSTACK-10446 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10446 > Project: CloudStack > Issue Type: New Feature >Reporter: David Jumani >Priority: Major > Labels: gsoc2022, mentor > > As of now, when an admin encounters an issue or error in CloudStack, the > maximum information they can immediately get is the API failure response > which provides a reason for the failure. At times this might not be > sufficinet to diagnose the error and would require the admin to investiage > the CloudStack logs. This would require the admin or the sysadmin to log into > the VM running CloudStack and either view or export the logs, and then dive > into identifying the issue. This idea aims to eiliminate that step. > The goal of this is to provide admins the ability to view the logs directly > in the UI. This would make diagnosing failures and RCAs much quicker. > Provide the ability display the logs in the UI > Add an API / WebSocket (and UI) support to : > * View the logs > * Live follow the logs (similar to 'tail -f') > > Duration > * 175 hours > > Potential Mentors > - David Jumani > > References > * https://github.com/apache/cloudstack/issues/6011 > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CLOUDSTACK-10445) Add the ability to Safely Shutdown / restart CloudStack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jumani updated CLOUDSTACK-10445: -- Issue Type: New Feature (was: Improvement) > Add the ability to Safely Shutdown / restart CloudStack > --- > > Key: CLOUDSTACK-10445 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10445 > Project: CloudStack > Issue Type: New Feature >Reporter: David Jumani >Priority: Major > Labels: gsoc2022, mentor > > Shutting down / Restarting Cloudstack is a necessary step in upgrades, system > maintenance, etc. As of now, there is no way to safely shutdown or restart > CloudStack. It is directly terminated via systemd. Since this is the case, > any asyncronous job or background task is abrubptly terminated and can fail. > As of now, CloudStack maintains a list of asynchronous jobs wihtin it's > database along with their status. > This idea aims to provide a way to safely shutdown CloudStack. It involves > two parts : > * Prevent new asynchronous jobs from being added to CloudStack when a safe > shutdown is triggered > * Check the status of the async jobs and Shut down CloudStack when all the > jobs have been completed > > Provide the ability to safely shutdown CloudStack > Add API (and/or UI) support to : > * Trigger a safe shutdown > * (Optional) Support restarts > * (Optional) Support a forced shutdown when CloudStack will quit even if > there are async jobs running > > Duration > * Some Experience : 175 hours > * Newbie : 350 hours > > Potential Mentors > - David Jumani > > References > * https://github.com/apache/cloudstack/issues/6021 > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CLOUDSTACK-10444) Make CloudStack aware of Unmanaged Kubernetes Clusters
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jumani updated CLOUDSTACK-10444: -- Issue Type: New Feature (was: Improvement) > Make CloudStack aware of Unmanaged Kubernetes Clusters > -- > > Key: CLOUDSTACK-10444 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10444 > Project: CloudStack > Issue Type: New Feature >Reporter: David Jumani >Priority: Major > Labels: gsoc2022, mentor > > ClouStack Kubernetes Service [CKS] is CloudStack's own managed Kubernetes > offering which users can use to deploy and manage Kubernetes Clusters from > CloudStack. However, there might be cases in which users may want to deploy > their own Virtual Machines and convert them into Kubernetes Nodes to run > their own personally managed Kubernetes Clusters outside the scope of > CloudStack. > In such cases, CloudStack is unaware of these clusters and sees them as just > a bunch of VMs running on its infrastructure. Although this might be > acceptable, it would be a good idea for users to make CloudStack aware of the > existing unmanaged Kubernetes Clusters and be able to view them in the UI or > via an API > Provide the ability to make CloudStack aware of these unmanaged Kubernetes > Clusters > Add / Modify existing API (and/or UI) support to : > * Add an unmanaged Kubernetes Cluster > * Update an unmanaged Kubernetes Cluster > * Delete an unmanaged Kubernetes Cluster > > Duration > * 175 hours > > Potential Mentors > - David Jumani > > References > * https://github.com/apache/cloudstack/issues/6036 > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CLOUDSTACK-10444) Make CloudStack aware of Unmanaged Kubernetes Clusters
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jumani updated CLOUDSTACK-10444: -- Description: ClouStack Kubernetes Service [CKS] is CloudStack's own managed Kubernetes offering which users can use to deploy and manage Kubernetes Clusters from CloudStack. However, there might be cases in which users may want to deploy their own Virtual Machines and convert them into Kubernetes Nodes to run their own personally managed Kubernetes Clusters outside the scope of CloudStack. In such cases, CloudStack is unaware of these clusters and sees them as just a bunch of VMs running on its infrastructure. Although this might be acceptable, it would be a good idea for users to make CloudStack aware of the existing unmanaged Kubernetes Clusters and be able to view them in the UI or via an API Provide the ability to make CloudStack aware of these unmanaged Kubernetes Clusters Add / Modify existing API (and/or UI) support to : * Add an unmanaged Kubernetes Cluster * Update an unmanaged Kubernetes Cluster * Delete an unmanaged Kubernetes Cluster Duration * 175 hours Potential Mentors - David Jumani - Abhishek Kumar References * [https://github.com/apache/cloudstack/issues/6036] was: ClouStack Kubernetes Service [CKS] is CloudStack's own managed Kubernetes offering which users can use to deploy and manage Kubernetes Clusters from CloudStack. However, there might be cases in which users may want to deploy their own Virtual Machines and convert them into Kubernetes Nodes to run their own personally managed Kubernetes Clusters outside the scope of CloudStack. In such cases, CloudStack is unaware of these clusters and sees them as just a bunch of VMs running on its infrastructure. Although this might be acceptable, it would be a good idea for users to make CloudStack aware of the existing unmanaged Kubernetes Clusters and be able to view them in the UI or via an API Provide the ability to make CloudStack aware of these unmanaged Kubernetes Clusters Add / Modify existing API (and/or UI) support to : * Add an unmanaged Kubernetes Cluster * Update an unmanaged Kubernetes Cluster * Delete an unmanaged Kubernetes Cluster Duration * 175 hours Potential Mentors - David Jumani References * https://github.com/apache/cloudstack/issues/6036 > Make CloudStack aware of Unmanaged Kubernetes Clusters > -- > > Key: CLOUDSTACK-10444 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10444 > Project: CloudStack > Issue Type: New Feature >Reporter: David Jumani >Priority: Major > Labels: gsoc2022, mentor > > ClouStack Kubernetes Service [CKS] is CloudStack's own managed Kubernetes > offering which users can use to deploy and manage Kubernetes Clusters from > CloudStack. However, there might be cases in which users may want to deploy > their own Virtual Machines and convert them into Kubernetes Nodes to run > their own personally managed Kubernetes Clusters outside the scope of > CloudStack. > In such cases, CloudStack is unaware of these clusters and sees them as just > a bunch of VMs running on its infrastructure. Although this might be > acceptable, it would be a good idea for users to make CloudStack aware of the > existing unmanaged Kubernetes Clusters and be able to view them in the UI or > via an API > Provide the ability to make CloudStack aware of these unmanaged Kubernetes > Clusters > Add / Modify existing API (and/or UI) support to : > * Add an unmanaged Kubernetes Cluster > * Update an unmanaged Kubernetes Cluster > * Delete an unmanaged Kubernetes Cluster > > Duration > * 175 hours > > Potential Mentors > - David Jumani > - Abhishek Kumar > > References > * [https://github.com/apache/cloudstack/issues/6036] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CLOUDSTACK-10447) GSoC 2022: More granularity on affinity/anti-affinity groups
Nicolás Vázquez created CLOUDSTACK-10447: Summary: GSoC 2022: More granularity on affinity/anti-affinity groups Key: CLOUDSTACK-10447 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10447 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Components: API, Management Server Reporter: Nicolás Vázquez Currently, defining an affinity or anti-affinity rule works only at hosts level. I would like to have more detail on the affinity group, extending it at different levels (cluster, pod, zone,..) and also within the same level, being able to add or remove resources from the group. For hosts and storage pools, administrators can make use of host tags or storage tags to get a similar result. However, the extension of affinity/anti-affinity groups would make the administration easier. Size of the project: Medium (~175hs) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CLOUDSTACK-10447) GSoC 2022: More granularity on affinity/anti-affinity groups
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolás Vázquez updated CLOUDSTACK-10447: - External issue URL: https://github.com/apache/cloudstack/issues/6039 > GSoC 2022: More granularity on affinity/anti-affinity groups > > > Key: CLOUDSTACK-10447 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10447 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server >Reporter: Nicolás Vázquez >Priority: Major > Labels: gsoc2022 > > Currently, defining an affinity or anti-affinity rule works only at hosts > level. I would like to have more detail on the affinity group, extending it > at different levels (cluster, pod, zone,..) and also within the same level, > being able to add or remove resources from the group. > For hosts and storage pools, administrators can make use of host tags or > storage tags to get a similar result. However, the extension of > affinity/anti-affinity groups would make the administration easier. > Size of the project: Medium (~175hs) -- This message was sent by Atlassian Jira (v8.20.1#820001)
