Re: proper place to put migrations
> Op 3 mei 2017 om 22:47 schreef Nathan Johnson : > > > I have created a JIRA bug here that will require the use of a migration to > fix. > > https://issues.apache.org/jira/browse/CLOUDSTACK-9902 > > What is the most appropriate branch to fork from to submit a PR in this > case, and what is the most appropriate migration script to edit (or create > a new one)? Is there going to be a new 4.9.x release? If so, what is the > next one called? 4.9.2.1 or 4.9.3.0 ? Or should this go against master > and just get added to schema-4920to41000.sql? > I think 4.9.3 will be released. You could put it into master I think and right now in 4920to41000.sql Wido > Thanks in advance > > Nathan Johnson > R&D Engineer > Education Networks of America >
Re: Very slow Virtual Router provisioning with 4.9.2.0
Thanks Daan, Remi. I found a additional bug where it seems that 'network.dns.basiczone.updates' isn't read when sending DHCP settings in Basic Networking. This means that the VR gets all DHCP setting for the whole zone instead of just for that POD. In this case some VRs we have get ~2k of DHCP offerings send to them which causes a large slowdown. Wido > Op 3 mei 2017 om 14:49 schreef Daan Hoogland : > > > Happy to pick this up, Remi. I'm travelling now but will look at both on > Friday. > > Biligual auto correct use. Read at your own risico > > On 3 May 2017 2:25 pm, "Remi Bergsma" wrote: > > > Always happy to share, but I won’t have time to work on porting this to > > CloudStack any time soon. > > > > Regards, Remi > > > > > > On 03/05/2017, 13:44, "Rohit Yadav" wrote: > > > > Hi Remi, thanks for sharing. We would love to have those changes (for > > 4.9+), looking forward to your pull requests. > > > > > > Regards. > > > > > > From: Remi Bergsma > > Sent: 03 May 2017 16:58:18 > > To: dev@cloudstack.apache.org > > Subject: Re: Very slow Virtual Router provisioning with 4.9.2.0 > > > > Hi, > > > > The patches I talked about: > > > > 1) Iptables speed improvement > > https://github.com/apache/cloudstack/pull/1482 > > Was reverted due to a licensing issue. > > > > 2) Passwd speed improvement > > https://github.com/MissionCriticalCloudOldRepos/cosmic-core/pull/138 > > > > By now, these are rather old patches so they need some work before > > they apply to CloudStack again. > > > > Regards, Remi > > > > > > > > On 03/05/2017, 12:49, "Jeff Hair" wrote: > > > > Hi Remi, > > > > Do you have a link to the PR that was reverted? And also possibly > > the code > > that makes the password updating more efficient? > > > > Jeff > > > > On Wed, May 3, 2017 at 10:36 AM, Remi Bergsma < > > rberg...@schubergphilis.com> > > wrote: > > > > > Hi Wido, > > > > > > When we had similar issues last year, we found that for example > > comparing > > > the iptables rules one-by-one is 1000x slower than simply > > loading them all > > > at once. Boris rewrote this part in our Cosmic fork, may be > > worth looking > > > into this again. The PR to CloudStack was merged, but reverted > > later, can't > > > remember why. We run it in production ever since. Also feeding > > passwords to > > > the passwd server is very inefficient (it operates like a > > snowball and gets > > > slower once you have more VMs). That we also fixed in Cosmic, > > not sure if > > > that patch made it upstream. Wrote it about a year ago already. > > > > > > We tested applying 10K iptables rules in just a couple of > > seconds. 1000 > > > VMs takes a few minutes to deploy. > > > > > > Generally speaking I'd suggest looking at the logs to find what > > takes long > > > or is executed a lot of times. Iptables and passwd are two to > > look at. > > > > > > If you want I can lookup the patches. Not handy on my phone now > > ;-) > > > > > > Regards, Remi > > > > > > From: Wido den Hollander > > > Sent: Tuesday, May 2, 2017 7:57:08 PM > > > To: dev@cloudstack.apache.org > > > Subject: Very slow Virtual Router provisioning with 4.9.2.0 > > > > > > Hi, > > > > > > Last night I upgraded a CloudStack 4.5.2 setup to 4.9.2.0. All > > went well, > > > but the VR provisioning is terribly slow which causes all kinds > > of problems. > > > > > > The vr_cfg.sh and update_config.py scripts start to run. Restart > > dnsmasq, > > > add metadata, etc. > > > > > > But for just 1800 hosts this can take up to 2 hours and that > > causes > > > timeouts in the management server and other problems. > > > > > > 2 hours is just very, very slow. So I am starting to wonder if > > something > > > is wrong here. > > > > > > Did anybody else see this? > > > > > > Running Basic Networking with CloudStack 4.9.2.0 > > > > > > Wido > > > > > > > > > > > > > rohit.ya...@shapeblue.com > > www.shapeblue.com > > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > > @shapeblue > > > > > > > > > > > >
Re: Very slow Virtual Router provisioning with 4.9.2.0
Hi Wido,
A simple improvement is, donot wait while restarting dnsmasq service in VR.
'''
diff --git a/systemvm/patches/debian/config/opt/cloud/bin/cs/CsDhcp.py
b/systemvm/patches/debian/config/opt/cloud/bin/cs/CsDhcp.py
index 95d2eff..999be8f 100755
--- a/systemvm/patches/debian/config/opt/cloud/bin/cs/CsDhcp.py
+++ b/systemvm/patches/debian/config/opt/cloud/bin/cs/CsDhcp.py
@@ -59,7 +59,7 @@ class CsDhcp(CsDataBag):
# We restart DNSMASQ every time the configure.py is called in
order to avoid lease problems.
if not self.cl.is_redundant() or self.cl.is_master():
-CsHelper.service("dnsmasq", "restart")
+CsHelper.execute3("service dnsmasq restart")
def configure_server(self):
# self.conf.addeq("dhcp-hostsfile=%s" % DHCP_HOSTS)
diff --git a/systemvm/patches/debian/config/opt/cloud/bin/cs/CsHelper.py
b/systemvm/patches/debian/config/opt/cloud/bin/cs/CsHelper.py
index a8ccea2..b06bde3 100755
--- a/systemvm/patches/debian/config/opt/cloud/bin/cs/CsHelper.py
+++ b/systemvm/patches/debian/config/opt/cloud/bin/cs/CsHelper.py
@@ -191,6 +191,11 @@ def execute2(command):
p.wait()
return p
+def execute3(command):
+""" Execute command """
+logging.debug("Executing: %s" % command)
+p = subprocess.Popen(command, stdout=subprocess.PIPE,
stderr=subprocess.PIPE, shell=True)
+return p
def service(name, op):
execute("service %s %s" % (name, op))
'''
-Wei
2017-05-04 10:48 GMT+02:00 Wido den Hollander :
> Thanks Daan, Remi.
>
> I found a additional bug where it seems that 'network.dns.basiczone.updates'
> isn't read when sending DHCP settings in Basic Networking.
>
> This means that the VR gets all DHCP setting for the whole zone instead of
> just for that POD.
>
> In this case some VRs we have get ~2k of DHCP offerings send to them which
> causes a large slowdown.
>
> Wido
>
> > Op 3 mei 2017 om 14:49 schreef Daan Hoogland :
> >
> >
> > Happy to pick this up, Remi. I'm travelling now but will look at both on
> > Friday.
> >
> > Biligual auto correct use. Read at your own risico
> >
> > On 3 May 2017 2:25 pm, "Remi Bergsma"
> wrote:
> >
> > > Always happy to share, but I won’t have time to work on porting this to
> > > CloudStack any time soon.
> > >
> > > Regards, Remi
> > >
> > >
> > > On 03/05/2017, 13:44, "Rohit Yadav" wrote:
> > >
> > > Hi Remi, thanks for sharing. We would love to have those changes
> (for
> > > 4.9+), looking forward to your pull requests.
> > >
> > >
> > > Regards.
> > >
> > >
> > > From: Remi Bergsma
> > > Sent: 03 May 2017 16:58:18
> > > To: dev@cloudstack.apache.org
> > > Subject: Re: Very slow Virtual Router provisioning with 4.9.2.0
> > >
> > > Hi,
> > >
> > > The patches I talked about:
> > >
> > > 1) Iptables speed improvement
> > > https://github.com/apache/cloudstack/pull/1482
> > > Was reverted due to a licensing issue.
> > >
> > > 2) Passwd speed improvement
> > > https://github.com/MissionCriticalCloudOldRepos/
> cosmic-core/pull/138
> > >
> > > By now, these are rather old patches so they need some work before
> > > they apply to CloudStack again.
> > >
> > > Regards, Remi
> > >
> > >
> > >
> > > On 03/05/2017, 12:49, "Jeff Hair" wrote:
> > >
> > > Hi Remi,
> > >
> > > Do you have a link to the PR that was reverted? And also
> possibly
> > > the code
> > > that makes the password updating more efficient?
> > >
> > > Jeff
> > >
> > > On Wed, May 3, 2017 at 10:36 AM, Remi Bergsma <
> > > rberg...@schubergphilis.com>
> > > wrote:
> > >
> > > > Hi Wido,
> > > >
> > > > When we had similar issues last year, we found that for
> example
> > > comparing
> > > > the iptables rules one-by-one is 1000x slower than simply
> > > loading them all
> > > > at once. Boris rewrote this part in our Cosmic fork, may be
> > > worth looking
> > > > into this again. The PR to CloudStack was merged, but
> reverted
> > > later, can't
> > > > remember why. We run it in production ever since. Also
> feeding
> > > passwords to
> > > > the passwd server is very inefficient (it operates like a
> > > snowball and gets
> > > > slower once you have more VMs). That we also fixed in Cosmic,
> > > not sure if
> > > > that patch made it upstream. Wrote it about a year ago
> already.
> > > >
> > > > We tested applying 10K iptables rules in just a couple of
> > > seconds. 1000
> > > > VMs takes a few minutes to deploy.
> > > >
> > > > Generally speaking I'd suggest looking at the logs to find
> what
> > > takes long
> > > > or is executed a lot of times. Iptables and passwd are two to
> > > look at.
> > > >
> > > > If you want I can lookup the patches. Not handy on my phone
> now
> > > ;-)
> > > >
> > > > Regards, Remi
> > >
Re: ovf file parser
The template generation related actions are better done on SSVM as they will be dealing/moving with various data/boot disks. Vim(VMWare infrastructure management), works with vCenter context and as such cannot be used inside SSVM. Vim gives a much better validation of OVF as it can make compatibility checks with vCenter. Currently it is part of vmware hypervisor plugin. Due to these dependency I ended parsing and generating OVF using standard dom api. Due to the nature of OVF we also ended up making several assumptions. Like the one that says the first disk is the boot disk. The few OVF file that I have seems to work for now. (Other than that the one OVA had second disk as boot disk). Though the OVF file does contain the OS of the VM but weirdly it does not link it to the disk that has it. Regards, -abhi On 03/05/17, 5:57 PM, "Will Stevens" wrote: >Cool. Let me know if you have questions. > >My instinct is that we probably want to keep the Ova manipulation in the >context of vmware since I don't believe it will be used outside that >context. Trying to manipulate the ovf files with generic tools may prove to >be more complicated to manage going forward as it is almost guaranteed to >require some 'hacks' to make it work. If we can avoid those by using the >vim jars, it may be worth it. I have not reviewed anything on the vim jars >side, so I don't know how good of an option that is. > >Are there key benefits to not using the vim jars? > >Cheers, > >Will > >On May 3, 2017 3:34 AM, "Abhinandan Prateek" < >abhinandan.prat...@shapeblue.com> wrote: > >> Hi Will, >> >>I am improving the multiple disk OVA feature. As part of revamp I am >> moving out some OVF manipulation code from the vmware hypervisor plugin >> context to secondary storage component. The existing code was using vim25 >> and managed objects to query and rewrite the OVF file. I have rewritten >> that, using standard java w3c dom parser. >> >>The overall flow is mostly similar and as below: >> 1. Decompress OVA and read the OVF file. OVF file will give information >> about various disks >> 3. Create the regular cloudstack template out for the boot disk and >> rewrite the OVF file, minus the information about other disks. >> 4. For each additional disk create data disk templates and capture the >> relationship in db. >> 5. This can then be followed by creating the multi-disk cloudstack VM. >> >> Essentially I am rewriting the original OVF file after removing the File >> and Disk information that refers to the other disks. Given that the the >> VMWare is picky, I think it will require some more cleanup and massaging. >> Your inputs will definitely help. >> >> Overall I think the two pieces, the tool that you have and the cloudstack >> multi disk OVA functionality can nicely complement each other. Will post my >> learning here. >> >> Thanks and regards, >> -abhi >> >> >> >> >> On 02/05/17, 6:05 PM, "williamstev...@gmail.com on behalf of Will >> Stevens" >> wrote: >> >> >Hey Abhinandan, >> >First, can you give us a bit more context regarding what you are doing so >> >we can highlight potential areas to watch out for? I have done some OVF >> >parsing/modification and there are a bunch of gotchas to be aware of. I >> >will try to outline some of the ones I found. I have not tried to use the >> >vim25.jar, so I can't really help on that front. >> > >> >In my use case, I was exporting VMs via the ovftool from a source VMware >> >environment, and I was migrating them to an ACS managed VMware >> >environment. In doing so, I also wanted to support VMs with multiple >> disks >> >using a Root volume and multiple Data volumes, as well as change the nic >> >type (vmxnet3), assign static IPs, etc... I have not had the time to open >> >source my migration tool, but it is on my todo list. >> > >> >My general flow was: >> >- Export the VM with ovftool >> >- Extract the resulting OVA into its parts (OVF, VMDKs, Manifest) >> >- Duplicate the OVF file, once per VMDK >> >- Modify a OVF file to be specific for each of the VMDKs (one OVF per >> VMDK) >> >- Take each VMDK and the corresponding OVF and recompress them back into >> an >> >OVA >> >- Treat the first OVA as a template and the rest as data disks >> > >> >My initial (naive) approach was to just treat the OVF as a well behaved >> XML >> >file and use standard XML libs (in my case in Python) to parse and >> >manipulate the OVF file. This approach had a few pitfalls which I will >> >outline here. >> > >> >VMware is VERY picky about the format of the OVF file, if the file is not >> >perfect, VMware won't import it (or at least the VM won't launch). There >> >were two main items which caused me issues. >> > >> >a) The tag MUST have all of the namespace definitions even if >> >they are not used in the file. This is something that most XML parsers >> are >> >confused by. Most XML parsers will only include the namespaces used in >> the >> >file when the file is saved. I had to ensure t
Re: Very slow Virtual Router provisioning with 4.9.2.0
Hi,
Yes, we are working on a few low hanging fruit fixes. Like checking if the last
restart of dnsmasq was < 10 sec ago. If so, skip the restart.
Will report back once we have anything.
Wido
> Op 4 mei 2017 om 11:11 schreef Wei ZHOU :
>
>
> Hi Wido,
>
> A simple improvement is, donot wait while restarting dnsmasq service in VR.
>
>
> '''
> diff --git a/systemvm/patches/debian/config/opt/cloud/bin/cs/CsDhcp.py
> b/systemvm/patches/debian/config/opt/cloud/bin/cs/CsDhcp.py
> index 95d2eff..999be8f 100755
> --- a/systemvm/patches/debian/config/opt/cloud/bin/cs/CsDhcp.py
> +++ b/systemvm/patches/debian/config/opt/cloud/bin/cs/CsDhcp.py
> @@ -59,7 +59,7 @@ class CsDhcp(CsDataBag):
>
> # We restart DNSMASQ every time the configure.py is called in
> order to avoid lease problems.
> if not self.cl.is_redundant() or self.cl.is_master():
> -CsHelper.service("dnsmasq", "restart")
> +CsHelper.execute3("service dnsmasq restart")
>
> def configure_server(self):
> # self.conf.addeq("dhcp-hostsfile=%s" % DHCP_HOSTS)
> diff --git a/systemvm/patches/debian/config/opt/cloud/bin/cs/CsHelper.py
> b/systemvm/patches/debian/config/opt/cloud/bin/cs/CsHelper.py
> index a8ccea2..b06bde3 100755
> --- a/systemvm/patches/debian/config/opt/cloud/bin/cs/CsHelper.py
> +++ b/systemvm/patches/debian/config/opt/cloud/bin/cs/CsHelper.py
> @@ -191,6 +191,11 @@ def execute2(command):
> p.wait()
> return p
>
> +def execute3(command):
> +""" Execute command """
> +logging.debug("Executing: %s" % command)
> +p = subprocess.Popen(command, stdout=subprocess.PIPE,
> stderr=subprocess.PIPE, shell=True)
> +return p
>
> def service(name, op):
> execute("service %s %s" % (name, op))
> '''
>
> -Wei
>
>
> 2017-05-04 10:48 GMT+02:00 Wido den Hollander :
>
> > Thanks Daan, Remi.
> >
> > I found a additional bug where it seems that 'network.dns.basiczone.updates'
> > isn't read when sending DHCP settings in Basic Networking.
> >
> > This means that the VR gets all DHCP setting for the whole zone instead of
> > just for that POD.
> >
> > In this case some VRs we have get ~2k of DHCP offerings send to them which
> > causes a large slowdown.
> >
> > Wido
> >
> > > Op 3 mei 2017 om 14:49 schreef Daan Hoogland :
> > >
> > >
> > > Happy to pick this up, Remi. I'm travelling now but will look at both on
> > > Friday.
> > >
> > > Biligual auto correct use. Read at your own risico
> > >
> > > On 3 May 2017 2:25 pm, "Remi Bergsma"
> > wrote:
> > >
> > > > Always happy to share, but I won’t have time to work on porting this to
> > > > CloudStack any time soon.
> > > >
> > > > Regards, Remi
> > > >
> > > >
> > > > On 03/05/2017, 13:44, "Rohit Yadav" wrote:
> > > >
> > > > Hi Remi, thanks for sharing. We would love to have those changes
> > (for
> > > > 4.9+), looking forward to your pull requests.
> > > >
> > > >
> > > > Regards.
> > > >
> > > >
> > > > From: Remi Bergsma
> > > > Sent: 03 May 2017 16:58:18
> > > > To: dev@cloudstack.apache.org
> > > > Subject: Re: Very slow Virtual Router provisioning with 4.9.2.0
> > > >
> > > > Hi,
> > > >
> > > > The patches I talked about:
> > > >
> > > > 1) Iptables speed improvement
> > > > https://github.com/apache/cloudstack/pull/1482
> > > > Was reverted due to a licensing issue.
> > > >
> > > > 2) Passwd speed improvement
> > > > https://github.com/MissionCriticalCloudOldRepos/
> > cosmic-core/pull/138
> > > >
> > > > By now, these are rather old patches so they need some work before
> > > > they apply to CloudStack again.
> > > >
> > > > Regards, Remi
> > > >
> > > >
> > > >
> > > > On 03/05/2017, 12:49, "Jeff Hair" wrote:
> > > >
> > > > Hi Remi,
> > > >
> > > > Do you have a link to the PR that was reverted? And also
> > possibly
> > > > the code
> > > > that makes the password updating more efficient?
> > > >
> > > > Jeff
> > > >
> > > > On Wed, May 3, 2017 at 10:36 AM, Remi Bergsma <
> > > > rberg...@schubergphilis.com>
> > > > wrote:
> > > >
> > > > > Hi Wido,
> > > > >
> > > > > When we had similar issues last year, we found that for
> > example
> > > > comparing
> > > > > the iptables rules one-by-one is 1000x slower than simply
> > > > loading them all
> > > > > at once. Boris rewrote this part in our Cosmic fork, may be
> > > > worth looking
> > > > > into this again. The PR to CloudStack was merged, but
> > reverted
> > > > later, can't
> > > > > remember why. We run it in production ever since. Also
> > feeding
> > > > passwords to
> > > > > the passwd server is very inefficient (it operates like a
> > > > snowball and gets
> > > > > slower once you have more VMs). That we also fixed in Cosmic,
> > > > not sure if
> > > > > that patch made it upstream. Wrote it about a year ago
> >
unable to download volume on cloudstack 4.6
Hi all, i'm not able to download a "volume" on cloudstack 4.6, having a 403 forbidden instead. I've just upgraded our cloudstack version to 4.6, so i'm performing a list of tests to confirm the usage is ok. My setup is the following one: - 1 x cloudstack managment server - 1 x bbdd server cloudstack database on it - 2 x Vmware Hipervisors (hosts) Everything went well until i tried: I'm having problems when i try to download a volume, cloudstack creates a link like this: Status Please click http://147.xxx.xxx.xxx/userdata/f7da105d-627d-473d-868d-bc33fa50777e.ova to download volume But it points to a directory instead of an "OVA" file, so it shows me a 403 forbidden on the browser instead of letting me download the file. That's what i see directly on the system VM: Symbolik link to the files: root@s-210-VM:/var/www/html/userdata# ls -lstha 4.0K lrwxrwxrwx 1 root root 99 May 4 10:12 f7da105d-627d-473d-868d-bc33fa50777e.ova -> /mnt/SecStorage/14fbc3c2-3302-3e50-b64e-71737bad431c/volumes/2/354/0c1f6612bee9482a8144276be07d317f As you can see, the path does not contain any OVA file, it's vmdk & .ovf stored instead: /mnt/SecStorage/14fbc3c2-3302-3e50-b64e-71737bad431c/volumes/2/354/0c1f6612bee9482a8144276be07d317f# ls -lstha total 84K 8.0K -rwxrwxrwx 1 root root 6.3K May 4 10:12 0c1f6612bee9482a8144276be07d317f.ovf 4.0K drwxrwxrwx 1 root root 168 May 4 10:12 . 68K -rwxrwxrwx 1 root root 67K May 4 10:12 0c1f6612bee9482a8144276be07d317f-disk0.vmdk Why is it happening? It does not happen on our old 4.5.2 version. Is there any way to fix it? changing any global parameter or permissions issue? We need a clue with that because if affecting to our production environment. Thanks in advance. Kind regards.
Re: Very slow Virtual Router provisioning with 4.9.2.0
Here we go: https://github.com/apache/cloudstack/pull/2077
That works really well for us. 70% less DHCP entries in our VR in Basic
Networking since only the entries for that POD are send to the VR.
Wido
> Op 4 mei 2017 om 12:12 schreef Wido den Hollander :
>
>
> Hi,
>
> Yes, we are working on a few low hanging fruit fixes. Like checking if the
> last restart of dnsmasq was < 10 sec ago. If so, skip the restart.
>
> Will report back once we have anything.
>
> Wido
>
> > Op 4 mei 2017 om 11:11 schreef Wei ZHOU :
> >
> >
> > Hi Wido,
> >
> > A simple improvement is, donot wait while restarting dnsmasq service in VR.
> >
> >
> > '''
> > diff --git a/systemvm/patches/debian/config/opt/cloud/bin/cs/CsDhcp.py
> > b/systemvm/patches/debian/config/opt/cloud/bin/cs/CsDhcp.py
> > index 95d2eff..999be8f 100755
> > --- a/systemvm/patches/debian/config/opt/cloud/bin/cs/CsDhcp.py
> > +++ b/systemvm/patches/debian/config/opt/cloud/bin/cs/CsDhcp.py
> > @@ -59,7 +59,7 @@ class CsDhcp(CsDataBag):
> >
> > # We restart DNSMASQ every time the configure.py is called in
> > order to avoid lease problems.
> > if not self.cl.is_redundant() or self.cl.is_master():
> > -CsHelper.service("dnsmasq", "restart")
> > +CsHelper.execute3("service dnsmasq restart")
> >
> > def configure_server(self):
> > # self.conf.addeq("dhcp-hostsfile=%s" % DHCP_HOSTS)
> > diff --git a/systemvm/patches/debian/config/opt/cloud/bin/cs/CsHelper.py
> > b/systemvm/patches/debian/config/opt/cloud/bin/cs/CsHelper.py
> > index a8ccea2..b06bde3 100755
> > --- a/systemvm/patches/debian/config/opt/cloud/bin/cs/CsHelper.py
> > +++ b/systemvm/patches/debian/config/opt/cloud/bin/cs/CsHelper.py
> > @@ -191,6 +191,11 @@ def execute2(command):
> > p.wait()
> > return p
> >
> > +def execute3(command):
> > +""" Execute command """
> > +logging.debug("Executing: %s" % command)
> > +p = subprocess.Popen(command, stdout=subprocess.PIPE,
> > stderr=subprocess.PIPE, shell=True)
> > +return p
> >
> > def service(name, op):
> > execute("service %s %s" % (name, op))
> > '''
> >
> > -Wei
> >
> >
> > 2017-05-04 10:48 GMT+02:00 Wido den Hollander :
> >
> > > Thanks Daan, Remi.
> > >
> > > I found a additional bug where it seems that
> > > 'network.dns.basiczone.updates'
> > > isn't read when sending DHCP settings in Basic Networking.
> > >
> > > This means that the VR gets all DHCP setting for the whole zone instead of
> > > just for that POD.
> > >
> > > In this case some VRs we have get ~2k of DHCP offerings send to them which
> > > causes a large slowdown.
> > >
> > > Wido
> > >
> > > > Op 3 mei 2017 om 14:49 schreef Daan Hoogland :
> > > >
> > > >
> > > > Happy to pick this up, Remi. I'm travelling now but will look at both on
> > > > Friday.
> > > >
> > > > Biligual auto correct use. Read at your own risico
> > > >
> > > > On 3 May 2017 2:25 pm, "Remi Bergsma"
> > > wrote:
> > > >
> > > > > Always happy to share, but I won’t have time to work on porting this
> > > > > to
> > > > > CloudStack any time soon.
> > > > >
> > > > > Regards, Remi
> > > > >
> > > > >
> > > > > On 03/05/2017, 13:44, "Rohit Yadav" wrote:
> > > > >
> > > > > Hi Remi, thanks for sharing. We would love to have those changes
> > > (for
> > > > > 4.9+), looking forward to your pull requests.
> > > > >
> > > > >
> > > > > Regards.
> > > > >
> > > > >
> > > > > From: Remi Bergsma
> > > > > Sent: 03 May 2017 16:58:18
> > > > > To: dev@cloudstack.apache.org
> > > > > Subject: Re: Very slow Virtual Router provisioning with 4.9.2.0
> > > > >
> > > > > Hi,
> > > > >
> > > > > The patches I talked about:
> > > > >
> > > > > 1) Iptables speed improvement
> > > > > https://github.com/apache/cloudstack/pull/1482
> > > > > Was reverted due to a licensing issue.
> > > > >
> > > > > 2) Passwd speed improvement
> > > > > https://github.com/MissionCriticalCloudOldRepos/
> > > cosmic-core/pull/138
> > > > >
> > > > > By now, these are rather old patches so they need some work before
> > > > > they apply to CloudStack again.
> > > > >
> > > > > Regards, Remi
> > > > >
> > > > >
> > > > >
> > > > > On 03/05/2017, 12:49, "Jeff Hair" wrote:
> > > > >
> > > > > Hi Remi,
> > > > >
> > > > > Do you have a link to the PR that was reverted? And also
> > > possibly
> > > > > the code
> > > > > that makes the password updating more efficient?
> > > > >
> > > > > Jeff
> > > > >
> > > > > On Wed, May 3, 2017 at 10:36 AM, Remi Bergsma <
> > > > > rberg...@schubergphilis.com>
> > > > > wrote:
> > > > >
> > > > > > Hi Wido,
> > > > > >
> > > > > > When we had similar issues last year, we found that for
> > > example
> > > > > comparing
> > > > > > the iptables rules one-by-one is 1000x slower than simply
> > > > > loading them all
> > > > >
Re: proper place to put migrations
Wido den Hollander wrote: > > I think 4.9.3 will be released. You could put it into master I think and > right now in 4920to41000.sql > > Wido Thank you. I have created a PR here: https://github.com/apache/cloudstack/pull/2078 So another question: In the past, whenever I would reference a JIRA bug in a github PR / commit message, they would get copied back into the JIRA ticket. This no longer seems to be happening. Is there some new requirement to get these mirrored back? Thanks, Nathan Johnson R&D Engineer Education Networks of America
