RE: New committer: Gabriel Beims Bräscher

[Paul Angus]

Well done Gabriel.



Kind regards,

Paul Angus

paul.an...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-Original Message-
From: Simon Weller [mailto:swel...@ena.com.INVALID] 
Sent: 16 November 2017 23:28
To: dev@cloudstack.apache.org
Subject: Re: New committer: Gabriel Beims Bräscher

Congrats Gabriel, much deserved!



From: Wei ZHOU 
Sent: Thursday, November 16, 2017 2:16 AM
To: dev@cloudstack.apache.org
Subject: Re: New committer: Gabriel Beims Bräscher

Congratulations Gabriel!

-Wei

2017-11-15 11:32 GMT+01:00 Rafael Weingärtner :

> The Project Management Committee (PMC) for Apache CloudStack has 
> invited Gabriel Beims Bräscher to become committer and we are pleased 
> to announce that he has accepted.
>
> Gabriel has shown commitment to Apache CloudStack community, 
> contributing with PRs in a constant fashion. Moreover, he has also 
> proved great abilities to interact with the community quite often in 
> our mailing lists and Slack channel trying to help people.
>
> Let´s congratulate and welcome Apache CloudStack's newest committer.
>
> --
> Rafael Weingärtner
>

Re: egress fw problems in 4.10?

[Jayapal Uradi]

Hi Nux,

I think the the ipset for destination cidr is not configured with 0.0.0.0/0 due 
this you might see this issue. 
Please check the ipset and iptables rules once.

iptables -L -nv
ipset -L 

Thanks,
Jayapal


> On Nov 17, 2017, a t 6:55 AM, Nux!  wrote:
> 
> Hi,
> 
> Just installed 4.10 today for a demo, but seems there are some problems with 
> the egress rules in isolated networks.
> Is there anything wrong with this rule? ACS allows me to add it, but no 
> outbound traffic is allowed at all.
> 
> 10.1.1.0/24   0.0.0.0/0   All All All 
> 
> http://img.nux.ro/gL3-Selection_002.png
> 
> If I replace 0.0.0.0/0 with a certain IP/32, then traffic works.
> 
> 
> Also, if I don't mention a destination cidr at all, outbound traffic also 
> works, but the docs state 0.0.0.0/0 should be honoured as valid destination 
> cidr.
> 
> Any ideas? I know there was recent work done on egress recently, maybe 
> related to that?
> 
> Lucian
> 
> --
> 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.

CloudStack-UI 1.49.14 released on November, 14, 2017

[Ivan Kudryavtsev]

Hello, community members, this is release announce for CloudStack-UI -
alternative UI for Apache CloudStack.

If you don't see a properly marked document and would like to see the same
press release with images, follow the link:

https://github.com/bwsw/cloudstack-ui/wiki/1.49.14-ReleaseNotes-En
https://github.com/bwsw/cloudstack-ui/wiki/1.49.14-ReleaseNotes-Ru

Release 1.49.14 Overview

On November 16, 2017, we released CloudStack-UI version 1.49.14. This
release contains significant functional changes, as well as some fixes and
improvements. A detailed description of improvements and new functionality
included in release is provided below.
List/Box
view switch

An important introduction in this release is the possibility to change data
representation between the "card" and "table" view. Each section contains a
switch and this improvement gives a user an opportunity to work with data
in each specific section in a more convenient way.

Account
creation for domain administrators

This is an extension of the functionality introduced in Release 1.49.13
 (account
management). Now, in addition to working with existing accounts, domain
administrators have a possibility to create new ones.

Adding
multiple shared security groups to VM

Now users can assign multiple shared security groups to virtual machine
during its creation, which is also an extension of the functionality
presented in the previous release
 (working
with shared security groups).

NGRX
library

Another important change in this release is the decision to use NGRX
 library (store, effects, router). Using this
library allows applying Redux approach when developing the application. The
transition to using NGRX will take
 several iterations.
Deployment
Instructions

The release can be found at GitHub releases:
https://github.com/bwsw/cloudstack-ui/releases/tag/1.49.14

Prepared Docker image is available at Dockerhub:
https://hub.docker.com/r/bwsw/cloudstack-ui/

You can pull it with:

# docker pull bwsw/cloudstack-ui:1.49.14

The project changelog is here:
https://github.com/bwsw/cloudstack-ui/wiki/Changelog

Deployment guide and project info can be found at GitHub pages:
https://bwsw.github.io/cloudstack-ui/
Release
1.410.15 expectations

