[GitHub] cloudstack pull request: tool to aid db comaprision for upgrade te...

[shwetaag]

Github user shwetaag commented on the pull request:

https://github.com/apache/cloudstack/pull/188#issuecomment-95824131
  
@agneya2001  this is version 1. 
I know enhancement are possible .
Like db comparison based on versions but that will come in next version


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: tool to aid db comaprision for upgrade te...

[karuturi]

Github user karuturi commented on the pull request:

https://github.com/apache/cloudstack/pull/188#issuecomment-95822665
  
@agneya2001 some functionality like?



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: tool to aid db comaprision for upgrade te...

[terbolous]

Github user terbolous commented on the pull request:

https://github.com/apache/cloudstack/pull/188#issuecomment-95821124
  
Shouldn't the files have licensing information in them?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: To Verfiy that list templates by domain a...

[gauravaradhye]

Github user gauravaradhye commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/189#discussion_r29025553
  
--- Diff: 
test/integration/component/test_escalation_listTemplateDomainAdmin.py ---
@@ -0,0 +1,157 @@
+
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+#
+#   http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+
+from marvin.cloudstackTestCase import cloudstackTestCase
+from marvin.lib.base import (Account,
+ Domain, Template
+ )
+from marvin.lib.utils import (cleanup_resources)
+from marvin.lib.common import (get_zone, get_builtin_template_info)
+from nose.plugins.attrib import attr
+import time
+
+
+class TestlistTemplatesDomainAdmin(cloudstackTestCase):
+
+@classmethod
+def setUpClass(cls):
+
+testClient = super(
+TestlistTemplatesDomainAdmin, cls).getClsTestClient()
+cls.apiclient = testClient.getApiClient()
+cls.testdata = testClient.getParsedTestDataConfig()
+cls.zone = get_zone(cls.apiclient, 
cls.testClient.getZoneForTests())
+cls.hypervisor = cls.testClient.getHypervisorInfo()
+builtin_info = get_builtin_template_info(cls.apiclient, 
cls.zone.id)
+cls.testdata["privatetemplate"]["url"] = builtin_info[0]
+cls.testdata["privatetemplate"]["hypervisor"] = builtin_info[1]
+cls.testdata["privatetemplate"]["format"] = builtin_info[2]
+cls.cleanup = []
+
+# Create 2 domain admin accounts
+
+cls.domain1 = Domain.create(
+cls.apiclient,
+cls.testdata["domain"])
+
+cls.domain2 = Domain.create(
+cls.apiclient,
+cls.testdata["domain"])
+
+cls.account1 = Account.create(
+cls.apiclient,
+cls.testdata["account"],
+admin=True,
+domainid=cls.domain1.id)
+
+cls.account2 = Account.create(
+cls.apiclient,
+cls.testdata["account2"],
+admin=True,
+domainid=cls.domain2.id)
+
+cls.debug("Created account %s in domain %s" %
+  (cls.account1.name, cls.domain1.id))
+cls.debug("Created account %s in domain %s" %
+  (cls.account2.name, cls.domain2.id))
+
+cls.cleanup.append(cls.account1)
+cls.cleanup.append(cls.account2)
+cls.cleanup.append(cls.domain1)
+cls.cleanup.append(cls.domain2)
+
+@classmethod
+def tearDownClass(cls):
+try:
+# Cleanup resources used
+cleanup_resources(cls.apiclient, cls.cleanup)
+
+except Exception as e:
+raise Exception("Warning: Exception during cleanup : %s" % e)
+return
+
+# test that the template register under root/domain1->account1 is not
+# listed under root/domain2->account2
+
+@attr(tags=["advanced", "basic"], required_hardware="true")
+def test_listtemplate(self):
+
+# Register template under one domain admin(root/domain1->account 1)
+
+template_register = Template.register(
+self.apiclient,
+self.testdata["privatetemplate"],
+zoneid=self.zone.id,
+hypervisor=self.hypervisor,
+account=self.account1.name,
+domainid=self.domain1.id)
+
+template_register.download(self.apiclient)
+# self.cleanup.append(self.template_register)
+
+time.sleep(self.testdata["sleep"])
+timeout = self.testdata["timeout"]
+while True:
+listTemplateResponse = Template.list(
+self.apiclient,
+templatefilter="all",
+id=template_register.id,
+account=self.account1.name,
+domainid=self.domain1.id
+)
+if isinstance(list

[GitHub] cloudstack pull request: tool to aid db comaprision for upgrade te...

[agneya2001]

Github user agneya2001 commented on the pull request:

https://github.com/apache/cloudstack/pull/188#issuecomment-95811296
  
It appears that some functionality still needs to be completed.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: To Verfiy that list templates by domain a...

[gauravaradhye]

Github user gauravaradhye commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/189#discussion_r29025564
  
--- Diff: 
test/integration/component/test_escalation_listTemplateDomainAdmin.py ---
@@ -0,0 +1,157 @@
+
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+#
+#   http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+
+from marvin.cloudstackTestCase import cloudstackTestCase
+from marvin.lib.base import (Account,
+ Domain, Template
+ )
+from marvin.lib.utils import (cleanup_resources)
+from marvin.lib.common import (get_zone, get_builtin_template_info)
+from nose.plugins.attrib import attr
+import time
+
+
+class TestlistTemplatesDomainAdmin(cloudstackTestCase):
+
+@classmethod
+def setUpClass(cls):
+
+testClient = super(
+TestlistTemplatesDomainAdmin, cls).getClsTestClient()
+cls.apiclient = testClient.getApiClient()
+cls.testdata = testClient.getParsedTestDataConfig()
+cls.zone = get_zone(cls.apiclient, 
cls.testClient.getZoneForTests())
+cls.hypervisor = cls.testClient.getHypervisorInfo()
+builtin_info = get_builtin_template_info(cls.apiclient, 
cls.zone.id)
+cls.testdata["privatetemplate"]["url"] = builtin_info[0]
+cls.testdata["privatetemplate"]["hypervisor"] = builtin_info[1]
+cls.testdata["privatetemplate"]["format"] = builtin_info[2]
+cls.cleanup = []
+
+# Create 2 domain admin accounts
+
+cls.domain1 = Domain.create(
+cls.apiclient,
+cls.testdata["domain"])
+
+cls.domain2 = Domain.create(
+cls.apiclient,
+cls.testdata["domain"])
+
+cls.account1 = Account.create(
+cls.apiclient,
+cls.testdata["account"],
+admin=True,
+domainid=cls.domain1.id)
+
+cls.account2 = Account.create(
+cls.apiclient,
+cls.testdata["account2"],
+admin=True,
+domainid=cls.domain2.id)
+
+cls.debug("Created account %s in domain %s" %
+  (cls.account1.name, cls.domain1.id))
+cls.debug("Created account %s in domain %s" %
+  (cls.account2.name, cls.domain2.id))
+
+cls.cleanup.append(cls.account1)
+cls.cleanup.append(cls.account2)
+cls.cleanup.append(cls.domain1)
+cls.cleanup.append(cls.domain2)
+
+@classmethod
+def tearDownClass(cls):
+try:
+# Cleanup resources used
+cleanup_resources(cls.apiclient, cls.cleanup)
+
+except Exception as e:
+raise Exception("Warning: Exception during cleanup : %s" % e)
+return
+
+# test that the template register under root/domain1->account1 is not
+# listed under root/domain2->account2
+
+@attr(tags=["advanced", "basic"], required_hardware="true")
+def test_listtemplate(self):
+
+# Register template under one domain admin(root/domain1->account 1)
+
+template_register = Template.register(
+self.apiclient,
+self.testdata["privatetemplate"],
+zoneid=self.zone.id,
+hypervisor=self.hypervisor,
+account=self.account1.name,
+domainid=self.domain1.id)
+
+template_register.download(self.apiclient)
+# self.cleanup.append(self.template_register)
+
+time.sleep(self.testdata["sleep"])
+timeout = self.testdata["timeout"]
+while True:
+listTemplateResponse = Template.list(
+self.apiclient,
+templatefilter="all",
+id=template_register.id,
+account=self.account1.name,
+domainid=self.domain1.id
+)
+if isinstance(list

Jenkins build is still unstable: simulator-singlerun #1140

[jenkins]

See 

[GitHub] cloudstack pull request: To Verfiy that list templates by domain a...

[manasaveloori]

GitHub user manasaveloori opened a pull request:

https://github.com/apache/cloudstack/pull/189

To Verfiy that list templates by domain admin is not listing the templates 
of other domains...

results:

test_listtemplate (integration.component.test.TestlistTemplatesDomainAdmin) 
... === TestName: test_listtemplate | Status : SUCCESS ===
ok

--
Ran 1 test in 307.996s

OK


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/manasaveloori/cloudstack local

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/189.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #189


commit f8659eb0079c48194e264c6400b001ea7a314518
Author: manasaVeloori 
Date:   2015-04-24T05:35:22Z

To Verfiy that list templates by domain admin is not listing the templates 
of other domains




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

upgrade from 4.2.1 to 4.4.2

[fight3000dz]

There was an error when i upgraded cloudstack4.2.1 to 4.4.2.
According to the <>,in the last process 
"upgrade system-VMs and Virtual-Routers",after i had run command:nohup 
cloudstack-sysvmadm -d IPaddress -u cloud -p password -a > sysvm.log 2>&1 
&there was an error in the log sysvm.log.These are the output in the log:
Stopping and starting 1 secondary storage vm(s)...Done stopping and starting 
secondary storage vm(s)Stopping and starting 1 console proxy vm(s)...ERROR: 
Failed to start console proxy vm with id 38 Done stopping and starting console 
proxy vm(s) .Stopping and starting 1 running routing vm(s)... Done restarting 
router(s).
I don't know what does the error "ERROR: Failed to start console proxy vm with 
id 38" mean.My envrionment seems ok after i have done that command.All the 
sysvms have been recreated automatically.Please tell me what should i do about 
that error.Can i ignore it?Thanks.

Re: ACS 4.5.1 repo please

[Keerthiraja SJ]

But still could not able to see the systemvm.

Thanks,
Keerthi

On Thu, Apr 23, 2015 at 10:55 PM, Rohit Yadav 
wrote:

> Can you refresh again, build latest 4.5 rpms/deb etc. now:
> http://packages.bhaisaab.org/cloudstack/testing/centos/4.5/
>
> This is not supposed to be a publicly consumable hosting so I keep
> adding/removing stuff, so something packages may get deleted.
> I’ll try to fix this issue by hosting a nightlies repo, will share when
> it’s done.
>
> > On 23-Apr-2015, at 4:16 pm, Keerthiraja SJ  wrote:
> >
> > Hi All,
> >
> > I am trying to validate ACS 4.5.1 rpm installation. Kindly let me know
> > which repo should I have to point.
> >
> > There is no rpm's available in the below location.
> >
> > RPM: http://packages.bhaisaab.org/cloudstack/testing/centos/4.5/
> > SystemVM Templates:
> http://packages.shapeblue.com/systemvmtemplate/4.5/4.5.0
> >
> >
> > Thanks,
> > Keerthi
>
> 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
> CloudStack Consulting
> 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.
>

[GitHub] cloudstack pull request: GetUsageRecordsCmd - NewInputFormat for S...

[kishankavala]

Github user kishankavala commented on the pull request:

https://github.com/apache/cloudstack/pull/185#issuecomment-95800447
  
@svscorp  Commit looks good to me.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: tool to aid db comaprision for upgrade te...

[shwetaag]

Github user shwetaag closed the pull request at:

https://github.com/apache/cloudstack/pull/188


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: tool to aid db comaprision for upgrade te...

[sanju1010]

Github user sanju1010 commented on the pull request:

https://github.com/apache/cloudstack/pull/188#issuecomment-95797865
  
I am taking this patch. LGTM


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: KVM securing root

[Nux!]

Good proposition.
Personally I would like to see support for Selinux and separation between VMs.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Marcus" 
> To: dev@cloudstack.apache.org
> Sent: Friday, 24 April, 2015 00:17:09
> Subject: KVM securing root

> Has anyone had experience with securing the KVM agent, specifically
> getting it to run as non-root. I've looked a bit, and I believe it
> would require code changes.  An initial, simple plan for this (that
> involves code fixes) might be to do something like:
> 
> 1) generate a list of included scripts during packaging and create a
> file for /etc/sudoers.d to allow a cloudstack user to run these. User
> and sudoers file are added by the package (?)
> 2) make sure the libvirt socket is owned by the cloudstack group in
> /etc/libvirt/libvirtd.conf
> 3) change the code to pass the sudo boolean to every Script command
> 4) audit for any other hardcoded root paths (e.g. the ssh keys dir) or
> system commands needed
> 5) change init script to launch agent as cloudstack user
> 
> Obviously this doesn't go all the way into auditing how all of the
> scripts act, or path issues, etc, but it could be a good first step.
> It would protect against malicious strings passed as parameters to
> these scripts, but perhaps not in cases were they might be escaped at
> the first exec and run by the script itself.
> 
> Alternatively, we could audit all of the scripts, adding sudo where
> necessary and manually including those into a sudoers.d config.
> 
> As an in-between, we could add all of the packaged scripts to a
> sudoers file, and remove them slowly as we audit each script.

