Re: [DISCUSS] Blocking the creation of new Basic Networking zones

[Wido den Hollander]

On 06/20/2018 08:42 PM, ilya musayev wrote:
> I think the simplicity of Basic Zone was - you can get away with 1 VLAN
> for everything (great for POC setup) where as Advanced Shared with VLAN
> isolation requires several VLANs to get going.
> 

Does it? I have Advanced Networking running with just vlan://untagged as
a broadcast domain.

Using VLAN 0 would be exactly the same since that's the default VLAN.

> How would we cover this use case?
> 

By using 'untagged' as the VLAN number, don't we?

Wido

> On Wed, Jun 20, 2018 at 11:34 AM Tutkowski, Mike
> mailto:mike.tutkow...@netapp.com>> wrote:
> 
> Also, yes, I agree with the list you provided, Wido. We might have
> to break “other fancy stuff” into more detail, though. ;)
> 
> On 6/20/18, 12:32 PM, "Tutkowski, Mike"  > wrote:
> 
>     Sorry, Wido :) I missed that part.
> 
>     On 6/20/18, 5:03 AM, "Wido den Hollander"  > wrote:
> 
> 
> 
>         On 06/20/2018 12:31 AM, Tutkowski, Mike wrote:
>         > If this initiative goes through, perhaps that’s a good
> time to bump CloudStack’s release number to 5.0.0?
>         >
> 
>         That's what I said in my e-mail :-) But yes, I agree with
> you, this
>         might be a good time to bump it to 5.0
> 
>         With that we would:
> 
>         - Drop creation of new Basic Networking Zones
>         - Support IPv6 in shared IPv6 networks
>         - Java 9?
>         - Drop support for Ubuntu 12.04
>         - Other fancy stuff?
>         - Support ConfigDrive in all scenarios properly
> 
>         How would that sound?
> 
>         Wido
> 
>         >> On Jun 19, 2018, at 3:17 PM, Wido den Hollander
> mailto:w...@widodh.nl>> wrote:
>         >>
>         >>
>         >>
>         >>> On 06/19/2018 11:07 PM, Daan Hoogland wrote:
>         >>> I like this initiative, and here comes the big but even
> though I myself
>         >>> might think it is not valid; Basic zones are there to
> give a simple start
>         >>> for new users. If we can give a one-knob start/one page
> wizard for creating
>         >>> a shared network in advanced zone with security groups
> and userdata, great.
>         >>
>         >> That would be a UI thing, but it would be a matter of
> using VLAN
>         >> isolation and giving in VLAN 0 or 'untagged', because
> that's basically
>         >> what Basic Networking does.
>         >>
>         >> It plugs the VM on top of usually cloudbr0 (KVM).
>         >>
>         >> If you use vlan://untagged for the broadcast_uri in
> Advanced Networking
>         >> you get exactly the same result.
>         >>
>         >>> And I really fancy this idea. let's make ACS more simple
> by throwing at as
>         >>> much code as we can in a gradual and controlled way :+1:
>         >>
>         >> I would love to. But I'm a real novice when it comes to
> the UI though.
>         >> So that would be something I wouldn't be good at doing.
>         >>
>         >> Blocking Basic Networking creation is a few if-statements
> at the right
>         >> location and you're done.
>         >>
>         >> Wido
>         >>
>         >>>
>          On Tue, Jun 19, 2018 at 10:57 PM, Wido den Hollander
> mailto:w...@widodh.nl>> wrote:
>         
>          Hi,
>         
>          We (PCextreme) are a big-time user of Basic Networking
> and recently
>          started to look into Advanced Networking with VLAN
> isolation and a
>          shared network.
>         
>          This provides (from what we can see) all the features
> Basic Networking
>          provides, like the VR just doing DHCP and UserData
> while the Hypervisor
>          does the Security Grouping.
>         
>          That made me wonder why we still have Basic Networking.
>         
>          Dropping all the code would be a big problem for users
> as you can't
>          simply migrate from Basic to Advanced. In theory we
> found out that it's
>          possible by changing the database, but I wouldn't
> guarantee it works in
>          every use-case. So doing this automatically during a
> upgrade would be
>          difficult.
>         
>          To prevent us from having to maintain the Basic
> Networking code for ever
>          I would like to propose and discuss the matter of
> preventing the
>          creation of new Basic Networking zones.
>         
>          In the future this can get us rid of a lot of if-else
> statements in the
>         

