Re: S2S VPN to AWS problems

[Nux!]

Thanks!

Manually modifying the VR kind of sucks ... hopefully this will be improved in 
the future.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Srinivas Gandikota" 
> To: "dev" , "Nux!" 
> Cc: "users" 
> Sent: Friday, 1 December, 2017 03:06:14
> Subject: Re: S2S VPN to AWS problems

> Nux,
> 
> 
> You can get one tunnel working, but requires two manual changes in the VR
> strongswan vpn options.
> 
> 
>  1.  Enforce ikev1
>  2.  add compress=no
> 
> If all other pieces are in sync, tunnel should be up.
> 
> Thanks,
> Srinivas
> 
> 
> 
> 
> From: Nux! 
> Sent: Thursday, November 30, 2017 11:04 PM
> To: dev
> Cc: users
> Subject: S2S VPN to AWS problems
> 
> Hello,
> 
> Has anyone managed to get a s2s VPN up with an AWS VPC?
> I see AWS require the setup of two tunnels which does not seem possible in 
> ACS.
> Connecting to either tunnels alone results in the VPN getting disconnected.
> 
> Any pointers much appreciated!
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> DISCLAIMER
> ==
> This e-mail may contain privileged and confidential information which is the
> property of Accelerite, a Persistent Systems business. It is intended only for
> the use of the individual or entity to which it is addressed. If you are not
> the intended recipient, you are not authorized to read, retain, copy, print,
> distribute or use this message. If you have received this communication in
> error, please notify the sender and delete all copies of this message.
> Accelerite, a Persistent Systems business does not accept any liability for
> virus infected mails.

Re: Clean up old and obsolete branches

[Khosrow Moossavi]

@Daan That's a good point, I'll try to update the list to
CLOUDSTACK- wherever applicable. But the majority of branches are
4.1.x to 4.6.x, which might be able to be cleaned up easily.

- I feel we might be able to delete everything 4.1.x, 4.2.x, 4.3.x, 4.4.x,
4.5.x, 4.6.x (almost blindly).
- the only branches of 4.7.x are the RCs (should be safe to be deleted)
- the only branches of 4.8.x are the RCs (should be safe to be deleted)
- the only branches of 4.9.x are the RCs and 3 develop branches (should be
safe to be deleted)
- there are bunch of CID- which I don't know what they are. There
are no corresponding CLOUDSTACK tickets for those number. (might be safe to
be deleted)

@Rafael I agree which this approach. We can have master and release
branches with names as "major.minor.micro.x" (e.g. 4.11.0.x) in which their
HEAD's pom version always have SNAPSHOT (e.g. 4.11.0.1-SNAPSHOT) and on
releasing:

- remove the SNAPSHOT from pom
- tag it (with full qualified pom version)
- bump pom version on the branch to next available SNAPSHOT

and if there's a need to fix on older releases, one can either 1) create a
branch out of that tag 2) fix on HEAD of corresponding release branch. (I,
personally, like the second approach better)


Khosrow Moossavi

Cloud Infrastructure Developer

t 514.447.3456





On Fri, Dec 1, 2017 at 5:05 AM, Daan Hoogland 
wrote:

> also I think we can tolerate collective work on our repo. Not everything
> has to go on forks.
>
> On Fri, Dec 1, 2017 at 11:04 AM, Daan Hoogland 
> wrote:
>
> > Rafael, I don't think that works. the versions in the pom.xml files are
> > updated to non snapshot versions on per release mini branches. I like the
> > principle but be carefull not to remove the GA branches.
> >
> > On Fri, Dec 1, 2017 at 10:41 AM, Rafael Weingärtner <
> > rafaelweingart...@gmail.com> wrote:
> >
> >> Thanks for the initiative and the hard worki Khosrow!
> >>
> >> In my opinion, we should only maintain the master and major release
> >> branches. Then, for minor versions, we can keep track of them using
> tags.
> >> There is no need to have things such as GA-4.4.1, GA-4.4.2, and so
> forth.
> >> Instead, we should keep only the branch 4.4, and the minor versions are
> >> built on top of that branch (the branch would always have the top minor
> >> version of the major version). The versioning is done using tags, and
> not
> >> branches. Moreover, people should not use the official apache repository
> >> to
> >> store working branches. Working branches should be kept at the
> developer’s
> >> personal repository on Github.
> >>
> >> To the initial list, I would also remove things such as GA-4.4.1,
> >> GA-4.4.2,
> >> and so on. As I said, we only need on branch per major release. The
> >> versioning is executed through tags, and fixes on past releases should
> be
> >> done in the branch of the release. Also, there are things like
> >> “add_XS_71_72”, “cloudearlyinit”, “new-location”, and
> >> “debian9-systemvmtemplate”; none of them should be there. They are
> working
> >> branch from contributors/committers. These branches can be at their own
> >> personal forks.
> >>
> >> On Fri, Dec 1, 2017 at 4:16 AM, Daan Hoogland 
> >> wrote:
> >>
> >> > thanks for that list Khosrow,  Also very usefull for cleaning people
> to
> >> > clean their own fork.
> >> > I think you can start with the lowest pom versions but I changed one
> >> > because the referred ticket isn't closed. It's my own and I'll have a
> >> look
> >> > later today. For a lot of the branches the ticket aren't clear because
> >> only
> >> >  or CS- is in the titel. Only when
> >> CLOUDSTACK- >> > number> is in the titel you can see immediately that it is closed by
> the
> >> > automatic strikethrough that happens. just a heads-up.
> >> >
> >> > +1
> >> >
> >> >
> >> > On Fri, Dec 1, 2017 at 2:13 AM, Gabriel Beims Bräscher <
> >> > gabrasc...@gmail.com
> >> > > wrote:
> >> >
> >> > > Thanks for the initiative, Khosrow.
> >> > >
> >> > > +1 on removing obsolete branches.
> >> > >
> >> > > 2017-11-30 18:05 GMT-02:00 Khosrow Moossavi  >:
> >> > >
> >> > > > Hi Community
> >> > > >
> >> > > > I would like to start the discussion around deleting old and
> >> obsolete
> >> > > > branches on github repository. This will help newcomers (including
> >> > > myself)
> >> > > > to keep track of which branches are important and which are not.
> And
> >> > > since
> >> > > > almost everyone's working on their own forks there is no need to
> >> keep
> >> > > > feature/bugfix/hotfix branches around in the main official
> >> repository.
> >> > > >
> >> > > > I've created an issue which contains full list of branches in
> >> > > > GH/apache/cloudstack repo as of time of writing this email and the
> >> > > > proposition of which one of them can be deleted.
> >> > > >
> >> > > > 

Re: [PROPOSE] RM for 4.11

[Rohit Yadav]

Thanks everyone for your support (and statues :) ).


I look forward to working with everyone for the next best CloudStack release.


Regards.


From: Simon Weller 
Sent: Friday, December 1, 2017 1:12:21 AM
To: dev@cloudstack.apache.org
Subject: Re: [PROPOSE] RM for 4.11

Great Rohit! We'll provide as much support to you guys as we can.


From: Rohit Yadav 
Sent: Wednesday, November 29, 2017 4:14 AM
To: dev@cloudstack.apache.org
Subject: [PROPOSE] RM for 4.11

Hi All,

I’d like to put myself forward as release manager for 4.11. The 4.11
releases will be the next major version LTS release since 4.9 and will be
supported for 20 months per the LTS manifesto [2] until 1 July 2019.

Daan Hoogland and Paul Angus will assist during the process and all of us
will be the gatekeepers for reviewing/testing/merging the PRs, others will
be welcome to support as well.

As a community member, I will try to help get PRs reviewed, tested and
merged (as would everyone else I hope) but with an RM hat on I would like
to see if we can make that role less inherently life-consuming and put the
onus back on the community to get stuff done.