KVM securing root

[Marcus]

Has anyone had experience with securing the KVM agent, specifically
getting it to run as non-root. I've looked a bit, and I believe it
would require code changes.  An initial, simple plan for this (that
involves code fixes) might be to do something like:

1) generate a list of included scripts during packaging and create a
file for /etc/sudoers.d to allow a cloudstack user to run these. User
and sudoers file are added by the package (?)
2) make sure the libvirt socket is owned by the cloudstack group in
/etc/libvirt/libvirtd.conf
3) change the code to pass the sudo boolean to every Script command
4) audit for any other hardcoded root paths (e.g. the ssh keys dir) or
system commands needed
5) change init script to launch agent as cloudstack user

Obviously this doesn't go all the way into auditing how all of the
scripts act, or path issues, etc, but it could be a good first step.
It would protect against malicious strings passed as parameters to
these scripts, but perhaps not in cases were they might be escaped at
the first exec and run by the script itself.

Alternatively, we could audit all of the scripts, adding sudo where
necessary and manually including those into a sudoers.d config.

As an in-between, we could add all of the packaged scripts to a
sudoers file, and remove them slowly as we audit each script.

Re: [DISCUSS] 4.6 release management

[Marcus]

Before I rough draft anything, I just wanted to ask if we had voted on
moving to git-workflow, and dropping the multiple release branch
design. This seems like a significant change, and while good in many
ways, it also seems that many users are seeking for point releases to
their pet version and I'm not sure how they'll take to a response that
they need to upgrade. Overall I think it will approve stability and
focus our efforts, but have we had a vote around this change?

On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen  wrote:
>
>> On Apr 18, 2015, at 8:36 AM, Marcus  wrote:
>>
>> Have they diverged that much? Due to cherry-picking, I guess.
>> Otherwise you should be able to do it cleanly.
>>
>> There's a good opportunity to do this next release. Instead of
>> creating a release branch, we freeze master and start creating dev
>> branches.
>
> +1
>
> This just amounts to treating master now like a release branch. Getting back 
> to PL suggestion, that means
> that any commit to master would be through a PR or MERGE request on the ML. 
> Anything else will be reverted by the RM.
>
> Marcus, do you feel like writing down a little process for this and some 
> dates that we can target.
> It would be nice to do this for 4.6.
>
>>
>> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland  
>> wrote:
>>> We heavily invested in code now on master. Not looking forward to
>>> backporting that.
>>>
>>> mobile dev with bilingual spelling checker used (read at your own risk)
>>> Op 17 apr. 2015 21:02 schreef "Marcus" :
>>>
 Well, would we just swap the last release branch with master? Master
 is the dev branch, and the last release is really what we have as a
 stable branch.

 On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland 
 wrote:
> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen 
 wrote:
>>
>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion 
 wrote:
>>>
>>> Today during the CloudStackdays  we did a round table about Release
>>> management targeting the next 4.6 releases.
>>>
>>>
>>> Quick bullet point discussions:
>>>
>>> ideas to change release planning
>>>
>>>  - Plugin contribution is complicated because often  a new plugin
 involve