Open Summit CFP anyone ?

[Andrija Panic]

Hi all,

Just wondering if anyone submitted CFP here:

https://events.linuxfoundation.org/events/open-source-summit-europe-2018/program/cfp/

Sounds like an interesting place to present the products (ACS) - if anyone
interested, I'm happy to share the work(load) and present jointly, or
similar...

Deadline for CFP is 1st July...

Anyone?

Cheers,
Andrija

RE: [VOTE] Apache CloudStack 4.11.1.0 LTS [RC2]

[Paul Angus]

Hi All,
Sorry for the radio silence, I've been juggling the $dayjob and triaging bugs 
and liasing with the fixers.

I'm going to throw in a -1 due to the following issues found:

Gateway IP not being reapplied when non-redundant VPC is restarted (PR 2712)
hosts can go into Maintenance despite VMs running on it (PR2493)
move user api fails due to api key constraint (PR2710)

I hope that these will be resolved in a couple of days and that I can get an 
RC3 out with a very limited set of changes.




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


-Original Message-
From: Paul Angus  
Sent: 15 June 2018 20:34
To: dev@cloudstack.apache.org; us...@cloudstack.apache.org
Subject: RE: [VOTE] Apache CloudStack 4.11.1.0 LTS [RC2]

Hi All,

We're looking really good for a pass.  I've been at Apache Roadshow and 
FOSSBackstage this week, so I want to check the results of the smoke tests that 
I've been running and then if there are no -1s by Monday morning, look to call 
a result.

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


-Original Message-
From: Gabriel Beims Bräscher 
Sent: 15 June 2018 15:41
To: dev 
Subject: Re: [VOTE] Apache CloudStack 4.11.1.0 LTS [RC2]

+1

1 KVM host (Ubuntu 16.04)
1 CloudStack management + mysql DB (Ubuntu 16.04)
1 NFS storage (Ubuntu 16.04)
1 Ceph storage (Ubuntu 16.04)

- build from source.
- upgrade from 4.11.0.0 -- NOTE: error when executing DB update; it requires to 
update the System VMs template name to systemvm-kvm-4.11.1.
- install 4.11.1.0 -- NOTE: System VM template when installing 4.11.1 is named 
as 'SystemVM Template (KVM)', unlike the desired systemvm-kvm-4.11.1 when 
upgrading, it might reproduce errors when updating to further ACS versions 
although it does not impact in the installed 4.11.1.0.
- configure basic network zone.
- deploy System VMs and user instance.

2018-06-15 11:34 GMT-03:00 Dag Sonstebo :