Here the plan:
1. As RM I put forward the freeze date of the 8th of January 2018, hoping
for community approval.
2. After the freeze date (8th Jan) until GA release, features will not be
allowed and fixes only as long as there are blocker issues outstanding.
Fixes for other issues will be individually judged on their merit and risk.
3. RM will triage/report critical and blocker bugs for 4.11 [4] and
encourage people to get them fixed.
4. RM will create RCs and start voting once blocker bugs are cleared and
baseline smoke test results are on par with previous 4.9.3.0/4.10.0.0 smoke
test results.
5. RM will allocate at least a week for branch stabilization and testing.
At the earliest, on 15th January, RM will put 4.11.0.0-rc1 for voting from
the 4.11 branch, and master will be open to accepting new features.
6. RM will repeat 3-5 as required. Voting/testing of -rc2, -rc3 and so on
will be created as required.
7. Once vote passes - RM will continue with the release procedures [1].

In conjunction with that, I also propose and put forward the date of 4.12
cut-off as 4 months [3] after GA release of 4.11 (so everyone knows when
the next one is coming hopefully giving peace of mind to those who have
features which would not make the proposed 4.11 cut off).

I’d like the community (including myself and colleagues) to:
- Up to 8th January, community members try to review, test and merge as
many fixes as possible, while super-diligent to not de-stabilize the master
branch.
- Engage with gatekeepers to get your PRs reviewed, tested and merged
(currently myself, Daan and Paul, others are welcome to engage as well). Do
not merge the PRs
- A pull request may be reverted where the author(s) are not responding and
authors may be asked to re-submit their changes after taking suitable
remedies.
- Find automated method to show (at a glance) statuses of PRs with respect
to:
  · Number of LGTMs
  · Smoke tests
  · Functional tests
  · Travis tests passing
  · Mergeability
- Perform a weekly run of a component-test matrix against the master branch
before Jan 8th cut off (based on current hypervisors including basic (KVM)
and advanced networking).
- Continue to fix broken tests.

Thoughts, feedback, comments?

