: "Nux!"
To: dev@cloudstack.apache.org
Cc: "Daan Hoogland" , "John Kinsella"
, "int-cloud"
Sent: Thursday, 19 February, 2015 17:11:26
Subject: Re: [MERGE] Redundant VPC routers and persistent router config
Ian,
Thanks for the clarification and effort.
I'm trying to
pache.org
> Cc: "Daan Hoogland" , "John Kinsella"
> , "int-cloud"
>
> Sent: Thursday, 19 February, 2015 17:11:26
> Subject: Re: [MERGE] Redundant VPC routers and persistent router config
> Ian,
>
> Thanks for the clarification and effort.
&g
ssage -
> From: "Ian Southam"
> To: "Daan Hoogland"
> Cc: "dev" , "John Kinsella" ,
> "int-cloud"
> Sent: Thursday, 19 February, 2015 16:39:22
> Subject: Re: [MERGE] Redundant VPC routers and persistent router config
&g
Hi All,
We have had a discussion about this development in-house and have decided to
slow things down just a little. We just want a few days to get our own
integration test coverage better. We hope that way to be able to merge code
with a much fewer faults.
We do not however have the resourc
Good point Marcus. I'll look into that.
On Tue, Feb 17, 2015 at 9:38 PM, Marcus wrote:
> Yes, I just want to make sure that it doesn't require/assume
> persistency when some people rely on recreate.systemvm.enabled=true to
> provide clean/fresh systemvms with every reboot, consistent with the
> c
Yes, I just want to make sure that it doesn't require/assume
persistency when some people rely on recreate.systemvm.enabled=true to
provide clean/fresh systemvms with every reboot, consistent with the
cloud paradigm.
On Tue, Feb 17, 2015 at 12:09 PM, Daan Hoogland wrote:
> Yes, the delete works.
Yes, the delete works. Dont know if we included the option recreate in
our tests. Should not be a biggy though. It is not relevant for the
persistency.
On Tue, Feb 17, 2015 at 8:05 PM, Marcus wrote:
> But a recreate will still work, right? If you delete the router or set
> recreate.systemvm.enabl
But a recreate will still work, right? If you delete the router or set
recreate.systemvm.enabled=true it will still result in a working
router?
On Tue, Feb 17, 2015 at 11:05 AM, Daan Hoogland wrote:
> It means that cloudstack doesn't have to reconfigure them on reboot as
> they have the config on
It means that cloudstack doesn't have to reconfigure them on reboot as
they have the config on disk.
On Tue, Feb 17, 2015 at 4:16 PM, Marcus wrote:
> Can someone expand on what's meant by 'systemvm persistent config'?
> Somehow this makes me think that the systemvms would no longer be
> easily re
Hi Marcus,
Your review is awesomely welcome, Marcus - if such word exist. :)
Since this whole works was carried out along a few months, it was difficult to
split formatting, refactoring and functionality. But as you have noticed,
besides the Façade/Flyweight pattern applied to the ways command
I've browsed the code, and I don't really see anything
hypervisor-specific for KVM aside from a change to
VirtualRoutingResource to handle the new AbstractConfigItemFacade,
which looks like it's used to pass commands to the virtual router.
Assuming the VR can be configured, there aren't any changes
Can someone expand on what's meant by 'systemvm persistent config'?
Somehow this makes me think that the systemvms would no longer be
easily rebuildable.
On Tue, Feb 17, 2015 at 5:11 AM, Wilder Rodrigues
wrote:
> Hi there,
>
> I’m building a devcloud-kvm in order to test our changes with a differ
Wido, those were my thoughts as well. I haven't looked at the code
yet, but I'd be surprised if they had to change storage code (or even
hypervisor-specific code outside of passing along new VR script
Commands) in any way to accommodate a VR feature, so I hope this is
just caution. But enough guess
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/17/2015 02:19 PM, Daan Hoogland wrote:
> People,
>
> We are having some internal discussions about this code at
> Schuberg Philis. We are (most specifically I am) convinced that we
> cannot foresee the ways in which this can break master when
People,
We are having some internal discussions about this code at Schuberg
Philis. We are (most specifically I am) convinced that we cannot
foresee the ways in which this can break master when merged. We had
only one issue coming back from the community and this was functional
more then an issue.
Hi there,
I’m building a devcloud-kvm in order to test our changes with a different
environment as well.
Cheers,
Wilder
On 17 Feb 2015, at 01:46, Wilder Rodrigues
wrote:
> Hi all,
>
> I have been some tests on the branch in order to give you all some confidence.
>
> During the tests I fou
Hi all,
I have been some tests on the branch in order to give you all some confidence.
During the tests I found 1 bug related to communication from VM A on Tier 1 to
VM B on Tier 2 in a Single VPC. I can reproduce the bug and it disappears when
I convert the Single VPC to a redundant one. I alr
H,
I will merge our feature/systemvm-persistent-config into master. If
you have objections please let me know before tomorrow.
@john: your comment was addressed in the present day version.
--
Daan
Hi Karl,
On 12 Dec 2014, at 15:51, Karl Harris
mailto:karl.har...@sungardas.com>> wrote:
We have looked at the Java refactoring work. I seems most of that work was a
true refactoring in that it didn't change the interface used to manipulate the
systemvm's.
We could not find any posted changes
Daan,
Good to hear from you! Hope all is well.
Yes, we should talk, but I'm afraid my schedule is such that I cannot put a
meeting on the calendar until the new year.
We have looked at the Java refactoring work. I seems most of that work was
a true refactoring in that it didn't change the interf
H Karl, Did you have a look at the work going on @ Schuberg Philis
yet? It seems to me there is double work going on that is not
compatible to one another. our work is now at the branch
feature/systemvm-persistent-config-3 ('-3' because of the painful
rebase work we are having to do)
As things are
21 matches
Mail list logo