>>>  change on the core:
>>> - ex: storage plugin involve changes on Hypervisor code
>>>  - There is an idea of going on a 2 weeks release model which could
>>>  introduce issue the database schema.
>>>  - Database schema version should be different then the application
>>>  version.
>>>  - There is a will to enforce git workflow in 4.6  and trigger
 simulator
>>>  job on  PullRequest.
>>>  - Some people (I'm part of them) are concerned on our current way of
>>>  supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
>>>  4.5.x). But the current level of confidence against latest release
 is low,
>>>  so that need to be improved.
>>>
>>>
>>> So, the main messages is that w'd like to improve the release
 velocity, and
>>> release branch stability.  so we would like to propose few change in
 the
>>> way we would add code to the 4.6 branch as follow:
>>>
>>> - All new contribution to 4.6 would be thru Pull Request or merge
 request,
>>> which would trigger a simulator job, ideally only if that pass the PR
 would
>>> be accepted and automatically merged.  At this time, I think we pretty
 much
>>> have everything in place to do that. At a first step we would use
>>> simulator+marvin jobs then improve tests coverage from there.
>>
>> +1
>>
>> We do need to realize what this means and be all fine with it.
>>
>> It means that if someone who is not RM directly commits to the release
 branch, the commit will be reverted.
>> And that from the beginning of the branching…
> I agree and we can even go as far as reverting fixes that are
> cherry-picked in favour of merged forward.
>
>>
>> IMHO, I think this would be a good step but I don’t think it goes far
 enough.
> Agreed here as well but let's take the step while discussing further
> steps and not implement to much process as well
>
>>
>> This still uses a paradigm where a release is made from a release
 branch that was started from an unstable development branch.
>> Hence you still need *extensive* QA.
> The problem here is that there is no stable point to fork from at the
> moment. We will get there and we shouldn't stop taking steps in that
> direction.
>
>>
>> If we truly want to release faster, we need to release from the same
 QA’d branch time after time….a release needs to be based on a previous
 release
>>
>> Basically, we need a rolling release cycle. That will have the added
 benefit to not leave releases behind and have to focus on backporting.
>>
>>>
>>> Please comments :-)

Re: Next ACS release?

[Marcus]

I agree with that, there are regressions occasionally with bugfixes,
but I generally don't see any obvious distinction made in the voting
thread. Someone finds a problem, they want to patch it, others are
found, we roll a new RC.

On Wed, Apr 22, 2015 at 3:49 PM, David Nalley  wrote:
> On Wed, Apr 22, 2015 at 4:47 PM, Marcus  wrote:
>> We just have to do it.  We just freeze master at some point, do all of
>> the release bugfixes, and when it is solid enough to pass a release
>> vote we branch a release from it, and then only allow merges to master
>> that have been tested in a merge branch, or something along those
>> lines. Things will slip through, because our testing isn't full
>> coverage, but we can begin to add to it.
>>
>> I've said it before, but I think we're also a bit stingy regarding
>> bugfix releases. Unless we cause a regression, there should be no need
>> for bugfix releases to go through multiple RCs. We get caught on bugs
>> that are already in the shipping version and make them blockers for
>> the other bug fixes, or a pet patch needs to slip in (which also only
>> matters because bugfix releases are so few and hard to release).
>>
>
> It's not just new features that cause problems though.
> We've had bug fixes that cause issues, sometimes worse than the one
> they solved. Every change is a threat to stability, so we'd like to
> have smaller bug fix releases too. There's an inherent cost in doing
> releases in their current form.
>
> --David

Re: ACS 4.5.1 repo please

[Rohit Yadav]

Can you refresh again, build latest 4.5 rpms/deb etc. now:
http://packages.bhaisaab.org/cloudstack/testing/centos/4.5/

This is not supposed to be a publicly consumable hosting so I keep 
adding/removing stuff, so something packages may get deleted.
I’ll try to fix this issue by hosting a nightlies repo, will share when it’s 
done.

> On 23-Apr-2015, at 4:16 pm, Keerthiraja SJ  wrote:
>
> Hi All,
>
> I am trying to validate ACS 4.5.1 rpm installation. Kindly let me know
> which repo should I have to point.
>
> There is no rpm's available in the below location.
>
> RPM: http://packages.bhaisaab.org/cloudstack/testing/centos/4.5/
> SystemVM Templates: http://packages.shapeblue.com/systemvmtemplate/4.5/4.5.0
>
>
> Thanks,
> Keerthi

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
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Software 
Engineering
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

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.

Re: ACS 4.5.1 repo please

[Nux!]

Hi,

I have some here from the last RC: http://tmp.nux.ro/acs451/

HTH
Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Keerthiraja SJ" 
> To: dev@cloudstack.apache.org
> Sent: Thursday, 23 April, 2015 15:16:52
> Subject: ACS 4.5.1 repo please

> Hi All,
> 
> I am trying to validate ACS 4.5.1 rpm installation. Kindly let me know
> which repo should I have to point.
> 
> There is no rpm's available in the below location.
> 
> RPM: http://packages.bhaisaab.org/cloudstack/testing/centos/4.5/
> SystemVM Templates: http://packages.shapeblue.com/systemvmtemplate/4.5/4.5.0
> 
> 
> Thanks,
> Keerthi

Jenkins build is still unstable: simulator-4.5-singlerun #215

[jenkins]

See 

Jenkins build is still unstable: simulator-singlerun #1139

[jenkins]

See 

Re: [DISCUSS] Moving to Java 8

[Marcus]

Great to see someone working on it. What sorts of roadblocks came out
of reflection? How does the wrapper design solve the pluggability
issue? This is pretty important to me, since I've worked with several
companies now that end up subclassing LibvirtComputingResource in
order to handle their own Commands on the hypervisor from their
server-side plugins, and changing their 'resource' to that in
agent.properties. Since the main agent class needs to be set at agent
join, this is harder to manage than it should be.

I mentioned the reflection model because that's how I tend to handle
the commands when subclassing LibvirtComputingResource. I haven't had
any problems with it, but then again I haven't tried to refactor 5500
lines into that model, either.

On Thu, Apr 23, 2015 at 1:17 AM, Wilder Rodrigues
 wrote:
> Hi Marcus,
>
> I like the annotation idea, but reflection is trick because it hides some
> information about the code.
>
> Please, have a look at the CitrixResourceBase after the refactor I did. It
> became quite smaller and test coverage was improved.
>
> URL:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactoring+XenServer+Hypervisor+Plugin
>
> The same patter is being about to Libvirt stuff. The coverage on the KVM
> hypervisor plugin already went from 4 to 10.5% after refactoring 6 commands
>
> Cheers,
> Wilder
>
> On 22 Apr 2015, at 23:06, Marcus  wrote:
>
> Kind of a tangent, but I'd actually like to see some work done to
> clean up LibvirtComputing resource. One model I've prototyped that
> seems to work is to create an annotation, such as
> 'KVMCommandExecutor', with a 'handles' property. With this annotation,
> you implement a class that handles, e.g. StartCommand, etc. Then in
> LibvirtComputingResource, the 'configure' method fetches all of these
> executors via reflection and stores them in an object. Then, instead
> of having all of the 'instanceof' lines in LibvirtComputingResource,
> the executeRequest method fetches the executor that handles the
> incoming command and runs it.
>
> I think this would break up LibvirtComputingResource into smaller,
> more testable and manageable chunks, and force things like config and
> utility methods to move to a more sane location, as well. As a bonus,
> this model makes things pluggable. Someone could ship KVM plugin code
> containing standalone command executors that are discovered at runtime
> for things they need to run at the hypervisor level.
>
> On Tue, Apr 21, 2015 at 6:27 AM, Wilder Rodrigues
>  wrote:
>
> Hi all,
>
> Yesterday I started working on the LibvirtComputingResource class in order
> to apply the same patterns I used in the CitrixResourceBase + add more unit
> tests to it After 10 hours of work I got a bit stuck with the 1st test,
> which would cover the refactored LibvirtStopCommandWrapper. Why did I get
> stuck? The class used a few static methods that call native libraries, which
> I would like to mock. However, when writing the tests I faced problems with
> the current Mockito/PowerMock we are using: they are simply not enough for
> the task.
>
> What did I do then? I added a dependency to EasyMock and PowerMock-EasyMock
> API. It worked almost fine, but I had to add a “-noverify” to both my
> Eclipse Runtime configuration and also to the
> cloud-plugin-hypervisor-kvm/pom.xml file. I agree that’s not nice, but was
> my first attempt of getting it to work. After trying to first full build I
> faced more problems related to ClassDefNotFoundExpcetion which were
> complaining about Mockito classes. I then found out that adding the
> PowerMockRunner to all the tests classes was going to be a heavy burden and
> would also mess up future changes (e.g. the -noverify flag was removed from
> Java 8, thus adding it now would be a problem soon).
>
> Now that the first 2 paragraphs explain a bit about the problem, let’s get
> to the solution: Java 8
>
> The VerifyError that I was getting was due to the use of the latest EasyMock
> release (3.3.1). I tried to downgrade it to 3.1/3.2 but it also did not
> work. My decision: do not refactor if the proper tests cannot be added. This
> left me with one action: migrate to Java 8.
>
> There were mentions about Java 8 in february[1] and now I will put some
> energy in making it happen.
>
> What is your opinion on it?
>
> Thanks in advance.
>
> Cheers,
> Wilder
>
> http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201502.mbox/%3c54eef6be.5040...@shapeblue.com%3E>
>
>