[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure
Release Procedure - Apache Cloudstack - Apache Software 
...
cwiki.apache.org
This page describes the steps that a release manager needs to take to perform a 
release of Apache CloudStack. (Thanks to the couchdb project for a great 
template to ...



[2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
LTS - Apache Cloudstack - Apache Software 
Foundation
cwiki.apache.org
The project plans to produce the following types of releases: Regular: 
Introduce new features and enhancements. These releases are targeted for users 
who require the ...



[3] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases
Releases - Apache Cloudstack - Apache Software 
Foundation
cwiki.apache.org
Overview. All available releases can be found on the Apache CloudStack 
project's website, on the Downloads page. The release-specific child pages in 
this wiki are not ...



[4] The current list of blocker and critical bugs currently stands as per
the following list:

Re: Clean up old and obsolete branches

[Daan Hoogland]

also I think we can tolerate collective work on our repo. Not everything
has to go on forks.

On Fri, Dec 1, 2017 at 11:04 AM, Daan Hoogland 
wrote:

> Rafael, I don't think that works. the versions in the pom.xml files are
> updated to non snapshot versions on per release mini branches. I like the
> principle but be carefull not to remove the GA branches.
>
> On Fri, Dec 1, 2017 at 10:41 AM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
>> Thanks for the initiative and the hard worki Khosrow!
>>
>> In my opinion, we should only maintain the master and major release
>> branches. Then, for minor versions, we can keep track of them using tags.
>> There is no need to have things such as GA-4.4.1, GA-4.4.2, and so forth.
>> Instead, we should keep only the branch 4.4, and the minor versions are
>> built on top of that branch (the branch would always have the top minor
>> version of the major version). The versioning is done using tags, and not
>> branches. Moreover, people should not use the official apache repository
>> to
>> store working branches. Working branches should be kept at the developer’s
>> personal repository on Github.
>>
>> To the initial list, I would also remove things such as GA-4.4.1,
>> GA-4.4.2,
>> and so on. As I said, we only need on branch per major release. The
>> versioning is executed through tags, and fixes on past releases should be
>> done in the branch of the release. Also, there are things like
>> “add_XS_71_72”, “cloudearlyinit”, “new-location”, and
>> “debian9-systemvmtemplate”; none of them should be there. They are working
>> branch from contributors/committers. These branches can be at their own
>> personal forks.
>>
>> On Fri, Dec 1, 2017 at 4:16 AM, Daan Hoogland 
>> wrote:
>>
>> > thanks for that list Khosrow,  Also very usefull for cleaning people to
>> > clean their own fork.
>> > I think you can start with the lowest pom versions but I changed one
>> > because the referred ticket isn't closed. It's my own and I'll have a
>> look
>> > later today. For a lot of the branches the ticket aren't clear because
>> only
>> >  or CS- is in the titel. Only when
>> CLOUDSTACK-> > number> is in the titel you can see immediately that it is closed by the
>> > automatic strikethrough that happens. just a heads-up.
>> >
>> > +1
>> >
>> >
>> > On Fri, Dec 1, 2017 at 2:13 AM, Gabriel Beims Bräscher <
>> > gabrasc...@gmail.com
>> > > wrote:
>> >
>> > > Thanks for the initiative, Khosrow.
>> > >
>> > > +1 on removing obsolete branches.
>> > >
>> > > 2017-11-30 18:05 GMT-02:00 Khosrow Moossavi :
>> > >
>> > > > Hi Community
>> > > >
>> > > > I would like to start the discussion around deleting old and
>> obsolete
>> > > > branches on github repository. This will help newcomers (including
>> > > myself)
>> > > > to keep track of which branches are important and which are not. And
>> > > since
>> > > > almost everyone's working on their own forks there is no need to
>> keep
>> > > > feature/bugfix/hotfix branches around in the main official
>> repository.
>> > > >
>> > > > I've created an issue which contains full list of branches in
>> > > > GH/apache/cloudstack repo as of time of writing this email and the
>> > > > proposition of which one of them can be deleted.
>> > > >
>> > > > https://issues.apache.org/jira/browse/CLOUDSTACK-10169
>> > > >
>> > > > I would appreciate your questions, comments, suggestions.
>> > > >
>> > > > Thanks
>> > > >
>> > > > Khosrow Moossavi
>> > > >
>> > > > Cloud Infrastructure Developer
>> > > >
>> > > > CloudOps
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > Daan
>> >
>>
>>
>>
>> --
>> Rafael Weingärtner
>>
>
>
>
> --
> Daan
>



-- 
Daan

Re: Clean up old and obsolete branches

[Daan Hoogland]

Rafael, I don't think that works. the versions in the pom.xml files are
updated to non snapshot versions on per release mini branches. I like the
principle but be carefull not to remove the GA branches.

On Fri, Dec 1, 2017 at 10:41 AM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> Thanks for the initiative and the hard worki Khosrow!
>
> In my opinion, we should only maintain the master and major release
> branches. Then, for minor versions, we can keep track of them using tags.
> There is no need to have things such as GA-4.4.1, GA-4.4.2, and so forth.
> Instead, we should keep only the branch 4.4, and the minor versions are
> built on top of that branch (the branch would always have the top minor
> version of the major version). The versioning is done using tags, and not
> branches. Moreover, people should not use the official apache repository to
> store working branches. Working branches should be kept at the developer’s
> personal repository on Github.
>
> To the initial list, I would also remove things such as GA-4.4.1, GA-4.4.2,
> and so on. As I said, we only need on branch per major release. The
> versioning is executed through tags, and fixes on past releases should be
> done in the branch of the release. Also, there are things like
> “add_XS_71_72”, “cloudearlyinit”, “new-location”, and
> “debian9-systemvmtemplate”; none of them should be there. They are working
> branch from contributors/committers. These branches can be at their own
> personal forks.
>
> On Fri, Dec 1, 2017 at 4:16 AM, Daan Hoogland 
> wrote:
>
> > thanks for that list Khosrow,  Also very usefull for cleaning people to
> > clean their own fork.
> > I think you can start with the lowest pom versions but I changed one
> > because the referred ticket isn't closed. It's my own and I'll have a
> look
> > later today. For a lot of the branches the ticket aren't clear because
> only
> >  or CS- is in the titel. Only when
> CLOUDSTACK- > number> is in the titel you can see immediately that it is closed by the
> > automatic strikethrough that happens. just a heads-up.
> >
> > +1
> >
> >
> > On Fri, Dec 1, 2017 at 2:13 AM, Gabriel Beims Bräscher <
> > gabrasc...@gmail.com
> > > wrote:
> >
> > > Thanks for the initiative, Khosrow.
> > >
> > > +1 on removing obsolete branches.
> > >
> > > 2017-11-30 18:05 GMT-02:00 Khosrow Moossavi :
> > >
> > > > Hi Community
> > > >
> > > > I would like to start the discussion around deleting old and obsolete
> > > > branches on github repository. This will help newcomers (including
> > > myself)
> > > > to keep track of which branches are important and which are not. And
> > > since
> > > > almost everyone's working on their own forks there is no need to keep
> > > > feature/bugfix/hotfix branches around in the main official
> repository.
> > > >
> > > > I've created an issue which contains full list of branches in
> > > > GH/apache/cloudstack repo as of time of writing this email and the
> > > > proposition of which one of them can be deleted.
> > > >
> > > > https://issues.apache.org/jira/browse/CLOUDSTACK-10169
> > > >
> > > > I would appreciate your questions, comments, suggestions.
> > > >
> > > > Thanks
> > > >
> > > > Khosrow Moossavi
> > > >
> > > > Cloud Infrastructure Developer
> > > >
> > > > CloudOps
> > > >
> > >
> >
> >
> >
> > --
> > Daan
> >
>
>
>
> --
> Rafael Weingärtner
>



-- 
Daan

Re: Clean up old and obsolete branches

[Rafael Weingärtner]

Thanks for the initiative and the hard worki Khosrow!

In my opinion, we should only maintain the master and major release
branches. Then, for minor versions, we can keep track of them using tags.
There is no need to have things such as GA-4.4.1, GA-4.4.2, and so forth.
Instead, we should keep only the branch 4.4, and the minor versions are
built on top of that branch (the branch would always have the top minor
version of the major version). The versioning is done using tags, and not
branches. Moreover, people should not use the official apache repository to
store working branches. Working branches should be kept at the developer’s
personal repository on Github.

To the initial list, I would also remove things such as GA-4.4.1, GA-4.4.2,
and so on. As I said, we only need on branch per major release. The
versioning is executed through tags, and fixes on past releases should be
done in the branch of the release. Also, there are things like
“add_XS_71_72”, “cloudearlyinit”, “new-location”, and
“debian9-systemvmtemplate”; none of them should be there. They are working
branch from contributors/committers. These branches can be at their own
personal forks.

On Fri, Dec 1, 2017 at 4:16 AM, Daan Hoogland 
wrote:

> thanks for that list Khosrow,  Also very usefull for cleaning people to
> clean their own fork.
> I think you can start with the lowest pom versions but I changed one
> because the referred ticket isn't closed. It's my own and I'll have a look
> later today. For a lot of the branches the ticket aren't clear because only
>  or CS- is in the titel. Only when CLOUDSTACK- number> is in the titel you can see immediately that it is closed by the
> automatic strikethrough that happens. just a heads-up.
>
> +1
>
>
> On Fri, Dec 1, 2017 at 2:13 AM, Gabriel Beims Bräscher <
> gabrasc...@gmail.com
> > wrote:
>
> > Thanks for the initiative, Khosrow.
> >
> > +1 on removing obsolete branches.
> >
> > 2017-11-30 18:05 GMT-02:00 Khosrow Moossavi :
> >
> > > Hi Community
> > >
> > > I would like to start the discussion around deleting old and obsolete
> > > branches on github repository. This will help newcomers (including
> > myself)
> > > to keep track of which branches are important and which are not. And
> > since
> > > almost everyone's working on their own forks there is no need to keep
> > > feature/bugfix/hotfix branches around in the main official repository.
> > >
> > > I've created an issue which contains full list of branches in
> > > GH/apache/cloudstack repo as of time of writing this email and the
> > > proposition of which one of them can be deleted.
> > >
> > > https://issues.apache.org/jira/browse/CLOUDSTACK-10169
> > >
> > > I would appreciate your questions, comments, suggestions.
> > >
> > > Thanks
> > >
> > > Khosrow Moossavi
> > >
> > > Cloud Infrastructure Developer
> > >
> > > CloudOps
> > >
> >
>
>
>
> --
> Daan
>



-- 
Rafael Weingärtner

Re: Issue with Opensaml and Self-Signed Certificates

[Harika Punna]

Rohit,

I have debugged already and found that the password for keystore is null, 
though I have provided the password in properties file, which is the cause for 
the issue.

I will try with any publicly available SAML providers.


Thanks,
Harika.




On 30/11/17, 3:17 PM, "Rohit Yadav"  wrote:

Harika,


I'm planning to run some tests by end of next week, I'll keep you posted.

Meanwhile, try to debug the issue, attach a debugger and see what is 
causing the failure and use one of the publicly available SAML idp providers, 
the issue could also be related to your SAML sp/idp configuration.


Regards.


From: Harika Punna 
Sent: Thursday, November 30, 2017 11:03:05 AM
To: Rohit Yadav; dev@cloudstack.apache.org
Subject: Re: Issue with Opensaml and Self-Signed Certificates


Rohit,



I have tried the same thing on latest master, even on that I could the same 
dependencies.



Are you using opensaml of version 2.6.4? Have you faced this issue when 
working with self-signed certificates.



I would appreciate any help on this.







Thanks,

Harika.



From: Rohit Yadav 
Date: Wednesday, 29 November 2017 at 1:09 PM
To: "dev@cloudstack.apache.org" , Harika Punna 

Subject: Re: Issue with Opensaml and Self-Signed Certificates



Harika, Can you test the latest master and see if you can reproduce the 
error?

Get Outlook for Android



rohit.ya...@shapeblue.com
www.shapeblue.com
@shapeblue






From: Harika Punna 
Sent: Wednesday, November 29, 2017 10:57:53 AM
To: Rohit Yadav; dev@cloudstack.apache.org
Subject: Re: Issue with Opensaml and Self-Signed Certificates



Rohit,



I was trying to configure ACS with ADFS using saml plugin.



I find the not-yet-commons-ssl.jar in the opensaml-2.6.4 dependency of 
plugins/user-authentication/saml2/pom.xml



The dependency tree of not-yet-commons-ssl is as follows-

opensaml-2.6.4 > openws-1.5.4 > xmltooling-1.4.4 > not-yet-commons-ssl-0.3.9



May I know which version of opensaml are you using?





Thanks,

Harika.





From: Rohit Yadav 
Date: Tuesday, 28 November 2017 at 6:56 PM
To: Harika Punna , "dev@cloudstack.apache.org" 

Subject: Re: Issue with Opensaml and Self-Signed Certificates



Harika,



Can you share what exactly are you doing, perhaps you can submit a PR and 
ask for review?

I did not find any usage of a KeyStoreBuilder class in current master, nor 
we've a not-yet-commons-ssl dependency in current codebase.



Regard.

rohit.ya...@shapeblue.com
www.shapeblue.com
@shapeblue






From: Harika Punna 
Sent: Tuesday, November 28, 2017 2:13:33 PM
To: dev@cloudstack.apache.org; Rohit Yadav
Subject: Re: Issue with Opensaml and Self-Signed Certificates



Hi Rohit,

Could you please help me on this?

-Harika.



On 27/11/17, 4:26 PM, "Harika Punna"  wrote:

Hi,


When I use Opensaml on 4.10 with the self-signed certificates I get the 
following error, though the configuration for the opensaml and ssl is proper. 
It works fine if I debug and supply the password of the keystore in 
KeyStoreBuilder class, which is in not-yet-commons-ssl.jar.


Has anyone faced this issue, I tried with different versions of 
opensaml but nothing worked. Found similar issue on SO at [1], but none of them 
helped.



java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.

at sun.security.util.DerInputStream.getLength(DerInputStream.java:561)

at sun.security.util.DerValue.init(DerValue.java:365)

at sun.security.util.DerValue.(DerValue.java:320)

at 
sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:1914)

at java.security.KeyStore.load(KeyStore.java:1445)

at 
org.apache.commons.ssl.KeyStoreBuilder.tryJKS(KeyStoreBuilder.java:450)

at 
org.apache.commons.ssl.KeyStoreBuilder.parse(KeyStoreBuilder.java:416)

at org.apache.commons.ssl.TrustMaterial.(TrustMaterial.java:207)