The release is expected to include new functionality as follows:

   - Switching the development environment to CloudStack 4.10.0. The
   following releases will have 1.410.X enumeration and will be tested for
   compatibility only with the latest version of Apache CloudStack 4.10.X;
   - Managing users for domain administrators - an extension of the
   functionality for account management. Administrators will be able to manage
   users inside accounts;
   - API log copying when error occurs during VM creation, with which users
   can contact technical support;
   - Grouping in security groups view mode;
   - A possibility to specify an agreement for the use of VM installation
   sources (template/ISO) in VM creation.

Community
Message

Dear community member, we will be thankful if you

   - try the project and provide us with a feedback;
   - share the information about the project and the release in social
   media;
   - mark the GitHub repository  with
   star to support the project;
   - join LinkedIn group .


-- 
With best regards, Ivan Kudryavtsev
Bitworks Software, Ltd.
Cell: +7-923-414-1515
WWW: http://bitworks.software/ 

egress fw problems in 4.10?

[Nux!]

Hi,

Just installed 4.10 today for a demo, but seems there are some problems with 
the egress rules in isolated networks.
Is there anything wrong with this rule? ACS allows me to add it, but no 
outbound traffic is allowed at all.

10.1.1.0/24 0.0.0.0/0   All All All 

http://img.nux.ro/gL3-Selection_002.png

If I replace 0.0.0.0/0 with a certain IP/32, then traffic works.


Also, if I don't mention a destination cidr at all, outbound traffic also 
works, but the docs state 0.0.0.0/0 should be honoured as valid destination 
cidr.

Any ideas? I know there was recent work done on egress recently, maybe related 
to that?

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: New committer: Gabriel Beims Bräscher

[Simon Weller]

Congrats Gabriel, much deserved!



From: Wei ZHOU 
Sent: Thursday, November 16, 2017 2:16 AM
To: dev@cloudstack.apache.org
Subject: Re: New committer: Gabriel Beims Bräscher

Congratulations Gabriel!

-Wei

2017-11-15 11:32 GMT+01:00 Rafael Weingärtner :

> The Project Management Committee (PMC) for Apache CloudStack has invited
> Gabriel Beims Bräscher to become committer and we are pleased to announce
> that he has accepted.
>
> Gabriel has shown commitment to Apache CloudStack community, contributing
> with PRs in a constant fashion. Moreover, he has also proved great
> abilities to interact with the community quite often in our mailing lists
> and Slack channel trying to help people.
>
> Let´s congratulate and welcome Apache CloudStack’s newest committer.
>
> --
> Rafael Weingärtner
>

[FS] Request for comments: Secure VM Live Migration for KVM

[Rohit Yadav]

All,


Kindly review and share your thoughts and comments for a new feature - Secure 
VM live migration for KVM, this feature builds on top of the previous feature 
that brought in a new CA framework [1] for CloudStack.


Here is a rough first draft for your review:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+KVM+VM+Live+Migration