> + 1
>
> Tested:
> - XenServer 7.2
> - VMware vSphere 6.5
> - KVM on CentOS 7.4
> - XCP-NG 7.4.1
> - Basic user operations / VM lifecycle actions across platforms, 
> advanced zone, VPC and isolated networks, basic network operations.
>
> Regards,
> Dag Sonstebo
> Cloud Architect
> ShapeBlue
>
> On 15/06/2018, 15:27, "Wido den Hollander"  wrote:
>
> +1 (binding)
>
> Tested:
> - Upgrade from 4.11 to 4.11.1 (with new SSVM)
> - Deployment of new System VMs
> - Deployment of new Instance
>
> Wido
>
> On 06/11/2018 05:49 PM, Paul Angus wrote:
> > Hi All,
> >
> >
> >
> > I've created a 4.11.1.0 release (RC2), with the following 
> artefacts up for testing and a vote:
> >
> >
> >
> > Git Branch and Commit SH:
> >
> > https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=
> shortlog;h=refs/heads/4.11.1.0-RC20180611T1504
> >
> > Commit: bcf602c7cd4ab662a7c4f208dee32fb8513e26c8
> >
> >
> >
> > Source release (checksums and signatures are available at the same
> >
> > location):
> >
> > https://dist.apache.org/repos/dist/dev/cloudstack/4.11.1.0/
> >
> >
> >
> > PGP release keys (signed using 8B309F7251EE0BC8):
> >
> > https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> >
> >
> >
> > The vote will be open until the end of the week, 15nd June 2018.
> >
> >
> >
> > For sanity in tallying the vote, can PMC members please be sure 
> to indicate "(binding)" with their vote?
> >
> >
> >
> > [ ] +1  approve
> >
> > [ ] +0  no opinion
> >
> > [ ] -1  disapprove (and reason why)
> >
> >
> >
> > Additional information:
> >
> >
> >
> > For users' convenience, I've built packages from
> bcf602c7cd4ab662a7c4f208dee32fb8513e26c8 and published RC2 repository
> here:
> >
> > http://packages.shapeblue.com/testing/4111rc2/
> >
> >
> >
> > The release notes are still work-in-progress, but the systemvm 
> template upgrade section has been updated. You may refer the following 
> for systemvm template upgrade testing:
> >
> > http://docs.cloudstack.apache.org/projects/cloudstack-
> release-notes/en/latest/index.html
> >
> >
> >
> > 4.11.1 systemvm templates are available from here:
> > http://packages.shapeblue.com/systemvmtemplate/4.11.1-rc1/
> >
> >
> >
> >
> > Kind regards,
> >
> > Paul Angus
> >
> >
> > paul.an...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
> >
> >
> >
>
>
>
> dag.sonst...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
>
>
>
>

Re: [DISCUSS] Blocking the creation of new Basic Networking zones

[ilya musayev]

I think the simplicity of Basic Zone was - you can get away with 1 VLAN for
everything (great for POC setup) where as Advanced Shared with VLAN
isolation requires several VLANs to get going.

How would we cover this use case?

On Wed, Jun 20, 2018 at 11:34 AM Tutkowski, Mike 
wrote:

> Also, yes, I agree with the list you provided, Wido. We might have to
> break “other fancy stuff” into more detail, though. ;)
>
> On 6/20/18, 12:32 PM, "Tutkowski, Mike"  wrote:
>
> Sorry, Wido :) I missed that part.
>
> On 6/20/18, 5:03 AM, "Wido den Hollander"  wrote:
>
>
>
> On 06/20/2018 12:31 AM, Tutkowski, Mike wrote:
> > If this initiative goes through, perhaps that’s a good time to
> bump CloudStack’s release number to 5.0.0?
> >
>
> That's what I said in my e-mail :-) But yes, I agree with you, this
> might be a good time to bump it to 5.0
>
> With that we would:
>
> - Drop creation of new Basic Networking Zones
> - Support IPv6 in shared IPv6 networks
> - Java 9?
> - Drop support for Ubuntu 12.04
> - Other fancy stuff?
> - Support ConfigDrive in all scenarios properly
>
> How would that sound?
>
> Wido
>
> >> On Jun 19, 2018, at 3:17 PM, Wido den Hollander 
> wrote:
> >>
> >>
> >>
> >>> On 06/19/2018 11:07 PM, Daan Hoogland wrote:
> >>> I like this initiative, and here comes the big but even though
> I myself
> >>> might think it is not valid; Basic zones are there to give a
> simple start
> >>> for new users. If we can give a one-knob start/one page wizard
> for creating
> >>> a shared network in advanced zone with security groups and
> userdata, great.
> >>
> >> That would be a UI thing, but it would be a matter of using VLAN
> >> isolation and giving in VLAN 0 or 'untagged', because that's
> basically
> >> what Basic Networking does.
> >>
> >> It plugs the VM on top of usually cloudbr0 (KVM).
> >>
> >> If you use vlan://untagged for the broadcast_uri in Advanced
> Networking
> >> you get exactly the same result.
> >>
> >>> And I really fancy this idea. let's make ACS more simple by
> throwing at as
> >>> much code as we can in a gradual and controlled way :+1:
> >>
> >> I would love to. But I'm a real novice when it comes to the UI
> though.
> >> So that would be something I wouldn't be good at doing.
> >>
> >> Blocking Basic Networking creation is a few if-statements at
> the right
> >> location and you're done.
> >>
> >> Wido
> >>
> >>>
>  On Tue, Jun 19, 2018 at 10:57 PM, Wido den Hollander <
> w...@widodh.nl> wrote:
> 
>  Hi,
> 
>  We (PCextreme) are a big-time user of Basic Networking and
> recently
>  started to look into Advanced Networking with VLAN isolation
> and a
>  shared network.
> 
>  This provides (from what we can see) all the features Basic
> Networking
>  provides, like the VR just doing DHCP and UserData while the
> Hypervisor
>  does the Security Grouping.
> 
>  That made me wonder why we still have Basic Networking.
> 
>  Dropping all the code would be a big problem for users as you
> can't
>  simply migrate from Basic to Advanced. In theory we found out
> that it's
>  possible by changing the database, but I wouldn't guarantee
> it works in
>  every use-case. So doing this automatically during a upgrade
> would be
>  difficult.
> 
>  To prevent us from having to maintain the Basic Networking
> code for ever
>  I would like to propose and discuss the matter of preventing
> the
>  creation of new Basic Networking zones.
> 
>  In the future this can get us rid of a lot of if-else
> statements in the
>  code and it would make testing also easier as we have few
> things to test.
> 
>  Most of the development also seems to go in the Advanced
> Networking
>  direction.
> 
>  We are currently also working on IPv6 in Advanced Shared
> Networks and
>  that's progressing very good as well.
> 
>  Would this be something to call the 5.0 release where we
> simplify the
>  networking and in the UI/API get rid of Basic Networking
> while keeping
>  it alive for existing users?
> 
>  Wido
> 
> >>>
> >>>
> >>>
>
>
>
>
>

Re: [DISCUSS] Blocking the creation of new Basic Networking zones

[Tutkowski, Mike]

Also, yes, I agree with the list you provided, Wido. We might have to break 
“other fancy stuff” into more detail, though. ;)

On 6/20/18, 12:32 PM, "Tutkowski, Mike"  wrote:

Sorry, Wido :) I missed that part.

On 6/20/18, 5:03 AM, "Wido den Hollander"  wrote:



On 06/20/2018 12:31 AM, Tutkowski, Mike wrote:
> If this initiative goes through, perhaps that’s a good time to bump 
CloudStack’s release number to 5.0.0?
> 

That's what I said in my e-mail :-) But yes, I agree with you, this
might be a good time to bump it to 5.0

With that we would:

- Drop creation of new Basic Networking Zones
- Support IPv6 in shared IPv6 networks
- Java 9?
- Drop support for Ubuntu 12.04
- Other fancy stuff?
- Support ConfigDrive in all scenarios properly

How would that sound?

Wido

