Re: master marvin install problem

[Daan Hoogland]

thanks guys, that is a rather old issue. When I install
mysql-connector-python it looks in
https://pypi.python.org/simple/mysql-connector-python/. The file does exist
in https://pypi.python.org/pypi/mysql-connector-python/.

strange error to arise all of a sudden.


On Tue, Dec 29, 2015 at 7:54 AM, Jayapal Reddy Uradi <
jayapalreddy.ur...@citrix.com> wrote:

> I got the mysql-connector-python version issue on updating the marvin.
> I removed marvin, installed again and it working without issues.
>
> Thanks,
> Jayapl
>
> > On 29-Dec-2015, at 11:24 am, Srikanteswararao talluri <
> tall...@apache.org> wrote:
> >
> > Looks like Prasanna filed a bug for mysql :
> > https://bugs.mysql.com/bug.php?id=68549
> >
> > Daan, Problem you are facing is because pypi is being updated manually.
> It
> > should go away, try after some time or manually install that package.
> >
> > Thanks,
> > ~Talluri
> >
> > On Mon, Dec 28, 2015 at 6:21 PM, Daan Hoogland 
> > wrote:
> >
> >> People,
> >>
> >> I tried to install marvin 4.8.0-SNAPSHOT this afternoon and found
> >> mysql-connector-python missing from pypi. Is this expected? I tried last
> >> week and everything was dandy.
> >>
> >> --
> >> Daan
> >>
>
>


-- 
Daan

[GitHub] cloudstack pull request: CLOUDSTACK-8895: Verify if storage on sto...

[sanju1010]

Github user sanju1010 commented on the pull request:

https://github.com/apache/cloudstack/pull/869#issuecomment-167752857
  
It is not type Daan. First test inside TestAttachDataDisk class tests some 
functionality on ZWPS and this one is for CWPS.
Test Results :

Attach Data Disk To VM on ZWPS ... === TestName: 
test_01_attach_datadisk_to_vm_on_zwps | Status : SUCCESS === 
ok 
-- 
Ran 1 tests in 122.641s 
OK

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.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8895: Verify if storage on sto...

[sanju1010]

Github user sanju1010 commented on the pull request:

https://github.com/apache/cloudstack/pull/869#issuecomment-167752950
  
@DaanHoogland / @remibergsma can you please merge this PR?


---
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-8895: Verify if storage on sto...

[DaanHoogland]

Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/869#issuecomment-167753605
  
@sanju1010 it shouldn't be in the same file then, or the file should be 
renamed to a more generic name 


---
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.
---

Build failed in Jenkins: build-master-slowbuild #2854

[jenkins]

See 

