[jira] [Commented] (CLOUDSTACK-4858) Disable copy snapshot to secondary storage snapshot.backup.rightafter

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857536#comment-15857536
 ] 

ASF GitHub Bot commented on CLOUDSTACK-4858:


Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1697
  
merging this to 4.9+ branches


> Disable copy snapshot to secondary storage snapshot.backup.rightafter
> -
>
> Key: CLOUDSTACK-4858
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4858
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.2.0
> Environment: kvm, rbd
>Reporter: Sebastian Igerl
>
> "snapshot.backup.rightafterbackup"  is set to false but still the snapshot is 
> copied to secondary storage.
> Primary storage is Ceph/RDB, Secondary is NFS. I restarted both the 
> management server and the nodes.
> see : 
> http://www.marshut.com/wpviz/disable-copy-snapshot-to-secondary-storage-in-cs-4-2.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9738) Optimize vm expunge process for instances with vm snapshots

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857527#comment-15857527
 ] 

ASF subversion and git services commented on CLOUDSTACK-9738:
-

Commit e303baa1bf10e464d55b078d39cf3f42de1dc2c0 in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e303baa ]

Merge pull request #1905 from nvazquez/expungeVmRefactor

CLOUDSTACK-9738: [Vmware] Optimize vm expunge process for instances with vm 
snapshots## Description
It was noticed that expunging instances with many vm snapshots took a look of 
time, as hypervisor received as many tasks as vm snapshots instance had, apart 
from the delete vm task. We propose a way to optimize this process for 
instances with vm snapshots by sending only one delete task to hypervisor, 
which will delete vm and its snapshots

## Use cases

1. deleteVMsnapohsot-> no changes to current behavior
2. destroyVM with expunge=false ->  no actions to VMsnaphsot is performed at 
the moment. When VM cleanup thread is executed it will perform the same 
sequence as (3). If instance is recovered before expunged by the cleanup thread 
it will remain intact with VMSnapshot chain present
3. destroyVM with expunge=true:
   * Vmsnaphsot is marked with removed timestamp and state = Expunging in DB
   * VM is deleted in HW

* pr/1905:
  CLOUDSTACK-9738: [Vmware] Optimize vm expunge process for instances with vm 
snapshots

Signed-off-by: Rajani Karuturi 


> Optimize vm expunge process for instances with vm snapshots
> ---
>
> Key: CLOUDSTACK-9738
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9738
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0
>
>
> h2. Description
> It was noticed that expunging instances with many vm snapshots took a look of 
> time, as hypervisor received as many tasks as vm snapshots instance had, 
> apart from the delete vm task. We propose a way to optimize this process for 
> instances with vm snapshots by sending only one delete task to hypervisor, 
> which will delete vm and its snapshots
> h2. Use cases
> # deleteVMsnapohsot-> no changes to current behavior
> # destroyVM with expunge=false ->  no actions to VMsnaphsot is performed at 
> the moment. When VM cleanup thread is executed it will perform the same 
> sequence as #3. If instance is recovered before expunged by the cleanup 
> thread it will remain intact with VMSnapshot chain present
> # destroyVM with expunge=true:
> #*   Vmsnaphsot is  marked with removed timestamp and state = Expunging 
> in DB
> #*   VM is deleted in HW



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9738) Optimize vm expunge process for instances with vm snapshots

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857526#comment-15857526
 ] 

ASF subversion and git services commented on CLOUDSTACK-9738:
-

Commit e303baa1bf10e464d55b078d39cf3f42de1dc2c0 in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e303baa ]

Merge pull request #1905 from nvazquez/expungeVmRefactor

CLOUDSTACK-9738: [Vmware] Optimize vm expunge process for instances with vm 
snapshots## Description
It was noticed that expunging instances with many vm snapshots took a look of 
time, as hypervisor received as many tasks as vm snapshots instance had, apart 
from the delete vm task. We propose a way to optimize this process for 
instances with vm snapshots by sending only one delete task to hypervisor, 
which will delete vm and its snapshots

## Use cases

1. deleteVMsnapohsot-> no changes to current behavior
2. destroyVM with expunge=false ->  no actions to VMsnaphsot is performed at 
the moment. When VM cleanup thread is executed it will perform the same 
sequence as (3). If instance is recovered before expunged by the cleanup thread 
it will remain intact with VMSnapshot chain present
3. destroyVM with expunge=true:
   * Vmsnaphsot is marked with removed timestamp and state = Expunging in DB
   * VM is deleted in HW

* pr/1905:
  CLOUDSTACK-9738: [Vmware] Optimize vm expunge process for instances with vm 
snapshots

Signed-off-by: Rajani Karuturi 


> Optimize vm expunge process for instances with vm snapshots
> ---
>
> Key: CLOUDSTACK-9738
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9738
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0
>
>
> h2. Description
> It was noticed that expunging instances with many vm snapshots took a look of 
> time, as hypervisor received as many tasks as vm snapshots instance had, 
> apart from the delete vm task. We propose a way to optimize this process for 
> instances with vm snapshots by sending only one delete task to hypervisor, 
> which will delete vm and its snapshots
> h2. Use cases
> # deleteVMsnapohsot-> no changes to current behavior
> # destroyVM with expunge=false ->  no actions to VMsnaphsot is performed at 
> the moment. When VM cleanup thread is executed it will perform the same 
> sequence as #3. If instance is recovered before expunged by the cleanup 
> thread it will remain intact with VMSnapshot chain present
> # destroyVM with expunge=true:
> #*   Vmsnaphsot is  marked with removed timestamp and state = Expunging 
> in DB
> #*   VM is deleted in HW



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9738) Optimize vm expunge process for instances with vm snapshots

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857530#comment-15857530
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9738:


Github user asfgit closed the pull request at:

https://github.com/apache/cloudstack/pull/1905


> Optimize vm expunge process for instances with vm snapshots
> ---
>
> Key: CLOUDSTACK-9738
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9738
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0
>
>
> h2. Description
> It was noticed that expunging instances with many vm snapshots took a look of 
> time, as hypervisor received as many tasks as vm snapshots instance had, 
> apart from the delete vm task. We propose a way to optimize this process for 
> instances with vm snapshots by sending only one delete task to hypervisor, 
> which will delete vm and its snapshots
> h2. Use cases
> # deleteVMsnapohsot-> no changes to current behavior
> # destroyVM with expunge=false ->  no actions to VMsnaphsot is performed at 
> the moment. When VM cleanup thread is executed it will perform the same 
> sequence as #3. If instance is recovered before expunged by the cleanup 
> thread it will remain intact with VMSnapshot chain present
> # destroyVM with expunge=true:
> #*   Vmsnaphsot is  marked with removed timestamp and state = Expunging 
> in DB
> #*   VM is deleted in HW



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9738) Optimize vm expunge process for instances with vm snapshots

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857525#comment-15857525
 ] 

ASF subversion and git services commented on CLOUDSTACK-9738:
-

Commit 6ce6cf67f024e8e31d2ae2ab60fe1a758e42fcc3 in cloudstack's branch 
refs/heads/master from [~nvazquez]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6ce6cf6 ]

CLOUDSTACK-9738: [Vmware] Optimize vm expunge process for instances with vm 
snapshots


> Optimize vm expunge process for instances with vm snapshots
> ---
>
> Key: CLOUDSTACK-9738
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9738
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0
>
>
> h2. Description
> It was noticed that expunging instances with many vm snapshots took a look of 
> time, as hypervisor received as many tasks as vm snapshots instance had, 
> apart from the delete vm task. We propose a way to optimize this process for 
> instances with vm snapshots by sending only one delete task to hypervisor, 
> which will delete vm and its snapshots
> h2. Use cases
> # deleteVMsnapohsot-> no changes to current behavior
> # destroyVM with expunge=false ->  no actions to VMsnaphsot is performed at 
> the moment. When VM cleanup thread is executed it will perform the same 
> sequence as #3. If instance is recovered before expunged by the cleanup 
> thread it will remain intact with VMSnapshot chain present
> # destroyVM with expunge=true:
> #*   Vmsnaphsot is  marked with removed timestamp and state = Expunging 
> in DB
> #*   VM is deleted in HW



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9738) Optimize vm expunge process for instances with vm snapshots

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857524#comment-15857524
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9738:


Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1905
  
Thanks for the clarification. Its a nice enhancement. LGTM for the changes.
Marvin tests are always welcome :) 


> Optimize vm expunge process for instances with vm snapshots
> ---
>
> Key: CLOUDSTACK-9738
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9738
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0
>
>
> h2. Description
> It was noticed that expunging instances with many vm snapshots took a look of 
> time, as hypervisor received as many tasks as vm snapshots instance had, 
> apart from the delete vm task. We propose a way to optimize this process for 
> instances with vm snapshots by sending only one delete task to hypervisor, 
> which will delete vm and its snapshots
> h2. Use cases
> # deleteVMsnapohsot-> no changes to current behavior
> # destroyVM with expunge=false ->  no actions to VMsnaphsot is performed at 
> the moment. When VM cleanup thread is executed it will perform the same 
> sequence as #3. If instance is recovered before expunged by the cleanup 
> thread it will remain intact with VMSnapshot chain present
> # destroyVM with expunge=true:
> #*   Vmsnaphsot is  marked with removed timestamp and state = Expunging 
> in DB
> #*   VM is deleted in HW



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9457) Allow retrieval and modification of VM and template details via API and UI

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857503#comment-15857503
 ] 

ASF subversion and git services commented on CLOUDSTACK-9457:
-

Commit 202b92f2437ea0ebd575998bf7adc7d54aeb762e in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=202b92f ]

Merge pull request #1767 from nvazquez/userVmAndTemplatesDetails

CLOUDSTACK-9457: Allow retrieval and modification of VM and template details 
via API and UIJIRA TICKET: https://issues.apache.org/jira/browse/CLOUDSTACK-9457

### Goal
This PR proposes list/add/update/delete user vm and vm template details via API 
and UI.

### VM UI Screenshots
Setting tab is added on Instances page. Actions allowed are: Add/Edit/Remove
![](https://issues.apache.org/jira/secure/attachment/12844858/VMDetails1.JPG 
"Screenshot 1 - VM Details")

Settings tab is only shown if instance is Stopped:
![](https://issues.apache.org/jira/secure/attachment/12844859/VMDetailsRunning.JPG
 "Screenshot 2 - VM Details Hidden Running VM")
![](https://issues.apache.org/jira/secure/attachment/12844860/VMDetailsStopped.JPG
 "Screenshot 3 - VM Details Stopped VM")

### Templates UI Screenshots
Setting tab is added on Templates page. Actions allowed are: Add/Edit/Remove:
![](https://issues.apache.org/jira/secure/attachment/12844857/TemplateDetails1.JPG
 "Screenshot 4 - Template Details")