Jenkins build is still unstable: simulator-singlerun #1138

[jenkins]

See 

ACS 4.5.1 repo please

[Keerthiraja SJ]

Hi All,

I am trying to validate ACS 4.5.1 rpm installation. Kindly let me know
which repo should I have to point.

There is no rpm's available in the below location.

RPM: http://packages.bhaisaab.org/cloudstack/testing/centos/4.5/
SystemVM Templates: http://packages.shapeblue.com/systemvmtemplate/4.5/4.5.0


Thanks,
Keerthi

Fwd: ACS 4.5.1 fails

[Keerthiraja SJ]

Hi All,

I installed the ACS in my VirtualBox. After I install the CS with 4GB base
memory I could not able to start the server.

I scale the memory upto 12GB still I could not able to start the ACS.
In /var/log/cloudstack/management/catalina.out I could see error as

Can't start up: not enough memory
Can't start up: not enough memory
Can't start up: not enough memory
Can't start up: not enough memory
Can't start up: not enough memory
Can't start up: not enough memory
Can't start up: not enough memory
Can't start up: not enough memory
Can't start up: not enough memory
Can't start up: not enough memory

Is I missing anything.

In the default file of below I could see the java value as default.

tomcat6.conf -> /etc/cloudstack/management/tomcat6-nonssl.conf

JAVA_OPTS="-Djava.awt.headless=true -Dcom.sun.management.jmxremote=false
-Xmx2g -XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/var/log/cloudstack/management/ -XX:PermSize=512M
-XX:MaxPermSize=800m
-Djava.security.properties=/etc/cloudstack/management/java.security.ciphers"


Kindly let me know if any one found this issue.

I used the shapeblue  repo.

Thanks,
Keerthi

[GitHub] cloudstack pull request: GetUsageRecordsCmd - NewInputFormat for S...

[svscorp]

Github user svscorp commented on the pull request:

https://github.com/apache/cloudstack/pull/185#issuecomment-95592190
  
After making more tests, there is one more commit added to remove 
unnecessary adjustToDayStart/End code, since ParamProcessWorker is actually 
taking care of building proper date in new format.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Jenkins build is still unstable: simulator-4.5-singlerun #214

[jenkins]

See 

[GitHub] cloudstack pull request: GetUsageRecordsCmd - NewInputFormat for S...

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/185#issuecomment-95586207
  
LGTM! Thanks for the PR @svscorp 
I'll wait if @kishankavala wants to review


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: tool to aid db comaprision for upgrade te...

[shwetaag]

GitHub user shwetaag opened a pull request:

https://github.com/apache/cloudstack/pull/188

tool to aid db comaprision for upgrade testing

What this tool is capable to do is

1.  Compare all the tables schema between upgraded setup and fresh install 
setup  and find if there is any schema difference between any tables
2.  Compare global configuration between upgraded and fresh install setup 
and find out if there is any difference between the two on following fields
a.  Value
b.  Scope
c.  Description
d.  Component
e.  Category


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/shwetaag/cloudstack tools

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/188.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #188


commit 7f917f26a8b9700310144e031ecda5d82b00435e
Author: shweta agarwal 
Date:   2015-04-23T11:42:30Z

tool to aid db comaprision for upgrade testing




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8395: vmops plugin should work...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cloudstack/pull/186


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] test results data model

[Wido den Hollander]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 23-04-15 13:31, Daan Hoogland wrote:
> H,
> 
> I want to step away from the discussion about the cycle of
> releases before we get into another deadlock there. Just let it be
> said that ShapeBlue and Schuberg Philis are clearly not the same
> company;)
> 
> We agreed on having a central reports database of test results to
> be able to generate a compatibility matrix. (citation needed) I had
> a short oiliest talk with Wido about this to align it with his
> usage database. When the machine for this is ready @infra we can
> put either an extra schema or an extension of the usage schema to
> contain the test data. I opt for the latter as the usage itself is
> very useful as compatibility data as well.
> 
> a first shot at the db design: hardware: type, version cloudstack:
> version environment:
> hardware.id,cloudstack.id,testdate,reportdate,contactdata
> 
> - hardware and cloudstack can be shared tables with the usage db
> (@widoh right?)

Yes, correct! That should be possible. My usage reporter simply
generates a JSON which I then store in ElasticSearch.

Wido

> - I put in contact data for audibility. Usage or test data that is 
> anonymous shouldn't be counted as there is no way of control or 
> feedback.
> 
> catch22ish: contradicting reports may be submitted
> 
> thoughts?
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJVON7tAAoJEAGbWC3bPspCMSEQAKytv2mcb48xXiOz+ghNmTWv
qnGCY3dOoEGqSYFvIyS15jlglnz3mMRmv8yY7mSH7Xf9Uuh2mUQlIsNxkJmR5/4L
/9b4XaEkAirQbyZHYrG7VOWZAxxJ3HM41PMV/TSMUHXHVfCzMheFAj9oaVDl8K2/
rz1KKYiqwhcQqEBoI8C8Lp0MoUNafomCzZPtXzqkpTA1AV4YkDk1zQe7jk8wX6wd
35j3ImDBVVQ1N769nrA+DovsqkQw+dhVPAWOTIqZOK/iC+qF3b5+e9/7TFQ2x6F3
iQEctjXc/N345JQA7Iby3oHu8qjWJVONRRs/iRoof/sLtxmIZaXc0BjF7ry0aZhk
5JZdB+Ddu+H3gTMpzoWchaSzbvQQlMPhzPnb/Gb+KAf4hr3H61ARbhCjuUd4PDkG
TR04zATO7EPBhGmCmDsPmesgpNhrTVIbI1x47alKtdQa2gDqJz8ykdLsr2DlibBB
qYnTzoJ+6MItHKNvMwnrY/xv2q1L/Z+bYN2abLJV0nmpDea2PuiQMGk1XjOiOIxa
Vv3V6cKriurMpCgpaB9heefUCUd7894OvSadXYB51Fm+gTkXy8BL5O6c+Xc7lf6r
qZwkARPl5SB5SNVxyxScuUlDYj+TaiJecNLtfcrd4hcyM/l5akEDKElxnfp+wiHi
/CZdHp8MfVVn9yjS7RSR
=Hr2i
-END PGP SIGNATURE-

[GitHub] cloudstack pull request: Escalations

[shwetaag]

Github user shwetaag closed the pull request at:

https://github.com/apache/cloudstack/pull/184


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Edit permission to wiki

[Daan Hoogland]

guys, have yourself an account on the wiki and mention it here. I will
give you access to our space.

On Thu, Apr 23, 2015 at 12:49 PM, Vaibhav Gupta
 wrote:
> To me too..
>
> Thanks,
> Vaibhav
>
>
> -Original Message-
> From: Jayashree Ramamoorthy [mailto:jayashree.ramamoor...@citrix.com]
> Sent: 23 April 2015 16:03
> To: dev@cloudstack.apache.org
> Subject: Edit permission to wiki
>
> Hi,
>
> Kindly give me edit permission to the wiki.
>
> Thanks,
> Jayashree
>



-- 
Daan

[DISCUSS] test results data model