>> On Jun 19, 2018, at 3:17 PM, Wido den Hollander  
wrote:
>>
>>
>>
>>> On 06/19/2018 11:07 PM, Daan Hoogland wrote:
>>> I like this initiative, and here comes the big but even though I 
myself
>>> might think it is not valid; Basic zones are there to give a simple 
start
>>> for new users. If we can give a one-knob start/one page wizard for 
creating
>>> a shared network in advanced zone with security groups and 
userdata, great.
>>
>> That would be a UI thing, but it would be a matter of using VLAN
>> isolation and giving in VLAN 0 or 'untagged', because that's 
basically
>> what Basic Networking does.
>>
>> It plugs the VM on top of usually cloudbr0 (KVM).
>>
>> If you use vlan://untagged for the broadcast_uri in Advanced 
Networking
>> you get exactly the same result.
>>
>>> And I really fancy this idea. let's make ACS more simple by 
throwing at as
>>> much code as we can in a gradual and controlled way :+1:
>>
>> I would love to. But I'm a real novice when it comes to the UI 
though.
>> So that would be something I wouldn't be good at doing.
>>
>> Blocking Basic Networking creation is a few if-statements at the 
right
>> location and you're done.
>>
>> Wido
>>
>>>
 On Tue, Jun 19, 2018 at 10:57 PM, Wido den Hollander 
 wrote:

 Hi,

 We (PCextreme) are a big-time user of Basic Networking and recently
 started to look into Advanced Networking with VLAN isolation and a
 shared network.

 This provides (from what we can see) all the features Basic 
Networking
 provides, like the VR just doing DHCP and UserData while the 
Hypervisor
 does the Security Grouping.

 That made me wonder why we still have Basic Networking.

 Dropping all the code would be a big problem for users as you can't
 simply migrate from Basic to Advanced. In theory we found out that 
it's
 possible by changing the database, but I wouldn't guarantee it 
works in
 every use-case. So doing this automatically during a upgrade would 
be
 difficult.

 To prevent us from having to maintain the Basic Networking code 
for ever
 I would like to propose and discuss the matter of preventing the
 creation of new Basic Networking zones.

 In the future this can get us rid of a lot of if-else statements 
in the
 code and it would make testing also easier as we have few things 
to test.

 Most of the development also seems to go in the Advanced Networking
 direction.

 We are currently also working on IPv6 in Advanced Shared Networks 
and
 that's progressing very good as well.

 Would this be something to call the 5.0 release where we simplify 
the
 networking and in the UI/API get rid of Basic Networking while 
keeping
 it alive for existing users?

 Wido

>>>
>>>
>>>

Re: [DISCUSS] Blocking the creation of new Basic Networking zones

[Tutkowski, Mike]

Sorry, Wido :) I missed that part.

On 6/20/18, 5:03 AM, "Wido den Hollander"  wrote:



On 06/20/2018 12:31 AM, Tutkowski, Mike wrote:
> If this initiative goes through, perhaps that’s a good time to bump 
CloudStack’s release number to 5.0.0?
> 

That's what I said in my e-mail :-) But yes, I agree with you, this
might be a good time to bump it to 5.0

With that we would:

- Drop creation of new Basic Networking Zones
- Support IPv6 in shared IPv6 networks
- Java 9?
- Drop support for Ubuntu 12.04
- Other fancy stuff?
- Support ConfigDrive in all scenarios properly

How would that sound?

Wido

>> On Jun 19, 2018, at 3:17 PM, Wido den Hollander  wrote:
>>
>>
>>
>>> On 06/19/2018 11:07 PM, Daan Hoogland wrote:
>>> I like this initiative, and here comes the big but even though I myself
>>> might think it is not valid; Basic zones are there to give a simple 
start
>>> for new users. If we can give a one-knob start/one page wizard for 
creating
>>> a shared network in advanced zone with security groups and userdata, 
great.
>>
>> That would be a UI thing, but it would be a matter of using VLAN
>> isolation and giving in VLAN 0 or 'untagged', because that's basically
>> what Basic Networking does.
>>
>> It plugs the VM on top of usually cloudbr0 (KVM).
>>
>> If you use vlan://untagged for the broadcast_uri in Advanced Networking
>> you get exactly the same result.
>>
>>> And I really fancy this idea. let's make ACS more simple by throwing at 
as
>>> much code as we can in a gradual and controlled way :+1:
>>
>> I would love to. But I'm a real novice when it comes to the UI though.
>> So that would be something I wouldn't be good at doing.
>>
>> Blocking Basic Networking creation is a few if-statements at the right
>> location and you're done.
>>
>> Wido
>>
>>>
 On Tue, Jun 19, 2018 at 10:57 PM, Wido den Hollander  
