Re: Dynamic roles

2017-06-13 Thread Rohit Yadav
Hi Christian, Based on the error logs, I believe they are not related with dynamic roles changes. If your admin/user accounts are able to login and execute APIs (via UI/CLI) then the migration script has worked. For checking if a particular role is allowed to execute a certain API, see the

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

2017-06-13 Thread Tutkowski, Mike
FYI: I located what was going on with VMware + managed storage. It looks like there was a feature that went in (at some point…not sure when) that added the ability to resize a root disk (so it doesn’t have to be the same size as the template it uses) when spinning up a VM. That code triggered

Re: [proposal] allow mac address to be specified for vm and nic creation

2017-06-13 Thread Nathan Johnson
Remi Bergsma wrote: > Hi Nathan, > > Great feature! I've also been in situations where we had to keep the mac > adress the same. Until now hacked the DB to make it happen, so this is > way better. Will see if I can test it in the coming days. Thanks Remi! Would

Re: [proposal] allow mac address to be specified for vm and nic creation

2017-06-13 Thread Remi Bergsma
Hi Nathan, Great feature! I've also been in situations where we had to keep the mac adress the same. Until now hacked the DB to make it happen, so this is way better. Will see if I can test it in the coming days. Thanks, Remi _ From: Nathan Johnson

Fw: Dynamic roles

2017-06-13 Thread Christian Aublet
Hi Rohit, I'm doing QA on 4.10.0.206 and I'm having issues with a Create template from snapshot operation. We are using XenServers 6.5 SP1. Secondary store is swift. I did ran the python script (migrate-dynamicroles.py) to update database with dynamic roles and validated that the global

Re: [proposal] allow mac address to be specified for vm and nic creation

2017-06-13 Thread Nathan Johnson
Ron Wheeler wrote: > Does the PR include the documentation changes required to use it? Currently this is API only, and the API annotations have been updated to show how it is used. Automatic documentation generation that is currently used to generate API

Re: [proposal] allow mac address to be specified for vm and nic creation

2017-06-13 Thread Ron Wheeler
Does the PR include the documentation changes required to use it? Networking is one of the areas where Cloudstack is hard to understand and difficult to get setup properly. Anything that adds another option increases the complexity. Making Cloudstack more difficult to install in order to

Re: [proposal] allow mac address to be specified for vm and nic creation

2017-06-13 Thread Nathan Johnson
Ron Wheeler wrote: > This would seem to violate the license agreement. > The license is supposed to be tied to specific hardware not a VM. > This sounds like something to be addressed legally rather than technically. > Possibly, but I don’t think that is so much

Re: [proposal] allow mac address to be specified for vm and nic creation

2017-06-13 Thread Ron Wheeler
This would seem to violate the license agreement. The license is supposed to be tied to specific hardware not a VM. This sounds like something to be addressed legally rather than technically. It adds more complexity to a part of Cloudstack that already seems to be a barrier to entry. Ron On

[proposal] allow mac address to be specified for vm and nic creation

2017-06-13 Thread Nathan Johnson
The title pretty much says it all. Currently mac addresses are automagically generated based on the guru that is responsible for the network type. This would allow that behavior to be overridden by the API on deployVirtualMachine and addNicToVirtualMachine . One potential issue is that

Re: [DISCUSS] Config Drive: Using the OpenStack format?

2017-06-13 Thread Kris Sterckx
Hi all, This topic has been further deepened and prototyped at Nuage Networks, and the earlier submitted design doc [1] has been updated with an OpenStack support section [2]. Note that we also provided PR's for CoreOS support. Here we use the original Cloudstack format as I don't think the

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

2017-06-13 Thread Daan Hoogland
this is why i say we should branch on first RC, fix in release branch only and merge forward On Tue, Jun 13, 2017 at 12:41 PM, Will Stevens wrote: > I know it is hard to justify not merging PRs that seem ready but are not > blockers in an RC, but it is a vicious circle

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

2017-06-13 Thread Will Stevens
I know it is hard to justify not merging PRs that seem ready but are not blockers in an RC, but it is a vicious circle which ultimately results in a longer RC process. It is something i struggled with as a release manager as well. On Jun 13, 2017 1:56 AM, "Rajani Karuturi"