[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Agent+Communications


Regards.

rohit.ya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

Re: POLL: ACL default egress policy rule in VPC

[Nux!]

4. I think Jayapal's reply deserves more attention.

See below.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Jayapal Uradi" 
> To: "dev" 
> Sent: Tuesday, 14 November, 2017 05:12:52
> Subject: Re: POLL: ACL default egress policy rule in VPC

> Hi Rene,
> 
> Please look at my inline comments.
> Let me add some context for the VPC egress/ingress rules behavior.
> 
> Pre 4.5 (subject to correction) the behavior of VPC acl is as follows.
> 
> 1. Default egress is ALLOW and ingress is DROP.
>   a.  When a rule is added to egress then that particular rule traffic is 
> allowed
>   and rest is blocked in egress.
>   b.  When a rule is added to ingress then that particular rule traffic is 
> allowed
>   and rest is blocked in egress.
> 
> After 4.5 ACL lists and ACL items feature is introduced there we have ‘default
> allow’ and ‘default deny’ ACLs. User can also
> create a custom acl. In ACL feature we can add mix of allow and deny rules and
> the ordering of rules is maintained.
> 
> 1.  when ‘default allow’ is selected while creating the vpc tier
>By default traffic is ALLOWED and rules can be added to ALLOW/DENY the 
> traffic
>   After adding the rules there will be ACCEPT at the end
> 2.  when ‘default deny’ is selected while creating the vpc tier
>By default traffic is DENY and rules can be added to DENY/ALLOW the 
> traffic.
>  After adding the rules there will be DROP at the end
> 3. If no ACL selected for the ACL then Pre 4.5 behavior will be there.
> 4. With custom acl default ingress is DROP and egress is ALLOW. User can add
> rules for allow/deny rules.
> 
> If you see behavior other than above then there will be bug.
> 
> Currently in VPC egress behavior is controlled from the ACLs. If include
> ‘egressdefaultpolicy’ then there will be confusion.
> 
> What I feel is that current VPC ACLs are flexible enough  to configure the
> required behavior.
> 
> Thanks,
> Jayapal
> 
> 
> 
> 
> 
>> On Nov 13, 2017, at 11:17 PM, Rene Moser  wrote:
>> 
>> Hi Devs
>> 
>> The last days I fought with the ACL egress rule behaviour and I would
>> like to make a poll in which direction the fix should go.
>> 
>> Short Version:
>> 
>> We need to define a better default behaviour for acl default egress
>> rule. I see 3 different options:
>> 
>> 1. always add a default deny all egress rule.
>> 
>> This would be super easy to do (should probably also the intermediate
>> fix for 4.9, see https://github.com/apache/cloudstack/pull/2323)
>> 
>> 
>> 2. add a deny all egress rule in case if have at least one egress allow
>> rule.
>> 
>> A bit intransparent to the user, but doable. This seems to be the
>> behaviour how it was designed and should have been implemented.
>> 
> Currently we can configure the ACLs to get this behavior.
>> 
>> 3. use the default setting in the network offering "egressdefaultpolicy"
>> to specify the default behavior.
>> 
>> There is already a setting which specifies this behaviour but is not
>> used in VPC. Why not use it?
>> 
>> As a consequence when using this setting, the user should get more infos
>> about the policy of the network offering while choosing it for the tier.
>> 
>> 
>> Poll:
>> 
>> 1. []
>> 2. []
>> 3. []
>> 4. [] Other? What?
>> 
>> 
>> Long Version:
>> 
>> First, let's have a look of the issue:
>> 
>> In version 4.5, creating a new acl with no egress (ACL_OUTBOUND) rule
>> would result in a "accept egress all":
>> 
>> -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state
>> NEW -j ACL_OUTBOUND_eth2
>> -A ACL_OUTBOUND_eth2 -j ACCEPT
>> 
>> When an egress (here deny 25 egress) rule (no mather if deny or allow)
>> gets added the result is a "deny all" appended:
>> 
>> -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state
>> NEW -j ACL_OUTBOUND_eth2
>> -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 25 -j DROP
>> -A ACL_OUTBOUND_eth2 -j DROP
> This is seen because default egress is drop and user added rule to deny port 
> 25
> traffic.
> User has choice of adding allow/deny rules with priority number.
>> 
>> This does not make any sense and is a bug IMHO.
>> 
>> 
>> In 4.9 the behaviour is different:
>> 
>> (note there is a bug in the ordering of egress rules which is fixed by
>> https://github.com/apache/cloudstack/pull/2313)
>> 
>> The default policy is kept accept egress all.
>> 
>> -A PREROUTING -s 10.11.1.0/24 ! -d 10.11.1.1/32 -i eth2 -m state --state
>> NEW -j ACL_OUTBOUND_eth2
>> -A ACL_OUTBOUND_eth2 -d 224.0.0.18/32 -j ACCEPT
>> -A ACL_OUTBOUND_eth2 -d 225.0.0.50/32 -j ACCEPT
>> -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 80 -j ACCEPT
> 
> In 4.9 it is a bug. After accept rules there supposed to DROP all at the end.
>> 
>> 
>> To me it looks like the wanted behavior was "egress all as default. If
>> we have allow rules, append deny all". This would make sense but is
>> quite instransparent.
>> 

Re: New committer: Gabriel Beims Bräscher

[Wei ZHOU]

Congratulations Gabriel!

-Wei

2017-11-15 11:32 GMT+01:00 Rafael Weingärtner :

> The Project Management Committee (PMC) for Apache CloudStack has invited
> Gabriel Beims Bräscher to become committer and we are pleased to announce
> that he has accepted.
>
> Gabriel has shown commitment to Apache CloudStack community, contributing
> with PRs in a constant fashion. Moreover, he has also proved great
> abilities to interact with the community quite often in our mailing lists
> and Slack channel trying to help people.
>
> Let´s congratulate and welcome Apache CloudStack’s newest committer.
>
> --
> Rafael Weingärtner
>