On 02/14/2018 06:21 PM, Daan Hoogland wrote:
> the -x would only add it to the comment making it harder to find. As for
> multiple stable branches; merging forward always folows all branches
> forward so a fix on 4.9 would be merged forward to 4.10 and then 4.10 would
> be merged forward again to 4
Hi Sebastien,
Your points are noted; The plan is to make backups a first class citizen, so
their lifecycle is somewhat independent of the VM of that they are based on.
Users will be able to choose between policies (as defined by the vendor/Cloud
Operator), ad-hoc backups and scheduled backups (t
Thank you Paul, its a good proposal.
This is a really piece to get a global solution. I think that it should be
treated like load balancer, where Cloudstack offers a simple, but useful
solution, and Cloudstack allows to integrate dedicated solutions like F5.
In fact, Cloudstack just offers a glob
the -x would only add it to the comment making it harder to find. As for
multiple stable branches; merging forward always folows all branches
forward so a fix on 4.9 would be merged forward to 4.10 and then 4.10 would
be merged forward again to 4.11 and finally to master. of course there is
always
Hi Daan
On 02/14/2018 05:26 PM, Daan Hoogland wrote:
> Rene,
>
> The issue is certainly not due the git workflow but to upgrade schemes we
> have.
>
> The result of this workflow for us is that it is easier to find to which
> branches a particular commit is added as by merging forward the commit
Rene,
The issue is certainly not due the git workflow but to upgrade schemes we
have.
The result of this workflow for us is that it is easier to find to which
branches a particular commit is added as by merging forward the commit id
of the actual fix doesn't change. so instead of looking in each
Hi all
Thanks for taking care of this issue.
However, I wonder how we can prevent such issues in the future and
wondering if this "incident" has its orginos by our current git workflow.
I find the workflow "commit to stable branch --> merge back to master"
is inconvenient. Because at one point,
All,
Given there was no objection to the approach, the concerned PR has been merged
now. I've added a note to the release notes website for 4.10.0.0 users only.
4.11.1.0 will contain the fix, so in case 4.10.0.0 users want to upgrade, they
will not be required to manually run the sql/upgrade-
Hi Andrija,
the web interface does not allow to add / change tags for system VM
system offerings.
In a test system with the same configuration (as much as possible) I
added a new entry for the proxy console with the tags for the new
strorage and, after destroying the console VM, it was recrea
All,
Sending this on behalf of Gavin who has asked this to be shared on our
dev/user lists:
# Start #
The Travel Assistance Committee (TAC) are pleased to announce that travel
assistance applications for ApacheCon NA 2018 are now open!
We will be supporting ApacheCon NA Montreal, Canada on 24th
Hi Andrija
Wow - thanks for in-depth analysis! I already suspected HAProxy services
not hitting iptables chain.
Thanks for clarification, I see that the behaviour is EXPECTED, is it also
DESIRED?
Regards,
Samuel
11 matches
Mail list logo