* pr/1767:
  CLOUDSTACK-9457: Allow retrieval and modification of VM and template details 
via API and UI

Signed-off-by: Rajani Karuturi 


> Allow retrieval and modification of VM and template details via API and UI
> --
>
> Key: CLOUDSTACK-9457
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9457
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.10.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>Priority: Minor
> Attachments: TemplateDetails1.JPG, VMDetails1.JPG, 
> VMDetailsRunning.JPG, VMDetailsStopped.JPG
>
>
> h2. Introduction
> As suggested on [9379|https://issues.apache.org/jira/browse/CLOUDSTACK-9379], 
> it would be nice to be able to customize vm details through API



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9457) Allow retrieval and modification of VM and template details via API and UI

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857505#comment-15857505
 ] 

ASF subversion and git services commented on CLOUDSTACK-9457:
-

Commit 202b92f2437ea0ebd575998bf7adc7d54aeb762e in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=202b92f ]

Merge pull request #1767 from nvazquez/userVmAndTemplatesDetails

CLOUDSTACK-9457: Allow retrieval and modification of VM and template details 
via API and UIJIRA TICKET: https://issues.apache.org/jira/browse/CLOUDSTACK-9457

### Goal
This PR proposes list/add/update/delete user vm and vm template details via API 
and UI.

### VM UI Screenshots
Setting tab is added on Instances page. Actions allowed are: Add/Edit/Remove
![](https://issues.apache.org/jira/secure/attachment/12844858/VMDetails1.JPG 
"Screenshot 1 - VM Details")

Settings tab is only shown if instance is Stopped:
![](https://issues.apache.org/jira/secure/attachment/12844859/VMDetailsRunning.JPG
 "Screenshot 2 - VM Details Hidden Running VM")
![](https://issues.apache.org/jira/secure/attachment/12844860/VMDetailsStopped.JPG
 "Screenshot 3 - VM Details Stopped VM")

### Templates UI Screenshots
Setting tab is added on Templates page. Actions allowed are: Add/Edit/Remove:
![](https://issues.apache.org/jira/secure/attachment/12844857/TemplateDetails1.JPG
 "Screenshot 4 - Template Details")

* pr/1767:
  CLOUDSTACK-9457: Allow retrieval and modification of VM and template details 
via API and UI

Signed-off-by: Rajani Karuturi 


> Allow retrieval and modification of VM and template details via API and UI
> --
>
> Key: CLOUDSTACK-9457
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9457
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.10.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>Priority: Minor
> Attachments: TemplateDetails1.JPG, VMDetails1.JPG, 
> VMDetailsRunning.JPG, VMDetailsStopped.JPG
>
>
> h2. Introduction
> As suggested on [9379|https://issues.apache.org/jira/browse/CLOUDSTACK-9379], 
> it would be nice to be able to customize vm details through API



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9457) Allow retrieval and modification of VM and template details via API and UI

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857506#comment-15857506
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9457:


Github user asfgit closed the pull request at:

https://github.com/apache/cloudstack/pull/1767


> Allow retrieval and modification of VM and template details via API and UI
> --
>
> Key: CLOUDSTACK-9457
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9457
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.10.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>Priority: Minor
> Attachments: TemplateDetails1.JPG, VMDetails1.JPG, 
> VMDetailsRunning.JPG, VMDetailsStopped.JPG
>
>
> h2. Introduction
> As suggested on [9379|https://issues.apache.org/jira/browse/CLOUDSTACK-9379], 
> it would be nice to be able to customize vm details through API



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9457) Allow retrieval and modification of VM and template details via API and UI

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857504#comment-15857504
 ] 

ASF subversion and git services commented on CLOUDSTACK-9457:
-

Commit 202b92f2437ea0ebd575998bf7adc7d54aeb762e in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=202b92f ]

Merge pull request #1767 from nvazquez/userVmAndTemplatesDetails

CLOUDSTACK-9457: Allow retrieval and modification of VM and template details 
via API and UIJIRA TICKET: https://issues.apache.org/jira/browse/CLOUDSTACK-9457

### Goal
This PR proposes list/add/update/delete user vm and vm template details via API 
and UI.

### VM UI Screenshots
Setting tab is added on Instances page. Actions allowed are: Add/Edit/Remove
![](https://issues.apache.org/jira/secure/attachment/12844858/VMDetails1.JPG 
"Screenshot 1 - VM Details")

Settings tab is only shown if instance is Stopped:
![](https://issues.apache.org/jira/secure/attachment/12844859/VMDetailsRunning.JPG
 "Screenshot 2 - VM Details Hidden Running VM")
![](https://issues.apache.org/jira/secure/attachment/12844860/VMDetailsStopped.JPG
 "Screenshot 3 - VM Details Stopped VM")

### Templates UI Screenshots
Setting tab is added on Templates page. Actions allowed are: Add/Edit/Remove:
![](https://issues.apache.org/jira/secure/attachment/12844857/TemplateDetails1.JPG
 "Screenshot 4 - Template Details")

* pr/1767:
  CLOUDSTACK-9457: Allow retrieval and modification of VM and template details 
via API and UI

Signed-off-by: Rajani Karuturi 


