cloudstack-6476 - version for fix
Hi All, I'm running 4.3 and running into this: https://issues.apache.org/jira/browse/CLOUDSTACK-6476 I'm not sure though which version the fix for the above appears in, it says it affects 4.4.0 and is fixed in 4.4.0, but it doesn't appear in any "issues fixed in this release" section of the docs for any of the releases I have checked (4.4.0 onwards). I have also gone back and checked 4.3.1 and 4.3.2 but it is not mentioned there either. Can anyone confirm which versions it is fixed in? Thanks!
Re: cloudstack-6476 - version for fix
Hi Rajani, That's great, many thanks for replying, it is very much appreciated. Kind Regards On Wed, Mar 11, 2015 at 9:09 AM, Rajani Karuturi wrote: > Its in 4.4, 4.4.1 and 4.4.2 and all the forward releases. Its not in 4.3 > > $ git tag --contains 0b99822 > 4.4.0 > 4.4.1 > 4.4.2 > > > ~Rajani > > On Wed, Mar 11, 2015 at 1:55 PM, cs user wrote: > > > Hi All, > > > > I'm running 4.3 and running into this: > > https://issues.apache.org/jira/browse/CLOUDSTACK-6476 > > > > I'm not sure though which version the fix for the above appears in, it > says > > it affects 4.4.0 and is fixed in 4.4.0, but it doesn't appear in any > > "issues fixed in this release" section of the docs for any of the > releases > > I have checked (4.4.0 onwards). I have also gone back and checked 4.3.1 > and > > 4.3.2 but it is not mentioned there either. Can anyone confirm which > > versions it is fixed in? > > > > Thanks! > > >
Re: [DISCUSS] Support Docker as a hypervisor in CloudStack ( CloudStack / CLOUDSTACK-8205)
I'd really love to see this. CoreOS seems pretty well developed, with etcd and fleet. I envisage you would have clusters/pods of CoreOS machines with Cloudstack managing etcd discovery. Perhaps you could then define fleet unit files and have Cloudstack launch these on the CoreOS cluster. On Mon, Mar 16, 2015 at 8:45 AM, Nux! wrote: > I had a look at Atomic, the CentOS image should theoretically work with > Cloudstack; but in practice it does not (cloud-init fails). > When I'll get some more time I'll look more into it and perhaps we can get > that fixed. > > -- > Sent from the Delta quadrant using Borg technology! > > Nux! > www.nux.ro > > - Original Message - > > From: "Sebastien Goasguen" > > To: dev@cloudstack.apache.org > > Sent: Monday, 16 March, 2015 07:33:34 > > Subject: Re: [DISCUSS] Support Docker as a hypervisor in CloudStack ( > CloudStack / CLOUDSTACK-8205) > > >> On Mar 16, 2015, at 6:43 AM, Kishan Kavala > wrote: > >> > >> CoreOS is supported on CS. Templates are available here: > >> http://dl.openvm.eu/cloudstack/coreos/x86_64/ > >> > > > > There and on the official coreOS download site. It’s been available for > a while > > now. > > > > It would be very nice for someone to look at creating CS templates for > Atomic, > > Snappy and coreOS … > > > > We should have all docker minimal OS supported under CloudStack. > > > >> Still, I think it is working exploring Docker as a hypervisor also. > >> > >> Tuna stared some work on this earlier: > >> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Supporting+Docker+as+a+hypervisor > >> http://ngtuna.blogspot.in/2013/12/docker-in-cloudstack.html > >> > >> https://issues.apache.org/jira/browse/CLOUDSTACK-6664 > >> > >> > >> -Original Message- > >> From: Koushik Das [mailto:koushik@citrix.com] > >> Sent: Monday, March 16, 2015 10:49 AM > >> To: dev@cloudstack.apache.org > >> Subject: RE: [DISCUSS] Support Docker as a hypervisor in CloudStack ( > CloudStack > >> / CLOUDSTACK-8205) > >> > >> This is another alternate https://coreos.com/using-coreos/containers/. > CS needs > >> to support CoreOS. > >> > >> -Original Message- > >> From: Diwas Joshi [mailto:dj.dij...@gmail.com] > >> Sent: Monday, 16 March 2015 2:53 > >> To: dev@cloudstack.apache.org > >> Subject: [DISCUSS] Support Docker as a hypervisor in CloudStack ( > CloudStack / > >> CLOUDSTACK-8205) > >> > >> hello, I would like to work on the following issue for > >> https://issues.apache.org/jira/browse/CLOUDSTACK-8205 for google > summer of code > >> 2015. It would be really helpful if someone can tell me more about the > idea and > >> provide guidelines to get started with this. > >> > > > regards >
Re: WARNING for users migrating from Cloudstack 4.2 to 4.4.2
Hi Laurent,
Many many thanks for this. We had the exact same problem but using
xenserver as hosts. The fix for us was:
select name,broadcast_uri from networks where mode='Dhcp';
We were using basic networking as well.
We had upgraded from 4.3 to 4.4.2, using Xenserver 6.1.
Thank you!!!
On Mon, Feb 23, 2015 at 12:40 PM, Laurent Steff
wrote:
> Hi,
>
> This mail to share a fight we had at INRIA upgrading our Cloudstack/KVM
> farm
> from 4.2 to 4.4.2 following this documentation :
>
>
> http://cloudstack-release-notes.readthedocs.org/en/latest/upgrade/upgrade-4.2.html
>
> It's now solved, but I would like to share, as I think :
>
> - it could helps other people like us who have already migrated from
> Cloudstack 3.X to 4.X
> - there is one bug marked as fixed and it should not
> https://issues.apache.org/jira/browse/CLOUDSTACK-7399
> - a little documentation is missing (how to test if we have the good
> qemu-kvm version for systemVMs templates)
>
> Here are the (long) details
>
> Technical informations :
>
>
> - Upgrade from Cloudstack 4.2.1 to 4.4.2
> - CentOS 6/KVM for agents
> - official Cloudstack rpms
> - 1 zone with BasicNetworking
>
> We are using cloudstack here in two environnments :
>
> - qualification, with MS and agents created on 4.2.1
> - production, with MS and agents originally created on 3.x version, long
> time ago before
> Apache :D
>
>
> Qualification troubles and solution :
> -
>
> - systemVM do not start after cloudstack-sysvmadm launch
> - Solution was tu upgrade the KVM agents from Centos 6.3 to 6.6
> - we think (not sure) that we had a trouble with an historical qemu-kvm
> version, and a good test
> to document may be : what version of CentOS qemu-kvm supports, launching
> this command :
> ---
> /usr/libexec/qemu-kvm -M ?
> ---
>
>
> Production troubles and solution :
> --
>
> - cloudstack-sysvmadm takes hours to shutdown, upgrade and restart
> systemVM (2 or 3 hours)
> - starting/stopping existing instances works
> - but we're unable to create new instances (error on MS :
> ---
> com.cloud.exception.AgentUnavailableException: Resource [Host:xx] is
> unreachable: Host xx: Unable to start
> instance due to Unable to get answer that is of class
> com.cloud.agent.api.StartAnswer
> ---
> - when destroyed manually, systemVM won't restart
> - debug on agents shows the same message as this bug :
> https://issues.apache.org/jira/browse/CLOUDSTACK-7399
> which is officially resolved in 4.4.1 (our version is 4.4.2 !!!)
> ---
> WARN [cloud.agent.Agent] (agentRequest-Handler-2:null) Caught:
> java.lang.NullPointerException
> at
> com.cloud.network.Networks$BroadcastDomainType.getSchemeValue(Networks.java:159)
> ...
> DEBUG [cloud.agent.Agent] (agentRequest-Handler-2:null) Seq
> 25-6233544834234187813: { Ans: , MgmtId: 345044038925, via: 25, Ver: v1,
> Flags: 10,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"java.lang.NullPointerException\n\tat
> com.cloud.network.Networks$BroadcastDomainType.getSchemeValue(Networks.java:159)\n\tat
> com.cloud.network.Networks$BroadcastDomainType.getValue(Networks.java:213)\n\tat
> com.cloud.hypervisor.
> ...
> ---
> - we had to find our bascicnetwork in mysql table networks, whom
> broadcast_uri was NULL
> - and modify it to the "new" style vlan://untagged :
> ---
> update networks set broadcast_uri="vlan://untagged" where id="our
> bascinetwork id";
>
> Hope it could help,
>
> --
> Laurent Steff
>
> DSI/SESI
> INRIA
> http://www.inria.fr/
>
Re: WARNING for users migrating from Cloudstack 4.2 to 4.4.2
Just to clarify, the fix was:
update networks set broadcast_uri="vlan://untagged" where mode='Dhcp';
As these were set to null.
Sorry for the spam!
On Thu, Mar 26, 2015 at 12:31 PM, cs user wrote:
> Hi Laurent,
>
> Many many thanks for this. We had the exact same problem but using
> xenserver as hosts. The fix for us was:
>
> select name,broadcast_uri from networks where mode='Dhcp';
>
> We were using basic networking as well.
>
> We had upgraded from 4.3 to 4.4.2, using Xenserver 6.1.
>
> Thank you!!!
>
> On Mon, Feb 23, 2015 at 12:40 PM, Laurent Steff
> wrote:
>
>> Hi,
>>
>> This mail to share a fight we had at INRIA upgrading our Cloudstack/KVM
>> farm
>> from 4.2 to 4.4.2 following this documentation :
>>
>>
>> http://cloudstack-release-notes.readthedocs.org/en/latest/upgrade/upgrade-4.2.html
>>
>> It's now solved, but I would like to share, as I think :
>>
>> - it could helps other people like us who have already migrated from
>> Cloudstack 3.X to 4.X
>> - there is one bug marked as fixed and it should not
>> https://issues.apache.org/jira/browse/CLOUDSTACK-7399
>> - a little documentation is missing (how to test if we have the good
>> qemu-kvm version for systemVMs templates)
>>
>> Here are the (long) details
>>
>> Technical informations :
>>
>>
>> - Upgrade from Cloudstack 4.2.1 to 4.4.2
>> - CentOS 6/KVM for agents
>> - official Cloudstack rpms
>> - 1 zone with BasicNetworking
>>
>> We are using cloudstack here in two environnments :
>>
>> - qualification, with MS and agents created on 4.2.1
>> - production, with MS and agents originally created on 3.x version, long
>> time ago before
>> Apache :D
>>
>>
>> Qualification troubles and solution :
>> -
>>
>> - systemVM do not start after cloudstack-sysvmadm launch
>> - Solution was tu upgrade the KVM agents from Centos 6.3 to 6.6
>> - we think (not sure) that we had a trouble with an historical qemu-kvm
>> version, and a good test
>> to document may be : what version of CentOS qemu-kvm supports, launching
>> this command :
>> ---
>> /usr/libexec/qemu-kvm -M ?
>> ---
>>
>>
>> Production troubles and solution :
>> --
>>
>> - cloudstack-sysvmadm takes hours to shutdown, upgrade and restart
>> systemVM (2 or 3 hours)
>> - starting/stopping existing instances works
>> - but we're unable to create new instances (error on MS :
>> ---
>> com.cloud.exception.AgentUnavailableException: Resource [Host:xx] is
>> unreachable: Host xx: Unable to start
>> instance due to Unable to get answer that is of class
>> com.cloud.agent.api.StartAnswer
>> ---
>> - when destroyed manually, systemVM won't restart
>> - debug on agents shows the same message as this bug :
>> https://issues.apache.org/jira/browse/CLOUDSTACK-7399
>> which is officially resolved in 4.4.1 (our version is 4.4.2 !!!)
>> ---
>> WARN [cloud.agent.Agent] (agentRequest-Handler-2:null) Caught:
>> java.lang.NullPointerException
>> at
>> com.cloud.network.Networks$BroadcastDomainType.getSchemeValue(Networks.java:159)
>> ...
>> DEBUG [cloud.agent.Agent] (agentRequest-Handler-2:null) Seq
>> 25-6233544834234187813: { Ans: , MgmtId: 345044038925, via: 25, Ver: v1,
>> Flags: 10,
>> [{"com.cloud.agent.api.Answer":{"result":false,"details":"java.lang.NullPointerException\n\tat
>> com.cloud.network.Networks$BroadcastDomainType.getSchemeValue(Networks.java:159)\n\tat
>> com.cloud.network.Networks$BroadcastDomainType.getValue(Networks.java:213)\n\tat
>> com.cloud.hypervisor.
>> ...
>> ---
>> - we had to find our bascicnetwork in mysql table networks, whom
>> broadcast_uri was NULL
>> - and modify it to the "new" style vlan://untagged :
>> ---
>> update networks set broadcast_uri="vlan://untagged" where id="our
>> bascinetwork id";
>>
>> Hope it could help,
>>
>> --
>> Laurent Steff
>>
>> DSI/SESI
>> INRIA
>> http://www.inria.fr/
>>
>
>
Re: Simulator failing
Fix for this was to use this command: mvn -P simulator -pl :cloud-client-ui jetty:run And not: mvn -pl :cloud-client-ui jetty:run On Thu, Apr 2, 2015 at 2:42 PM, cs user wrote: > Hi All, > > I'm trying to run the simulator, I've tried with git tags 4.3, 4.3.2 and > 4.4.1. > > Each time I hit this error when adding a cluster. Adding a zone and pod > work fine. > > Deploy DC Started > Exception Occurred ['Traceback (most recent call last):\n', ' File > "marvin/deployDataCenter.py", line 185, in createClusters\n > clusterresponse = self.__apiClient.addCluster(clustercmd)\n', ' File > "/usr/lib/python2.6/site-packages/Marvin-4.4.1-py2.6.egg/marvin/cloudstackAPI/cloudstackAPIClient.py", > line 1506, in addCluster\nresponse = > self.connection.marvinRequest(command, response_type=response, > method=method)\n', ' File > "/usr/lib/python2.6/site-packages/Marvin-4.4.1-py2.6.egg/marvin/cloudstackConnection.py", > line 378, in marvinRequest\nraise e\n', 'CloudstackAPIException: > Execute cmd: addcluster failed, due to: errorCode: 431, errorText:Could not > find corresponding resource manager for simulator\n'] > > ===deploy dc failed, so cleaning the created entries=== > > Specifically : > errorCode: 431, errorText:Could not find corresponding resource manager > for simulator > > Has anyone seen this before? Is there a fix? > > This thread talks about commenting out references to simulator in > componentContext.xml > > > http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-dev/201302.mbox/%3c97f4356aea71904482cd192135c038f9011cc1d12...@banpmailbox01.citrite.net%3E > > But I've checked in there and I can't see any references. > > Cheers > > >
Simulator failing
Hi All, I'm trying to run the simulator, I've tried with git tags 4.3, 4.3.2 and 4.4.1. Each time I hit this error when adding a cluster. Adding a zone and pod work fine. Deploy DC Started Exception Occurred ['Traceback (most recent call last):\n', ' File "marvin/deployDataCenter.py", line 185, in createClusters\n clusterresponse = self.__apiClient.addCluster(clustercmd)\n', ' File "/usr/lib/python2.6/site-packages/Marvin-4.4.1-py2.6.egg/marvin/cloudstackAPI/cloudstackAPIClient.py", line 1506, in addCluster\nresponse = self.connection.marvinRequest(command, response_type=response, method=method)\n', ' File "/usr/lib/python2.6/site-packages/Marvin-4.4.1-py2.6.egg/marvin/cloudstackConnection.py", line 378, in marvinRequest\nraise e\n', 'CloudstackAPIException: Execute cmd: addcluster failed, due to: errorCode: 431, errorText:Could not find corresponding resource manager for simulator\n'] ===deploy dc failed, so cleaning the created entries=== Specifically : errorCode: 431, errorText:Could not find corresponding resource manager for simulator Has anyone seen this before? Is there a fix? This thread talks about commenting out references to simulator in componentContext.xml http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-dev/201302.mbox/%3c97f4356aea71904482cd192135c038f9011cc1d12...@banpmailbox01.citrite.net%3E But I've checked in there and I can't see any references. Cheers
Re: [DOCKER] cloudstack organisation
Thanks for creating this, much appreciated. Works great. It doesn't appear to have any zones/pods/hosts setup though, as you can do with the cloudstack simulator for the dev environment. Could we add some info on this page about how to run it and perhaps login? https://registry.hub.docker.com/u/apachecloudstack/simulator/ I was able to start it with the following: docker run -p 8080:8080 apachecloudstack/simulator Cheers! On Tue, Mar 24, 2015 at 7:29 PM, Pierre-Luc Dion wrote: > LOL, look like Docker support is efficient :-P > > I'll update jenkins jobs and destroy apachecloudstack org. > > Thanks! > > > > > On Tue, Mar 24, 2015 at 3:18 PM, Sebastien Goasguen > wrote: > > > PL, > > > > So my bad, I actually own the cloudstack org on Docker hub. I just added > > you as a member. > > You can publish your images there and delete the apachecloudstack org. I > > think it’s better to just use ‘cloudstack' > > > > > On Mar 24, 2015, at 2:26 PM, Pierre-Luc Dion > wrote: > > > > > > some addition inline: > > > > > > On Tue, Mar 24, 2015 at 9:13 AM, Sebastien Goasguen > > > wrote: > > > > > >> > > >>> On Mar 24, 2015, at 1:58 PM, Pierre-Luc Dion > > wrote: > > >>> > > >>> I've played a little with Docker over the weekend, here are some > > thought > > >>> and I'd like to have some input from community around this, > > >>> > > >>> 1. simulator: > > >>> I'v create a Jenkins[1] job that build a simulator container an push > it > > >> to > > >>> the docker org: apachecloudstack [2]. It is only done for master > branch > > >> at > > >>> the moment and the image is fairly big, ~2GB, using Sebastien's > > >> Dockerfile. > > >>> > > >> > > >> Cool. > > >> And yes the image is big, we can modify the Dockerfile to remove some > > >> maven stuff and make it smaller. > > >> Maybe even just run the jar like Ian has done for devcloud. > > >> > > >>> This will be perform for other branches but based on commit instead > of > > >>> daily, probably. > > >>> > > >>> 2. cloudstack-management + database > > >>> > > >>> As the current simulator image contain MySQL, Maven, CloudStack git > > >> repo,.. > > >>> it's quite big and not the "Docker" way, IMO. > > >> > > >> Correct. I just did it for devs…this is not meant for any type of prod > > >> > > > This should be clear that it is not for prod since the DB would have > been > > > pre-installed > > > > > > > > >>> So I'd like to see how it > > >>> would make sense provide two containers instead of one: > > >>> 1. cloudstack-database: mysql database with the initialized DB's > > (cloud, > > >>> cloud_usage)... > > >>> 2. cloudstack-management: pre installed cloudstack-management server > > >>> including tomcat dependencies,... > > >>> 3. cloudstack-usage: pre installed cloudstack-usage > > >>> > > >> > > >> You can create a mgt server image and then link it to two or one mysql > > >> containers. > > >> the mgt server image can be setup with the packages. > > >> > > >> I ran into problems with IP tables etc. since our setup scripts are > not > > >> meant for containers. > > > > > > I've experience this too, the container would be prepared without > > > "cloudstack-setup-management" as it expect to modify firewall which is > > not > > > available into container. > > > > > > > > >> > > >> > > >>> This imply that build of those containers would be done thru Jenkins > > for > > >>> the most part and use of Dockerfile might be difficult, which > wouldn't > > >>> allow to use dockers automatic builds. > > >>> > > >> > > >> you could have dockerfiles and an auto build in docker hub. > > >> Just use the build trigger in docker hub to setup a hook in the > jenkins > > >> job that builds the latest packages. > > >> > > > > > > The way I'm seeing things, because the DB would pre-initiated and > into a > > > separate container, I would not use dockerfile to build it, unless > there > > is > > > a way to create link at build, this is to provide the smallest > container > > as > > > possible. > > > > > > Also, I would use package (RPM,deb) to install cloudstack-management so > > it > > > will enforce the test/validation of packaging, and would make > containers > > > more close to prod like deployement. > > > > > > > > >> > > >> You could put the dockerfile in /tools or something > > > > > > Good Idea I'll place Dockerfiles into /tools/docker > > > > > > > > > > > >>> > > >>> > > >>> [1] > http://jenkins.buildacloud.org/job/build-master-simulator-docker/ > > >>> [2] https://registry.hub.docker.com/repos/apachecloudstack/ > > >>> > > >>> > > >>> On Fri, Mar 20, 2015 at 4:04 AM, Sebastien Goasguen < > run...@gmail.com> > > >>> wrote: > > >>> > > > > > On Mar 20, 2015, at 2:43 AM, Pierre-Luc Dion > > >> wrote: > > > > > > Look like some work as been done to have a Dockerfile in our repo > > which > > > build a CloudStack container easily. I'm curious to know if one of > us > > >> own > > > the cloudstack organisation and if so, if it would make sense to > > start
Re: [DOCKER] cloudstack organisation
Thanks Sebgoa, yes, pretty much. But for someone completely new to both docker and cloudstack, having all the steps you need to: 1. Start the container, with port mappings 2. Connect locally http://localhost:8080/client 3. Login details 4. Steps to attach to the container and use Marvin to setup the simulator Would be really useful I think, in the information tab on this page: https://registry.hub.docker.com/u/apachecloudstack/simulator/ People then searching for cloudstack on the docker registry would then have everything they need to fire up the container and have a play around. On Tue, Apr 7, 2015 at 10:22 AM, sebgoa wrote: > > On Apr 7, 2015, at 10:54 AM, cs user wrote: > > > Thanks for creating this, much appreciated. Works great. It doesn't > appear > > to have any zones/pods/hosts setup though, as you can do with the > > cloudstack simulator for the dev environment. > > > > Could we add some info on this page about how to run it and perhaps > login? > > > > I assume you mean, log into the container. the cloudstack ui works with > the usual password. > > > https://registry.hub.docker.com/u/apachecloudstack/simulator/ > > > > I was able to start it with the following: > > > > docker run -p 8080:8080 apachecloudstack/simulator > > so from there: > > docker exec -ti CONTAINER_ID bash > > and once in the container use Marvin to configure your zone. > > > > > > Cheers! > > > > On Tue, Mar 24, 2015 at 7:29 PM, Pierre-Luc Dion > wrote: > > > >> LOL, look like Docker support is efficient :-P > >> > >> I'll update jenkins jobs and destroy apachecloudstack org. > >> > >> Thanks! > >> > >> > >> > >> > >> On Tue, Mar 24, 2015 at 3:18 PM, Sebastien Goasguen > >> wrote: > >> > >>> PL, > >>> > >>> So my bad, I actually own the cloudstack org on Docker hub. I just > added > >>> you as a member. > >>> You can publish your images there and delete the apachecloudstack org. > I > >>> think it’s better to just use ‘cloudstack' > >>> > >>>> On Mar 24, 2015, at 2:26 PM, Pierre-Luc Dion > >> wrote: > >>>> > >>>> some addition inline: > >>>> > >>>> On Tue, Mar 24, 2015 at 9:13 AM, Sebastien Goasguen > > >>>> wrote: > >>>> > >>>>> > >>>>>> On Mar 24, 2015, at 1:58 PM, Pierre-Luc Dion > >>> wrote: > >>>>>> > >>>>>> I've played a little with Docker over the weekend, here are some > >>> thought > >>>>>> and I'd like to have some input from community around this, > >>>>>> > >>>>>> 1. simulator: > >>>>>> I'v create a Jenkins[1] job that build a simulator container an push > >> it > >>>>> to > >>>>>> the docker org: apachecloudstack [2]. It is only done for master > >> branch > >>>>> at > >>>>>> the moment and the image is fairly big, ~2GB, using Sebastien's > >>>>> Dockerfile. > >>>>>> > >>>>> > >>>>> Cool. > >>>>> And yes the image is big, we can modify the Dockerfile to remove some > >>>>> maven stuff and make it smaller. > >>>>> Maybe even just run the jar like Ian has done for devcloud. > >>>>> > >>>>>> This will be perform for other branches but based on commit instead > >> of > >>>>>> daily, probably. > >>>>>> > >>>>>> 2. cloudstack-management + database > >>>>>> > >>>>>> As the current simulator image contain MySQL, Maven, CloudStack git > >>>>> repo,.. > >>>>>> it's quite big and not the "Docker" way, IMO. > >>>>> > >>>>> Correct. I just did it for devs…this is not meant for any type of > prod > >>>>> > >>>> This should be clear that it is not for prod since the DB would have > >> been > >>>> pre-installed > >>>> > >>>> > >>>>>> So I'd like to see how it > >>>>>> would make sense provide two containers instead of one: > >>>>>> 1. cloudstack-database: mysql database with the initialized DB's > >>&
Re: [DOCKER] cloudstack organisation
Fantastic, thank you! On Wed, Apr 8, 2015 at 3:25 AM, Pierre-Luc Dion wrote: > Please note, the org: apachecloudstack as been removed and is now > available at: > > https://registry.hub.docker.com/u/cloudstack/simulator > > tags, latest and 4.5 are automatically build on jenkins > thru build-master-simulator-docker and build-4.5-simulator-docker jobs > > readme also updated. > > > On Tue, Apr 7, 2015 at 7:13 AM, cs user wrote: > > > Thanks Sebgoa, yes, pretty much. But for someone completely new to both > > docker and cloudstack, having all the steps you need to: > > > > 1. Start the container, with port mappings > > 2. Connect locally http://localhost:8080/client > > 3. Login details > > 4. Steps to attach to the container and use Marvin to setup the simulator > > > > Would be really useful I think, in the information tab on this page: > > https://registry.hub.docker.com/u/apachecloudstack/simulator/ > > > > People then searching for cloudstack on the docker registry would then > have > > everything they need to fire up the container and have a play around. > > > > > > > > On Tue, Apr 7, 2015 at 10:22 AM, sebgoa wrote: > > > > > > > > On Apr 7, 2015, at 10:54 AM, cs user wrote: > > > > > > > Thanks for creating this, much appreciated. Works great. It doesn't > > > appear > > > > to have any zones/pods/hosts setup though, as you can do with the > > > > cloudstack simulator for the dev environment. > > > > > > > > Could we add some info on this page about how to run it and perhaps > > > login? > > > > > > > > > > I assume you mean, log into the container. the cloudstack ui works with > > > the usual password. > > > > > > > https://registry.hub.docker.com/u/apachecloudstack/simulator/ > > > > > > > > I was able to start it with the following: > > > > > > > > docker run -p 8080:8080 apachecloudstack/simulator > > > > > > so from there: > > > > > > docker exec -ti CONTAINER_ID bash > > > > > > and once in the container use Marvin to configure your zone. > > > > > > > > > > > > > > Cheers! > > > > > > > > On Tue, Mar 24, 2015 at 7:29 PM, Pierre-Luc Dion > > > > wrote: > > > > > > > >> LOL, look like Docker support is efficient :-P > > > >> > > > >> I'll update jenkins jobs and destroy apachecloudstack org. > > > >> > > > >> Thanks! > > > >> > > > >> > > > >> > > > >> > > > >> On Tue, Mar 24, 2015 at 3:18 PM, Sebastien Goasguen < > run...@gmail.com > > > > > > >> wrote: > > > >> > > > >>> PL, > > > >>> > > > >>> So my bad, I actually own the cloudstack org on Docker hub. I just > > > added > > > >>> you as a member. > > > >>> You can publish your images there and delete the apachecloudstack > > org. > > > I > > > >>> think it’s better to just use ‘cloudstack' > > > >>> > > > >>>> On Mar 24, 2015, at 2:26 PM, Pierre-Luc Dion > > > >> wrote: > > > >>>> > > > >>>> some addition inline: > > > >>>> > > > >>>> On Tue, Mar 24, 2015 at 9:13 AM, Sebastien Goasguen < > > run...@gmail.com > > > > > > > >>>> wrote: > > > >>>> > > > >>>>> > > > >>>>>> On Mar 24, 2015, at 1:58 PM, Pierre-Luc Dion < > pd...@cloudops.com> > > > >>> wrote: > > > >>>>>> > > > >>>>>> I've played a little with Docker over the weekend, here are > some > > > >>> thought > > > >>>>>> and I'd like to have some input from community around this, > > > >>>>>> > > > >>>>>> 1. simulator: > > > >>>>>> I'v create a Jenkins[1] job that build a simulator container an > > push > > > >> it > > > >>>>> to > > > >>>>>> the docker org: apachecloudstack [2]. It is only done for master > > > >> branch > > > >>>>> at > > > >>>&g
Xen - S3 backed secondary storage - Local volume snapshots fail
Hello, I'm having an issue with Xen, S3 backed secondary storage and snapshots of volumes stored on the Xen hosts. It appears that either the behavior of Xen has changed, or perhaps there needs to be a tweak to the code to move snapshots from the staging area, rather than local disk. Snapshots of volumes stored in primary storage work fine when using S3 backed secondary storage. When using NFS as the secondary storage target, snapshots of local disks also work fine. Full details of the issue (logs etc) can be seen in https://issues.apache.org/jira/browse/CLOUDSTACK-7775 Many thanks for any help with this issue.
Re: venom/CVE-2015-345 Update your KVM folks
Looks like this is affects Xen as well: http://support.citrix.com/article/CTX201078 On Wed, May 13, 2015 at 3:23 PM, Nux! wrote: > https://access.redhat.com/articles/1444903 > > People running KVM might want to update their stuff. > > -- > Sent from the Delta quadrant using Borg technology! > > Nux! > www.nux.ro >
Xen - Migration fails in clustered environment - Possible fix
Hi Folks, This jira issue relates to vmware, and a fix appears to have been included for it in 4.5.1 and 4.5.2. https://issues.apache.org/jira/browse/CLOUDSTACK-8412 This is the diff of the commit: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=27b7e49;hp=6c649ce3ae3e4b3c785e98ef0da8da4410c7dad5 >From looking at the code, the exact same changes need to be made for Xenserver, here for example: https://github.com/apache/cloudstack/blob/master/plugins/hypervisors/xenserver/src/org/apache/cloudstack/storage/motion/XenServerStorageMotionStrategy.java We are running 4.5.1 and 4.5.2 and see the same issue in a clustered environment. Cheers!
Re: Xen - Migration fails in clustered environment - Possible fix
Hi All, I've raised a bug report for this issue, https://issues.apache.org/jira/browse/CLOUDSTACK-8937 Would it be possible for someone to give this a try at some point to see if it is reproducible? Cheers On Fri, Oct 2, 2015 at 7:28 AM, cs user wrote: > Hi Folks, > > This jira issue relates to vmware, and a fix appears to have been included > for it in 4.5.1 and 4.5.2. > > https://issues.apache.org/jira/browse/CLOUDSTACK-8412 > > This is the diff of the commit: > > > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=27b7e49;hp=6c649ce3ae3e4b3c785e98ef0da8da4410c7dad5 > > From looking at the code, the exact same changes need to be made for > Xenserver, here for example: > > > https://github.com/apache/cloudstack/blob/master/plugins/hypervisors/xenserver/src/org/apache/cloudstack/storage/motion/XenServerStorageMotionStrategy.java > > We are running 4.5.1 and 4.5.2 and see the same issue in a clustered > environment. > > Cheers! >
Re: Xen - Migration fails in clustered environment - Possible fix
I'm trying to take a look at this, but running into: Failed to execute goal on project cloud-framework-cluster: Could not resolve dependencies for project org.apache.cloudstack:cloud-framework-cluster:jar:4.5.2: Could not find artifact org.apache.cloudstack:cloud-api:jar:tests:4.5.2 in central ( http://repo.maven.apache.org/maven2 When trying to compile. Anyone know why this might be? On Tue, Oct 6, 2015 at 11:06 AM, cs user wrote: > Hi All, > > I've raised a bug report for this issue, > https://issues.apache.org/jira/browse/CLOUDSTACK-8937 > > Would it be possible for someone to give this a try at some point to see > if it is reproducible? > > Cheers > > On Fri, Oct 2, 2015 at 7:28 AM, cs user wrote: > >> Hi Folks, >> >> This jira issue relates to vmware, and a fix appears to have been >> included for it in 4.5.1 and 4.5.2. >> >> https://issues.apache.org/jira/browse/CLOUDSTACK-8412 >> >> This is the diff of the commit: >> >> >> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=27b7e49;hp=6c649ce3ae3e4b3c785e98ef0da8da4410c7dad5 >> >> From looking at the code, the exact same changes need to be made for >> Xenserver, here for example: >> >> >> https://github.com/apache/cloudstack/blob/master/plugins/hypervisors/xenserver/src/org/apache/cloudstack/storage/motion/XenServerStorageMotionStrategy.java >> >> We are running 4.5.1 and 4.5.2 and see the same issue in a clustered >> environment. >> >> Cheers! >> > >
Unable to compile 4.5 branch
Hi Folks, I'd really appreciate some help with this if anyone can spare a moment :-) So I've checked out the repo and got to this stage in git: [csuser@localhost cloudstack]$ git status # On branch origin/4.5 nothing to commit (working directory clean) I've then done a mvn clean, and all is fine. I've then tried to compile with the following command: [csuser@localhost cloudstack]$ mvn -U -P impatient,developer -Dmaven.test.skip=true -DskipTests However I keep getting the following: [INFO] Building Apache CloudStack Framework - Clustering 4.5.3-SNAPSHOT [INFO] Downloading: http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-api/4.5.3-SNAPSHOT/maven-metadata.xml Downloading: http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-api/4.5.3-SNAPSHOT/cloud-api-4.5.3-SNAPSHOT-tests.jar SNIP [ERROR] Failed to execute goal on project cloud-framework-cluster: Could not resolve dependencies for project org.apache.cloudstack:cloud-framework-cluster:jar:4.5.3-SNAPSHOT: Could not find artifact org.apache.cloudstack:cloud-api:jar:tests:4.5.3-SNAPSHOT in apache.snapshots (http://repository.apache.org/snapshots) -> [Help 1] This cloud-api-4.5.3-SNAPSHOT-tests.jar it mentions doesn't appear to exist in the location it is trying to download it from. Just to note, I do seem to be able to compile the master branch (4.6). That compiles and then launches fine. Is there a way around this issue for the 4.5 branch? mvn -v shows:
Re: Unable to compile 4.5 branch
Apologies, sent that too early, last bit should be : Apache Maven 3.0.4 (r1232337; 2012-01-17 08:44:56+) Maven home: /usr/local/apache-maven-3.0.4 Java version: 1.7.0_75, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75.x86_64/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "2.6.32-504.12.2.el6.x86_64", arch: "amd64", family: "unix" Thanks! On Sat, Oct 10, 2015 at 4:00 PM, cs user wrote: > Hi Folks, > > I'd really appreciate some help with this if anyone can spare a moment > :-) > > So I've checked out the repo and got to this stage in git: > > [csuser@localhost cloudstack]$ git status > # On branch origin/4.5 > nothing to commit (working directory clean) > > I've then done a mvn clean, and all is fine. > > I've then tried to compile with the following command: > > [csuser@localhost cloudstack]$ mvn -U -P impatient,developer > -Dmaven.test.skip=true -DskipTests > > However I keep getting the following: > > [INFO] Building Apache CloudStack Framework - Clustering 4.5.3-SNAPSHOT > [INFO] > > Downloading: > http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-api/4.5.3-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-api/4.5.3-SNAPSHOT/cloud-api-4.5.3-SNAPSHOT-tests.jar > SNIP > [ERROR] Failed to execute goal on project cloud-framework-cluster: Could > not resolve dependencies for project > org.apache.cloudstack:cloud-framework-cluster:jar:4.5.3-SNAPSHOT: Could not > find artifact org.apache.cloudstack:cloud-api:jar:tests:4.5.3-SNAPSHOT in > apache.snapshots (http://repository.apache.org/snapshots) -> [Help 1] > > > This cloud-api-4.5.3-SNAPSHOT-tests.jar it mentions doesn't appear to > exist in the location it is trying to download it from. Just to note, I do > seem to be able to compile the master branch (4.6). That compiles and then > launches fine. > > Is there a way around this issue for the 4.5 branch? > > mvn -v shows: > > > >
Re: Unable to compile 4.5 branch
Hi Frank/Rohit, Many thanks to you both for getting back to me, very much appreciated. Running it without this: Mvn.skip.tests=true Appears to have fixed it for me... :-) Should have given it a try, I thought having that in there would be helping to get past this issue. So for anyone else who stumbles upon this thread, I managed to get it compiled and running with the above command plus mvn -Pdeveloper -pl developer -Ddeploydb mvn -Pdeveloper -pl developer -Ddeploydb-simulator mvn -P simulator -pl :cloud-client-ui jetty:run Which gets me a 4.5.3-SNAPSHOT version running :) Thanks again guys. Cheers! On Sat, Oct 10, 2015 at 6:24 PM, Rohit Yadav wrote: > Can you try with: > > mvn clean install -pl api > > And then, try with the impatient profile skipping the tests. I’ve just > built latest 4.5 branch and it works for me. > > Regards. > > On 10-Oct-2015, at 4:00 pm, cs user wrote: > > Hi Folks, > > I'd really appreciate some help with this if anyone can spare a moment > :-) > > So I've checked out the repo and got to this stage in git: > > [csuser@localhost cloudstack]$ git status > # On branch origin/4.5 > nothing to commit (working directory clean) > > I've then done a mvn clean, and all is fine. > > I've then tried to compile with the following command: > > [csuser@localhost cloudstack]$ mvn -U -P impatient,developer > -Dmaven.test.skip=true -DskipTests > > However I keep getting the following: > > [INFO] Building Apache CloudStack Framework - Clustering 4.5.3-SNAPSHOT > [INFO] > > Downloading: > > http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-api/4.5.3-SNAPSHOT/maven-metadata.xml > Downloading: > > http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-api/4.5.3-SNAPSHOT/cloud-api-4.5.3-SNAPSHOT-tests.jar > SNIP > [ERROR] Failed to execute goal on project cloud-framework-cluster: Could > not resolve dependencies for project > org.apache.cloudstack:cloud-framework-cluster:jar:4.5.3-SNAPSHOT: Could not > find artifact org.apache.cloudstack:cloud-api:jar:tests:4.5.3-SNAPSHOT in > apache.snapshots (http://repository.apache.org/snapshots) -> [Help 1] > > > This cloud-api-4.5.3-SNAPSHOT-tests.jar it mentions doesn't appear to exist > in the location it is trying to download it from. Just to note, I do seem > to be able to compile the master branch (4.6). That compiles and then > launches fine. > > Is there a way around this issue for the 4.5 branch? > > mvn -v shows: > > > Regards, > Rohit Yadav > Software Architect, ShapeBlue > > > > > M. +91 88 262 30892 | rohit.ya...@shapeblue.com > Blog: bhaisaab.org | Twitter: @_bhaisaab > > > > > Find out more about ShapeBlue and our range of CloudStack related services > > IaaS Cloud Design & Build > <http://shapeblue.com/iaas-cloud-design-and-build//> > CSForge – rapid IaaS deployment framework <http://shapeblue.com/csforge/> > CloudStack Consulting <http://shapeblue.com/cloudstack-consultancy/> > CloudStack Software Engineering > <http://shapeblue.com/cloudstack-software-engineering/> > CloudStack Infrastructure Support > <http://shapeblue.com/cloudstack-infrastructure-support/> > CloudStack Bootcamp Training Courses > <http://shapeblue.com/cloudstack-training/> > > This email and any attachments to it may be confidential and are intended > solely for the use of the individual to whom it is addressed. Any views or > opinions expressed are solely those of the author and do not necessarily > represent those of Shape Blue Ltd or related companies. If you are not the > intended recipient of this email, you must neither take any action based > upon its contents, nor copy or show it to anyone. Please contact the sender > if you believe you have received this email in error. Shape Blue Ltd is a > company incorporated in England & Wales. ShapeBlue Services India LLP is a > company incorporated in India and is operated under license from Shape Blue > Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil > and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is > a company registered by The Republic of South Africa and is traded under > license from Shape Blue Ltd. ShapeBlue is a registered trademark. >
Development and building of ui components
Hi Folks, If you are modifying the code (javascript for example) under the following directory within the cloudstack project: ui/scripts/ And lets say I'm buidling and starting the simulator with the following: mvn -Pdeveloper -pl developer -Ddeploydb mvn -Pdeveloper -pl developer -Ddeploydb-simulator mvn -P simulator -pl :cloud-client-ui jetty:run Is there a maven command to rebuild just the UI components so that my javascript modifications are immediately included and will appear in the next run? I'm finding that I'm having to do a complete mvn clean, and then a rebuild of the entire project for it to pickup the changes. for small changes this takes a huge amount of time. Many thanks in advance for any help with this. Cheers!
Compiling master - build error
Hi Folks, I'm trying to compile master, but I'm getting the following errors: Check, is this api part of another build profile? Null value for key: listCiscoAsa1000vResources preProcessedCommand=1 Traceback (most recent call last): File "/home/acldstkusr/git/cloudstack/tools/apidoc/gen_toc.py", line 208, in category = choose_category(fn) File "/home/acldstkusr/git/cloudstack/tools/apidoc/gen_toc.py", line 187, in choose_category (fn, __file__)) Exception: Need to add a category for deleteBigSwitchVnsDevice.xml to /home/acldstkusr/git/cloudstack/tools/apidoc/gen_toc.py:known_categories Has anyone seen this and if so know how to resolve it? Cheers!
Re: Compiling master - build error
Hi Daan, Thanks for getting back to me. I just had chance to try this again today and it appeared to go through fine. Very strange! Cheers On Mon, Nov 2, 2015 at 3:12 PM, Daan Hoogland wrote: > hey some guy, > > Our jenkins apidoc builders have been failing regularly in such a way > coming back after a while. Have a look to see if it is the same issue. and > if it is; Try just building anew it might just work. if you find the root > cause please submit a PR. > > regards, > > On Mon, Nov 2, 2015 at 4:01 PM, cs user wrote: > > > Hi Folks, > > > > I'm trying to compile master, but I'm getting the following errors: > > > > Check, is this api part of another build profile? Null value for key: > > listCiscoAsa1000vResources preProcessedCommand=1 > > Traceback (most recent call last): > > File "/home/acldstkusr/git/cloudstack/tools/apidoc/gen_toc.py", line > 208, > > in > > category = choose_category(fn) > > File "/home/acldstkusr/git/cloudstack/tools/apidoc/gen_toc.py", line > 187, > > in choose_category > > (fn, __file__)) > > Exception: Need to add a category for deleteBigSwitchVnsDevice.xml to > > /home/acldstkusr/git/cloudstack/tools/apidoc/gen_toc.py:known_categories > > > > Has anyone seen this and if so know how to resolve it? > > > > Cheers! > > > > > > -- > Daan >
Re: Feature freeze ACS 4.7 next Monday
Hi Folks,
Would anyone else be able to give
https://github.com/apache/cloudstack/pull/1037 a try at some point?
Quite a serious issue when running in clustered mode with Xen, and trying
to perform VM migrations between hosts.
Thanks!
On Mon, Dec 7, 2015 at 12:08 PM, sebgoa wrote:
> The rn repo contains a script that polls JIRA for a release filter and
> generates the tables of issues fixed:
>
> https://github.com/apache/cloudstack-docs-rn/blob/master/utils/jira.py
>
> but we are not tracking the ones that really are *features*….
>
> small detail that would be nice to sort out.
>
> On Dec 7, 2015, at 12:01 PM, Remi Bergsma
> wrote:
>
> > Hi Seb,
> >
> > Now that we merge everything and have a smaller scope, it should be
> easier to get the list of pull requests that got in since 4.6.
> >
> > Quick attempt:
> >
> > git log --pretty=oneline --abbrev-commit upstream/4.6..master | grep
> Merge | grep -v release | grep -v 4\.6 | awk {'print $5'} | sed s/\#//g |
> sort -n
> >
> > 801
> > 834
> > 840
> > 841
> > 850
> > 929
> > 935
> > 937
> > 942
> > 943
> > 944
> > 1007
> > 1013
> > 1018
> > 1019
> > 1021
> > 1035
> > 1038
> > 1049
> > 1051
> > 1057
> > 1065
> > 1068
> > 1069
> > 1071
> > 1083
> > 1084
> > 1086
> > 1092
> > 1100
> > 1102
> > 1107
> > 1108
> > 1110
> > 1118
> > 1122
> > 1128
> > 1129
> > 1137
> > 1139
> > 1140
> > 1143
> > 1167
> > 1172
> > 1173
> >
> > If we make a script that gets this output and queries Github, we can get
> a list of the PR titles. Then we need to make sure those titles are any
> good ;-)
> >
> >
> > Regards,
> > Remi
> >
> >
> >
> >
> > On 07/12/15 10:13, "sebgoa" wrote:
> >
> >>
> >> On Dec 7, 2015, at 9:56 AM, Daan Hoogland
> wrote:
> >>
> >>> Rohit, Sebastien,
> >>>
> >>> I think we do not need to hurry any issues. work on 4.8 will start in
> >>> January or february at the latest.
> >>
> >>
> >> I don't want to hurry anything, I want to be able to have release notes
> that describe *all* the features added.
> >>
> >> Check the 4.6 release notes, I am sure we did more than this, but since
> dev more often than not don't care much about the RN, the features are not
> publicized.
> >>
> >>
> >>
> >>>
> >>> On Mon, Dec 7, 2015 at 8:55 AM, sebgoa wrote:
> >>>
> Hate to be a pain, but could you make sure to keep the exact list of
> Features merged, so that the Release notes are accurate ?
>
> thanks
>
> On Dec 4, 2015, at 11:58 PM, Remi Bergsma <
> rberg...@schubergphilis.com>
> wrote:
>
> > Hi all,
> >
> > Next Monday we'll feature freeze for our upcoming 4.7 release. We
> looked
> through all open Pull Requests and below is our "whish list" to get
> in 4.7.
> Feel free to nominate any other changes that should go in 4.7. No
> guarantees, there is limited time so only PRs that we actively work
> on will
> make it.
> >
> > The RC of 4.7.0 is scheduled for Monday Dec 14th so that we all will
> have a nice Christmas present ;-)
> >
> > Please help us review these PRs. Most have already had some review
> and
> when we can reach 2xLGTM we can include them in 4.7 on time and make
> another great release.
> >
> > Happy testing and reviewing!
> >
> > Regards,
> > Daan & Remi
> >
> >
> > Features & Fixes PRs:
> >
> > Quota
> > https://github.com/apache/cloudstack/pull/768
> >
> > Logging enhancement
> > https://github.com/apache/cloudstack/pull/1167
> >
> > VMware diskcontrollers
> > https://github.com/apache/cloudstack/pull/1132
> >
> > ACS allows to create isolated networks with invalid gateway ip
> > https://github.com/apache/cloudstack/pull/1125
> >
> > Update nic IP address of stopped vm
> > https://github.com/apache/cloudstack/pull/1086
> >
> > Hypervisor changes to support UserData for Nuage VSP
> > https://github.com/apache/cloudstack/pull/1142
> >
> > Support shared networking in NiciraNVP Plugin
> > https://github.com/apache/cloudstack/pull/1094
> >
> > Strongswan vpn feature
> > https://github.com/apache/cloudstack/pull/872
> >
> > VM Snapshotting implementation for KVM
> > https://github.com/apache/cloudstack/pull/977
> >
> > Redundant VPC improvement
> > (PR will follow over the weekend)
> >
> >
> > UI PRs:
> >
> > [UI] fix bug: Cannot delete SSH keypairs in projects
> > https://github.com/apache/cloudstack/pull/1154
> >
> > UI icon over VM snapshot to deploy user instance
> > https://github.com/apache/cloudstack/pull/1150
> >
> > Newly added project is not showing in the drop down until the
> browser is
> refreshed
> > https://github.com/apache/cloudstack/pull/1082
>
>
> >>>
> >>>
> >>> --
> >>> Daan
> >>
>
>
4.5.1 - SSVM Cert issues
Hi Folks, After updating to 4.5.1 and installing using the shapeblue SSVM templates: http://packages.shapeblue.com/systemvmtemplate/4.5/new/ We are hitting an issue very similar to the below when trying to copy templates between zones: https://issues.apache.org/jira/browse/CLOUDSTACK-1475 We are using our own wildcard cert for this parameter: secstorage.ssl.cert.domain We weren't having any issues when using 4.3. Has anyone run into this? Cheers!
Re: Database consistency check
This would be fantastic if it can be written. On Mon, Aug 10, 2015 at 1:17 PM, Daan Hoogland wrote: > Norbert, I haven't begun to think about it. including dev@ to gather > ideas. > The db structure is based on updates since 4.0. A new install will be a 4.0 > DB which will then undergo a series of upgrade steps. A validation of the > db could be divided in a basic part and an incremental part, maybe. > > A good tactic might be to start a collection of smaller checks that > validate only individual parts. An example would be orphaned volumes, or > removed volumes that are still attached to VMs. completeness of link tables > is another one. > > This is not going to be caught in a single story, i'm afraid. > > On Mon, Aug 10, 2015 at 2:03 PM, Norbert Klein < > norbert.kl...@infosecprojects.net> wrote: > > > Do you have any idea where to start? (I am not a developer). If there is > > no script avaible > > I think a developer has to do it or at least I need the criterias from > > them. Without knowing > > the internal CS structure I don't know exactly what to check. > > > > Am 10.08.2015 um 13:51 schrieb Daan Hoogland: > > > Good point Norbert, I don't think there is. would be a great addition > > > though. You want to take this on or at least create a ticket for it in > > > jira? > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20CLOUDSTACK > > > > > > On Mon, Aug 10, 2015 at 1:48 PM, Norbert Klein < > > > norbert.kl...@infosecprojects.net> wrote: > > > > > >> Hi all, > > >> > > >> what is the best way to check the cloudstack database consistency? > > >> Is there any tool or script available which we could use to make sure > > >> the database structure and content > > >> is in a valid state? (for example after manual changes). > > >> > > >> Thx > > >> Norbert > > >> > > >> > > > > > > > > > -- > Daan >
Instance reboot issue - CS 4.5.1 - Xen 6.5
Hi All, We have seen this in 2 separate environments, both running the same versions of Cloudstack and Xenserver. When we reboot an instance, we lose access to it. Looking at the iptables config on the xen host, we can see that the vif is incremented for the bridged entries, but not updated for the rules. For example, this is how the iptables look before a reboot: [root@xen001 cloud]# iptables -L|grep 25075 i-2-25075-def all -- anywhere anywhere PHYSDEV match --physdev-in vif108.0 --physdev-is-bridged i-2-25075-def all -- anywhere anywhere PHYSDEV match --physdev-out vif108.0 --physdev-is-bridged Chain i-2-25075-VM (1 references) Chain i-2-25075-VM-eg (1 references) Chain i-2-25075-def (2 references) RETURN udp -- anywhere anywhere PHYSDEV match --physdev-in vif108.0 --physdev-is-bridged match-set i-2-25075-VM src udp dpt:domain DROP all -- anywhere anywhere PHYSDEV match --physdev-in vif108.0 --physdev-is-bridged ! match-set i-2-25075-VM src DROP all -- anywhere anywhere PHYSDEV match --physdev-out vif108.0 --physdev-is-bridged ! match-set i-2-25075-VM dst i-2-25075-VM-eg all -- anywhere anywhere PHYSDEV match --physdev-in vif108.0 --physdev-is-bridged match-set i-2-25075-VM src i-2-25075-VM all -- anywhere anywhere PHYSDEV match --physdev-out vif108.0 --physdev-is-bridged After a reboot, we can see the following: [root@xen001 cloud]# iptables -L|grep 25075 i-2-25075-def all -- anywhere anywhere PHYSDEV match --physdev-in vif109.0 --physdev-is-bridged i-2-25075-def all -- anywhere anywhere PHYSDEV match --physdev-out vif109.0 --physdev-is-bridged Chain i-2-25075-VM (1 references) Chain i-2-25075-VM-eg (1 references) Chain i-2-25075-def (2 references) RETURN udp -- anywhere anywhere PHYSDEV match --physdev-in vif108.0 --physdev-is-bridged match-set i-2-25075-VM src udp dpt:domain DROP all -- anywhere anywhere PHYSDEV match --physdev-in vif108.0 --physdev-is-bridged ! match-set i-2-25075-VM src DROP all -- anywhere anywhere PHYSDEV match --physdev-out vif108.0 --physdev-is-bridged ! match-set i-2-25075-VM dst i-2-25075-VM-eg all -- anywhere anywhere PHYSDEV match --physdev-in vif108.0 --physdev-is-bridged match-set i-2-25075-VM src i-2-25075-VM all -- anywhere anywhere PHYSDEV match --physdev-out vif108.0 --physdev-is-bridged You can see that the bridged entries have been incremented to vif109, where as the rules still reference vif108. Stopping the instance appears to clear out the rules, and then everything works fine again once the instance is started. Is this a known issue? Is anyone able to replicate this? Cheers!
Re: Instance reboot issue - CS 4.5.1 - Xen 6.5
Hi Folks, Looks like this is fixed in https://github.com/apache/cloudstack/pull/479 ? Which cloudstack release contains this fix? Many thanks! On Wed, Sep 2, 2015 at 11:16 AM, cs user wrote: > Forwarding to users channel in case anyone else has seen this... > > > > Hi All, > > We have seen this in 2 separate environments, both running the same > versions of Cloudstack and Xenserver. When we reboot an instance, we lose > access to it. > > Looking at the iptables config on the xen host, we can see that the vif is > incremented for the bridged entries, but not updated for the rules. > > For example, this is how the iptables look before a reboot: > > [root@xen001 cloud]# iptables -L|grep 25075 > i-2-25075-def all -- anywhere anywhere PHYSDEV > match --physdev-in vif108.0 --physdev-is-bridged > i-2-25075-def all -- anywhere anywhere PHYSDEV > match --physdev-out vif108.0 --physdev-is-bridged > Chain i-2-25075-VM (1 references) > Chain i-2-25075-VM-eg (1 references) > Chain i-2-25075-def (2 references) > RETURN udp -- anywhere anywhere PHYSDEV > match --physdev-in vif108.0 --physdev-is-bridged match-set i-2-25075-VM src > udp dpt:domain > DROP all -- anywhere anywhere PHYSDEV > match --physdev-in vif108.0 --physdev-is-bridged ! match-set i-2-25075-VM > src > DROP all -- anywhere anywhere PHYSDEV > match --physdev-out vif108.0 --physdev-is-bridged ! match-set i-2-25075-VM > dst > i-2-25075-VM-eg all -- anywhere anywhere > PHYSDEV match --physdev-in vif108.0 --physdev-is-bridged match-set > i-2-25075-VM src > i-2-25075-VM all -- anywhere anywhere PHYSDEV > match --physdev-out vif108.0 --physdev-is-bridged > > After a reboot, we can see the following: > > [root@xen001 cloud]# iptables -L|grep 25075 > i-2-25075-def all -- anywhere anywhere PHYSDEV > match --physdev-in vif109.0 --physdev-is-bridged > i-2-25075-def all -- anywhere anywhere PHYSDEV > match --physdev-out vif109.0 --physdev-is-bridged > Chain i-2-25075-VM (1 references) > Chain i-2-25075-VM-eg (1 references) > Chain i-2-25075-def (2 references) > RETURN udp -- anywhere anywhere PHYSDEV > match --physdev-in vif108.0 --physdev-is-bridged match-set i-2-25075-VM src > udp dpt:domain > DROP all -- anywhere anywhere PHYSDEV > match --physdev-in vif108.0 --physdev-is-bridged ! match-set i-2-25075-VM > src > DROP all -- anywhere anywhere PHYSDEV > match --physdev-out vif108.0 --physdev-is-bridged ! match-set i-2-25075-VM > dst > i-2-25075-VM-eg all -- anywhere anywhere > PHYSDEV match --physdev-in vif108.0 --physdev-is-bridged match-set > i-2-25075-VM src > i-2-25075-VM all -- anywhere anywhere PHYSDEV > match --physdev-out vif108.0 --physdev-is-bridged > > You can see that the bridged entries have been incremented to vif109, > where as the rules still reference vif108. > > Stopping the instance appears to clear out the rules, and then everything > works fine again once the instance is started. > > Is this a known issue? Is anyone able to replicate this? > > Cheers! > >
Re: Instance reboot issue - CS 4.5.1 - Xen 6.5
Great, thanks ! On Thu, Sep 3, 2015 at 7:10 AM, Rajani Karuturi wrote: > its in 4.5.2 and will also be in 4.6.0 > > ~Rajani > > On Wed, Sep 2, 2015 at 5:33 PM, cs user wrote: > > > Hi Folks, > > > > Looks like this is fixed in > https://github.com/apache/cloudstack/pull/479 > > ? > > > > Which cloudstack release contains this fix? > > > > Many thanks! > > > > On Wed, Sep 2, 2015 at 11:16 AM, cs user wrote: > > > > > Forwarding to users channel in case anyone else has seen this... > > > > > > > > > > > > Hi All, > > > > > > We have seen this in 2 separate environments, both running the same > > > versions of Cloudstack and Xenserver. When we reboot an instance, we > lose > > > access to it. > > > > > > Looking at the iptables config on the xen host, we can see that the vif > > is > > > incremented for the bridged entries, but not updated for the rules. > > > > > > For example, this is how the iptables look before a reboot: > > > > > > [root@xen001 cloud]# iptables -L|grep 25075 > > > i-2-25075-def all -- anywhere anywhere > PHYSDEV > > > match --physdev-in vif108.0 --physdev-is-bridged > > > i-2-25075-def all -- anywhere anywhere > PHYSDEV > > > match --physdev-out vif108.0 --physdev-is-bridged > > > Chain i-2-25075-VM (1 references) > > > Chain i-2-25075-VM-eg (1 references) > > > Chain i-2-25075-def (2 references) > > > RETURN udp -- anywhere anywhere PHYSDEV > > > match --physdev-in vif108.0 --physdev-is-bridged match-set i-2-25075-VM > > src > > > udp dpt:domain > > > DROP all -- anywhere anywhere PHYSDEV > > > match --physdev-in vif108.0 --physdev-is-bridged ! match-set > i-2-25075-VM > > > src > > > DROP all -- anywhere anywhere PHYSDEV > > > match --physdev-out vif108.0 --physdev-is-bridged ! match-set > > i-2-25075-VM > > > dst > > > i-2-25075-VM-eg all -- anywhere anywhere > > > PHYSDEV match --physdev-in vif108.0 --physdev-is-bridged match-set > > > i-2-25075-VM src > > > i-2-25075-VM all -- anywhere anywhere > PHYSDEV > > > match --physdev-out vif108.0 --physdev-is-bridged > > > > > > After a reboot, we can see the following: > > > > > > [root@xen001 cloud]# iptables -L|grep 25075 > > > i-2-25075-def all -- anywhere anywhere > PHYSDEV > > > match --physdev-in vif109.0 --physdev-is-bridged > > > i-2-25075-def all -- anywhere anywhere > PHYSDEV > > > match --physdev-out vif109.0 --physdev-is-bridged > > > Chain i-2-25075-VM (1 references) > > > Chain i-2-25075-VM-eg (1 references) > > > Chain i-2-25075-def (2 references) > > > RETURN udp -- anywhere anywhere PHYSDEV > > > match --physdev-in vif108.0 --physdev-is-bridged match-set i-2-25075-VM > > src > > > udp dpt:domain > > > DROP all -- anywhere anywhere PHYSDEV > > > match --physdev-in vif108.0 --physdev-is-bridged ! match-set > i-2-25075-VM > > > src > > > DROP all -- anywhere anywhere PHYSDEV > > > match --physdev-out vif108.0 --physdev-is-bridged ! match-set > > i-2-25075-VM > > > dst > > > i-2-25075-VM-eg all -- anywhere anywhere > > > PHYSDEV match --physdev-in vif108.0 --physdev-is-bridged match-set > > > i-2-25075-VM src > > > i-2-25075-VM all -- anywhere anywhere > PHYSDEV > > > match --physdev-out vif108.0 --physdev-is-bridged > > > > > > You can see that the bridged entries have been incremented to vif109, > > > where as the rules still reference vif108. > > > > > > Stopping the instance appears to clear out the rules, and then > everything > > > works fine again once the instance is started. > > > > > > Is this a known issue? Is anyone able to replicate this? > > > > > > Cheers! > > > > > > > > >