wrote:

 Hi,

 We (PCextreme) are a big-time user of Basic Networking and recently
 started to look into Advanced Networking with VLAN isolation and a
 shared network.

 This provides (from what we can see) all the features Basic Networking
 provides, like the VR just doing DHCP and UserData while the Hypervisor
 does the Security Grouping.

 That made me wonder why we still have Basic Networking.

 Dropping all the code would be a big problem for users as you can't
 simply migrate from Basic to Advanced. In theory we found out that it's
 possible by changing the database, but I wouldn't guarantee it works in
 every use-case. So doing this automatically during a upgrade would be
 difficult.

 To prevent us from having to maintain the Basic Networking code for 
ever
 I would like to propose and discuss the matter of preventing the
 creation of new Basic Networking zones.

 In the future this can get us rid of a lot of if-else statements in the
 code and it would make testing also easier as we have few things to 
test.

 Most of the development also seems to go in the Advanced Networking
 direction.

 We are currently also working on IPv6 in Advanced Shared Networks and
 that's progressing very good as well.

 Would this be something to call the 5.0 release where we simplify the
 networking and in the UI/API get rid of Basic Networking while keeping
 it alive for existing users?

 Wido

>>>
>>>
>>>

Re: [DISCUSS] Blocking the creation of new Basic Networking zones

[Wido den Hollander]

I never meant for this thread to de-rail into what should be CloudStack
5.0 :-)

I haven't heard any objections against the creation of new Basic
Networking Zones being prohibited, but hey, it's been <24 hours since I
send the first mail.

Wido

On 06/20/2018 04:51 PM, Stephan Seitz wrote:
> Hi!
> 
> 
>>> With that we would:
>>>
>>> - Drop creation of new Basic Networking Zones
>>> - Support IPv6 in shared IPv6 networks
>>> - Java 9?
>>> - Drop support for Ubuntu 12.04
>>> - Other fancy stuff?
>> - Versioned API: keep v1 API (< v5.0.0)  and create a v2 API >= v5.0.0
>> where we fix all inconsistencies (ACL API generally, paging does not
>> always work, returned keys sometime camel case (crossZone), a.s.o.)
> 
> - Usable Error Messages (including a reason why things failed). Nothing fancy
> I think, following the respective Stacktrace in the Logfile, the top most 
> exception
> shows everything (in most cases), but looks like the last "generic" exception 
> is
> reported. 
> 
> 
>>>
>>> - Support ConfigDrive in all scenarios properly
> 
> 



signature.asc
Description: OpenPGP digital signature

Re: [DISCUSS] Blocking the creation of new Basic Networking zones

[Rafael Weingärtner]

- When roles do not have access to some API methods, the buttons/links that
use these API methods should disappear from the interface.

On Wed, Jun 20, 2018 at 4:51 PM, Stephan Seitz 
wrote:

> Hi!
>
>
> > > With that we would:
> > >
> > > - Drop creation of new Basic Networking Zones
> > > - Support IPv6 in shared IPv6 networks
> > > - Java 9?
> > > - Drop support for Ubuntu 12.04
> > > - Other fancy stuff?
> > - Versioned API: keep v1 API (< v5.0.0)  and create a v2 API >= v5.0.0
> > where we fix all inconsistencies (ACL API generally, paging does not
> > always work, returned keys sometime camel case (crossZone), a.s.o.)
>
> - Usable Error Messages (including a reason why things failed). Nothing
> fancy
> I think, following the respective Stacktrace in the Logfile, the top most
> exception
> shows everything (in most cases), but looks like the last "generic"
> exception is
> reported.
>
>
> > >
> > > - Support ConfigDrive in all scenarios properly
>
>
>