[Daan Hoogland]

H,

I want to step away from the discussion about the cycle of releases
before we get into another deadlock there. Just let it be said that
ShapeBlue and Schuberg Philis are clearly not the same company;)

We agreed on having a central reports database of test results to be
able to generate a compatibility matrix. (citation needed) I had a
short oiliest talk with Wido about this to align it with his usage
database. When the machine for this is ready @infra we can put either
an extra schema or an extension of the usage schema to contain the
test data. I opt for the latter as the usage itself is very useful as
compatibility data as well.

a first shot at the db design:
hardware: type, version
cloudstack: version
environment: hardware.id,cloudstack.id,testdate,reportdate,contactdata

- hardware and cloudstack can be shared tables with the usage db (@widoh right?)
- I put in contact data for audibility. Usage or test data that is
anonymous shouldn't be counted as there is no way of control or
feedback.

catch22ish: contradicting reports may be submitted

thoughts?
-- 
Daan

RE: Edit permission to wiki

[Vaibhav Gupta]

To me too..

Thanks,
Vaibhav 


-Original Message-
From: Jayashree Ramamoorthy [mailto:jayashree.ramamoor...@citrix.com] 
Sent: 23 April 2015 16:03
To: dev@cloudstack.apache.org
Subject: Edit permission to wiki

Hi,

Kindly give me edit permission to the wiki.

Thanks,
Jayashree

Re: Next ACS release?

[Abhinandan Prateek]

A smaller release cycle benefits individual companies running their own cloud. 
Basically they are looking for the next versions that have features that they 
need or are incrementally moving to new releases smoothly as they know what 
they need, the test environment and deployment is with them and can quickly 
figure out if a release is worth moving to or not.

Companies providing services need to worry about all the versions out there 
that their customers are using. In general with many versions around you need 
to support and patch more and more versions as time goes on. The QA needs to be 
more extensive here as the real deployment is somewhere else. More releases in 
use create bigger overhead.

The release timelines suggested are from 2 weeks to 6 months !   We can target 
for a smaller release cycle but I don’t think we are there yet to have a two 
week release cycle.
For a smaller release cycle the RM needs to ensure that very specific code gets 
in. The test coverage is measured and is good so that it almost eliminates the 
possibility of regression.
To decrease release cycle companies should collaborate more on QA, like they 
can divide the QA work and also share the QA automation results.

Some of this is already happening like the infra that SBP, Daan and others have 
put in place, I accept my ignorance of some of these things that are already 
there.

We can target for a major release very six month and can have incremental 
fortnightly releases with control on patches and fixes that get in.

-abhi


> On 23-Apr-2015, at 3:26 pm, Ian Southam  wrote:
>
> At SBP, we are working on two environments for testing.  Primarily focussed 
> on Xen and KVM with Nicira and without Nicira.
>
> One will focus more on building and extending the current integration tests 
> and making sure they are running on real hardware in real life situations.  
> The other we are planning to be more “chaos monkey” in operation.  So 
> genuinely testing how the system reacts to hypervisors crashing.  Loss of 
> network connectivity, VR failures/failovers and so on.
>
> I know other people in the community are doing similar things.  By having 
> enough such systems that together have a high coverage of all the various 
> configuration and hardware combinations out there, we should be able to 
> really get to a much shorter delivery cycle with quite high levels of 
> confidence about quality.
>
> We are not there yet but, I am absolutely convinced that aiming for a 2 week 
> release cycle is the way to go.
>
> —
> Grts!
> Ian
>
>> On 23 Apr 2015, at 10:38, Abhinandan Prateek 
>>  wrote:
>>
>> On automated QA front following is available:
>>
>> 1. Before pushing in a feature a dev can run simulator based tests that will 
>> basically test various functionality that does not depend on the type of 
>> Hypervisor.
>> (https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes%2C+using+Simulator.)
>> The test suite are located in testing/integration/smoke folder.
>> The travis system runs most of the test in this folder.
>>
>>
>> 2. Then there are tests that will require real hardware to run most of these 
>> are in testing/integration/component.
>>
>>
>> Basically there are two kind of test cases not strictly classified as per 
>> above directory structure - Ones that have required_hardware set as “false” 
>> and “others” that have this as “true”.
>> The one with required_hardware is false can run on simulator but for the 
>> others you need a real Hypervisor based environment.
>>
>> I have been able to run a lot of tests both with hardware and simulator. The 
>> problem I faced is scattered documentation. Missing description of a model 
>> deployment; say for a particular Hypervisor that will allow a dev to run the 
>> provisioning tests.
>>
>> In all there is a huge scope for improvement.
>>
>>
>> -abhi
>>
>>
>>> On 23-Apr-2015, at 1:02 am, Remi Bergsma  wrote:
>>>
>>> Hi,
>>>
>>> The '2 week cycle' was intended as something to work towards, like a
>>> mission. The nice thing is that it immediately shows that we cannot achieve
>>> such a thing if we keep our current method of (semi)manual testing, as you
>>> said. Totally agree.
>>>
>>> That's why we need to improve on our automated functional testing. And that
>>> will of course take time and effort. As I don't currently have a clear
>>> overview of what is already available, I'll try to get that first and work
>>> from there. I spoke to several people recently and most seem to do testing
>>> on their own way (with sometimes cool automatic stuff going on!). It'd be
>>> interesting to bring that together and share.
>>> I think improving this is important, so I'll try to spend as much time on
>>> this as possible.
>>>
>>> However, the tread started with comments on 4.5. Let's try to get it stable
>>> and deliver 4.5.1. What is still to be done here? Can we share the load
>>> somehow to fasten it?
>>>
>>> Regards,
>>> Remi
>>>
>>> 2015-0

Edit permission to wiki

[Jayashree Ramamoorthy]

Hi,

Kindly give me edit permission to the wiki.

Thanks,
Jayashree

ACS 4.5.1 fails

[Keerthiraja SJ]

Hi All,

I installed the ACS in my VirtualBox. After I install the CS with 4GB base
memory I could not able to start the server.

I scale the memory upto 12GB still I could not able to start the ACS.
In /var/log/cloudstack/management/catalina.out I could see error as

Can't start up: not enough memory
Can't start up: not enough memory
Can't start up: not enough memory
Can't start up: not enough memory
Can't start up: not enough memory
Can't start up: not enough memory
Can't start up: not enough memory
Can't start up: not enough memory
Can't start up: not enough memory
Can't start up: not enough memory

Is I missing anything.

In the default file of below I could see the java value as default.

tomcat6.conf -> /etc/cloudstack/management/tomcat6-nonssl.conf

JAVA_OPTS="-Djava.awt.headless=true -Dcom.sun.management.jmxremote=false
-Xmx2g -XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/var/log/cloudstack/management/ -XX:PermSize=512M
-XX:MaxPermSize=800m
-Djava.security.properties=/etc/cloudstack/management/java.security.ciphers"


Kindly let me know if any one found this issue.

I used the shapeblue  repo.

Thanks,
Keerthi

Re: Next ACS release?

[Daan Hoogland]

@bhinandan and others,

note that we have
http://jenkins.buildacloud.org/view/parameterized/job/parameterized-slowbuild/
and 
https://builds.apache.org/view/A-D/view/Cloudstack/job/cloudstack-pull-requests/

those should give people a good idea on whether a branch can be merged
to master based on simulator. Of course this is only a first step but
let's use them intensively.

On Thu, Apr 23, 2015 at 11:56 AM, Ian Southam
 wrote:
> At SBP, we are working on two environments for testing.  Primarily focussed 
> on Xen and KVM with Nicira and without Nicira.
>
> One will focus more on building and extending the current integration tests 
> and making sure they are running on real hardware in real life situations.  
> The other we are planning to be more “chaos monkey” in operation.  So 
> genuinely testing how the system reacts to hypervisors crashing.  Loss of 
> network connectivity, VR failures/failovers and so on.
>
> I know other people in the community are doing similar things.  By having 
> enough such systems that together have a high coverage of all the various 
> configuration and hardware combinations out there, we should be able to 
> really get to a much shorter delivery cycle with quite high levels of 
> confidence about quality.
>
> We are not there yet but, I am absolutely convinced that aiming for a 2 week 
> release cycle is the way to go.
>
> —
> Grts!
> Ian
>
>> On 23 Apr 2015, at 10:38, Abhinandan Prateek 
>>  wrote:
>>
>> On automated QA front following is available:
>>
>> 1. Before pushing in a feature a dev can run simulator based tests that will 
>> basically test various functionality that does not depend on the type of 
>> Hypervisor.
>> (https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes%2C+using+Simulator.)
>> The test suite are located in testing/integration/smoke folder.
>> The travis system runs most of the test in this folder.
>>
>>
>> 2. Then there are tests that will require real hardware to run most of these 
>> are in testing/integration/component.
>>
>>
>> Basically there are two kind of test cases not strictly classified as per 
>> above directory structure - Ones that have required_hardware set as “false” 
>> and “others” that have this as “true”.
>> The one with required_hardware is false can run on simulator but for the 
>> others you need a real Hypervisor based environment.
>>
>> I have been able to run a lot of tests both with hardware and simulator. The 
>> problem I faced is scattered documentation. Missing description of a model 
>> deployment; say for a particular Hypervisor that will allow a dev to run the 
>> provisioning tests.
>>
>> In all there is a huge scope for improvement.
>>
>>
>> -abhi
>>
>>
>>> On 23-Apr-2015, at 1:02 am, Remi Bergsma  wrote:
>>>
>>> Hi,
>>>
>>> The '2 week cycle' was intended as something to work towards, like a
>>> mission. The nice thing is that it immediately shows that we cannot achieve
>>> such a thing if we keep our current method of (semi)manual testing, as you
>>> said. Totally agree.
>>>
>>> That's why we need to improve on our automated functional testing. And that
>>> will of course take time and effort. As I don't currently have a clear
>>> overview of what is already available, I'll try to get that first and work
>>> from there. I spoke to several people recently and most seem to do testing
>>> on their own way (with sometimes cool automatic stuff going on!). It'd be
>>> interesting to bring that together and share.
>>> I think improving this is important, so I'll try to spend as much time on
>>> this as possible.
>>>
>>> However, the tread started with comments on 4.5. Let's try to get it stable
>>> and deliver 4.5.1. What is still to be done here? Can we share the load
>>> somehow to fasten it?
>>>
>>> Regards,
>>> Remi
>>>
>>> 2015-04-22 20:13 GMT+02:00 Paul Angus :
>>>
 I fully support the idea of a stable master with an automated CD process
 to protect against regressions.

 However, we obviously don't currently have fantastic integration
 testing otherwise we wouldn't have relied on 'people' to pick up the
 release blockers recently.  A 2 week release cycle IMHO is way too frequent
 to expect 'people' to be carrying out integration testing.

 Maybe 1 month is a workable compromise until the integration testing is of
 a coverage and standard that can give real confidence.



 I'm also going to compile a list of people who vote "+1 - it works on my
 laptop" and devise a Guinness related punishment for any of them that show
 up at the CloudStack day in Dublin.

 Regards

 Paul Angus
 Cloud Architect
 S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
 paul.an...@shapeblue.com

 -Original Message-
 From: Remi Bergsma [mailto:r...@remi.nl]
 Sent: 22 April 2015 10:25
 To: dev@cloudstack.apache.org
 Subject: Re: Next ACS release?

 I'd 

Re: Next ACS release?

[Ian Southam]

At SBP, we are working on two environments for testing.  Primarily focussed on 
Xen and KVM with Nicira and without Nicira.

One will focus more on building and extending the current integration tests and 
making sure they are running on real hardware in real life situations.  The 
other we are planning to be more “chaos monkey” in operation.  So genuinely 
testing how the system reacts to hypervisors crashing.  Loss of network 
connectivity, VR failures/failovers and so on.

I know other people in the community are doing similar things.  By having 
enough such systems that together have a high coverage of all the various 
configuration and hardware combinations out there, we should be able to really 
get to a much shorter delivery cycle with quite high levels of confidence about 
quality.

We are not there yet but, I am absolutely convinced that aiming for a 2 week 
release cycle is the way to go. 

—
Grts!
Ian

> On 23 Apr 2015, at 10:38, Abhinandan Prateek 
>  wrote:
> 
> On automated QA front following is available:
> 
> 1. Before pushing in a feature a dev can run simulator based tests that will 
> basically test various functionality that does not depend on the type of 
> Hypervisor.
> (https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes%2C+using+Simulator.)
> The test suite are located in testing/integration/smoke folder.
> The travis system runs most of the test in this folder.
> 
> 
> 2. Then there are tests that will require real hardware to run most of these 
> are in testing/integration/component.
> 
> 
> Basically there are two kind of test cases not strictly classified as per 
> above directory structure - Ones that have required_hardware set as “false” 
> and “others” that have this as “true”.
> The one with required_hardware is false can run on simulator but for the 
> others you need a real Hypervisor based environment.
> 
> I have been able to run a lot of tests both with hardware and simulator. The 
> problem I faced is scattered documentation. Missing description of a model 
> deployment; say for a particular Hypervisor that will allow a dev to run the 
> provisioning tests.
> 
> In all there is a huge scope for improvement.
> 
> 
> -abhi
> 
> 
>> On 23-Apr-2015, at 1:02 am, Remi Bergsma  wrote:
>> 
>> Hi,
>> 
>> The '2 week cycle' was intended as something to work towards, like a
>> mission. The nice thing is that it immediately shows that we cannot achieve
>> such a thing if we keep our current method of (semi)manual testing, as you
>> said. Totally agree.
>> 
>> That's why we need to improve on our automated functional testing. And that
>> will of course take time and effort. As I don't currently have a clear
>> overview of what is already available, I'll try to get that first and work
>> from there. I spoke to several people recently and most seem to do testing
>> on their own way (with sometimes cool automatic stuff going on!). It'd be
>> interesting to bring that together and share.
>> I think improving this is important, so I'll try to spend as much time on
>> this as possible.
>> 
>> However, the tread started with comments on 4.5. Let's try to get it stable
>> and deliver 4.5.1. What is still to be done here? Can we share the load
>> somehow to fasten it?
>> 
>> Regards,
>> Remi
>> 
>> 2015-04-22 20:13 GMT+02:00 Paul Angus :
>> 
>>> I fully support the idea of a stable master with an automated CD process
>>> to protect against regressions.
>>> 
>>> However, we obviously don't currently have fantastic integration
>>> testing otherwise we wouldn't have relied on 'people' to pick up the
>>> release blockers recently.  A 2 week release cycle IMHO is way too frequent
>>> to expect 'people' to be carrying out integration testing.
>>> 
>>> Maybe 1 month is a workable compromise until the integration testing is of
>>> a coverage and standard that can give real confidence.
>>> 
>>> 
>>> 
>>> I'm also going to compile a list of people who vote "+1 - it works on my
>>> laptop" and devise a Guinness related punishment for any of them that show
>>> up at the CloudStack day in Dublin.
>>> 
>>> Regards
>>> 
>>> Paul Angus
>>> Cloud Architect
>>> S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
>>> paul.an...@shapeblue.com
>>> 
>>> -Original Message-
>>> From: Remi Bergsma [mailto:r...@remi.nl]
>>> Sent: 22 April 2015 10:25
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: Next ACS release?
>>> 
>>> I'd be happy to help here as well. Last week in Austin, we also discussed
>>> this topic a couple of times. I do agree shorter release cycles are better.
>>> 
>>> In my opinion, the first thing to improve is the minor releases in both the
>>> 4.4 and 4.5 branches. If we speed those up to let's say once every 2-weeks
>>> we will be able to do the next minor release with less effort and users can
>>> choose to either wait to start using 4.5 or start now and upgrade when the
>>> next minor release is available. This would have helped i

Re: add network to VM by assign ip address

[Christian]

Hi all,

It looks like this could be implemented by adding an IP address field to
the NICs tab. I’ve tried this in the labs and it seems to work, but I
admit to having limited knowledge regarding what this might be breaking in
the background :-)

I’m assuming that there is a reason why the CloudStack UI allows us to
choose an IP address at instantiation, but not when adding a NIC to an
existing VM. Can anyone shed any light on this? As Star Guo says, it is
permitted via the API.

Best regards,

-Christian

Christian Lafferty (BT)

-邮件原件-
Does anyone focus on this ?

