if we don't use a wrapper we get PRs like
https://github.com/apache/cloudstack/pull/2276 in the future, trying to
update logging touches 1710 files. I think we should go for the wrapper
model on these kind of utilities.
On Thu, Jan 11, 2018 at 9:59 PM, Rafael Weingärtner <
rafaelweingart...@gmail.
Well, there is always other approaches...If we did not use those static
loggers, this number could be greatly reduced. Most of those objects are
singletons and we could use a protected attribute in the first element of
the hierarchy.
I do not mind a PR with this number of files changes as long as
+1!
Do you think it would be the right page to also have debian version used by
the ssvm?
For the management-server section the cloudstack column would list the last
acs version tested on that OS?
Le 11 janv. 2018 12 h 53, "Will Stevens" a écrit :
> I like this initiative. I think this would
+1 I've updated the page with upcoming Ubuntu 18.04 LTS.
After 4.11, I think 4.12 (assuming releases by mid of 2018) should remove
"declared" (they might still work with 4.12+ but in docs and by project we
should officially support them) support for following:
a. Hypervisor:
XenServer - 6.2,
Hi,
We need to start a architecture discussion about running SystemVM and
Virtual-Router as HVM instances in XenServer. With recent Meltdown-Spectre,
one of the mitigation step is currently to run VMs as HVM on XenServer to
self contain a user space attack from a guest OS.
Recent hotfix from Citr
It looks reasonable to manage VRs via management IP network. We should
focus on using the same work flow for different deployment scenarios.
On Fri, Jan 12, 2018 at 12:13 PM, Pierre-Luc Dion
wrote:
> Hi,
>
> We need to start a architecture discussion about running SystemVM and
> Virtual-Router
dom0 already has a DHCP server listening for requests on internal
management networks. I'd be wary trying to manage it from an external
service like cloudstack lest it get reset upon XenServer patch. This alone
makes me favor option #2. I also think option #2 simplifies network design
for users.
A
All,
We're down to one feature PR towards 4.11 milestone now:
https://github.com/apache/cloudstack/pull/2298
The config drive PR from Frank (Nuage) has been accepted today after no
regression test failures seen from yesterday's smoketest run. We've also
tested, reviewed and merge Wido's (blo
I believe there is no problem in merging Wido’s and Mike’s PRs, they have
been extensively discussed and improved (specially Mike’s one).
I noticed the merge of #2152 today morning, but crying over spilled milk
does not help anything… The code seems to be ok, maybe those variable names
`cmd` and `
i answers something similar to Rafael's answer here, on the PR itself.
On Fri, Jan 12, 2018 at 7:21 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:
> I believe there is no problem in merging Wido’s and Mike’s PRs, they have
> been extensively discussed and improved (specially Mike’s
The reason why we used link local in the first place was to isolate the VR
from directly accessing the management network. This provides another layer
of security in case of a VR exploit. This will also have a side effect of
making all VRs visible to each other. Are we okay accepting this?
Thanks,
but we are already using this design in vmware deployments (not sure about
KVM). The management network is already an isolated network only used by
system vms and ACS. Unless we are attacked by some internal agent, we are
safe from customer attack through management networks. Also, we can (if we
do
Thanks Rafael and Daan.
> From: Rafael Weingärtner
>
>I believe there is no problem in merging Wido’s and Mike’s PRs, they have
>been extensively discussed and improved (specially Mike’s one).
Thanks, Mike's PR has several regression smoketest failures and can be accepted
only when those failu
They do not. They receive a link-local ip address that is used for host agent
to VR communication. All VR commands are proxied through the host agent. Host
agent to VR communication is over SSH.
From: Rafael Weingärtner
Sent: Friday, January 12, 2018 1:42 PM
To
KVM uses a VirtIO channel to send information about the IP address and
other params to the SystemVMs. We could use a similar strategy in XenServer
using XenStore. This would involve minimal changes to the code while
keeping backward compatibility.
On Fri, Jan 12, 2018 at 3:07 PM, Simon Weller
w
I’m investigating these now. I have found and fixed two of them so far.
> On Jan 12, 2018, at 2:49 PM, Rohit Yadav wrote:
>
> Thanks Rafael and Daan.
>
>
>> From: Rafael Weingärtner
>>
>> I believe there is no problem in merging Wido’s and Mike’s PRs, they have
>> been extensively discussed
After some verification with Syed and Khosrow,
We found that we can use xenstore-read / xenstore-write to send data from
dom0 to domU which are in our case VRs or SVMs. Any reason not using this
approach ? that way we would not need a architectural change for XenServer
pods, and this would suppo
> We found that we can use xenstore-read / xenstore-write to send data from
dom0 to domU which are in our case VRs or SVMs. Any reason not using this
approach ?
xenstore has had some issues in the past. The most notable of which were
limitations on the number of event channels in use, followed by
18 matches
Mail list logo