> Allow retrieval and modification of VM and template details via API and UI
> --
>
> Key: CLOUDSTACK-9457
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9457
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.10.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>Priority: Minor
> Attachments: TemplateDetails1.JPG, VMDetails1.JPG, 
> VMDetailsRunning.JPG, VMDetailsStopped.JPG
>
>
> h2. Introduction
> As suggested on [9379|https://issues.apache.org/jira/browse/CLOUDSTACK-9379], 
> it would be nice to be able to customize vm details through API



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9457) Allow retrieval and modification of VM and template details via API and UI

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857502#comment-15857502
 ] 

ASF subversion and git services commented on CLOUDSTACK-9457:
-

Commit e8049af1534f1ab2cc8335034c2fd76c67f9fdec in cloudstack's branch 
refs/heads/master from [~nicolas.vazquez]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e8049af ]

CLOUDSTACK-9457: Allow retrieval and modification of VM and template details 
via API and UI


> Allow retrieval and modification of VM and template details via API and UI
> --
>
> Key: CLOUDSTACK-9457
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9457
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.10.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>Priority: Minor
> Attachments: TemplateDetails1.JPG, VMDetails1.JPG, 
> VMDetailsRunning.JPG, VMDetailsStopped.JPG
>
>
> h2. Introduction
> As suggested on [9379|https://issues.apache.org/jira/browse/CLOUDSTACK-9379], 
> it would be nice to be able to customize vm details through API



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9731) Hardcoded label appears on the Add zone wizard

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857489#comment-15857489
 ] 

ASF subversion and git services commented on CLOUDSTACK-9731:
-

Commit 30aef289049abbec1ae5769723988ecc5bbe58b0 in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=30aef28 ]

Merge pull request #1892 from Accelerite/CLOUDSTACK-9731

CLOUDSTACK-9731: Hardcoded label appears on the Add zone wizardHardcoded label 
(label.remove.this.physical.network) appears on the Add zone wizard

* pr/1892:
  CLOUDSTACK-9731: Hardcoded label appears on the Add zone wizard

Signed-off-by: Rajani Karuturi 


> Hardcoded label appears on the Add zone wizard
> --
>
> Key: CLOUDSTACK-9731
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9731
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: 4.10.0.0
>
> Attachments: hardcoded_label.jpg
>
>
> Repro Steps: 
> 1. Setup basic environments as normal.
> 2. Open a browser, go to CloudStack Web Console.
> 3. Go on "Infrastructure" on left panel, choose Zone and click "View all".
> 4. Click on "Add Zone", choose "Advanced" and click "Next".
> 5. Input name and IPv4 NDS on "Setup Zone", click "next".
> 6. Add "Physical network 2", move mouse to "X" (close) button, check the tip.
> 7. Tip shows the label name: label.remove.this.physical.network.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9731) Hardcoded label appears on the Add zone wizard

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857485#comment-15857485
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9731:


Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1892
  
trivial. merged


> Hardcoded label appears on the Add zone wizard
> --
>
> Key: CLOUDSTACK-9731
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9731
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: 4.10.0.0
>
> Attachments: hardcoded_label.jpg
>
>
> Repro Steps: 
> 1. Setup basic environments as normal.
> 2. Open a browser, go to CloudStack Web Console.
> 3. Go on "Infrastructure" on left panel, choose Zone and click "View all".
> 4. Click on "Add Zone", choose "Advanced" and click "Next".
> 5. Input name and IPv4 NDS on "Setup Zone", click "next".
> 6. Add "Physical network 2", move mouse to "X" (close) button, check the tip.
> 7. Tip shows the label name: label.remove.this.physical.network.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9731) Hardcoded label appears on the Add zone wizard

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857487#comment-15857487
 ] 

ASF subversion and git services commented on CLOUDSTACK-9731:
-

Commit 30aef289049abbec1ae5769723988ecc5bbe58b0 in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=30aef28 ]

Merge pull request #1892 from Accelerite/CLOUDSTACK-9731

CLOUDSTACK-9731: Hardcoded label appears on the Add zone wizardHardcoded label 
(label.remove.this.physical.network) appears on the Add zone wizard

* pr/1892:
  CLOUDSTACK-9731: Hardcoded label appears on the Add zone wizard

Signed-off-by: Rajani Karuturi 


> Hardcoded label appears on the Add zone wizard
> --
>
> Key: CLOUDSTACK-9731
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9731
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: 4.10.0.0
>
> Attachments: hardcoded_label.jpg
>
>
> Repro Steps: 
> 1. Setup basic environments as normal.
> 2. Open a browser, go to CloudStack Web Console.
> 3. Go on "Infrastructure" on left panel, choose Zone and click "View all".
> 4. Click on "Add Zone", choose "Advanced" and click "Next".
> 5. Input name and IPv4 NDS on "Setup Zone", click "next".
> 6. Add "Physical network 2", move mouse to "X" (close) button, check the tip.
> 7. Tip shows the label name: label.remove.this.physical.network.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9731) Hardcoded label appears on the Add zone wizard

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857488#comment-15857488
 ] 

ASF subversion and git services commented on CLOUDSTACK-9731:
-

Commit 30aef289049abbec1ae5769723988ecc5bbe58b0 in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=30aef28 ]

Merge pull request #1892 from Accelerite/CLOUDSTACK-9731

CLOUDSTACK-9731: Hardcoded label appears on the Add zone wizardHardcoded label 
(label.remove.this.physical.network) appears on the Add zone wizard

* pr/1892:
  CLOUDSTACK-9731: Hardcoded label appears on the Add zone wizard

Signed-off-by: Rajani Karuturi 