Best Regards,
Star Guo

-邮件原件-
发件人: Star Guo [mailto:st...@ceph.me]
发送时间: 2015年3月27日 17:22
收件人: dev@cloudstack.apache.org
主题: add network to VM by assign ip address

Hi all,

I run cloudstack branch master in simulator. I add network to VM but cannot
assign IP for vNIC.

I just see URL:
http://cloudstack.apache.org/docs/api/apidocs-4.5/root_admin/addNicToVirtua
l Machine.html

AddNicToVirtualMachine supports assign ipaddress. Cloud any one who focus
on UI add ipaddress request parameters.

I hope UI support it instead of using CloudMonkey CLI tool but I have
little knowledge of css, js. Thanks.

Best Regards,
Star Guo

Re: CentOS 7 KVM Agent installation fails

[Wido den Hollander]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 21-04-15 22:11, Remi Bergsma wrote:
> Hi Wido,
> 
> Take them from here: 
> http://jenkins.buildacloud.org/view/4.4/job/package-centos7-4.4-noredi
st/
> 
>
>  or here: http://cloudstack.apt-get.eu/centos/4.4/7/
> 
> 
> Worked for me.
> 

Yes, they work just fine!

> Regards, Remi
> 
> 
>> On 21 Apr 2015, at 20:10 , Remi Bergsma  wrote:
>> 
>> Hi,
>> 
>> The RPM’s I use were baked from the 4.4 branch (4.4.3-SNAPSHOT) a
>> few weeks back. Hence, the now released 4.4.3 should also work.
>> Marcus is right, the dependency is now on ‘java >= 1.7.0’.
>> 
>> CentOS 7 support was needed in our setup and Daan helped me
>> backport the needed changes from to 4.4. This allowed me to test
>> in a production-like environment and fix whatever did not work
>> properly. These patches are included in 4.4.3. Even though it
>> runs fine now, we will probably find some new issues over time so
>> I can understand the ’tech preview’ status.
>> 
>> If you need more info or help, drop me a line.
>> 
>> Regards, Remi
>> 
>> 
>>> On 21 Apr 2015, at 18:38 , Marcus  wrote:
>>> 
>>> This requires has actually bitten us in the past. It needs to
>>> change to 'java-1.7.0', because 'java7' isn't satisfied by
>>> anything in EL7, and 'java >= 1.7.0' actually is satisfied by
>>> java 1.6 due to epoch issues.
>>> 
>>> That said, EL7 support was considered 'tech preview' even with
>>> 4.5, I'm not sure what the status of it is in 4.4.
>>> 
>>> Also, in 4.5 we use packaging/centos63/package.sh -o rhel7. I
>>> haven't researched why/when this was added here or if it is
>>> applicable to 4.4, but it works.
>>> 
>>> On Tue, Apr 21, 2015 at 9:17 AM, Remi Bergsma 
>>> wrote:
 There are some fixes in 4.4.3 for kvm on CentOS7 so that's a
 good idea.
 
 Regards, Remi
 
 Sent from my iPhone
 
> On 21 Apr 2015, at 18:09, Rohit Yadav
>  wrote:
> 
> Hi Wido,
> 
> You can try the latest 4.4.3 release from this EL6 repo:
> http://packages.shapeblue.com/cloudstack/upstream/centos/4.4
>
>>
> 
On 21-Apr-2015, at 4:25 pm, Wido den Hollander  wrote:
>> 
 On 04/21/2015 04:10 PM, Remi Bergsma wrote: Hi Wido,
 
 We run kvm on centos7 without problems. When I'm back
 in the office I will check which package we used. It
 seems el6 is for centos6?
> 
> Thanks! Aha, let me check if the packages coming from Jenkins do
> work.
> 
> Wido
> 
 Will let you know!
 
 Remi
 
 Sent from my iPhone
 
> On 21 Apr 2015, at 16:00, Wido den Hollander
>  wrote:
 Hi,
 
 I'm trying to install cloudstack-agent on CentOS but
 it fails with:
 
 --> Finished Dependency Resolution Error: Package: 
 cloudstack-agent-4.4.2-NONOSS_1.el6.x86_64
 (cloudstack-repo) Requires: java7 Error: Package: 
 cloudstack-common-4.4.2-NONOSS_1.el6.x86_64
 (cloudstack-repo) Requires: python(abi) = 2.6
 Installed: python-2.7.5-16.el7.x86_64 (@anaconda)
 python(abi) = 2.7 python(abi) = 2.7 You could try
 using --skip-broken to work around the problem You
 could try running: rpm -Va --nofiles --nodigest
 
 
 Looking at packaging/centos7/cloud.spec I found
 this:
 
 %package agent Summary: CloudStack Agent for KVM
 hypervisors . Requires: java => 1.7.0 .
 
 So where does "java7" come from?
 
 I used these packages btw:
 http://cloudstack.apt-get.eu/rhel/4.4/
 
 Any clues on why this is happening?
 
 Wido
> 
> 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 
> CSForge – rapid IaaS deployment
> framework CloudStack
> Consulting 
> CloudStack Software
> Engineering
>
> 
CloudStack Infrastructure
Support
> CloudStack Bootcamp Training
> Courses
> 
> 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

Re: Next ACS release?

[Abhinandan Prateek]

On automated QA front following is available:

1. Before pushing in a feature a dev can run simulator based tests that will 
basically test various functionality that does not depend on the type of 
Hypervisor.
(https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes%2C+using+Simulator.)
The test suite are located in testing/integration/smoke folder.
The travis system runs most of the test in this folder.


2. Then there are tests that will require real hardware to run most of these 
are in testing/integration/component.


Basically there are two kind of test cases not strictly classified as per above 
directory structure - Ones that have required_hardware set as “false” and 
“others” that have this as “true”.
The one with required_hardware is false can run on simulator but for the others 
you need a real Hypervisor based environment.

I have been able to run a lot of tests both with hardware and simulator. The 
problem I faced is scattered documentation. Missing description of a model 
deployment; say for a particular Hypervisor that will allow a dev to run the 
provisioning tests.

In all there is a huge scope for improvement.


-abhi


> On 23-Apr-2015, at 1:02 am, Remi Bergsma  wrote:
>
> Hi,
>
> The '2 week cycle' was intended as something to work towards, like a
> mission. The nice thing is that it immediately shows that we cannot achieve
> such a thing if we keep our current method of (semi)manual testing, as you
> said. Totally agree.
>
> That's why we need to improve on our automated functional testing. And that
> will of course take time and effort. As I don't currently have a clear
> overview of what is already available, I'll try to get that first and work
> from there. I spoke to several people recently and most seem to do testing
> on their own way (with sometimes cool automatic stuff going on!). It'd be
> interesting to bring that together and share.
> I think improving this is important, so I'll try to spend as much time on
> this as possible.
>
> However, the tread started with comments on 4.5. Let's try to get it stable
> and deliver 4.5.1. What is still to be done here? Can we share the load
> somehow to fasten it?
>
> Regards,
> Remi
>
> 2015-04-22 20:13 GMT+02:00 Paul Angus :
>
>> I fully support the idea of a stable master with an automated CD process
>> to protect against regressions.
>>
>> However, we obviously don't currently have fantastic integration
>> testing otherwise we wouldn't have relied on 'people' to pick up the
>> release blockers recently.  A 2 week release cycle IMHO is way too frequent
>> to expect 'people' to be carrying out integration testing.
>>
>> Maybe 1 month is a workable compromise until the integration testing is of
>> a coverage and standard that can give real confidence.
>>
>>
>>
>> I'm also going to compile a list of people who vote "+1 - it works on my
>> laptop" and devise a Guinness related punishment for any of them that show
>> up at the CloudStack day in Dublin.
>>
>> Regards
>>
>> Paul Angus
>> Cloud Architect
>> S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
>> paul.an...@shapeblue.com
>>
>> -Original Message-
>> From: Remi Bergsma [mailto:r...@remi.nl]
>> Sent: 22 April 2015 10:25
>> To: dev@cloudstack.apache.org
>> Subject: Re: Next ACS release?
>>
>> I'd be happy to help here as well. Last week in Austin, we also discussed
>> this topic a couple of times. I do agree shorter release cycles are better.
>>
>> In my opinion, the first thing to improve is the minor releases in both the
>> 4.4 and 4.5 branches. If we speed those up to let's say once every 2-weeks
>> we will be able to do the next minor release with less effort and users can
>> choose to either wait to start using 4.5 or start now and upgrade when the
>> next minor release is available. This would have helped in getting 4.5 out
>> on time and quickly fixing issues after the initial release. Also, it will
>> save time which we can invest in getting the next release out on time, etc.
>>
>> The common thing here is we need more automated testing, preferably
>> functional testing in addition to unit testing. There might also be other
>> steps that we do manually now that can be automated. I'll try to understand
>> the current process first and then come up with a proposal to improve which
>> we can discuss.
>>
>> Regards,
>> Remi
>>
>> 2015-04-22 10:56 GMT+02:00 Erik Weber :
>>
>>> On Wed, Apr 22, 2015 at 10:46 AM, Daan Hoogland
>>> 
>>> wrote:
>>>
 On Wed, Apr 22, 2015 at 10:29 AM, Erik Weber 