-- 
Rafael Weingärtner

Re: [DISCUSS] Blocking the creation of new Basic Networking zones

[Stephan Seitz]

Hi!


> > With that we would:
> > 
> > - Drop creation of new Basic Networking Zones
> > - Support IPv6 in shared IPv6 networks
> > - Java 9?
> > - Drop support for Ubuntu 12.04
> > - Other fancy stuff?
> - Versioned API: keep v1 API (< v5.0.0)  and create a v2 API >= v5.0.0
> where we fix all inconsistencies (ACL API generally, paging does not
> always work, returned keys sometime camel case (crossZone), a.s.o.)

- Usable Error Messages (including a reason why things failed). Nothing fancy
I think, following the respective Stacktrace in the Logfile, the top most 
exception
shows everything (in most cases), but looks like the last "generic" exception is
reported. 


> > 
> > - Support ConfigDrive in all scenarios properly




signature.asc
Description: This is a digitally signed message part

Re: [DISCUSS] Blocking the creation of new Basic Networking zones

[Rafael Weingärtner]

+1

On Wed, Jun 20, 2018 at 4:35 PM, Rene Moser  wrote:

>
>
> On 06/20/2018 01:03 PM, Wido den Hollander wrote:
> >
> >
> > On 06/20/2018 12:31 AM, Tutkowski, Mike wrote:
> >> If this initiative goes through, perhaps that’s a good time to bump
> CloudStack’s release number to 5.0.0?
> >>
> >
> > That's what I said in my e-mail :-) But yes, I agree with you, this
> > might be a good time to bump it to 5.0
> >
> > With that we would:
> >
> > - Drop creation of new Basic Networking Zones
> > - Support IPv6 in shared IPv6 networks
> > - Java 9?
> > - Drop support for Ubuntu 12.04
> > - Other fancy stuff?
>
> - Versioned API: keep v1 API (< v5.0.0)  and create a v2 API >= v5.0.0
> where we fix all inconsistencies (ACL API generally, paging does not
> always work, returned keys sometime camel case (crossZone), a.s.o.)
>
> > - Support ConfigDrive in all scenarios properly
>



-- 
Rafael Weingärtner

Re: [DISCUSS] Blocking the creation of new Basic Networking zones

[Rene Moser]

On 06/20/2018 01:03 PM, Wido den Hollander wrote:
> 
> 
> On 06/20/2018 12:31 AM, Tutkowski, Mike wrote:
>> If this initiative goes through, perhaps that’s a good time to bump 
>> CloudStack’s release number to 5.0.0?
>>
> 
> That's what I said in my e-mail :-) But yes, I agree with you, this
> might be a good time to bump it to 5.0
> 
> With that we would:
> 
> - Drop creation of new Basic Networking Zones
> - Support IPv6 in shared IPv6 networks
> - Java 9?
> - Drop support for Ubuntu 12.04
> - Other fancy stuff?

- Versioned API: keep v1 API (< v5.0.0)  and create a v2 API >= v5.0.0
where we fix all inconsistencies (ACL API generally, paging does not
always work, returned keys sometime camel case (crossZone), a.s.o.)

> - Support ConfigDrive in all scenarios properly

Re: Working with a 'PendingReleaseNotes' file

[Wido den Hollander]

On 06/20/2018 07:53 AM, Rafael Weingärtner wrote:
> It seems so. It can then be a part of the PR. I mean, in the PR we could
> require a commit that updates this file.

Yes, that would be the thing. When you send a PR with a change that is
'big enough' you also include updating the Pending Release Notes file.

> Of course, we need to discuss if all PRs should update it, or only
> important things should go in.
> 

I think only important things and that it's up to the developer to guess
if it's important enough to go into the PendingReleaseNotes file.

Wido