> Hardcoded label appears on the Add zone wizard
> --
>
> Key: CLOUDSTACK-9731
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9731
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: 4.10.0.0
>
> Attachments: hardcoded_label.jpg
>
>
> Repro Steps: 
> 1. Setup basic environments as normal.
> 2. Open a browser, go to CloudStack Web Console.
> 3. Go on "Infrastructure" on left panel, choose Zone and click "View all".
> 4. Click on "Add Zone", choose "Advanced" and click "Next".
> 5. Input name and IPv4 NDS on "Setup Zone", click "next".
> 6. Add "Physical network 2", move mouse to "X" (close) button, check the tip.
> 7. Tip shows the label name: label.remove.this.physical.network.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9731) Hardcoded label appears on the Add zone wizard

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857486#comment-15857486
 ] 

ASF subversion and git services commented on CLOUDSTACK-9731:
-

Commit 9a2f3d95c1ba46ce0f52e6d409cdb1d2db902932 in cloudstack's branch 
refs/heads/master from [~sureshkumar.anaparti]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9a2f3d9 ]

CLOUDSTACK-9731: Hardcoded label appears on the Add zone wizard


> Hardcoded label appears on the Add zone wizard
> --
>
> Key: CLOUDSTACK-9731
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9731
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: 4.10.0.0
>
> Attachments: hardcoded_label.jpg
>
>
> Repro Steps: 
> 1. Setup basic environments as normal.
> 2. Open a browser, go to CloudStack Web Console.
> 3. Go on "Infrastructure" on left panel, choose Zone and click "View all".
> 4. Click on "Add Zone", choose "Advanced" and click "Next".
> 5. Input name and IPv4 NDS on "Setup Zone", click "next".
> 6. Add "Physical network 2", move mouse to "X" (close) button, check the tip.
> 7. Tip shows the label name: label.remove.this.physical.network.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9731) Hardcoded label appears on the Add zone wizard

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857490#comment-15857490
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9731:


Github user asfgit closed the pull request at:

https://github.com/apache/cloudstack/pull/1892


> Hardcoded label appears on the Add zone wizard
> --
>
> Key: CLOUDSTACK-9731
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9731
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: 4.10.0.0
>
> Attachments: hardcoded_label.jpg
>
>
> Repro Steps: 
> 1. Setup basic environments as normal.
> 2. Open a browser, go to CloudStack Web Console.
> 3. Go on "Infrastructure" on left panel, choose Zone and click "View all".
> 4. Click on "Add Zone", choose "Advanced" and click "Next".
> 5. Input name and IPv4 NDS on "Setup Zone", click "next".
> 6. Add "Physical network 2", move mouse to "X" (close) button, check the tip.
> 7. Tip shows the label name: label.remove.this.physical.network.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CLOUDSTACK-9777) decouple cloudstack UI

[Rajani Karuturi (JIRA)]

Rajani Karuturi created CLOUDSTACK-9777:
---

 Summary: decouple cloudstack UI
 Key: CLOUDSTACK-9777
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9777
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Rajani Karuturi


just like cloudmonkey, decouple cloudstack UI to a separate project.
It should be able to talk to any cloudstack endpoint 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CLOUDSTACK-8310) commit to commit db upgrades and db version control

[Rajani Karuturi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajani Karuturi updated CLOUDSTACK-8310:

Labels: gsoc2017  (was: gsoc2015)

> commit to commit db upgrades and db version control
> ---
>
> Key: CLOUDSTACK-8310
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8310
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rajani Karuturi
>  Labels: gsoc2017
>
> Cloudstack currently uses a homegrown tool to do the database upgrades. 
> The challenges with the current one being, it can only do version to version 
> but not commit to commit upgrades.
> Due to this, when different people work on the same branch and have db 
> changes, environment is broken untill you do fresh db deploy.
> To achieve this, we can use existing and well tested tools like liquibase, 
> flywaydb etc. or improve on the existing one. 
> Related discussions on dev lists
> http://markmail.org/thread/aicijeu6g5mzx4sc
> http://markmail.org/thread/r7wv36o356nolq7f



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9731) Hardcoded label appears on the Add zone wizard

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857462#comment-15857462
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9731:


Github user sureshanaparti commented on the issue:

https://github.com/apache/cloudstack/pull/1892
  
@koushik-das, UI screenshots of hardcoded label on the Add zone wizard and 
the UI fix for it are attached. Please check.