>>> wrote:
> On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner <
 stephen.tur...@citrix.com>
> wrote:
>
>> I have to admit I'm a bit sceptical because when we did have a
 four-month
>> release cycle, we never seemed to manage to meet it. Personally I
>>> think
>> six-monthly might be easier.
>>
>> Having said that, part of the problem was the long close-down
>> period
 where
>> we 

Re: [DISCUSS] Moving to Java 8

[Wilder Rodrigues]

Hi Marcus,

I like the annotation idea, but reflection is trick because it hides some 
information about the code.

Please, have a look at the CitrixResourceBase after the refactor I did. It 
became quite smaller and test coverage was improved.

URL: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactoring+XenServer+Hypervisor+Plugin

The same patter is being about to Libvirt stuff. The coverage on the KVM 
hypervisor plugin already went from 4 to 10.5% after refactoring 6 commands

Cheers,
Wilder

On 22 Apr 2015, at 23:06, Marcus 
mailto:shadow...@gmail.com>> wrote:

Kind of a tangent, but I'd actually like to see some work done to
clean up LibvirtComputing resource. One model I've prototyped that
seems to work is to create an annotation, such as
'KVMCommandExecutor', with a 'handles' property. With this annotation,
you implement a class that handles, e.g. StartCommand, etc. Then in
LibvirtComputingResource, the 'configure' method fetches all of these
executors via reflection and stores them in an object. Then, instead
of having all of the 'instanceof' lines in LibvirtComputingResource,
the executeRequest method fetches the executor that handles the
incoming command and runs it.

I think this would break up LibvirtComputingResource into smaller,
more testable and manageable chunks, and force things like config and
utility methods to move to a more sane location, as well. As a bonus,
this model makes things pluggable. Someone could ship KVM plugin code
containing standalone command executors that are discovered at runtime
for things they need to run at the hypervisor level.

On Tue, Apr 21, 2015 at 6:27 AM, Wilder Rodrigues
mailto:wrodrig...@schubergphilis.com>> wrote:
Hi all,

Yesterday I started working on the LibvirtComputingResource class in order to 
apply the same patterns I used in the CitrixResourceBase + add more unit tests 
to it After 10 hours of work I got a bit stuck with the 1st test, which would 
cover the refactored LibvirtStopCommandWrapper. Why did I get stuck? The class 
used a few static methods that call native libraries, which I would like to 
mock. However, when writing the tests I faced problems with the current 
Mockito/PowerMock we are using: they are simply not enough for the task.

What did I do then? I added a dependency to EasyMock and PowerMock-EasyMock 
API. It worked almost fine, but I had to add a “-noverify” to both my Eclipse 
Runtime configuration and also to the cloud-plugin-hypervisor-kvm/pom.xml file. 
I agree that’s not nice, but was my first attempt of getting it to work. After 
trying to first full build I faced more problems related to 
ClassDefNotFoundExpcetion which were complaining about Mockito classes. I then 
found out that adding the PowerMockRunner to all the tests classes was going to 
be a heavy burden and would also mess up future changes (e.g. the -noverify 
flag was removed from Java 8, thus adding it now would be a problem soon).

Now that the first 2 paragraphs explain a bit about the problem, let’s get to 
the solution: Java 8

The VerifyError that I was getting was due to the use of the latest EasyMock  
release (3.3.1). I tried to downgrade it to 3.1/3.2 but it also did not work. 
My decision: do not refactor if the proper tests cannot be added. This left me 
with one action: migrate to Java 8.

There were mentions about Java 8 in february[1] and now I will put some energy 
in making it happen.

What is your opinion on it?

Thanks in advance.

Cheers,
Wilder

http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201502.mbox/%3c54eef6be.5040...@shapeblue.com%3E>

Re: Next ACS release?

[Sebastien Goasguen]

Folks, great discussion. I am on vacation, so not ignoring.
Will chime in when i return.

-Sebastien

> On 23 Apr 2015, at 09:57, Daan Hoogland  wrote:
> 
> Paul,
> This will be interesting:
> "I'm also going to compile a list of people who vote "+1 - it works on my
> laptop" and devise a Guinness related punishment for any of them that show
> up at the CloudStack day in Dublin."
> 
> Why don't you start on list and see how this improves test quality.
> 
> I agree wiith David on the harm bugfixes. can do. The two week cycle is
> ment as a moment for initializing a bf rc, not all of them have to make it
> or be deemed necessary.
> 
> mobile dev with bilingual spelling checker used (read at your own risk)
> Op 23 apr. 2015 00:50 schreef "David Nalley" :
> 
>> On Wed, Apr 22, 2015 at 4:47 PM, Marcus  wrote:
>>> We just have to do it.  We just freeze master at some point, do all of
>>> the release bugfixes, and when it is solid enough to pass a release
>>> vote we branch a release from it, and then only allow merges to master
>>> that have been tested in a merge branch, or something along those
>>> lines. Things will slip through, because our testing isn't full
>>> coverage, but we can begin to add to it.
>>> 
>>> I've said it before, but I think we're also a bit stingy regarding
>>> bugfix releases. Unless we cause a regression, there should be no need
>>> for bugfix releases to go through multiple RCs. We get caught on bugs
>>> that are already in the shipping version and make them blockers for
>>> the other bug fixes, or a pet patch needs to slip in (which also only
>>> matters because bugfix releases are so few and hard to release).
>>> 
>> 
>> It's not just new features that cause problems though.
>> We've had bug fixes that cause issues, sometimes worse than the one
>> they solved. Every change is a threat to stability, so we'd like to
>> have smaller bug fix releases too. There's an inherent cost in doing
>> releases in their current form.
>> 
>> --David
>> 

Re: Next ACS release?

[Daan Hoogland]

Paul,
This will be interesting:
"I'm also going to compile a list of people who vote "+1 - it works on my
laptop" and devise a Guinness related punishment for any of them that show
up at the CloudStack day in Dublin."

Why don't you start on list and see how this improves test quality.

I agree wiith David on the harm bugfixes. can do. The two week cycle is
ment as a moment for initializing a bf rc, not all of them have to make it
or be deemed necessary.

mobile dev with bilingual spelling checker used (read at your own risk)
Op 23 apr. 2015 00:50 schreef "David Nalley" :

> On Wed, Apr 22, 2015 at 4:47 PM, Marcus  wrote:
> > We just have to do it.  We just freeze master at some point, do all of
> > the release bugfixes, and when it is solid enough to pass a release
> > vote we branch a release from it, and then only allow merges to master
> > that have been tested in a merge branch, or something along those
> > lines. Things will slip through, because our testing isn't full
> > coverage, but we can begin to add to it.
> >
> > I've said it before, but I think we're also a bit stingy regarding
> > bugfix releases. Unless we cause a regression, there should be no need
> > for bugfix releases to go through multiple RCs. We get caught on bugs
> > that are already in the shipping version and make them blockers for
> > the other bug fixes, or a pet patch needs to slip in (which also only
> > matters because bugfix releases are so few and hard to release).
> >
>
> It's not just new features that cause problems though.
> We've had bug fixes that cause issues, sometimes worse than the one
> they solved. Every change is a threat to stability, so we'd like to
> have smaller bug fix releases too. There's an inherent cost in doing
> releases in their current form.
>
> --David
>