> +1
> 
> On Tue, Jun 19, 2018 at 11:00 PM, Wido den Hollander  wrote:
> 
>> Hi,
>>
>> At the Ceph project we work with a Pending Release Notes [0].
>>
>> The idea is that if a developer writes a new feature or fixes something
>> that changes functionality (or adds one) she/he also updates the
>> PendingReleaseNotes file.
>>
>> That way when a new version is released it's easier for the Release
>> Manager to know what to highlight.
>>
>> Although we can try to get everything from Jira and Github Issues it
>> might be difficult to use the proper wording.
>>
>> On every release the files is cleared and people start to add again.
>>
>> Would this be something which could benefit CloudStack and make the
>> release notes easier and more complete?
>>
>> Wido
>>
>> [0]: https://github.com/ceph/ceph/blob/master/PendingReleaseNotes
>>
> 
> 
> 

Re: [DISCUSS] Blocking the creation of new Basic Networking zones

[Wido den Hollander]

On 06/20/2018 12:31 AM, Tutkowski, Mike wrote:
> If this initiative goes through, perhaps that’s a good time to bump 
> CloudStack’s release number to 5.0.0?
> 

That's what I said in my e-mail :-) But yes, I agree with you, this
might be a good time to bump it to 5.0

With that we would:

- Drop creation of new Basic Networking Zones
- Support IPv6 in shared IPv6 networks
- Java 9?
- Drop support for Ubuntu 12.04
- Other fancy stuff?
- Support ConfigDrive in all scenarios properly

How would that sound?

Wido

>> On Jun 19, 2018, at 3:17 PM, Wido den Hollander  wrote:
>>
>>
>>
>>> On 06/19/2018 11:07 PM, Daan Hoogland wrote:
>>> I like this initiative, and here comes the big but even though I myself
>>> might think it is not valid; Basic zones are there to give a simple start
>>> for new users. If we can give a one-knob start/one page wizard for creating
>>> a shared network in advanced zone with security groups and userdata, great.
>>
>> That would be a UI thing, but it would be a matter of using VLAN
>> isolation and giving in VLAN 0 or 'untagged', because that's basically
>> what Basic Networking does.
>>
>> It plugs the VM on top of usually cloudbr0 (KVM).
>>
>> If you use vlan://untagged for the broadcast_uri in Advanced Networking
>> you get exactly the same result.
>>
>>> And I really fancy this idea. let's make ACS more simple by throwing at as
>>> much code as we can in a gradual and controlled way :+1:
>>
>> I would love to. But I'm a real novice when it comes to the UI though.
>> So that would be something I wouldn't be good at doing.
>>
>> Blocking Basic Networking creation is a few if-statements at the right
>> location and you're done.
>>
>> Wido
>>
>>>
 On Tue, Jun 19, 2018 at 10:57 PM, Wido den Hollander  
 wrote:

 Hi,

 We (PCextreme) are a big-time user of Basic Networking and recently
 started to look into Advanced Networking with VLAN isolation and a
 shared network.

 This provides (from what we can see) all the features Basic Networking
 provides, like the VR just doing DHCP and UserData while the Hypervisor
 does the Security Grouping.

 That made me wonder why we still have Basic Networking.

 Dropping all the code would be a big problem for users as you can't
 simply migrate from Basic to Advanced. In theory we found out that it's
 possible by changing the database, but I wouldn't guarantee it works in
 every use-case. So doing this automatically during a upgrade would be
 difficult.

 To prevent us from having to maintain the Basic Networking code for ever
 I would like to propose and discuss the matter of preventing the
 creation of new Basic Networking zones.

 In the future this can get us rid of a lot of if-else statements in the
 code and it would make testing also easier as we have few things to test.

 Most of the development also seems to go in the Advanced Networking
 direction.

 We are currently also working on IPv6 in Advanced Shared Networks and
 that's progressing very good as well.

 Would this be something to call the 5.0 release where we simplify the
 networking and in the UI/API get rid of Basic Networking while keeping
 it alive for existing users?

 Wido

>>>
>>>
>>>