![hardcoded_label](https://cloud.githubusercontent.com/assets/12028987/22725141/4aefc006-edf1-11e6-9ea2-69b254dda030.jpg)


![fixed_hardcoded_label](https://cloud.githubusercontent.com/assets/12028987/22725179/bd234c42-edf1-11e6-8a9c-3aa4f4c44b2a.jpg)



> Hardcoded label appears on the Add zone wizard
> --
>
> Key: CLOUDSTACK-9731
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9731
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: 4.10.0.0
>
> Attachments: hardcoded_label.jpg
>
>
> Repro Steps: 
> 1. Setup basic environments as normal.
> 2. Open a browser, go to CloudStack Web Console.
> 3. Go on "Infrastructure" on left panel, choose Zone and click "View all".
> 4. Click on "Add Zone", choose "Advanced" and click "Next".
> 5. Input name and IPv4 NDS on "Setup Zone", click "next".
> 6. Add "Physical network 2", move mouse to "X" (close) button, check the tip.
> 7. Tip shows the label name: label.remove.this.physical.network.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857375#comment-15857375
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8862:


GitHub user anshul1886 reopened a pull request:

https://github.com/apache/cloudstack/pull/1900

CLOUDSTACK-8862: Introduced new state attaching for volume. This will…

… make sure that other attach operation on same volume will fail gracefully 
without calling access calls for managed storage like SolidFire

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/anshul1886/cloudstack-1 CLOUDSTACK-8862

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1900.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1900


commit 40d1a82bd9b7e799f269fcfbdfc4ec5923c189b2
Author: Anshul Gangwar 
Date:   2017-01-10T11:40:28Z

CLOUDSTACK-8862: Introduced new state attaching for volume. This will make 
sure that other attach operation on same volume will fail gracefully without 
calling access calls for managed storage like SolidFire




> Issuing multiple attach-volume commands simultaneously can be problematic
> -
>
> Key: CLOUDSTACK-8862
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8862
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0, 4.5.1, 4.5.2, 4.6.0
> Environment: N/A
>Reporter: Mike Tutkowski
> Fix For: Future
>
>
> If a user submits two volumeAttach commands around the same time, the first 
> one can succeed while the second one can fail and can lead CloudStack to ask 
> the underlying storage plug-in to remove the volume from a given ACL (but the 
> volume should be in the ACL because the first attachVolume command succeeded).
> A somewhat similar problem can happen if you submit the second attachVolume 
> command to another VM in the same cluster.
> Proposed solution:
> A data volume should make use of a new column in the volumes table: 
> attach_state (or some name like that).
> This column can have five possible values: null (for root disks), detached 
> (default state for data volumes), attaching, attached, and detaching.
> When an attachVolume command is submitted, the volume should immediately be 
> placed into the "attaching" state. If a transition to that state is not 
> possible, an exception is thrown (for example, if you're already in the 
> "attached" state, you can't transition to the "attaching" state).
> A similar kind of logic already exists for volume snapshots.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857374#comment-15857374
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8862:


Github user anshul1886 closed the pull request at:

https://github.com/apache/cloudstack/pull/1900


> Issuing multiple attach-volume commands simultaneously can be problematic
> -
>
> Key: CLOUDSTACK-8862
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8862
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0, 4.5.1, 4.5.2, 4.6.0
> Environment: N/A
>Reporter: Mike Tutkowski
> Fix For: Future
>
>
> If a user submits two volumeAttach commands around the same time, the first 
> one can succeed while the second one can fail and can lead CloudStack to ask 
> the underlying storage plug-in to remove the volume from a given ACL (but the 
> volume should be in the ACL because the first attachVolume command succeeded).
> A somewhat similar problem can happen if you submit the second attachVolume 
> command to another VM in the same cluster.
> Proposed solution:
> A data volume should make use of a new column in the volumes table: 
> attach_state (or some name like that).
> This column can have five possible values: null (for root disks), detached 
> (default state for data volumes), attaching, attached, and detaching.
> When an attachVolume command is submitted, the volume should immediately be 
> placed into the "attaching" state. If a transition to that state is not 
> possible, an exception is thrown (for example, if you're already in the 
> "attached" state, you can't transition to the "attaching" state).
> A similar kind of logic already exists for volume snapshots.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9574) Redesign storage views

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856920#comment-15856920
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9574:


Github user rafaelweingartner commented on the issue:

https://github.com/apache/cloudstack/pull/1747
  
@serg38 got it. 
Thanks for the explanation


> Redesign storage views
> --
>
> Key: CLOUDSTACK-9574
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9574
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, UI
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Attachments: PS-DETAILS.PNG, PS.PNG
>
>
> h2. Part 1: Redesign storage tags
> h3. Actual behavior
> Primary storage tags are being saved as an entry on {{storage_pool_details}} 
> with:
> * name = TAG_NAME
> * value = "true"
> When a boolean property is defined in {{storage_pool_details}} and has value 
> = "true", it is displayed as a tag.
> !https://issues.apache.org/jira/secure/attachment/12836196/PS-DETAILS.PNG!
> !https://issues.apache.org/jira/secure/attachment/12836195/PS.PNG!
> h3. Goal
> Redesign {{Storage Tags}} for Primary Storage view, to list only tags, as it 
> is done in Host Tags (Hosts view).
> h2. Part 2: Remove details from listImageStores API call response and UI
> h3. Description
> In Secondary Storage view we propose removing Details field, as Setting tab 
> list details for a given image store. We also remove details from response on 
> listImageStores API method



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9574) Redesign storage views

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856913#comment-15856913
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9574:


Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1747
  
@rafaelweingartner This PR is two fold.
1. This is something that was done a long ago for hosts and was never 
implemented for storage. It  transitions location of  of storage tags over to 
dedicated tables (storage_pool_tags) and converts current storage_tags to the 
new location so there should be no impact on current installation
2. For secondary storage there is no need to show details since they are 
coming from configurations  that now support ImageStore as Scope via PR1615. 
With that Details tag becomes obsolete.


> Redesign storage views
> --
>
> Key: CLOUDSTACK-9574
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9574
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, UI
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Attachments: PS-DETAILS.PNG, PS.PNG
>
>
> h2. Part 1: Redesign storage tags
> h3. Actual behavior
> Primary storage tags are being saved as an entry on {{storage_pool_details}} 
> with:
> * name = TAG_NAME
> * value = "true"
> When a boolean property is defined in {{storage_pool_details}} and has value 
> = "true", it is displayed as a tag.
> !https://issues.apache.org/jira/secure/attachment/12836196/PS-DETAILS.PNG!
> !https://issues.apache.org/jira/secure/attachment/12836195/PS.PNG!
> h3. Goal
> Redesign {{Storage Tags}} for Primary Storage view, to list only tags, as it 
> is done in Host Tags (Hosts view).
> h2. Part 2: Remove details from listImageStores API call response and UI
> h3. Description
> In Secondary Storage view we propose removing Details field, as Setting tab 
> list details for a given image store. We also remove details from response on 
> listImageStores API method



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9574) Redesign storage views

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856885#comment-15856885
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9574:


Github user rafaelweingartner commented on the issue:

https://github.com/apache/cloudstack/pull/1747
  
@nvazquez, @serg38, before checking code any deeper a have a more 
high-level question.

This PR will change the response of an API method, right? It will remove 
some data that today is being delivered to users. 

If I understood it properly, this data (storage tags) will be 
delivered/retrieved using another method. This may break compatibility with 
current clients that may use this information. If so, this break in 
compatibility has to be properly documented. Do you guys know how we could do 
this? Is there a protocol for this? Some alert on the release notes? Or maybe 
something on documentation pages?


> Redesign storage views
> --
>
> Key: CLOUDSTACK-9574
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9574
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, UI
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Attachments: PS-DETAILS.PNG, PS.PNG
>
>
> h2. Part 1: Redesign storage tags
> h3. Actual behavior
> Primary storage tags are being saved as an entry on {{storage_pool_details}} 
> with:
> * name = TAG_NAME
> * value = "true"
> When a boolean property is defined in {{storage_pool_details}} and has value 
> = "true", it is displayed as a tag.
> !https://issues.apache.org/jira/secure/attachment/12836196/PS-DETAILS.PNG!
> !https://issues.apache.org/jira/secure/attachment/12836195/PS.PNG!
> h3. Goal
> Redesign {{Storage Tags}} for Primary Storage view, to list only tags, as it 
> is done in Host Tags (Hosts view).
> h2. Part 2: Remove details from listImageStores API call response and UI
> h3. Description
> In Secondary Storage view we propose removing Details field, as Setting tab 
> list details for a given image store. We also remove details from response on 
> listImageStores API method



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9457) Allow retrieval and modification of VM and template details via API and UI

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856855#comment-15856855
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9457:


Github user rafaelweingartner commented on the issue:

https://github.com/apache/cloudstack/pull/1767
  
I have just reviewed the PR. There are only small suggestions I made.

BTW: from the Jira ticket 
https://issues.apache.org/jira/browse/CLOUDSTACK-9457, I ended up at 
https://issues.apache.org/jira/browse/CLOUDSTACK-9379, which is already done. I 
do not have permission to mark it as done. I believe @nvazquez might have.



> Allow retrieval and modification of VM and template details via API and UI
> --
>
> Key: CLOUDSTACK-9457
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9457
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.10.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>Priority: Minor
> Attachments: TemplateDetails1.JPG, VMDetails1.JPG, 
> VMDetailsRunning.JPG, VMDetailsStopped.JPG
>
>
> h2. Introduction
> As suggested on [9379|https://issues.apache.org/jira/browse/CLOUDSTACK-9379], 
> it would be nice to be able to customize vm details through API



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856802#comment-15856802
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9539:


Github user rafaelweingartner commented on the issue:

https://github.com/apache/cloudstack/pull/1727
  
Long time I do not review a PR here. I have to say, @nvazquez , great job!!
@serg38 you read my mind!! I had just started reading @nvazquez PR 
description when you called me.

Well documented methods. The methods are short and concise. The code is 
clear and looks nice (at least for me).

I jumped over the 70+ messages here. So, excuse me if I ask something that 
has already been clarified before.

However, as always I have something to complain; I might be getting old, 
that is probably why :) . Just teasing; it is more like a set of suggestion;

* On VMSnapshotVO, what about declaring the instance attribute you create 
as private? I know the others are not, and at the end of the day, it does not 
change much. However, as long as we are using Java and if we consider 
“VMSnapshotVO” as a POJO, then it feels a good idea to use private attributes 
that are only accessible to their gets/sets.
* On VMSnapshotManagerImpl, here we have a “service” layer 
object/component. I would have the same suggestion regarding the use of 
private/protected attributes here (this is cosmetics).
* Still on VMSnapshotManagerImpl, what about extracting the code from lines 
358-373 to a method? This may enable you to write unit test cases for these 
lines.
* Also on VMSnapshotManagerImpl, methods 
“addSupportForCustomServiceOffering”, “updateUserVmServiceOffering”, 
“getVmMapDetails”, “changeUserVmServiceOffering”, 
revertUserVmDetailsFromVmSnapshot, and “ugradeUserVmServiceOffering” are clean 
and well documented. However, I am missing their test cases. What about some 
test cases here, then it would be awesome.
* on VMSnapshotManagerImpl, the method “ugradeUserVmServiceOffering” seems 
to have a typo mistake ;)
* the method “revertUserVmDetailsFromVmSnapshot” receives a parameter 
“userVm”, but it does not seem to be used.

I am assuming you have executed the functional test “test_vm_snapshots.py” 
and it passed successfully, right?

Very good feature to be added. Thanks for the valuable contribution to ACS 
 