--
[...truncated 28723 lines...]
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:findbugs (findbugs) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud ---
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ 
cloud-quickcloud ---
[WARNING] No files to instrument.
[INFO] NOT adding cobertura ser file to attached artifacts list.
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud ---
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration  SUCCESS 
[2.846s]
[INFO] Apache CloudStack . SUCCESS [3.075s]
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [0.979s]
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [21.052s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:31.182s]
[INFO] Apache CloudStack Framework ... SUCCESS [0.108s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [53.500s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [27.281s]
[INFO] Apache CloudStack API . SUCCESS [1:49.999s]
[INFO] Apache CloudStack Framework - REST  SUCCESS [16.729s]
[INFO] Apache CloudStack Framework - IPC . SUCCESS [30.928s]
[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.088s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [27.851s]
[INFO] Apache CloudStack Framework - Security  SUCCESS [24.606s]
[INFO] Apache CloudStack Core  SUCCESS [1:23.912s]
[INFO] Apache CloudStack Agents .. SUCCESS [35.762s]
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [37.337s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [14.428s]
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:08.608s]
[INFO] Apache CloudStack Framework - Jobs  SUCCESS [41.082s]
[INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS [25.943s]
[INFO] Apache CloudStack Server .. SUCCESS [4:12.453s]
[INFO] Apache CloudStack Framework - Quota ... SUCCESS [37.716s]
[INFO] Apache CloudStack Usage Server  SUCCESS [44.008s]
[INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS 
[1:21.469s]
[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.071s]
[INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.487s]
[INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [54.741s]
[INFO] Apache CloudStack Engine Storage Component  SUCCESS [48.953s]
[INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [30.650s]
[INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [26.338s]
[INFO] Apache CloudStack Engine Storage Data Motion Component  SUCCESS [30.748s]
[INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [20.939s]
[INFO] Apache CloudStack Engine Storage Snapshot Component  SUCCESS [35.333s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [12.452s]
[INFO] Apache CloudStack Cloud Engine Service  SUCCESS [7.855s]
[INFO] Apache CloudStack Plugin POM .. SUCCESS [0.992s]
[INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [27.328s]
[INFO] Apache CloudStack Plugin - Storage Volume default provider  SUCCESS 
[24.075s]
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider  SUCCESS 
[35.863s]
[INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [18.013s]
[INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [22.986s]
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [15.031s]
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SUCCESS 
[16.909s]
[INFO] Apache Cloud

Re: Let’s discuss database upgrades

[Daan Hoogland]

€0,02:

I think it is important to support per commit upgrades, so I not with Wido
on this at all. Looking at your naming scheme that might be a problem.
Other then this your initial proposal seems fine. The reason is not to
allow for x.y.z schema changes but to be able to decide a certain commit
goes in or not and have their schema changed be merged in seperately. As an
RM most conflict resolution, I had to do in 4.4, where in the schema files
in parts of the system I would otherwise not touch.

Downgrade might not be an issue. I dread to think it would be, so let's
drop it indeed, at least for now.

regards

On Mon, Dec 28, 2015 at 9:34 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> Hi Wido, Rohit,
> I have just read the feature suggestion.
>
> Wido, I am not trying to complicate things, quite the opposite, I just
> illustrate a simple thing that can happen and is happening; I just pointed
> how it can be easily solved.
>
> About the release of .Z, releases more constant and others, I do not want
> to mix topics. Let’s keep this thread strict to discuss database upgrades.
>
> Now, about the FS. I agree with Rohit that we should have only one way of
> managing database upgrades and creation. I just do not like the idea of
> creating a tool that work as a wrapper on frameworks/tools such as
> flywaydb. I think that those frameworks already work pretty good as they
> are; and, I would rather maintain configurations than some wrapper code.
>
> I personally like the way ACS works during upgrades (I just do not like the
> code itself and how things are structured), as a system administrator I
> like to change the version in the “/etc/apt/sources.list.d/cloudstack.list”
> and use the "apt-get" "update" and "install" from the command line. I do
> not see the need to add another tool that is just a wrapper to the mix. If
> I update ACS code to 4.7.0, why would I let the database schema in an older
> version? And if we want version DB schemas and application code separately
> maintaining somehow compatibility between them, which would bring a whole
> other level of complexity to the code; I think we should avoid that.
>
> The flywaydb can be easily integrated with everything we have now; we could
> have a maven profile for developers and integrate it in ACS bootstrap using
> its API as a Spring bean. Therefore, we could remove the current
> “DatabaseUpgradeChecker “, “DbUpgrade” and other classes that aim to do
> that. We could even add the creation of the schema into the first time it
> boots using flywaydb and retire the “cloudstack-setup-database” script, or
> at least make it less complicated, using it just to configure the database
> URL and users.
>
> The point is that to use Flywaydb we would have to agree upon a convention
> on creating routines (java and SQL) to execute upgrades. Moreover, using a
> tool such as Flywaydb we do not need to worry about upgrade paths. As I
> wrote in the email I used to start this thread, the upgrade has to be
> straightforward, to go to a version we have to run all of the upgrade
> routines between the current version until the desired one. Our job is to
> create upgrade routines that work and name them properly, the job of the
> tool is to check the current version, the desired one, the upgrades that it
> needs to run and execute everything properly.
>
> Additionally, I do not see the need to break compatibility as Rohit
> suggested in the FS; in my opinion, everything we have up today can be
> migrated to the new structure I proposed. If we use a tool such as
> Flywaydb, I even volunteered for that. The only thing we have to discuss
> and agree upon is the naming conventions for upgrades routines, where to
> put them and the configurations for flywaydb.
>
> Thanks for your contribution and time.
>
>
> On Mon, Dec 28, 2015 at 2:10 PM, Rohit Yadav 
> wrote:
>
> > Hi Rafael and Wido,
> >
> > Thanks for starting a conversation in this regard, I could not pursue the
> > Chimp tool due to other $dayjob work though it’s good to see some
> > discussion has started again. Hope we’ll solve this in 2016.
> >
> > In my opinion, we will need to first separate the database init/migration
> > tooling away from mgmt server (right now the mgmt server does db
> migrations
> > when it starts and there is a code/db version mismatch) and secondly make
> > sure that we’re using the same code/tool to deploy database (right now,
> > users use the cloudstack-setup-database python tool while developer use
> the
> > maven/java DatabaseCreator activated by the -Ddeploydb flag).
> >
> > After we’ve addressed these two issues we can look into how we can
> support
> > minor releases workflow (or decide to do something else, like not support
> > .Z releases like Wido mentioned), and see if we can or want to use any
> > existing migration tool or write a wrapper tool “chimp” that uses
> existing
> > tools (some of those are mentioned in the Chimp FS like flywaydb etc).
> For
> > allowing

[GitHub] cloudstack pull request: CLOUDSTACK-9132: API createVolume takes e...

[rafaelweingartner]

Github user rafaelweingartner commented on the pull request:

https://github.com/apache/cloudstack/pull/1273#issuecomment-167760979
  
@nitin-maharana now almost everything is ok.
There is only one problem. the 
"org.apache.commons.lang.StringUtils.isBlank" also returns true if the value is 
null or empty. Therefore, you can remove the "userSpecifiedName == null || 
userSpecifiedName.isEmpty() " conditions.


---
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: Let’s discuss database upgrades

[Wido den Hollander]

On 28-12-15 21:34, Rafael Weingärtner wrote:
> Hi Wido, Rohit,
> I have just read the feature suggestion.
> 
> Wido, I am not trying to complicate things, quite the opposite, I just
> illustrate a simple thing that can happen and is happening; I just pointed
> how it can be easily solved.
> 
> About the release of .Z, releases more constant and others, I do not want
> to mix topics. Let’s keep this thread strict to discuss database upgrades.
> 

I do not want to start the release discussion, but what I meant is that
we try to find a technical solution to something which might be solved
easier by just changing the way we release.

4.6.0 is released and afterwards 4.5.3 is released. How does somebody
upgrade from 4.5.3 to 4.6.0? He can't, since the 4.6.0 code doesn't
support that path.

So my idea is to split the database version from the code version.

The code requires database version >= X and during boot it simply checks
that.

The database migration tool can indeed do the DB migration, it doesn't
have to be the mgmt server who does the upgrade.

> Now, about the FS. I agree with Rohit that we should have only one way of
> managing database upgrades and creation. I just do not like the idea of
> creating a tool that work as a wrapper on frameworks/tools such as
> flywaydb. I think that those frameworks already work pretty good as they
> are; and, I would rather maintain configurations than some wrapper code.
> 
> I personally like the way ACS works during upgrades (I just do not like the
> code itself and how things are structured), as a system administrator I
> like to change the version in the “/etc/apt/sources.list.d/cloudstack.list”
> and use the "apt-get" "update" and "install" from the command line. I do
> not see the need to add another tool that is just a wrapper to the mix. If
> I update ACS code to 4.7.0, why would I let the database schema in an older
> version? And if we want version DB schemas and application code separately
> maintaining somehow compatibility between them, which would bring a whole
> other level of complexity to the code; I think we should avoid that.
> 
> The flywaydb can be easily integrated with everything we have now; we could
> have a maven profile for developers and integrate it in ACS bootstrap using
> its API as a Spring bean. Therefore, we could remove the current
> “DatabaseUpgradeChecker “, “DbUpgrade” and other classes that aim to do
> that. We could even add the creation of the schema into the first time it
> boots using flywaydb and retire the “cloudstack-setup-database” script, or
> at least make it less complicated, using it just to configure the database
> URL and users.
> 
> The point is that to use Flywaydb we would have to agree upon a convention
> on creating routines (java and SQL) to execute upgrades. Moreover, using a
> tool such as Flywaydb we do not need to worry about upgrade paths. As I
> wrote in the email I used to start this thread, the upgrade has to be
> straightforward, to go to a version we have to run all of the upgrade
> routines between the current version until the desired one. Our job is to
> create upgrade routines that work and name them properly, the job of the
> tool is to check the current version, the desired one, the upgrades that it
> needs to run and execute everything properly.
> 

Yes, indeed. I just wanted to start the discussion if we shouldn't
version the database differently from the code.

> Additionally, I do not see the need to break compatibility as Rohit
> suggested in the FS; in my opinion, everything we have up today can be
> migrated to the new structure I proposed. If we use a tool such as
> Flywaydb, I even volunteered for that. The only thing we have to discuss
> and agree upon is the naming conventions for upgrades routines, where to
> put them and the configurations for flywaydb.
> 
> Thanks for your contribution and time.
> 
> 
> On Mon, Dec 28, 2015 at 2:10 PM, Rohit Yadav 
> wrote:
> 
>> Hi Rafael and Wido,
>>
>> Thanks for starting a conversation in this regard, I could not pursue the
>> Chimp tool due to other $dayjob work though it’s good to see some
>> discussion has started again. Hope we’ll solve this in 2016.
>>
>> In my opinion, we will need to first separate the database init/migration
>> tooling away from mgmt server (right now the mgmt server does db migrations
>> when it starts and there is a code/db version mismatch) and secondly make
>> sure that we’re using the same code/tool to deploy database (right now,
>> users use the cloudstack-setup-database python tool while developer use the
>> maven/java DatabaseCreator activated by the -Ddeploydb flag).
>>
>> After we’ve addressed these two issues we can look into how we can support
>> minor releases workflow (or decide to do something else, like not support
>> .Z releases like Wido mentioned), and see if we can or want to use any
>> existing migration tool or write a wrapper tool “chimp” that uses existing
>> tools (some of those are mentione

[GitHub] cloudstack pull request: CLOUDSTACK-9132: API createVolume takes e...

[nitin-maharana]

Github user nitin-maharana commented on the pull request:

https://github.com/apache/cloudstack/pull/1273#issuecomment-167765606
  
@rafaelweingartner : Thats cool. I went through the detail of isBlank, but 
could not catch. Thank you.
I have updated.


---
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: Let’s discuss database upgrades

[Rafael Weingärtner]

Thanks, Daan and Wido for your contributions, I will discuss them as
follows.

Daan, about the idea of per commit upgrades. Do you mean that we separate
each change in the database that is introduced by PRs/Commits in a
different file (routine upgrade) per ACS version?
So we would have, V_480_A.sql (for a PR),V_480_B.sql (for another PR) and
so forth

If that is the case, we can achieve that using a simple convention naming
as I suggested. Each developer when she/he needs to change or add something
in the database creates an upgrade routine separately and gives it an
execution order to be taken by Flywaydb. I think that could help RMs to
track and isolate the problem, right?

Hi Wido, now I understand your example.
I understand your worry about upgrade paths, and that is the point I want
to discuss and solve. In your example, if we release a 4.6.0 and later a
4.5.3. You said that there would be no upgrade path from 4.5.3 to 4.6.0.
Well, today that is what happens. However, if we change the technology we
use to upgrade the database (using a tool such as Flywaydb) and if we
define a standard to create upgrade routines that would not be a problem.

As I have written in my first email, to go from a version to another we
should be able to run all of the upgrade routines in between them
(including the upgrade routine of the goal version). Therefore, if we
release a version 4.6.0, and then 4.5.3, if someone upgrades to 4.5.3 from
any other version, and then wants to upgrade to 4.6.0, that would not be a
problem, it would be a metter of running only the routine upgrade of 4.6.0
version. We do not need to explicitly create upgrade paths. They should be
implicit by our upgrade conventions.

About creating versions of the code that rely on some version of the
database. I do not like much because of compatibility issues that might
arise. For instance, let’s say version X of ACS depends on version >=Y of
the database. If I upgrade the database to version Y + 1 or +2, the same
ACS version has to keep running nice and shiny. My worry is that may bring
some complications, such as to remove columns that cease to be used or data
structure that we might want to improve.

I normally see that the database version and the code base are tied in a
mapping 1 to 1. Maybe I am having troubles identifying the benefits of that
change.

Thanks for your time ;)

On Tue, Dec 29, 2015 at 8:15 AM, Wido den Hollander  wrote:

>
>
> On 28-12-15 21:34, Rafael Weingärtner wrote:
> > Hi Wido, Rohit,
> > I have just read the feature suggestion.
> >
> > Wido, I am not trying to complicate things, quite the opposite, I just
> > illustrate a simple thing that can happen and is happening; I just
> pointed
> > how it can be easily solved.
> >
> > About the release of .Z, releases more constant and others, I do not want
> > to mix topics. Let’s keep this thread strict to discuss database
> upgrades.
> >
>
> I do not want to start the release discussion, but what I meant is that
> we try to find a technical solution to something which might be solved
> easier by just changing the way we release.
>
> 4.6.0 is released and afterwards 4.5.3 is released. How does somebody
> upgrade from 4.5.3 to 4.6.0? He can't, since the 4.6.0 code doesn't
> support that path.
>
> So my idea is to split the database version from the code version.
>
> The code requires database version >= X and during boot it simply checks
> that.
>
> The database migration tool can indeed do the DB migration, it doesn't
> have to be the mgmt server who does the upgrade.
>
> > Now, about the FS. I agree with Rohit that we should have only one way of
> > managing database upgrades and creation. I just do not like the idea of
> > creating a tool that work as a wrapper on frameworks/tools such as
> > flywaydb. I think that those frameworks already work pretty good as they
> > are; and, I would rather maintain configurations than some wrapper code.
> >
> > I personally like the way ACS works during upgrades (I just do not like
> the
> > code itself and how things are structured), as a system administrator I
> > like to change the version in the
> “/etc/apt/sources.list.d/cloudstack.list”
> > and use the "apt-get" "update" and "install" from the command line. I do
> > not see the need to add another tool that is just a wrapper to the mix.
> If
> > I update ACS code to 4.7.0, why would I let the database schema in an
> older
> > version? And if we want version DB schemas and application code
> separately
> > maintaining somehow compatibility between them, which would bring a whole
> > other level of complexity to the code; I think we should avoid that.
> >
> > The flywaydb can be easily integrated with everything we have now; we
> could
> > have a maven profile for developers and integrate it in ACS bootstrap
> using
> > its API as a Spring bean. Therefore, we could remove the current
> > “DatabaseUpgradeChecker “, “DbUpgrade” and other classes that aim to do
> > that. We could even add the crea

[GitHub] cloudstack pull request: CLOUDSTACK-9132: API createVolume takes e...

[rafaelweingartner]

Github user rafaelweingartner commented on the pull request:

https://github.com/apache/cloudstack/pull/1273#issuecomment-167768433
  
@nitin-maharana now the code is perfect.
I can give a LGTM now.

Sorry if I bothered you with a lot of changes. 


---
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: Strongswan vpn feature

[jayapalu]

Github user jayapalu commented on the pull request:

https://github.com/apache/cloudstack/pull/872#issuecomment-167769469
  
Site to site vpn test case results:
$nosetests-2.7 --with-marvin 
--marvin-config=/Users/jayapalreddy/advanced-acs.cfg  
/Users/jayapalreddy/dev/ccp/internal-cloudstack/test/integration/smoke/test_vpc_vpn.py:TestVpcSite2SiteVpn
 -a tags=advanced   --zone=zone1  --hypervisor=xenserver
 Marvin Init Started 

=== Marvin Parse Config Successful ===

=== Marvin Setting TestData Successful===

 Log Folder Path: /tmp//MarvinLogs//Dec_29_2015_15_20_16_BLFI1D. All 
logs will be available here 

=== Marvin Init Logging Successful===

 Marvin Init Successful 
Downloading Template: tiny-xen from: 
http://10.147.28.7/templates/macchinina-xen.vhd.bz2

VPC1 7c512e57-d5d7-4b43-ad66-0d3f12db33e4 created
VPC2 ffa04a98-2d3f-40e3-8ed9-02fa553343a7 created
Network 251f2416-8695-4d72-bf0e-ec6be1fd5968 created in VPC 
7c512e57-d5d7-4b43-ad66-0d3f12db33e4
Network c39bd9c6-dd4f-4b98-86a7-9a8f1cfe1464 created in VPC 
ffa04a98-2d3f-40e3-8ed9-02fa553343a7
VM 21cf26a4-2aa8-4d78-9514-b2e29fd23e8d deployed in VPC 
7c512e57-d5d7-4b43-ad66-0d3f12db33e4
VPN gateway for VPC 7c512e57-d5d7-4b43-ad66-0d3f12db33e4 enabled
VPN gateway for VPC ffa04a98-2d3f-40e3-8ed9-02fa553343a7 enabled
{'account': u'test-TestVpcSite2SiteVpn-WN8YZA', 'domainid': 
u'a18845c6-a7c2-11e5-92c7-4d467782273c', 'name': u'Peer VPC1', 'cidrlist': 
u'10.1.0.0/16', 'ikepolicy': u'3des-md5;modp1536', 'esplifetime': 3600, 'id': 
u'55537b14-36ba-4743-be3d-45789a47706a', 'dpd': False, 'domain': u'ROOT', 
'ikelifetime': 86400, 'ipsecpsk': u'ipsecpsk', 'esppolicy': 
u'3des-md5;modp1536', 'gateway': u'10.147.52.174'}
{'account': u'test-TestVpcSite2SiteVpn-WN8YZA', 'domainid': 
u'a18845c6-a7c2-11e5-92c7-4d467782273c', 'name': u'Peer VPC2', 'cidrlist': 
u'10.2.0.0/16', 'ikepolicy': u'3des-md5;modp1536', 'esplifetime': 3600, 'id': 
u'f1ebc3d4-6b25-4fdd-a3ea-ffd7ba2194b6', 'dpd': False, 'domain': u'ROOT', 
'ikelifetime': 86400, 'ipsecpsk': u'ipsecpsk', 'esppolicy': 
u'3des-md5;modp1536', 'gateway': u'10.147.52.176'}
Creating NAT rule in network for vm with public IP
Adding NetworkACL rules to make NAT rule accessible
Trying SSH Connection: Host:10.147.52.177 User:root 
  Port:22 RetryCnt:10===
===SSH to Host 10.147.52.177 port : 22 SUCCESSFUL===
{Cmd: /bin/ping -c 3 -t 10 10.1.1.73 |grep packet|cut -d ' ' -f 7| cut -f1 
-d'%' via Host: 10.147.52.177} {returns: [u'0']}
===final results are now copied to: /tmp//MarvinLogs/test_vpc_vpn_SI9ILA===


$cat  /tmp//MarvinLogs/test_vpc_vpn_SI9ILA/results.txt
Test VPN in VPC ... === TestName: test_vpc_site2site_vpn | Status : SUCCESS 
===
ok

--
Ran 1 test in 691.332s

OK


---
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-9132: API createVolume takes e...

[nitin-maharana]

Github user nitin-maharana commented on the pull request:

https://github.com/apache/cloudstack/pull/1273#issuecomment-167773312
  
Thanks a lot @rafaelweingartner , I learned many things. 


---
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: Let’s discuss database upgrades

[Daan Hoogland]

Rafael,

On Tue, Dec 29, 2015 at 12:22 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> Thanks, Daan and Wido for your contributions, I will discuss them as
> follows.
>
> Daan, about the idea of per commit upgrades. Do you mean that we separate
> each change in the database that is introduced by PRs/Commits in a
> different file (routine upgrade) per ACS version?
> So we would have, V_480_A.sql (for a PR),V_480_B.sql (for another PR) and
> so forth
>
> If that is the case, we can achieve that using a simple convention naming
> as I suggested. Each developer when she/he needs to change or add something
> in the database creates an upgrade routine separately and gives it an
> execution order to be taken by Flywaydb. I think that could help RMs to
> track and isolate the problem, right?
>
​Yes, with one little caveat. We do not know in what version a feature/PR
will end up at the time of implementing, so a name containing the version
would not be ideal.
​


>
> Hi Wido, now I understand your example.
> I understand your worry about upgrade paths, and that is the point I want
> to discuss and solve. In your example, if we release a 4.6.0 and later a
> 4.5.3. You said that there would be no upgrade path from 4.5.3 to 4.6.0.
> Well, today that is what happens. However, if we change the technology we
> use to upgrade the database (using a tool such as Flywaydb) and if we
> define a standard to create upgrade routines that would not be a problem.
>
> As I have written in my first email, to go from a version to another we
> should be able to run all of the upgrade routines in between them
> (including the upgrade routine of the goal version). Therefore, if we
> release a version 4.6.0, and then 4.5.3, if someone upgrades to 4.5.3 from
> any other version, and then wants to upgrade to 4.6.0, that would not be a
> problem, it would be a metter of running only the routine upgrade of 4.6.0
> version. We do not need to explicitly create upgrade paths. They should be
> implicit by our upgrade conventions.
>
> About creating versions of the code that rely on some version of the
> database. I do not like much because of compatibility issues that might
> arise. For instance, let’s say version X of ACS depends on version >=Y of
> the database. If I upgrade the database to version Y + 1 or +2, the same
> ACS version has to keep running nice and shiny. My worry is that may bring
> some complications, such as to remove columns that cease to be used or data
> structure that we might want to improve.
>
> I normally see that the database version and the code base are tied in a
> mapping 1 to 1. Maybe I am having troubles identifying the benefits of that
> change.
>
> Thanks for your time ;)
>
> On Tue, Dec 29, 2015 at 8:15 AM, Wido den Hollander 
> wrote:
>
> >
> >
> > On 28-12-15 21:34, Rafael Weingärtner wrote:
> > > Hi Wido, Rohit,
> > > I have just read the feature suggestion.
> > >
> > > Wido, I am not trying to complicate things, quite the opposite, I just
> > > illustrate a simple thing that can happen and is happening; I just
> > pointed
> > > how it can be easily solved.
> > >
> > > About the release of .Z, releases more constant and others, I do not
> want
> > > to mix topics. Let’s keep this thread strict to discuss database
> > upgrades.
> > >
> >
> > I do not want to start the release discussion, but what I meant is that
> > we try to find a technical solution to something which might be solved
> > easier by just changing the way we release.
> >
> > 4.6.0 is released and afterwards 4.5.3 is released. How does somebody
> > upgrade from 4.5.3 to 4.6.0? He can't, since the 4.6.0 code doesn't
> > support that path.
> >
> > So my idea is to split the database version from the code version.
> >
> > The code requires database version >= X and during boot it simply checks
> > that.
> >
> > The database migration tool can indeed do the DB migration, it doesn't
> > have to be the mgmt server who does the upgrade.
> >
> > > Now, about the FS. I agree with Rohit that we should have only one way
> of
> > > managing database upgrades and creation. I just do not like the idea of
> > > creating a tool that work as a wrapper on frameworks/tools such as
> > > flywaydb. I think that those frameworks already work pretty good as
> they
> > > are; and, I would rather maintain configurations than some wrapper
> code.
> > >
> > > I personally like the way ACS works during upgrades (I just do not like
> > the
> > > code itself and how things are structured), as a system administrator I
> > > like to change the version in the
> > “/etc/apt/sources.list.d/cloudstack.list”
> > > and use the "apt-get" "update" and "install" from the command line. I
> do
> > > not see the need to add another tool that is just a wrapper to the mix.
> > If
> > > I update ACS code to 4.7.0, why would I let the database schema in an
> > older
> > > version? And if we want version DB schemas and application code
> > separately
> > > maintaining somehow 

Build failed in Jenkins: build-master-slowbuild #2855

[jenkins]

See 

--
[...truncated 28723 lines...]
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:findbugs (findbugs) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud ---
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ 
cloud-quickcloud ---
[WARNING] No files to instrument.
[INFO] NOT adding cobertura ser file to attached artifacts list.
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud ---
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration  SUCCESS 
[1.771s]
[INFO] Apache CloudStack . SUCCESS [2.153s]
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [0.787s]
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [18.785s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:30.731s]
[INFO] Apache CloudStack Framework ... SUCCESS [0.108s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [53.442s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [28.342s]
[INFO] Apache CloudStack API . SUCCESS [1:57.355s]
[INFO] Apache CloudStack Framework - REST  SUCCESS [16.591s]
[INFO] Apache CloudStack Framework - IPC . SUCCESS [30.093s]
[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.088s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [28.749s]
[INFO] Apache CloudStack Framework - Security  SUCCESS [25.229s]
[INFO] Apache CloudStack Core  SUCCESS [1:21.651s]
[INFO] Apache CloudStack Agents .. SUCCESS [36.118s]
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [37.046s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [14.396s]
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:09.367s]
[INFO] Apache CloudStack Framework - Jobs  SUCCESS [41.325s]
[INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS [25.334s]
[INFO] Apache CloudStack Server .. SUCCESS [4:14.622s]
[INFO] Apache CloudStack Framework - Quota ... SUCCESS [37.222s]
[INFO] Apache CloudStack Usage Server  SUCCESS [44.080s]
[INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS 
[1:21.424s]
[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.079s]
[INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.454s]
[INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [54.326s]
[INFO] Apache CloudStack Engine Storage Component  SUCCESS [48.047s]
[INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [31.119s]
[INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [26.862s]
[INFO] Apache CloudStack Engine Storage Data Motion Component  SUCCESS [23.028s]
[INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [20.813s]
[INFO] Apache CloudStack Engine Storage Snapshot Component  SUCCESS [35.769s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [12.636s]
[INFO] Apache CloudStack Cloud Engine Service  SUCCESS [7.707s]
[INFO] Apache CloudStack Plugin POM .. SUCCESS [1.012s]
[INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [26.796s]
[INFO] Apache CloudStack Plugin - Storage Volume default provider  SUCCESS 
[23.941s]
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider  SUCCESS 
[35.618s]
[INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [17.550s]
[INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [24.023s]
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [15.965s]
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SUCCESS 
[16.867s]
[INFO] Apache Cloud

Re: Let’s discuss database upgrades

[Rafael Weingärtner]

I got your point Daan.

Well, and if we linked a version of ACS with a time stamp in the format of
DD.MM.?

We could then use the time stamp in the same format to name upgrade
routines. This way the idea of running all of the routines in between
version during upgrades could be applied.

On Tue, Dec 29, 2015 at 10:03 AM, Daan Hoogland 
wrote:

> Rafael,
>
> On Tue, Dec 29, 2015 at 12:22 PM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
> > Thanks, Daan and Wido for your contributions, I will discuss them as
> > follows.
> >
> > Daan, about the idea of per commit upgrades. Do you mean that we separate
> > each change in the database that is introduced by PRs/Commits in a
> > different file (routine upgrade) per ACS version?
> > So we would have, V_480_A.sql (for a PR),V_480_B.sql (for another PR) and
> > so forth
> >
> > If that is the case, we can achieve that using a simple convention naming
> > as I suggested. Each developer when she/he needs to change or add
> something
> > in the database creates an upgrade routine separately and gives it an
> > execution order to be taken by Flywaydb. I think that could help RMs to
> > track and isolate the problem, right?
> >
> ​Yes, with one little caveat. We do not know in what version a feature/PR
> will end up at the time of implementing, so a name containing the version
> would not be ideal.
> ​
>
>
> >
> > Hi Wido, now I understand your example.
> > I understand your worry about upgrade paths, and that is the point I want
> > to discuss and solve. In your example, if we release a 4.6.0 and later a
> > 4.5.3. You said that there would be no upgrade path from 4.5.3 to 4.6.0.
> > Well, today that is what happens. However, if we change the technology we
> > use to upgrade the database (using a tool such as Flywaydb) and if we
> > define a standard to create upgrade routines that would not be a problem.
> >
> > As I have written in my first email, to go from a version to another we
> > should be able to run all of the upgrade routines in between them
> > (including the upgrade routine of the goal version). Therefore, if we
> > release a version 4.6.0, and then 4.5.3, if someone upgrades to 4.5.3
> from
> > any other version, and then wants to upgrade to 4.6.0, that would not be
> a
> > problem, it would be a metter of running only the routine upgrade of
> 4.6.0
> > version. We do not need to explicitly create upgrade paths. They should
> be
> > implicit by our upgrade conventions.
> >
> > About creating versions of the code that rely on some version of the
> > database. I do not like much because of compatibility issues that might
> > arise. For instance, let’s say version X of ACS depends on version >=Y of
> > the database. If I upgrade the database to version Y + 1 or +2, the same
> > ACS version has to keep running nice and shiny. My worry is that may
> bring
> > some complications, such as to remove columns that cease to be used or
> data
> > structure that we might want to improve.
> >
> > I normally see that the database version and the code base are tied in a
> > mapping 1 to 1. Maybe I am having troubles identifying the benefits of
> that
> > change.
> >
> > Thanks for your time ;)
> >
> > On Tue, Dec 29, 2015 at 8:15 AM, Wido den Hollander 
> > wrote:
> >
> > >
> > >
> > > On 28-12-15 21:34, Rafael Weingärtner wrote:
> > > > Hi Wido, Rohit,
> > > > I have just read the feature suggestion.
> > > >
> > > > Wido, I am not trying to complicate things, quite the opposite, I
> just
> > > > illustrate a simple thing that can happen and is happening; I just
> > > pointed
> > > > how it can be easily solved.
> > > >
> > > > About the release of .Z, releases more constant and others, I do not
> > want
> > > > to mix topics. Let’s keep this thread strict to discuss database
> > > upgrades.
> > > >
> > >
> > > I do not want to start the release discussion, but what I meant is that
> > > we try to find a technical solution to something which might be solved
> > > easier by just changing the way we release.
> > >
> > > 4.6.0 is released and afterwards 4.5.3 is released. How does somebody
> > > upgrade from 4.5.3 to 4.6.0? He can't, since the 4.6.0 code doesn't
> > > support that path.
> > >
> > > So my idea is to split the database version from the code version.
> > >
> > > The code requires database version >= X and during boot it simply
> checks
> > > that.
> > >
> > > The database migration tool can indeed do the DB migration, it doesn't
> > > have to be the mgmt server who does the upgrade.
> > >
> > > > Now, about the FS. I agree with Rohit that we should have only one
> way
> > of
> > > > managing database upgrades and creation. I just do not like the idea
> of
> > > > creating a tool that work as a wrapper on frameworks/tools such as
> > > > flywaydb. I think that those frameworks already work pretty good as
> > they
> > > > are; and, I would rather maintain configurations than some wrapper
> > code.
> > > >
> > > > I personally like the way ACS

Re: Let’s discuss database upgrades

[Wido den Hollander]

On 29-12-15 13:21, Rafael Weingärtner wrote:
> I got your point Daan.
> 
> Well, and if we linked a version of ACS with a time stamp in the format of
> DD.MM.?
> 

In that case you could also say.

ACS 4.6.0 == db ver X

You don't have to say ver >= X, you can also say ver = X.

> We could then use the time stamp in the same format to name upgrade
> routines. This way the idea of running all of the routines in between
> version during upgrades could be applied.
> 

Same goes for giving all database changes a simple numeric int which
keeps incrementing each time a change is applied ;)

Wido

> On Tue, Dec 29, 2015 at 10:03 AM, Daan Hoogland 
> wrote:
> 
>> Rafael,
>>
>> On Tue, Dec 29, 2015 at 12:22 PM, Rafael Weingärtner <
>> rafaelweingart...@gmail.com> wrote:
>>
>>> Thanks, Daan and Wido for your contributions, I will discuss them as
>>> follows.
>>>
>>> Daan, about the idea of per commit upgrades. Do you mean that we separate
>>> each change in the database that is introduced by PRs/Commits in a
>>> different file (routine upgrade) per ACS version?
>>> So we would have, V_480_A.sql (for a PR),V_480_B.sql (for another PR) and
>>> so forth
>>>
>>> If that is the case, we can achieve that using a simple convention naming
>>> as I suggested. Each developer when she/he needs to change or add
>> something
>>> in the database creates an upgrade routine separately and gives it an
>>> execution order to be taken by Flywaydb. I think that could help RMs to
>>> track and isolate the problem, right?
>>>
>> ​Yes, with one little caveat. We do not know in what version a feature/PR
>> will end up at the time of implementing, so a name containing the version
>> would not be ideal.
>> ​
>>
>>
>>>
>>> Hi Wido, now I understand your example.
>>> I understand your worry about upgrade paths, and that is the point I want
>>> to discuss and solve. In your example, if we release a 4.6.0 and later a
>>> 4.5.3. You said that there would be no upgrade path from 4.5.3 to 4.6.0.
>>> Well, today that is what happens. However, if we change the technology we
>>> use to upgrade the database (using a tool such as Flywaydb) and if we
>>> define a standard to create upgrade routines that would not be a problem.
>>>
>>> As I have written in my first email, to go from a version to another we
>>> should be able to run all of the upgrade routines in between them
>>> (including the upgrade routine of the goal version). Therefore, if we
>>> release a version 4.6.0, and then 4.5.3, if someone upgrades to 4.5.3
>> from
>>> any other version, and then wants to upgrade to 4.6.0, that would not be
>> a
>>> problem, it would be a metter of running only the routine upgrade of
>> 4.6.0
>>> version. We do not need to explicitly create upgrade paths. They should
>> be
>>> implicit by our upgrade conventions.
>>>
>>> About creating versions of the code that rely on some version of the
>>> database. I do not like much because of compatibility issues that might
>>> arise. For instance, let’s say version X of ACS depends on version >=Y of
>>> the database. If I upgrade the database to version Y + 1 or +2, the same
>>> ACS version has to keep running nice and shiny. My worry is that may
>> bring
>>> some complications, such as to remove columns that cease to be used or
>> data
>>> structure that we might want to improve.
>>>
>>> I normally see that the database version and the code base are tied in a
>>> mapping 1 to 1. Maybe I am having troubles identifying the benefits of
>> that
>>> change.
>>>
>>> Thanks for your time ;)
>>>
>>> On Tue, Dec 29, 2015 at 8:15 AM, Wido den Hollander 
>>> wrote:
>>>


 On 28-12-15 21:34, Rafael Weingärtner wrote:
> Hi Wido, Rohit,
> I have just read the feature suggestion.
>
> Wido, I am not trying to complicate things, quite the opposite, I
>> just
> illustrate a simple thing that can happen and is happening; I just
 pointed
> how it can be easily solved.
>
> About the release of .Z, releases more constant and others, I do not
>>> want
> to mix topics. Let’s keep this thread strict to discuss database
 upgrades.
>

 I do not want to start the release discussion, but what I meant is that
 we try to find a technical solution to something which might be solved
 easier by just changing the way we release.

 4.6.0 is released and afterwards 4.5.3 is released. How does somebody
 upgrade from 4.5.3 to 4.6.0? He can't, since the 4.6.0 code doesn't
 support that path.

 So my idea is to split the database version from the code version.

 The code requires database version >= X and during boot it simply
>> checks
 that.

 The database migration tool can indeed do the DB migration, it doesn't
 have to be the mgmt server who does the upgrade.

> Now, about the FS. I agree with Rohit that we should have only one
>> way
>>> of
> managing database upgrades and creation. I just do not like the idea
>>

Re: Let’s discuss database upgrades

[Rafael Weingärtner]

Wido, that is true, you are right; the naming on upgrade routines can use a
numeric value independent of the number of the version. The numeric value
can be a simple integer that is incremented each routine that is added or a
time stamp when the routine was added. The point is that we would have to
link a version to a number. That would enable us to use flywaydb.

To use that approach I think we might need to break compatibility as you
pointed out earlier, but I believe that the benefits of an improved way to
manage upgrade routines will compensate by the breaking of compatibility.

On Tue, Dec 29, 2015 at 10:25 AM, Wido den Hollander  wrote:

>
>
> On 29-12-15 13:21, Rafael Weingärtner wrote:
> > I got your point Daan.
> >
> > Well, and if we linked a version of ACS with a time stamp in the format
> of
> > DD.MM.?
> >
>
> In that case you could also say.
>
> ACS 4.6.0 == db ver X
>
> You don't have to say ver >= X, you can also say ver = X.
>
> > We could then use the time stamp in the same format to name upgrade
> > routines. This way the idea of running all of the routines in between
> > version during upgrades could be applied.
> >
>
> Same goes for giving all database changes a simple numeric int which
> keeps incrementing each time a change is applied ;)
>
> Wido
>
> > On Tue, Dec 29, 2015 at 10:03 AM, Daan Hoogland  >
> > wrote:
> >
> >> Rafael,
> >>
> >> On Tue, Dec 29, 2015 at 12:22 PM, Rafael Weingärtner <
> >> rafaelweingart...@gmail.com> wrote:
> >>
> >>> Thanks, Daan and Wido for your contributions, I will discuss them as
> >>> follows.
> >>>
> >>> Daan, about the idea of per commit upgrades. Do you mean that we
> separate
> >>> each change in the database that is introduced by PRs/Commits in a
> >>> different file (routine upgrade) per ACS version?
> >>> So we would have, V_480_A.sql (for a PR),V_480_B.sql (for another PR)
> and
> >>> so forth
> >>>
> >>> If that is the case, we can achieve that using a simple convention
> naming
> >>> as I suggested. Each developer when she/he needs to change or add
> >> something
> >>> in the database creates an upgrade routine separately and gives it an
> >>> execution order to be taken by Flywaydb. I think that could help RMs to
> >>> track and isolate the problem, right?
> >>>
> >> ​Yes, with one little caveat. We do not know in what version a
> feature/PR
> >> will end up at the time of implementing, so a name containing the
> version
> >> would not be ideal.
> >> ​
> >>
> >>
> >>>
> >>> Hi Wido, now I understand your example.
> >>> I understand your worry about upgrade paths, and that is the point I
> want
> >>> to discuss and solve. In your example, if we release a 4.6.0 and later
> a
> >>> 4.5.3. You said that there would be no upgrade path from 4.5.3 to
> 4.6.0.
> >>> Well, today that is what happens. However, if we change the technology
> we
> >>> use to upgrade the database (using a tool such as Flywaydb) and if we
> >>> define a standard to create upgrade routines that would not be a
> problem.
> >>>
> >>> As I have written in my first email, to go from a version to another we
> >>> should be able to run all of the upgrade routines in between them
> >>> (including the upgrade routine of the goal version). Therefore, if we
> >>> release a version 4.6.0, and then 4.5.3, if someone upgrades to 4.5.3
> >> from
> >>> any other version, and then wants to upgrade to 4.6.0, that would not
> be
> >> a
> >>> problem, it would be a metter of running only the routine upgrade of
> >> 4.6.0
> >>> version. We do not need to explicitly create upgrade paths. They should
> >> be
> >>> implicit by our upgrade conventions.
> >>>
> >>> About creating versions of the code that rely on some version of the
> >>> database. I do not like much because of compatibility issues that might
> >>> arise. For instance, let’s say version X of ACS depends on version >=Y
> of
> >>> the database. If I upgrade the database to version Y + 1 or +2, the
> same
> >>> ACS version has to keep running nice and shiny. My worry is that may
> >> bring
> >>> some complications, such as to remove columns that cease to be used or
> >> data
> >>> structure that we might want to improve.
> >>>
> >>> I normally see that the database version and the code base are tied in
> a
> >>> mapping 1 to 1. Maybe I am having troubles identifying the benefits of
> >> that
> >>> change.
> >>>
> >>> Thanks for your time ;)
> >>>
> >>> On Tue, Dec 29, 2015 at 8:15 AM, Wido den Hollander 
> >>> wrote:
> >>>
> 
> 
>  On 28-12-15 21:34, Rafael Weingärtner wrote:
> > Hi Wido, Rohit,
> > I have just read the feature suggestion.
> >
> > Wido, I am not trying to complicate things, quite the opposite, I
> >> just
> > illustrate a simple thing that can happen and is happening; I just
>  pointed
> > how it can be easily solved.
> >
> > About the release of .Z, releases more constant and others, I do not
> >>> want
> > to mix topics. Let’s keep this thread strict to discu

Re: Let’s discuss database upgrades

[Daan Hoogland]

Wido, Rafael,

I like the date-format but then of course CCYY-MM-DD. I can still think of
ways to screw up that (or the plain int;)

On Tue, Dec 29, 2015 at 1:40 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> Wido, that is true, you are right; the naming on upgrade routines can use a
> numeric value independent of the number of the version. The numeric value
> can be a simple integer that is incremented each routine that is added or a
> time stamp when the routine was added. The point is that we would have to
> link a version to a number. That would enable us to use flywaydb.
>
> To use that approach I think we might need to break compatibility as you
> pointed out earlier, but I believe that the benefits of an improved way to
> manage upgrade routines will compensate by the breaking of compatibility.
>
> On Tue, Dec 29, 2015 at 10:25 AM, Wido den Hollander 
> wrote:
>
> >
> >
> > On 29-12-15 13:21, Rafael Weingärtner wrote:
> > > I got your point Daan.
> > >
> > > Well, and if we linked a version of ACS with a time stamp in the format
> > of
> > > DD.MM.?
> > >
> >
> > In that case you could also say.
> >
> > ACS 4.6.0 == db ver X
> >
> > You don't have to say ver >= X, you can also say ver = X.
> >
> > > We could then use the time stamp in the same format to name upgrade
> > > routines. This way the idea of running all of the routines in between
> > > version during upgrades could be applied.
> > >
> >
> > Same goes for giving all database changes a simple numeric int which
> > keeps incrementing each time a change is applied ;)
> >
> > Wido
> >
> > > On Tue, Dec 29, 2015 at 10:03 AM, Daan Hoogland <
> daan.hoogl...@gmail.com
> > >
> > > wrote:
> > >
> > >> Rafael,
> > >>
> > >> On Tue, Dec 29, 2015 at 12:22 PM, Rafael Weingärtner <
> > >> rafaelweingart...@gmail.com> wrote:
> > >>
> > >>> Thanks, Daan and Wido for your contributions, I will discuss them as
> > >>> follows.
> > >>>
> > >>> Daan, about the idea of per commit upgrades. Do you mean that we
> > separate
> > >>> each change in the database that is introduced by PRs/Commits in a
> > >>> different file (routine upgrade) per ACS version?
> > >>> So we would have, V_480_A.sql (for a PR),V_480_B.sql (for another PR)
> > and
> > >>> so forth
> > >>>
> > >>> If that is the case, we can achieve that using a simple convention
> > naming
> > >>> as I suggested. Each developer when she/he needs to change or add
> > >> something
> > >>> in the database creates an upgrade routine separately and gives it an
> > >>> execution order to be taken by Flywaydb. I think that could help RMs
> to
> > >>> track and isolate the problem, right?
> > >>>
> > >> ​Yes, with one little caveat. We do not know in what version a
> > feature/PR
> > >> will end up at the time of implementing, so a name containing the
> > version
> > >> would not be ideal.
> > >> ​
> > >>
> > >>
> > >>>
> > >>> Hi Wido, now I understand your example.
> > >>> I understand your worry about upgrade paths, and that is the point I
> > want
> > >>> to discuss and solve. In your example, if we release a 4.6.0 and
> later
> > a
> > >>> 4.5.3. You said that there would be no upgrade path from 4.5.3 to
> > 4.6.0.
> > >>> Well, today that is what happens. However, if we change the
> technology
> > we
> > >>> use to upgrade the database (using a tool such as Flywaydb) and if we
> > >>> define a standard to create upgrade routines that would not be a
> > problem.
> > >>>
> > >>> As I have written in my first email, to go from a version to another
> we
> > >>> should be able to run all of the upgrade routines in between them
> > >>> (including the upgrade routine of the goal version). Therefore, if we
> > >>> release a version 4.6.0, and then 4.5.3, if someone upgrades to 4.5.3
> > >> from
> > >>> any other version, and then wants to upgrade to 4.6.0, that would not
> > be
> > >> a
> > >>> problem, it would be a metter of running only the routine upgrade of
> > >> 4.6.0
> > >>> version. We do not need to explicitly create upgrade paths. They
> should
> > >> be
> > >>> implicit by our upgrade conventions.
> > >>>
> > >>> About creating versions of the code that rely on some version of the
> > >>> database. I do not like much because of compatibility issues that
> might
> > >>> arise. For instance, let’s say version X of ACS depends on version
> >=Y
> > of
> > >>> the database. If I upgrade the database to version Y + 1 or +2, the
> > same
> > >>> ACS version has to keep running nice and shiny. My worry is that may
> > >> bring
> > >>> some complications, such as to remove columns that cease to be used
> or
> > >> data
> > >>> structure that we might want to improve.
> > >>>
> > >>> I normally see that the database version and the code base are tied
> in
> > a
> > >>> mapping 1 to 1. Maybe I am having troubles identifying the benefits
> of
> > >> that
> > >>> change.
> > >>>
> > >>> Thanks for your time ;)
> > >>>
> > >>> On Tue, Dec 29, 2015 at 8:15 AM, Wido den Hollander 
> > >>> wrote:
>

Re: Let’s discuss database upgrades

[Daan Hoogland]

By this I meant I'm fine with any decision the implementer makes, btw. We
will encounter the administrative issues with it and deal with them.

On Tue, Dec 29, 2015 at 2:46 PM, Daan Hoogland 
wrote:

> Wido, Rafael,
>
> I like the date-format but then of course CCYY-MM-DD. I can still think of
> ways to screw up that (or the plain int;)
>
> On Tue, Dec 29, 2015 at 1:40 PM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
>> Wido, that is true, you are right; the naming on upgrade routines can use
>> a
>> numeric value independent of the number of the version. The numeric value
>> can be a simple integer that is incremented each routine that is added or
>> a
>> time stamp when the routine was added. The point is that we would have to
>> link a version to a number. That would enable us to use flywaydb.
>>
>> To use that approach I think we might need to break compatibility as you
>> pointed out earlier, but I believe that the benefits of an improved way to
>> manage upgrade routines will compensate by the breaking of compatibility.
>>
>> On Tue, Dec 29, 2015 at 10:25 AM, Wido den Hollander 
>> wrote:
>>
>> >
>> >
>> > On 29-12-15 13:21, Rafael Weingärtner wrote:
>> > > I got your point Daan.
>> > >
>> > > Well, and if we linked a version of ACS with a time stamp in the
>> format
>> > of
>> > > DD.MM.?
>> > >
>> >
>> > In that case you could also say.
>> >
>> > ACS 4.6.0 == db ver X
>> >
>> > You don't have to say ver >= X, you can also say ver = X.
>> >
>> > > We could then use the time stamp in the same format to name upgrade
>> > > routines. This way the idea of running all of the routines in between
>> > > version during upgrades could be applied.
>> > >
>> >
>> > Same goes for giving all database changes a simple numeric int which
>> > keeps incrementing each time a change is applied ;)
>> >
>> > Wido
>> >
>> > > On Tue, Dec 29, 2015 at 10:03 AM, Daan Hoogland <
>> daan.hoogl...@gmail.com
>> > >
>> > > wrote:
>> > >
>> > >> Rafael,
>> > >>
>> > >> On Tue, Dec 29, 2015 at 12:22 PM, Rafael Weingärtner <
>> > >> rafaelweingart...@gmail.com> wrote:
>> > >>
>> > >>> Thanks, Daan and Wido for your contributions, I will discuss them as
>> > >>> follows.
>> > >>>
>> > >>> Daan, about the idea of per commit upgrades. Do you mean that we
>> > separate
>> > >>> each change in the database that is introduced by PRs/Commits in a
>> > >>> different file (routine upgrade) per ACS version?
>> > >>> So we would have, V_480_A.sql (for a PR),V_480_B.sql (for another
>> PR)
>> > and
>> > >>> so forth
>> > >>>
>> > >>> If that is the case, we can achieve that using a simple convention
>> > naming
>> > >>> as I suggested. Each developer when she/he needs to change or add
>> > >> something
>> > >>> in the database creates an upgrade routine separately and gives it
>> an
>> > >>> execution order to be taken by Flywaydb. I think that could help
>> RMs to
>> > >>> track and isolate the problem, right?
>> > >>>
>> > >> ​Yes, with one little caveat. We do not know in what version a
>> > feature/PR
>> > >> will end up at the time of implementing, so a name containing the
>> > version
>> > >> would not be ideal.
>> > >> ​
>> > >>
>> > >>
>> > >>>
>> > >>> Hi Wido, now I understand your example.
>> > >>> I understand your worry about upgrade paths, and that is the point I
>> > want
>> > >>> to discuss and solve. In your example, if we release a 4.6.0 and
>> later
>> > a
>> > >>> 4.5.3. You said that there would be no upgrade path from 4.5.3 to
>> > 4.6.0.
>> > >>> Well, today that is what happens. However, if we change the
>> technology
>> > we
>> > >>> use to upgrade the database (using a tool such as Flywaydb) and if
>> we
>> > >>> define a standard to create upgrade routines that would not be a
>> > problem.
>> > >>>
>> > >>> As I have written in my first email, to go from a version to
>> another we
>> > >>> should be able to run all of the upgrade routines in between them
>> > >>> (including the upgrade routine of the goal version). Therefore, if
>> we
>> > >>> release a version 4.6.0, and then 4.5.3, if someone upgrades to
>> 4.5.3
>> > >> from
>> > >>> any other version, and then wants to upgrade to 4.6.0, that would
>> not
>> > be
>> > >> a
>> > >>> problem, it would be a metter of running only the routine upgrade of
>> > >> 4.6.0
>> > >>> version. We do not need to explicitly create upgrade paths. They
>> should
>> > >> be
>> > >>> implicit by our upgrade conventions.
>> > >>>
>> > >>> About creating versions of the code that rely on some version of the
>> > >>> database. I do not like much because of compatibility issues that
>> might
>> > >>> arise. For instance, let’s say version X of ACS depends on version
>> >=Y
>> > of
>> > >>> the database. If I upgrade the database to version Y + 1 or +2, the
>> > same
>> > >>> ACS version has to keep running nice and shiny. My worry is that may
>> > >> bring
>> > >>> some complications, such as to remove columns that cease to be used
>> or
>> > >> data
>> > >>> structu

Re: Let’s discuss database upgrades

[Wido den Hollander]

On 29-12-15 14:46, Daan Hoogland wrote:
> Wido, Rafael,
> 
> I like the date-format but then of course CCYY-MM-DD. I can still think of
> ways to screw up that (or the plain int;)
> 

20151229 is a valid integer which you can simply use to compare with.

100, 101, 102 or 20151229, 20160103, 20160104, I don't care that much.

My point is that the database version should be separated from the code
base.

Wido

> On Tue, Dec 29, 2015 at 1:40 PM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
> 
>> Wido, that is true, you are right; the naming on upgrade routines can use a
>> numeric value independent of the number of the version. The numeric value
>> can be a simple integer that is incremented each routine that is added or a
>> time stamp when the routine was added. The point is that we would have to
>> link a version to a number. That would enable us to use flywaydb.
>>
>> To use that approach I think we might need to break compatibility as you
>> pointed out earlier, but I believe that the benefits of an improved way to
>> manage upgrade routines will compensate by the breaking of compatibility.
>>
>> On Tue, Dec 29, 2015 at 10:25 AM, Wido den Hollander 
>> wrote:
>>
>>>
>>>
>>> On 29-12-15 13:21, Rafael Weingärtner wrote:
>>>> I got your point Daan.
>>>>
>>>> Well, and if we linked a version of ACS with a time stamp in the format
>>> of
>>>> DD.MM.?
>>>>
>>>
>>> In that case you could also say.
>>>
>>> ACS 4.6.0 == db ver X
>>>
>>> You don't have to say ver >= X, you can also say ver = X.
>>>
>>>> We could then use the time stamp in the same format to name upgrade
>>>> routines. This way the idea of running all of the routines in between
>>>> version during upgrades could be applied.
>>>>
>>>
>>> Same goes for giving all database changes a simple numeric int which
>>> keeps incrementing each time a change is applied ;)
>>>
>>> Wido
>>>
>>>> On Tue, Dec 29, 2015 at 10:03 AM, Daan Hoogland <
>> daan.hoogl...@gmail.com
>>>>
>>>> wrote:
>>>>
>>>>> Rafael,
>>>>>
>>>>> On Tue, Dec 29, 2015 at 12:22 PM, Rafael Weingärtner <
>>>>> rafaelweingart...@gmail.com> wrote:
>>>>>
>>>>>> Thanks, Daan and Wido for your contributions, I will discuss them as
>>>>>> follows.
>>>>>>
>>>>>> Daan, about the idea of per commit upgrades. Do you mean that we
>>> separate
>>>>>> each change in the database that is introduced by PRs/Commits in a
>>>>>> different file (routine upgrade) per ACS version?
>>>>>> So we would have, V_480_A.sql (for a PR),V_480_B.sql (for another PR)
>>> and
>>>>>> so forth
>>>>>>
>>>>>> If that is the case, we can achieve that using a simple convention
>>> naming
>>>>>> as I suggested. Each developer when she/he needs to change or add
>>>>> something
>>>>>> in the database creates an upgrade routine separately and gives it an
>>>>>> execution order to be taken by Flywaydb. I think that could help RMs
>> to
>>>>>> track and isolate the problem, right?
>>>>>>
>>>>> ​Yes, with one little caveat. We do not know in what version a
>>> feature/PR
>>>>> will end up at the time of implementing, so a name containing the
>>> version
>>>>> would not be ideal.
>>>>> ​
>>>>>
>>>>>
>>>>>>
>>>>>> Hi Wido, now I understand your example.
>>>>>> I understand your worry about upgrade paths, and that is the point I
>>> want
>>>>>> to discuss and solve. In your example, if we release a 4.6.0 and
>> later
>>> a
>>>>>> 4.5.3. You said that there would be no upgrade path from 4.5.3 to
>>> 4.6.0.
>>>>>> Well, today that is what happens. However, if we change the
>> technology
>>> we
>>>>>> use to upgrade the database (using a tool such as Flywaydb) and if we
>>>>>> define a standard to create upgrade routines that would not be a
>>> problem.
>>>>>>
>>>>>> As I have written in my first email, to go from a version to another
>> we
>>>>

Re: Let’s discuss database upgrades

[Rafael Weingärtner]

I also liked the date-format, what did you mean with CCYY?



The way I think we might have a problem, would be to commits/PRs that end
up creating files with same names. Then, we would have to agree upon a way
to solve those conflicts, such as appending an extra character to indicate
a sequence to be followed or adding more data such as HH and mm to the
naming convention (-MM-DD-HH-mm).


I liked the way Wido suggested, we could just remove the “-” from
“-MM-DD-HH-mm” and use the value as an integer (MMDDHHmm).



It seems that we are reaching a consensus. I would love to hear back from
other devs though, especially committers.



BTW: do I have permission to create a page on the wiki so I can add
everything we discuss and agree upon here? This way, we could add that page
to the guidelines for devs creating PRs and committers reviewing and
merging them.

On Tue, Dec 29, 2015 at 12:00 PM, Wido den Hollander  wrote:

>
>
> On 29-12-15 14:46, Daan Hoogland wrote:
> > Wido, Rafael,
> >
> > I like the date-format but then of course CCYY-MM-DD. I can still think
> of
> > ways to screw up that (or the plain int;)
> >
>
> 20151229 is a valid integer which you can simply use to compare with.
>
> 100, 101, 102 or 20151229, 20160103, 20160104, I don't care that much.
>
> My point is that the database version should be separated from the code
> base.
>
> Wido
>
> > On Tue, Dec 29, 2015 at 1:40 PM, Rafael Weingärtner <
> > rafaelweingart...@gmail.com> wrote:
> >
> >> Wido, that is true, you are right; the naming on upgrade routines can
> use a
> >> numeric value independent of the number of the version. The numeric
> value
> >> can be a simple integer that is incremented each routine that is added
> or a
> >> time stamp when the routine was added. The point is that we would have
> to
> >> link a version to a number. That would enable us to use flywaydb.
> >>
> >> To use that approach I think we might need to break compatibility as you
> >> pointed out earlier, but I believe that the benefits of an improved way
> to
> >> manage upgrade routines will compensate by the breaking of
> compatibility.
> >>
> >> On Tue, Dec 29, 2015 at 10:25 AM, Wido den Hollander 
> >> wrote:
> >>
> >>>
> >>>
> >>> On 29-12-15 13:21, Rafael Weingärtner wrote:
> >>>> I got your point Daan.
> >>>>
> >>>> Well, and if we linked a version of ACS with a time stamp in the
> format
> >>> of
> >>>> DD.MM.?
> >>>>
> >>>
> >>> In that case you could also say.
> >>>
> >>> ACS 4.6.0 == db ver X
> >>>
> >>> You don't have to say ver >= X, you can also say ver = X.
> >>>
> >>>> We could then use the time stamp in the same format to name upgrade
> >>>> routines. This way the idea of running all of the routines in between
> >>>> version during upgrades could be applied.
> >>>>
> >>>
> >>> Same goes for giving all database changes a simple numeric int which
> >>> keeps incrementing each time a change is applied ;)
> >>>
> >>> Wido
> >>>
> >>>> On Tue, Dec 29, 2015 at 10:03 AM, Daan Hoogland <
> >> daan.hoogl...@gmail.com
> >>>>
> >>>> wrote:
> >>>>
> >>>>> Rafael,
> >>>>>
> >>>>> On Tue, Dec 29, 2015 at 12:22 PM, Rafael Weingärtner <
> >>>>> rafaelweingart...@gmail.com> wrote:
> >>>>>
> >>>>>> Thanks, Daan and Wido for your contributions, I will discuss them as
> >>>>>> follows.
> >>>>>>
> >>>>>> Daan, about the idea of per commit upgrades. Do you mean that we
> >>> separate
> >>>>>> each change in the database that is introduced by PRs/Commits in a
> >>>>>> different file (routine upgrade) per ACS version?
> >>>>>> So we would have, V_480_A.sql (for a PR),V_480_B.sql (for another
> PR)
> >>> and
> >>>>>> so forth
> >>>>>>
> >>>>>> If that is the case, we can achieve that using a simple convention
> >>> naming
> >>>>>> as I suggested. Each developer when she/he needs to change or add
> >>>>> something
> >>>>>> in the database creates an upgrade routine separately and gives it
> an
> >&g

Re: Let’s discuss database upgrades

[Daan Hoogland]

CCYY == 

On Tue, Dec 29, 2015 at 3:06 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> I also liked the date-format, what did you mean with CCYY?
>
>
>
> The way I think we might have a problem, would be to commits/PRs that end
> up creating files with same names. Then, we would have to agree upon a way
> to solve those conflicts, such as appending an extra character to indicate
> a sequence to be followed or adding more data such as HH and mm to the
> naming convention (-MM-DD-HH-mm).
>
>
> I liked the way Wido suggested, we could just remove the “-” from
> “-MM-DD-HH-mm” and use the value as an integer (MMDDHHmm).
>
>
>
> It seems that we are reaching a consensus. I would love to hear back from
> other devs though, especially committers.
>
>
>
> BTW: do I have permission to create a page on the wiki so I can add
> everything we discuss and agree upon here? This way, we could add that page
> to the guidelines for devs creating PRs and committers reviewing and
> merging them.
>
> On Tue, Dec 29, 2015 at 12:00 PM, Wido den Hollander 
> wrote:
>
> >
> >
> > On 29-12-15 14:46, Daan Hoogland wrote:
> > > Wido, Rafael,
> > >
> > > I like the date-format but then of course CCYY-MM-DD. I can still think
> > of
> > > ways to screw up that (or the plain int;)
> > >
> >
> > 20151229 is a valid integer which you can simply use to compare with.
> >
> > 100, 101, 102 or 20151229, 20160103, 20160104, I don't care that much.
> >
> > My point is that the database version should be separated from the code
> > base.
> >
> > Wido
> >
> > > On Tue, Dec 29, 2015 at 1:40 PM, Rafael Weingärtner <
> > > rafaelweingart...@gmail.com> wrote:
> > >
> > >> Wido, that is true, you are right; the naming on upgrade routines can
> > use a
> > >> numeric value independent of the number of the version. The numeric
> > value
> > >> can be a simple integer that is incremented each routine that is added
> > or a
> > >> time stamp when the routine was added. The point is that we would have
> > to
> > >> link a version to a number. That would enable us to use flywaydb.
> > >>
> > >> To use that approach I think we might need to break compatibility as
> you
> > >> pointed out earlier, but I believe that the benefits of an improved
> way
> > to
> > >> manage upgrade routines will compensate by the breaking of
> > compatibility.
> > >>
> > >> On Tue, Dec 29, 2015 at 10:25 AM, Wido den Hollander 
> > >> wrote:
> > >>
> > >>>
> > >>>
> > >>> On 29-12-15 13:21, Rafael Weingärtner wrote:
> > >>>> I got your point Daan.
> > >>>>
> > >>>> Well, and if we linked a version of ACS with a time stamp in the
> > format
> > >>> of
> > >>>> DD.MM.?
> > >>>>
> > >>>
> > >>> In that case you could also say.
> > >>>
> > >>> ACS 4.6.0 == db ver X
> > >>>
> > >>> You don't have to say ver >= X, you can also say ver = X.
> > >>>
> > >>>> We could then use the time stamp in the same format to name upgrade
> > >>>> routines. This way the idea of running all of the routines in
> between
> > >>>> version during upgrades could be applied.
> > >>>>
> > >>>
> > >>> Same goes for giving all database changes a simple numeric int which
> > >>> keeps incrementing each time a change is applied ;)
> > >>>
> > >>> Wido
> > >>>
> > >>>> On Tue, Dec 29, 2015 at 10:03 AM, Daan Hoogland <
> > >> daan.hoogl...@gmail.com
> > >>>>
> > >>>> wrote:
> > >>>>
> > >>>>> Rafael,
> > >>>>>
> > >>>>> On Tue, Dec 29, 2015 at 12:22 PM, Rafael Weingärtner <
> > >>>>> rafaelweingart...@gmail.com> wrote:
> > >>>>>
> > >>>>>> Thanks, Daan and Wido for your contributions, I will discuss them
> as
> > >>>>>> follows.
> > >>>>>>
> > >>>>>> Daan, about the idea of per commit upgrades. Do you mean that we
> > >>> separate
> > >>>>>> each change in the database that 

Build failed in Jenkins: build-master-slowbuild #2856

[jenkins]

See 

--
[...truncated 28723 lines...]
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:findbugs (findbugs) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud ---
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ 
cloud-quickcloud ---
[WARNING] No files to instrument.
[INFO] NOT adding cobertura ser file to attached artifacts list.
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud ---
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration  SUCCESS 
[1.775s]
[INFO] Apache CloudStack . SUCCESS [2.101s]
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [0.793s]
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [19.310s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:32.010s]
[INFO] Apache CloudStack Framework ... SUCCESS [0.112s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [53.419s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [28.075s]
[INFO] Apache CloudStack API . SUCCESS [1:51.567s]
[INFO] Apache CloudStack Framework - REST  SUCCESS [16.544s]
[INFO] Apache CloudStack Framework - IPC . SUCCESS [30.049s]
[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.084s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [28.356s]
[INFO] Apache CloudStack Framework - Security  SUCCESS [24.810s]
[INFO] Apache CloudStack Core  SUCCESS [1:20.525s]
[INFO] Apache CloudStack Agents .. SUCCESS [36.988s]
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [36.772s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [14.115s]
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:08.040s]
[INFO] Apache CloudStack Framework - Jobs  SUCCESS [40.474s]
[INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS [25.482s]
[INFO] Apache CloudStack Server .. SUCCESS [4:15.336s]
[INFO] Apache CloudStack Framework - Quota ... SUCCESS [37.452s]
[INFO] Apache CloudStack Usage Server  SUCCESS [44.216s]
[INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS 
[1:22.044s]
[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.079s]
[INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.448s]
[INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [54.220s]
[INFO] Apache CloudStack Engine Storage Component  SUCCESS [48.845s]
[INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [29.949s]
[INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [26.531s]
[INFO] Apache CloudStack Engine Storage Data Motion Component  SUCCESS [31.090s]
[INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [23.712s]
[INFO] Apache CloudStack Engine Storage Snapshot Component  SUCCESS [35.592s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [12.578s]
[INFO] Apache CloudStack Cloud Engine Service  SUCCESS [7.865s]
[INFO] Apache CloudStack Plugin POM .. SUCCESS [0.952s]
[INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [26.692s]
[INFO] Apache CloudStack Plugin - Storage Volume default provider  SUCCESS 
[24.216s]
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider  SUCCESS 
[35.700s]
[INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [17.676s]
[INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [23.366s]
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [16.932s]
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SUCCESS 
[17.259s]
[INFO] Apache Cloud

Re: Let’s discuss database upgrades

[Ron Wheeler]

As an old-timer but a  new cloudstack user, it strikes me as a bit odd 
that changes to the database are allowed within a minor version change.

This seems to cause a lot more problems than it solves.

It could delay the release of someone's pet enhancement or bug fix but 
the idea of not being able to upgrade from 4.5.3 to 4.6.2 is frightening.
The prospect of having upgrade scripts for 4.5.2 to 4.6.0, 4.6.1 
and4.6.2 as well as as a separate upgrade from 4.5.3 to 4.6.2 and 
similar scripts for 4.5.4, 4.5.5, etc. to 4.6.2, 4.6.3, 4.6.4 and so on, 
is unpleasant.
This would have to continue until someone says that 4.5.x is dead and no 
upgrade scripts to new 4.6.x releases will be available.


In projects that I have run, a change to the database required a new 
major release so a single conversion will take one from 4.5.x to 4.6.x


The nice thing about release numbers is that one never runs out!

Ron



On 29/12/2015 10:08 AM, Daan Hoogland wrote:

CCYY == 

On Tue, Dec 29, 2015 at 3:06 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:


I also liked the date-format, what did you mean with CCYY?



The way I think we might have a problem, would be to commits/PRs that end
up creating files with same names. Then, we would have to agree upon a way
to solve those conflicts, such as appending an extra character to indicate
a sequence to be followed or adding more data such as HH and mm to the
naming convention (-MM-DD-HH-mm).


I liked the way Wido suggested, we could just remove the “-” from
“-MM-DD-HH-mm” and use the value as an integer (MMDDHHmm).



It seems that we are reaching a consensus. I would love to hear back from
other devs though, especially committers.



BTW: do I have permission to create a page on the wiki so I can add
everything we discuss and agree upon here? This way, we could add that page
to the guidelines for devs creating PRs and committers reviewing and
merging them.

On Tue, Dec 29, 2015 at 12:00 PM, Wido den Hollander 
wrote:



On 29-12-15 14:46, Daan Hoogland wrote:

Wido, Rafael,

I like the date-format but then of course CCYY-MM-DD. I can still think

of

ways to screw up that (or the plain int;)


20151229 is a valid integer which you can simply use to compare with.

100, 101, 102 or 20151229, 20160103, 20160104, I don't care that much.

My point is that the database version should be separated from the code
base.

Wido


On Tue, Dec 29, 2015 at 1:40 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:


Wido, that is true, you are right; the naming on upgrade routines can

use a

numeric value independent of the number of the version. The numeric

value

can be a simple integer that is incremented each routine that is added

or a

time stamp when the routine was added. The point is that we would have

to

link a version to a number. That would enable us to use flywaydb.

To use that approach I think we might need to break compatibility as

you

pointed out earlier, but I believe that the benefits of an improved

way

to

manage upgrade routines will compensate by the breaking of

compatibility.

On Tue, Dec 29, 2015 at 10:25 AM, Wido den Hollander 
wrote:



On 29-12-15 13:21, Rafael Weingärtner wrote:

I got your point Daan.

Well, and if we linked a version of ACS with a time stamp in the

format

of

DD.MM.?


In that case you could also say.

ACS 4.6.0 == db ver X

You don't have to say ver >= X, you can also say ver = X.


We could then use the time stamp in the same format to name upgrade
routines. This way the idea of running all of the routines in

between

version during upgrades could be applied.


Same goes for giving all database changes a simple numeric int which
keeps incrementing each time a change is applied ;)

Wido


On Tue, Dec 29, 2015 at 10:03 AM, Daan Hoogland <

daan.hoogl...@gmail.com

wrote:


Rafael,

On Tue, Dec 29, 2015 at 12:22 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:


Thanks, Daan and Wido for your contributions, I will discuss them

as

follows.

Daan, about the idea of per commit upgrades. Do you mean that we

separate

each change in the database that is introduced by PRs/Commits in a
different file (routine upgrade) per ACS version?
So we would have, V_480_A.sql (for a PR),V_480_B.sql (for another

PR)

and

so forth

If that is the case, we can achieve that using a simple convention

naming

as I suggested. Each developer when she/he needs to change or add

something

in the database creates an upgrade routine separately and gives it

an

execution order to be taken by Flywaydb. I think that could help

RMs

to

track and isolate the problem, right?


​Yes, with one little caveat. We do not know in what version a

feature/PR

will end up at the time of implementing, so a name containing the

version

would not be ideal.
​



Hi Wido, now I understand your example.
I understand your worry about upgrade paths, and that is the

point I

want

to

Re: Let’s discuss database upgrades

[Daan Hoogland]

You are right Ron, but there is always security fixes that might require db
changes on a point release.

On Tue, Dec 29, 2015 at 5:39 PM, Ron Wheeler  wrote:

> As an old-timer but a  new cloudstack user, it strikes me as a bit odd
> that changes to the database are allowed within a minor version change.
> This seems to cause a lot more problems than it solves.
>
> It could delay the release of someone's pet enhancement or bug fix but the
> idea of not being able to upgrade from 4.5.3 to 4.6.2 is frightening.
> The prospect of having upgrade scripts for 4.5.2 to 4.6.0, 4.6.1 and4.6.2
> as well as as a separate upgrade from 4.5.3 to 4.6.2 and similar scripts
> for 4.5.4, 4.5.5, etc. to 4.6.2, 4.6.3, 4.6.4 and so on, is unpleasant.
> This would have to continue until someone says that 4.5.x is dead and no
> upgrade scripts to new 4.6.x releases will be available.
>
> In projects that I have run, a change to the database required a new major
> release so a single conversion will take one from 4.5.x to 4.6.x
>
> The nice thing about release numbers is that one never runs out!
>
> Ron
>
>
>
> On 29/12/2015 10:08 AM, Daan Hoogland wrote:
>
>> CCYY == 
>>
>> On Tue, Dec 29, 2015 at 3:06 PM, Rafael Weingärtner <
>> rafaelweingart...@gmail.com> wrote:
>>
>> I also liked the date-format, what did you mean with CCYY?
>>>
>>>
>>>
>>> The way I think we might have a problem, would be to commits/PRs that end
>>> up creating files with same names. Then, we would have to agree upon a
>>> way
>>> to solve those conflicts, such as appending an extra character to
>>> indicate
>>> a sequence to be followed or adding more data such as HH and mm to the
>>> naming convention (-MM-DD-HH-mm).
>>>
>>>
>>> I liked the way Wido suggested, we could just remove the “-” from
>>> “-MM-DD-HH-mm” and use the value as an integer (MMDDHHmm).
>>>
>>>
>>>
>>> It seems that we are reaching a consensus. I would love to hear back from
>>> other devs though, especially committers.
>>>
>>>
>>>
>>> BTW: do I have permission to create a page on the wiki so I can add
>>> everything we discuss and agree upon here? This way, we could add that
>>> page
>>> to the guidelines for devs creating PRs and committers reviewing and
>>> merging them.
>>>
>>> On Tue, Dec 29, 2015 at 12:00 PM, Wido den Hollander 
>>> wrote:
>>>
>>>
>>>> On 29-12-15 14:46, Daan Hoogland wrote:
>>>>
>>>>> Wido, Rafael,
>>>>>
>>>>> I like the date-format but then of course CCYY-MM-DD. I can still think
>>>>>
>>>> of
>>>>
>>>>> ways to screw up that (or the plain int;)
>>>>>
>>>>> 20151229 is a valid integer which you can simply use to compare with.
>>>>
>>>> 100, 101, 102 or 20151229, 20160103, 20160104, I don't care that much.
>>>>
>>>> My point is that the database version should be separated from the code
>>>> base.
>>>>
>>>> Wido
>>>>
>>>> On Tue, Dec 29, 2015 at 1:40 PM, Rafael Weingärtner <
>>>>> rafaelweingart...@gmail.com> wrote:
>>>>>
>>>>> Wido, that is true, you are right; the naming on upgrade routines can
>>>>>>
>>>>> use a
>>>>
>>>>> numeric value independent of the number of the version. The numeric
>>>>>>
>>>>> value
>>>>
>>>>> can be a simple integer that is incremented each routine that is added
>>>>>>
>>>>> or a
>>>>
>>>>> time stamp when the routine was added. The point is that we would have
>>>>>>
>>>>> to
>>>>
>>>>> link a version to a number. That would enable us to use flywaydb.
>>>>>>
>>>>>> To use that approach I think we might need to break compatibility as
>>>>>>
>>>>> you
>>>
>>>> pointed out earlier, but I believe that the benefits of an improved
>>>>>>
>>>>> way
>>>
>>>> to
>>>>
>>>>> manage upgrade routines will compensate by the breaking of
>>>>>>
>>>>> compatibility.
>>>>
>>>>> On Tue, Dec 29, 2015 at 10:25 AM, Wido den Hollander 
>>>>>> w

Re: Let’s discuss database upgrades

[Ron Wheeler]

On 29/12/2015 12:01 PM, Daan Hoogland wrote:

You are right Ron, but there is always security fixes that might require db
changes on a point release.

That might not be so bad if
a) they are very exceptional
b) the bug is so critical that all users of version 4.5.x and earlier 
will have to move to 4.5.x+1 so support for the 4.5.x to 4.6.x upgrade 
will be somewhat constrained (ie no support for 4.5.x and earlier to 
current 4.6.x).


Ron



On Tue, Dec 29, 2015 at 5:39 PM, Ron Wheeler 
wrote:
As an old-timer but a  new cloudstack user, it strikes me as a bit odd
that changes to the database are allowed within a minor version change.
This seems to cause a lot more problems than it solves.

It could delay the release of someone's pet enhancement or bug fix but the
idea of not being able to upgrade from 4.5.3 to 4.6.2 is frightening.
The prospect of having upgrade scripts for 4.5.2 to 4.6.0, 4.6.1 and4.6.2
as well as as a separate upgrade from 4.5.3 to 4.6.2 and similar scripts
for 4.5.4, 4.5.5, etc. to 4.6.2, 4.6.3, 4.6.4 and so on, is unpleasant.
This would have to continue until someone says that 4.5.x is dead and no
upgrade scripts to new 4.6.x releases will be available.

In projects that I have run, a change to the database required a new major
release so a single conversion will take one from 4.5.x to 4.6.x

The nice thing about release numbers is that one never runs out!

Ron



On 29/12/2015 10:08 AM, Daan Hoogland wrote:


CCYY == 

On Tue, Dec 29, 2015 at 3:06 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

I also liked the date-format, what did you mean with CCYY?



The way I think we might have a problem, would be to commits/PRs that end
up creating files with same names. Then, we would have to agree upon a
way
to solve those conflicts, such as appending an extra character to
indicate
a sequence to be followed or adding more data such as HH and mm to the
naming convention (-MM-DD-HH-mm).


I liked the way Wido suggested, we could just remove the “-” from
“-MM-DD-HH-mm” and use the value as an integer (MMDDHHmm).



It seems that we are reaching a consensus. I would love to hear back from
other devs though, especially committers.



BTW: do I have permission to create a page on the wiki so I can add
everything we discuss and agree upon here? This way, we could add that
page
to the guidelines for devs creating PRs and committers reviewing and
merging them.

On Tue, Dec 29, 2015 at 12:00 PM, Wido den Hollander 
wrote:



On 29-12-15 14:46, Daan Hoogland wrote:


Wido, Rafael,

I like the date-format but then of course CCYY-MM-DD. I can still think


of


ways to screw up that (or the plain int;)

20151229 is a valid integer which you can simply use to compare with.

100, 101, 102 or 20151229, 20160103, 20160104, I don't care that much.

My point is that the database version should be separated from the code
base.

Wido

On Tue, Dec 29, 2015 at 1:40 PM, Rafael Weingärtner <

rafaelweingart...@gmail.com> wrote:

Wido, that is true, you are right; the naming on upgrade routines can
use a
numeric value independent of the number of the version. The numeric
value
can be a simple integer that is incremented each routine that is added
or a
time stamp when the routine was added. The point is that we would have
to
link a version to a number. That would enable us to use flywaydb.

To use that approach I think we might need to break compatibility as


you

pointed out earlier, but I believe that the benefits of an improved

way

to


manage upgrade routines will compensate by the breaking of
compatibility.
On Tue, Dec 29, 2015 at 10:25 AM, Wido den Hollander 

wrote:



On 29-12-15 13:21, Rafael Weingärtner wrote:


I got your point Daan.

Well, and if we linked a version of ACS with a time stamp in the


format

of

DD.MM.?

In that case you could also say.

ACS 4.6.0 == db ver X

You don't have to say ver >= X, you can also say ver = X.

We could then use the time stamp in the same format to name upgrade

routines. This way the idea of running all of the routines in


between

version during upgrades could be applied.

Same goes for giving all database changes a simple numeric int which

keeps incrementing each time a change is applied ;)

Wido

On Tue, Dec 29, 2015 at 10:03 AM, Daan Hoogland <
daan.hoogl...@gmail.com
wrote:

Rafael,

On Tue, Dec 29, 2015 at 12:22 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

Thanks, Daan and Wido for your contributions, I will discuss them
as

follows.

Daan, about the idea of per commit upgrades. Do you mean that we


separate

each change in the database that is introduced by PRs/Commits in a

different file (routine upgrade) per ACS version?
So we would have, V_480_A.sql (for a PR),V_480_B.sql (for another


PR)

and

so forth

If that is the case, we can achieve that using a simple convention


naming

as I suggested. Each developer when she/he needs to change or add

somethi

[GitHub] cloudstack pull request: CLOUDSTACK-9202 Bump ssh timeout for VR c...

[remibergsma]

Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1291#issuecomment-167842159
  
With this fix it survives longer wait times:
```
2015-12-29 12:40:02,011 DEBUG [c.c.a.r.v.VirtualRoutingResource] 
(DirectAgent-111:ctx-d584fccd) Processing ScriptConfigItem, executing 
update_config.py forwarding_rules.json took 63767ms
```


---
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-9181 Prevent syntax error in c...

[remibergsma]

Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1296#issuecomment-167842372
  
@rafaelweingartner In the original PR against master someone asked to split 
the commits hehe :-s


---
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.
---

Upcoming releases: ACS 4.7.1 / 4.8.0

[Remi Bergsma]

Hi all,

We will freeze for new features for Apache CloudStack 4.8 on January 15th. The 
release is expected by the end of the month.

So far we have one feature merged. Please go ahead and test/review any 
additional features. Bug fixes should be pointed towards 4.7 branch and will 
end up in both 4.7.1 and 4.8.0.

As we have not much for 4.7.1 yet, I think due to the time of the year we 
should skip one point release and next month release (only) 4.7.1 and 4.8.0.

Full schedule:

Jan 15: Freeze for 4.8
Jan 20: ACS 4.8.0 RC
Jan 20: ACS 4.7.1 RC
Jan 31 (the latest): 4.7.1 / 4.8.0 released!

Regards,
Remi

Re: Upcoming releases: ACS 4.7.1 / 4.8.0

[Wido den Hollander]

On 12/29/2015 06:59 PM, Remi Bergsma wrote:
> Hi all,
> 
> We will freeze for new features for Apache CloudStack 4.8 on January 15th. 
> The release is expected by the end of the month.
> 
> So far we have one feature merged. Please go ahead and test/review any 
> additional features. Bug fixes should be pointed towards 4.7 branch and will 
> end up in both 4.7.1 and 4.8.0.
> 
> As we have not much for 4.7.1 yet, I think due to the time of the year we 
> should skip one point release and next month release (only) 4.7.1 and 4.8.0.
> 

Seems like a good thing to me. The shorter the release cycles become,
the less need there is for a point release imho.

Wido

> Full schedule:
> 
> Jan 15: Freeze for 4.8
> Jan 20: ACS 4.8.0 RC
> Jan 20: ACS 4.7.1 RC
> Jan 31 (the latest): 4.7.1 / 4.8.0 released!
> 
> Regards,
> Remi
> 

Build failed in Jenkins: build-master-slowbuild #2857

[jenkins]

See 

--
[...truncated 28723 lines...]
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:findbugs (findbugs) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud ---
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ 
cloud-quickcloud ---
[WARNING] No files to instrument.
[INFO] NOT adding cobertura ser file to attached artifacts list.
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud ---
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration  SUCCESS 
[1.754s]
[INFO] Apache CloudStack . SUCCESS [2.067s]
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [0.782s]
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [19.432s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:31.486s]
[INFO] Apache CloudStack Framework ... SUCCESS [0.106s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [53.205s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [27.953s]
[INFO] Apache CloudStack API . SUCCESS [1:54.332s]
[INFO] Apache CloudStack Framework - REST  SUCCESS [16.484s]
[INFO] Apache CloudStack Framework - IPC . SUCCESS [29.761s]
[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.094s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [28.201s]
[INFO] Apache CloudStack Framework - Security  SUCCESS [24.108s]
[INFO] Apache CloudStack Core  SUCCESS [1:21.864s]
[INFO] Apache CloudStack Agents .. SUCCESS [36.082s]
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [37.153s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [14.167s]
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:06.363s]
[INFO] Apache CloudStack Framework - Jobs  SUCCESS [40.400s]
[INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS [25.473s]
[INFO] Apache CloudStack Server .. SUCCESS [4:14.752s]
[INFO] Apache CloudStack Framework - Quota ... SUCCESS [36.538s]
[INFO] Apache CloudStack Usage Server  SUCCESS [44.476s]
[INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS 
[1:20.687s]
[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.069s]
[INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.445s]
[INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [54.005s]
[INFO] Apache CloudStack Engine Storage Component  SUCCESS [48.079s]
[INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [30.038s]
[INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [26.495s]
[INFO] Apache CloudStack Engine Storage Data Motion Component  SUCCESS [31.003s]
[INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [22.963s]
[INFO] Apache CloudStack Engine Storage Snapshot Component  SUCCESS [35.260s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [12.534s]
[INFO] Apache CloudStack Cloud Engine Service  SUCCESS [7.604s]
[INFO] Apache CloudStack Plugin POM .. SUCCESS [0.946s]
[INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [26.790s]
[INFO] Apache CloudStack Plugin - Storage Volume default provider  SUCCESS 
[23.475s]
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider  SUCCESS 
[37.711s]
[INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [17.778s]
[INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [23.137s]
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [15.700s]
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SUCCESS 
[16.704s]
[INFO] Apache Cloud

Build failed in Jenkins: build-master-slowbuild #2858

[jenkins]

See 

--
[...truncated 28723 lines...]
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:findbugs (findbugs) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud ---
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ 
cloud-quickcloud ---
[WARNING] No files to instrument.
[INFO] NOT adding cobertura ser file to attached artifacts list.
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud ---
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration  SUCCESS 
[1.840s]
[INFO] Apache CloudStack . SUCCESS [2.076s]
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [0.785s]
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [19.691s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:29.127s]
[INFO] Apache CloudStack Framework ... SUCCESS [0.102s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [53.495s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [27.609s]
[INFO] Apache CloudStack API . SUCCESS [1:49.259s]
[INFO] Apache CloudStack Framework - REST  SUCCESS [16.135s]
[INFO] Apache CloudStack Framework - IPC . SUCCESS [29.748s]
[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.087s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [28.675s]
[INFO] Apache CloudStack Framework - Security  SUCCESS [25.234s]
[INFO] Apache CloudStack Core  SUCCESS [1:20.847s]
[INFO] Apache CloudStack Agents .. SUCCESS [36.160s]
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [36.332s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [14.079s]
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:07.343s]
[INFO] Apache CloudStack Framework - Jobs  SUCCESS [40.536s]
[INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS [24.972s]
[INFO] Apache CloudStack Server .. SUCCESS [4:13.099s]
[INFO] Apache CloudStack Framework - Quota ... SUCCESS [36.869s]
[INFO] Apache CloudStack Usage Server  SUCCESS [44.033s]
[INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS 
[1:21.754s]
[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.074s]
[INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.461s]
[INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [54.235s]
[INFO] Apache CloudStack Engine Storage Component  SUCCESS [48.167s]
[INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [29.662s]
[INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [25.466s]
[INFO] Apache CloudStack Engine Storage Data Motion Component  SUCCESS [31.104s]
[INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [20.325s]
[INFO] Apache CloudStack Engine Storage Snapshot Component  SUCCESS [35.446s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [12.561s]
[INFO] Apache CloudStack Cloud Engine Service  SUCCESS [7.557s]
[INFO] Apache CloudStack Plugin POM .. SUCCESS [0.982s]
[INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [26.396s]
[INFO] Apache CloudStack Plugin - Storage Volume default provider  SUCCESS 
[23.265s]
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider  SUCCESS 
[37.547s]
[INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [17.234s]
[INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [23.687s]
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [14.755s]
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SUCCESS 
[16.705s]
[INFO] Apache Cloud

Re: Let’s discuss database upgrades

[Erik Weber]

On Mon, Dec 28, 2015 at 2:16 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> Hi all devs,
> First of all, sorry the long text, but I hope we can start a discussion
> here and improve that part of ACS.
>
> A while ago I have faced the code that Apache CloudStack (ACS) uses to
> upgrade from a version to newer one and that did not seem to be a good way
> to execute our upgrades. Therefore, I decided to use some time to search
> for alternatives.
>
> I have read some material about versioning of scripts used to upgrade a
> database (DB) of a system and went through some frameworks that could help
> us.
>
> In the literature of software engineering, it is firmly stated that we have
> to version DB scripts as we do with the source code of the application,
> using the baseline approach. Gladly, we were not that bad at this point, we
> already versioned our routines for DB upgrade (.sql and .java). Therefore,
> it seemed that we just did not have used a practical approach to help us
> during DB upgrades.
>
> From my readings and looking at the ACS source code I raised the following
> requirement:
> •We should be able to write more than one routine to upgrade to a
> version; those routines can be written in Java and SQL. We might have more
> than a routine to be executed for each version and we should be able to
> define an order of execution. Additionally, to go to an upper version, we
> have to run all of the routines from smaller versions first, until we
> achieve the desired version.
>
> We could also add another requirement that is the downgrade from a version,
> which we currently do not support. With that comes my first question for
> discussion:
> •Do we want/need a method to downgrade from a version to a previous
> one?
>
> I found an explanation for not supporting downgrades, and I liked it:
> http://flywaydb.org/documentation/faq.html#downgrade
>
> So, what I devised for us:
> First the bureaucracy part  - our migrations occur basically in three (3)
> steps, first we have a "prepare script", then a cleanup script and finally
> the migration per se that is written in Java, at least, that is what we can
> expect when reading the interface “com.cloud.upgrade.dao.DbUpgrade”.
>
> Additionally, our scripts have the following naming convention:
> schema-to, which in IMHO may cause some
> confusion because at first sight we may think that from the same version we
> could have different paths to an upper version, which in practice is not
> happening. Instead of a to we could simply use
> V__., giving that, we have to
> execute all of the V_ scripts that are smaller than the version we
> want to upgrade.
>
> To clarify what I am saying, I will use an example. Let’s say we have just
> installed ACS and ran the cloudstack-setup-database. That command will
> create a database schema in version 4.0.0. To upgrade that schema to
> version 4.3.0 (it is just an example, it could be any other version), ACS
> will use the following mapping:
>
> _upgradeMap.put("4.0.0", new DbUpgrade[] {new Upgrade40to41(), new
> Upgrade410to420(), new Upgrade420to421(), new Upgrade421to430())
>
> After loading the mapping, ACS will execute the scripts defined in each one
> of the Upgrade path classes and the migration code per se.
>
> Now, let’s say we change the “.sql” scripts name to the pattern I
> mentioned, we would have the following scripts; those are the scripts found
> that aim to upgrade to versions between the interval 4.0.0 – 4.3.0
> (considering 4.3.0, since that is the goal version):
>
>
>- schema-40to410, can be named to:  V_410_A.sql
>- schema-40to410-cleanup, can be named to:  V_410_B.sql
>- schema-410to420, can be named to:  V_420_A.sql
>- schema-410to420-cleanup , can be named to:  V_420_b.sql
>- schema-420to421, can be named to:  V_421_A.sql
>- schema-421to430, can be named to:  V_430_A.sql
>- schema-421to430-cleanup, can be named to:  V_430_B.sql
>
>
> Additionally, all of the java code would have to follow the same
> convention. For instance, we have “com.cloud.upgrade.dao.Upgrade40to41”,
> which has some java code to migrate from 4.0.0 to 4.1.0. The idea is to
> extract that migration code to a Java class named:  V_410_C.java, giving
> that it has to execute the SQL scripts before the java code.
>
> In order to go from a smaller version (4.0.0) to an upper one (4.3.0), we
> have to run all of the migration routines from intermediate versions. That
> is what we are already doing, but we do all of that manually.
>
> Bottom line, I think we could simple use the convention
> V__. to name upgrade routines.
> That would facilitate us to use a framework to help us with that process.
> Additionally, I believe that we should always assume that to go from a
> smaller version to a higher one, we should run all of the scripts that
> exist between them. What do you guys think of that?
>
> After the bureaucracy, we can discuss tools. If we use that convention to
> name migration 

Build failed in Jenkins: build-master-slowbuild #2859

[jenkins]

See 

--
[...truncated 28733 lines...]
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:findbugs (findbugs) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud ---
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ 
cloud-quickcloud ---
[WARNING] No files to instrument.
[INFO] NOT adding cobertura ser file to attached artifacts list.
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud ---
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration  SUCCESS 
[1.841s]
[INFO] Apache CloudStack . SUCCESS [2.070s]
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [0.779s]
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [20.181s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:29.636s]
[INFO] Apache CloudStack Framework ... SUCCESS [0.102s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [53.962s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [27.082s]
[INFO] Apache CloudStack API . SUCCESS [1:46.547s]
[INFO] Apache CloudStack Framework - REST  SUCCESS [16.750s]
[INFO] Apache CloudStack Framework - IPC . SUCCESS [30.487s]
[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.094s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [28.515s]
[INFO] Apache CloudStack Framework - Security  SUCCESS [24.410s]
[INFO] Apache CloudStack Core  SUCCESS [1:21.465s]
[INFO] Apache CloudStack Agents .. SUCCESS [35.779s]
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [37.599s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [14.157s]
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:07.246s]
[INFO] Apache CloudStack Framework - Jobs  SUCCESS [40.556s]
[INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS [25.275s]
[INFO] Apache CloudStack Server .. SUCCESS [4:13.012s]
[INFO] Apache CloudStack Framework - Quota ... SUCCESS [36.722s]
[INFO] Apache CloudStack Usage Server  SUCCESS [44.684s]
[INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS 
[1:21.577s]
[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.073s]
[INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.431s]
[INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [53.821s]
[INFO] Apache CloudStack Engine Storage Component  SUCCESS [50.125s]
[INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [32.216s]
[INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [26.575s]
[INFO] Apache CloudStack Engine Storage Data Motion Component  SUCCESS [25.635s]
[INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [20.724s]
[INFO] Apache CloudStack Engine Storage Snapshot Component  SUCCESS [35.836s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [12.069s]
[INFO] Apache CloudStack Cloud Engine Service  SUCCESS [7.859s]
[INFO] Apache CloudStack Plugin POM .. SUCCESS [0.943s]
[INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [26.628s]
[INFO] Apache CloudStack Plugin - Storage Volume default provider  SUCCESS 
[23.103s]
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider  SUCCESS 
[37.073s]
[INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [17.678s]
[INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [23.587s]
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [15.708s]
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SUCCESS 
[16.500s]
[INFO] Apache Cloud

Build failed in Jenkins: build-master-slowbuild #2860

[jenkins]

See 

--
[...truncated 28723 lines...]
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:findbugs (findbugs) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud ---
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ 
cloud-quickcloud ---
[WARNING] No files to instrument.
[INFO] NOT adding cobertura ser file to attached artifacts list.
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud ---
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration  SUCCESS 
[1.758s]
[INFO] Apache CloudStack . SUCCESS [2.061s]
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [0.766s]
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [19.128s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:30.707s]
[INFO] Apache CloudStack Framework ... SUCCESS [0.101s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [53.789s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [26.861s]
[INFO] Apache CloudStack API . SUCCESS [1:50.042s]
[INFO] Apache CloudStack Framework - REST  SUCCESS [16.331s]
[INFO] Apache CloudStack Framework - IPC . SUCCESS [30.181s]
[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.094s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [28.518s]
[INFO] Apache CloudStack Framework - Security  SUCCESS [25.254s]
[INFO] Apache CloudStack Core  SUCCESS [1:21.255s]
[INFO] Apache CloudStack Agents .. SUCCESS [35.625s]
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [36.090s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [14.260s]
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:07.154s]
[INFO] Apache CloudStack Framework - Jobs  SUCCESS [40.895s]
[INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS [25.609s]
[INFO] Apache CloudStack Server .. SUCCESS [4:15.326s]
[INFO] Apache CloudStack Framework - Quota ... SUCCESS [37.741s]
[INFO] Apache CloudStack Usage Server  SUCCESS [44.662s]
[INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS 
[1:23.042s]
[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.073s]
[INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.449s]
[INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [54.062s]
[INFO] Apache CloudStack Engine Storage Component  SUCCESS [48.227s]
[INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [29.774s]
[INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [25.949s]
[INFO] Apache CloudStack Engine Storage Data Motion Component  SUCCESS [25.586s]
[INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [20.589s]
[INFO] Apache CloudStack Engine Storage Snapshot Component  SUCCESS [35.257s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [12.288s]
[INFO] Apache CloudStack Cloud Engine Service  SUCCESS [8.013s]
[INFO] Apache CloudStack Plugin POM .. SUCCESS [1.039s]
[INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [26.837s]
[INFO] Apache CloudStack Plugin - Storage Volume default provider  SUCCESS 
[23.190s]
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider  SUCCESS 
[37.026s]
[INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [17.109s]
[INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [23.305s]
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [15.828s]
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SUCCESS 
[16.646s]
[INFO] Apache Cloud

[GitHub] cloudstack pull request: CLOUDSTACK-9132: API createVolume takes e...

[nitin-maharana]

Github user nitin-maharana commented on the pull request:

https://github.com/apache/cloudstack/pull/1273#issuecomment-167931759
  
cc @remibergsma @bhaisaab 


---
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-8968: UI icon over VM snapshot...

[nitin-maharana]

Github user nitin-maharana commented on the pull request:

https://github.com/apache/cloudstack/pull/1150#issuecomment-167931844
  
cc @bhaisaab 


---
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: Strongswan vpn feature

[jayapalu]

Github user jayapalu commented on the pull request:

https://github.com/apache/cloudstack/pull/872#issuecomment-167932695
  
@remibergsma @kishankavala @terbolous @bhaisaab 
Added all the required tests below. Please review the PR.

nosetests-2.7 --with-marvin 
--marvin-config=/Users/jayapalreddy/advanced-acs.cfg  
/Users/jayapalreddy/dev/ccp/internal-cloudstack/test/integration/smoke/test_vpc_vpn.py:
 -a tags=advanced   --zone=zone1  --hypervisor=xenserver

 Marvin Init Started 

=== Marvin Parse Config Successful ===

=== Marvin Setting TestData Successful===

 Log Folder Path: /tmp//MarvinLogs//Dec_29_2015_17_38_50_UWQR0C. All 
logs will be available here 

=== Marvin Init Logging Successful===

 Marvin Init Successful 
Downloading Template: tiny-xen from: 
http://10.147.28.7/templates/macchinina-xen.vhd.bz2
Retrieving default VPC offering
VPC 34f02162-2a74-4cfd-abe9-4c49963448bd created
Network 390e967e-76a6-4295-bfe3-f7e5979f941d created in VPC 
34f02162-2a74-4cfd-abe9-4c49963448bd
Deployed virtual machine: OK
Acquired public ip address: OK
Created Remote Access VPN: OK
Created VPN User: OK
Deleted the Remote Access VPN: OK
309.452
Cleaning up resources
Downloading Template: tiny-xen from: 
http://10.147.28.7/templates/macchinina-xen.vhd.bz2
VPC1 4069f201-9b8c-4f88-be3a-854f950b116a created
VPC2 27d2d1f4-b259-4054-b86c-42b523697bdd created
Network 6ea68fd2-00e6-466a-98fe-4afc3ef9388f created in VPC 
4069f201-9b8c-4f88-be3a-854f950b116a
Network 52080ba5-141a-447f-bdef-6743ab7fa28b created in VPC 
27d2d1f4-b259-4054-b86c-42b523697bdd
VM 70b15111-c747-4ace-8f77-6dc4eb4c4d7d deployed in VPC 
4069f201-9b8c-4f88-be3a-854f950b116a
VPN gateway for VPC 4069f201-9b8c-4f88-be3a-854f950b116a enabled
VPN gateway for VPC 27d2d1f4-b259-4054-b86c-42b523697bdd enabled
{'account': u'test-TestVpcSite2SiteVpn-test_vpc_remote_access_vpn-2065YX', 
'domainid': u'a18845c6-a7c2-11e5-92c7-4d467782273c', 'name': u'Peer VPC1', 
'cidrlist': u'10.1.0.0/16', 'ikepolicy': u'3des-md5;modp1536', 'esplifetime': 
3600, 'id': u'b53267c1-f983-4743-b2c0-772ad18347d4', 'dpd': False, 'domain': 
u'ROOT', 'ikelifetime': 86400, 'ipsecpsk': u'ipsecpsk', 'esppolicy': 
u'3des-md5;modp1536', 'gateway': u'10.147.52.174'}
{'account': u'test-TestVpcSite2SiteVpn-test_vpc_remote_access_vpn-2065YX', 
'domainid': u'a18845c6-a7c2-11e5-92c7-4d467782273c', 'name': u'Peer VPC2', 
'cidrlist': u'10.2.0.0/16', 'ikepolicy': u'3des-md5;modp1536', 'esplifetime': 
3600, 'id': u'8c617821-08b6-438c-a4ca-77dc75a07498', 'dpd': False, 'domain': 
u'ROOT', 'ikelifetime': 86400, 'ipsecpsk': u'ipsecpsk', 'esppolicy': 
u'3des-md5;modp1536', 'gateway': u'10.147.52.176'}
Creating NAT rule in network for vm with public IP
Adding NetworkACL rules to make NAT rule accessible
Trying SSH Connection: Host:10.147.52.177 User:root 
  Port:22 RetryCnt:10===
===SSH to Host 10.147.52.177 port : 22 SUCCESSFUL===
{Cmd: /bin/ping -c 3 -t 10 10.1.1.68 |grep packet|cut -d ' ' -f 7| cut -f1 
-d'%' via Host: 10.147.52.177} {returns: [u'0']}
===final results are now copied to: /tmp//MarvinLogs/test_vpc_vpn_BFUI7X===

cat /tmp//MarvinLogs/test_vpc_vpn_BFUI7X/results.txt
Test Remote Access VPN in VPC ... === TestName: test_vpc_remote_access_vpn 
| Status : SUCCESS ===
ok
Test VPN in VPC ... === TestName: test_vpc_site2site_vpn | Status : SUCCESS 
===
ok

--
Ran 2 tests in 849.926s

OK


---
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.
---

Build failed in Jenkins: build-master-slowbuild #2861

[jenkins]

See 

--
[...truncated 28723 lines...]
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:findbugs (findbugs) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud ---
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ 
cloud-quickcloud ---
[WARNING] No files to instrument.
[INFO] NOT adding cobertura ser file to attached artifacts list.
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud ---
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration  SUCCESS 
[1.779s]
[INFO] Apache CloudStack . SUCCESS [2.092s]
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [0.789s]
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [19.174s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:30.096s]
[INFO] Apache CloudStack Framework ... SUCCESS [0.110s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [53.769s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [27.080s]
[INFO] Apache CloudStack API . SUCCESS [1:51.326s]
[INFO] Apache CloudStack Framework - REST  SUCCESS [16.248s]
[INFO] Apache CloudStack Framework - IPC . SUCCESS [30.293s]
[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.080s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [27.917s]
[INFO] Apache CloudStack Framework - Security  SUCCESS [24.805s]
[INFO] Apache CloudStack Core  SUCCESS [1:21.920s]
[INFO] Apache CloudStack Agents .. SUCCESS [35.405s]
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [37.235s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [14.166s]
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:08.147s]
[INFO] Apache CloudStack Framework - Jobs  SUCCESS [40.461s]
[INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS [24.921s]
[INFO] Apache CloudStack Server .. SUCCESS [4:11.587s]
[INFO] Apache CloudStack Framework - Quota ... SUCCESS [37.517s]
[INFO] Apache CloudStack Usage Server  SUCCESS [44.872s]
[INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS 
[1:19.789s]
[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.069s]
[INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.448s]
[INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [53.978s]
[INFO] Apache CloudStack Engine Storage Component  SUCCESS [48.398s]
[INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [29.533s]
[INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [26.728s]
[INFO] Apache CloudStack Engine Storage Data Motion Component  SUCCESS [31.865s]
[INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [23.508s]
[INFO] Apache CloudStack Engine Storage Snapshot Component  SUCCESS [34.754s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [12.382s]
[INFO] Apache CloudStack Cloud Engine Service  SUCCESS [7.886s]
[INFO] Apache CloudStack Plugin POM .. SUCCESS [1.001s]
[INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [27.190s]
[INFO] Apache CloudStack Plugin - Storage Volume default provider  SUCCESS 
[23.660s]
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider  SUCCESS 
[37.855s]
[INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [17.267s]
[INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [23.176s]
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [14.661s]
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SUCCESS 
[17.024s]
[INFO] Apache Cloud

[GitHub] cloudstack pull request: CLOUDSTACK-9132: API createVolume takes e...

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/1273#issuecomment-167953466
  
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.
---