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" wrote:
Thanks Mike,
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 which ultimately results in
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 Clou
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 i
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 1
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 a cloudstack concern as the
use
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 circu
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 docs would pick this up.
>
> Networ
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 setting
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 mailto:njohn...@e
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 very much appreciate independ
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 an
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 rol
13 matches
Mail list logo