> Support changing Service offering for instance with VM Snapshots
> 
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which 
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which 
> have vm snapshots. In that case, previously taken snapshots (if reverted) 
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
> snapshot can be reverted to original state even though service offering can 
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id 
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as 
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9457) Allow retrieval and modification of VM and template details via API and UI

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856749#comment-15856749
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9457:


Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1767
  
LGTM


> Allow retrieval and modification of VM and template details via API and UI
> --
>
> Key: CLOUDSTACK-9457
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9457
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.10.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>Priority: Minor
> Attachments: TemplateDetails1.JPG, VMDetails1.JPG, 
> VMDetailsRunning.JPG, VMDetailsStopped.JPG
>
>
> h2. Introduction
> As suggested on [9379|https://issues.apache.org/jira/browse/CLOUDSTACK-9379], 
> it would be nice to be able to customize vm details through API



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9574) Redesign storage views

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856747#comment-15856747
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9574:


Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1747
  
@rafaelweingartner  Can you review this PR? 


> Redesign storage views
> --
>
> Key: CLOUDSTACK-9574
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9574
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, UI
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Attachments: PS-DETAILS.PNG, PS.PNG
>
>
> h2. Part 1: Redesign storage tags
> h3. Actual behavior
> Primary storage tags are being saved as an entry on {{storage_pool_details}} 
> with:
> * name = TAG_NAME
> * value = "true"
> When a boolean property is defined in {{storage_pool_details}} and has value 
> = "true", it is displayed as a tag.
> !https://issues.apache.org/jira/secure/attachment/12836196/PS-DETAILS.PNG!
> !https://issues.apache.org/jira/secure/attachment/12836195/PS.PNG!
> h3. Goal
> Redesign {{Storage Tags}} for Primary Storage view, to list only tags, as it 
> is done in Host Tags (Hosts view).
> h2. Part 2: Remove details from listImageStores API call response and UI
> h3. Description
> In Secondary Storage view we propose removing Details field, as Setting tab 
> list details for a given image store. We also remove details from response on 
> listImageStores API method



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856745#comment-15856745
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9539:


Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1727
  
@koushik-das @rhtyd @rafaelweingartner  Can you review changes @nvazquez 
put in place? CI tests are good.


> Support changing Service offering for instance with VM Snapshots
> 
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which 
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which 
> have vm snapshots. In that case, previously taken snapshots (if reverted) 
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
> snapshot can be reverted to original state even though service offering can 
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id 
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as 
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856743#comment-15856743
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9539:


Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1727
  
LGTM


> Support changing Service offering for instance with VM Snapshots
> 
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which 
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which 
> have vm snapshots. In that case, previously taken snapshots (if reverted) 
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
> snapshot can be reverted to original state even though service offering can 
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id 
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as 
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CLOUDSTACK-9776) extra DHCP option support

[Sigert Goeminne (JIRA)]

Sigert Goeminne created CLOUDSTACK-9776:
---

 Summary: extra DHCP option support
 Key: CLOUDSTACK-9776
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9776
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: API, Network Devices
Affects Versions: Future
Reporter: Sigert Goeminne
Assignee: Sigert Goeminne


Cloudstack currently does not allow users to set extra DHCP options. This 
feature will add support for adding extra (user defined) DHCP options on every 
nic of a VM in Cloudstack.
 
CloudStack currently supports the following DHCP options:
1: netmask
3: router
6: dns-server
15: domain name

[Design 
Document|https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+extra+DHCP+option+support]




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CLOUDSTACK-9775) ListInternalLBVMsCmd shows blank in UI although VM is there via api

[Raf Smeets (JIRA)]

Raf Smeets created CLOUDSTACK-9775:
--

 Summary: ListInternalLBVMsCmd shows blank in UI although VM is 
there via api
 Key: CLOUDSTACK-9775
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9775
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Affects Versions: 4.9.0
Reporter: Raf Smeets
 Attachments: InternalLBVMFail.png

ListInternalLBVMsCmd shows blank in the UI although LB VM is there via api
See attached UI screenshot.

{NOFORMAT}
[root@csc-1 ~]# cloudmonkey api listInternalLoadBalancerVMs 
zoneid=8f14b344-7080-4d1c-a37d-badbfb2e90c8 listAll=true
count = 3
internalloadbalancervm:
++--+---+---+--+-+--+--+--+---+--+---+--+---+-+-++--+--+--+-++--+--+-+---+--+--+--+-+---+--++---+++
| domain |   domainid   |  guestmacaddress  |  
linklocalip  |zoneid| linklocalmacaddress | 
 linklocalnetworkid  | linklocalnetmask |  id   
   | isredundantrouter |   guestnetworkname 
  | networkdomain |guestnetworkid|
hostname   |  state  | version |  role  |  
serviceofferingid   | zonename |podid | 




  nic   




| 
redundantstate |vpcid |  templateid 
 | requiresupgrade |  account  |
hostid|   name   | created  |   dns2  | 
 dns1 | vpcname  | 
hypervisor |  guestnetmask | guestipaddress |serviceofferingname
 |

[jira] [Commented] (CLOUDSTACK-9710) Switch to JDK 1.8

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15855594#comment-15855594
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9710:


Github user wido commented on the issue:

https://github.com/apache/cloudstack/pull/1888
  
@swill: Yes we should! I think that was an oversight. Can you send a PR for 
this against master?


> Switch to JDK 1.8
> -
>
> Key: CLOUDSTACK-9710
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9710
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.0.0
>
>
> Switch to using JDK1.8 by default for building and running CloudStack.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)