Re: Why CloudStack 5

[Sven Vogel]

Hi Guys,

That what I say to version 5.

I understand both people these they say version 5.0 is the right way or 4.XX. 
For a marketing men version 5 looks like a big deal but under the hood what’s 
really new? I know there are new features but what of them is a groundbreaking 
feature? For me its not important if there is a 5. Or a 4.XX version.

I see the the stability of the UI is one of the important things we have to do. 
Hey folks, a project with a good API but no working UI will not be a cloud 
environment. In the long run it will not be interesting for new people.

--My team and me will work in the next months make the jQuery UI better, add 
features and try to bug fix. I hope anybody will help. We started with any 
thing like jQuery library update and will go further. Normally we don’t need a 
new UI but we need to fix it and make it better.--

The things to do that are there. I know that any web frontend developer will 
say hhh „jQuery“ its very old lets use a newer thing. We know all that 
every year new features come new features and programming languages and 
everytime there come people they say why you use such a old …

A good UI is a working UI and one of the important things of a cloud 
environment! humans are visual! Not all but I think the most of them. Okay it 
should looks good and not so ugly but it should be working and let the people 
do the things they want to do. I worked with VMware vCloud and OpenStack too 
and I think the interface is not so bad. It needs some love :)

Thats what I think for a change from 4.X.X to 5.0.0

5.0.0 Is a Marketing hype and let people outside from cloudstack think there's 
something going on...
4.X.X is really without this marketing hype and I think the same like Ivan, 
what he wrote is the same what I think.

Maybe maybe you will find a compromise and make a 5.0.0 for the marketing hype 
let us do what we do now - cleanup, improving codebase, stabilize the existing 
functions and add new features!

I see the same like @Ivan.

> Well, my intention is to prevent the community from doing revolutionary
> changes intending to deliver redesigned 5.0, to keep going the current road
> improving the codebase, removing the odd stuff like 'Citrix NetScaler',
> 'Juniper XYZ' if nobody supports them, improving current functionality and
> adding new core features which are opensource without vendor lock-in, e.g.
> SDNs (I know Wido is very into it) e.g. Cumulus infra support. I believe
> current codebase is a pretty capable basement for future stable
> functionality.


@Wido

> SDNs (I know Wido is very into it) e.g. Cumulus infra support

Yes we use cumulus… great!

Sorry for my English.

Thanks Guys


__

Sven Vogel
Teamlead Platform

EWERK RZ GmbH
Brühl 24, D-04109 Leipzig
P +49 341 42649 - 11
F +49 341 42649 - 18
s.vo...@ewerk.com
www.ewerk.com

Geschäftsführer:
Dr. Erik Wende, Hendrik Schubert, Frank Richter, Gerhard Hoyer
Registergericht: Leipzig HRB 17023

Zertifiziert nach:
ISO/IEC 27001:2013
DIN EN ISO 9001:2015
DIN ISO/IEC 2-1:2011

EWERK-Blog | LinkedIn | Xing | Twitter | Facebook

Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.

Disclaimer Privacy:
Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist 
vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der 
bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, 
Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte 
informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die 
E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen 
Dank.

The contents of this e-mail (including any attachments) are confidential and 
may be legally privileged. If you are not the intended recipient of this 
e-mail, any disclosure, copying, distribution or use of its contents is 
strictly prohibited, and you should please notify the sender immediately and 
then delete it (including any attachments) from your system. Thank you.
> Am 26.01.2019 um 03:36 schrieb Ivan Kudryavtsev :
>
> Well, my intention is to prevent the community from doing revolutionary
> changes intending to deliver redesigned 5.0, to keep going the current road
> improving the codebase, removing the odd stuff like 'Citrix NetScaler',
> 'Juniper XYZ' if nobody supports them, improving current functionality and
> adding new core features which are opensource without vendor lock-in, e.g.
> SDNs (I know Wido is very into it) e.g. Cumulus infra support. I believe
> current codebase is a pretty capable basement for future stable
> functionality.
>
> About new UI, etc stuff... Let's be honest. We develop CloudStack-UI
> project for 1.5 years AFAIK. No single PR from other developers. Next,
> Imagine, you have tree dedicated devs for CS5.X. Ok, it will take two years
> to deliver new UI. Is it possible? NO.
>
> Only gradual improvement can work for the current production team. We need
> to put efforts to broaden the community, 

Re: Why CloudStack 5

[Ron Wheeler]

Maybe it might be a good idea to keep 4.x for the version with no spec 
which can be extended without regard for upward compatibility and start 
a spec for 5.x. which would have some iron-clad rules about 
compatibility and interface/API stability.


That way everyone could contribute to the version that they feel most 
comfortable supporting.


Surely CS must be at a state by now where a really stable spec and API 
could be documented in a short amount of time.

If there was a spec perhaps more developers would be able to contribute.
If the docs were simplified as a result of a cleaner spec, perhaps more 
users would be able to get it implemented into production.


Even if it takes a few years to get a solid 5.0 out the door, it might 
be worthwhile if that results in a product that can be marketed as a 
mature product with clean rules for extensibility and customization.


In the meantime version 4 could be kept going if people want to keep 
patching it and cleaning it up.


Every major software product reaches a point where the initial base and 
layers of patches needs to be replaced by a version that is based on the 
latest technology and development practices or it dies under its own weight.


From the discussion, it may be that CS has reached that point and it 
would be a lot less work to do a major rewrite than to clean out the 
accumulated junk.


I am not a CS developer and I find it hard to believe that CS is not yet 
a sufficiently mature product providing a well understood functionality 
that a really solid stable spec can not be developed.



Ron

On 1/25/19 9:36 PM, Ivan Kudryavtsev wrote:

Well, my intention is to prevent the community from doing revolutionary
changes intending to deliver redesigned 5.0, to keep going the current road
improving the codebase, removing the odd stuff like 'Citrix NetScaler',
'Juniper XYZ' if nobody supports them, improving current functionality and
adding new core features which are opensource without vendor lock-in, e.g.
SDNs (I know Wido is very into it) e.g. Cumulus infra support. I believe
current codebase is a pretty capable basement for future stable
functionality.

About new UI, etc stuff... Let's be honest. We develop CloudStack-UI
project for 1.5 years AFAIK. No single PR from other developers. Next,
Imagine, you have tree dedicated devs for CS5.X. Ok, it will take two years
to deliver new UI. Is it possible? NO.

Only gradual improvement can work for the current production team. We need
to put efforts to broaden the community, delivering the stuff which
helps new adopters to launch fast, e.g. as simple as Proxmox VE or oVirt or
VmWare ESXi. New users don't need much top-notch stuff, they need to
bootstrap fast.




сб, 26 янв. 2019 г. в 04:26, Rafael Weingärtner 
:
I am 100% with @Rohit Yadav  with respect to
4.12. I do diverge regarding the next LTS version though.

As you all guys said, the community is small, and as such, if we have the
requirement for multiple major changes, before upgrading the "X" bit in a
release, we will never go there (that is a fact). In my opinion, because
the community is small, we should look for a single major change (e.g. new
database upgrade method/scheme), and this should trigger the next major
release. The ability to upgrade the "X" bit free us to remove things such
as the basic network support (of course, we need to create a migration
path), new database scheme management method, normalize log messages and
logging framework and so on (many more issues can be listed here).

I really do not understand why we have so much resistance from some people
on this topic.

On Thu, Jan 24, 2019 at 2:27 PM Suresh Kumar Anaparti <
sureshkumar.anapa...@gmail.com> wrote:


Sounds good. Altogether, the makeover should be a new user experience and
leverage the latest hypervisor/storage tech and new/redesigned

frameworks.

-Suresh

On Thu, Jan 24, 2019 at 10:13 AM Rohit Yadav 
wrote:


I'm in the favour of keeping the 4.x going because no API compatibility

is

broken, and as long as we are following semver there is no need.

Calling

a

4.x a 5.x just for the sake of bumping versions may cause some

perception

issue.

Removal of unsupported/poc/incomplete features, plugins including APIs
should not constitute breaking of compatibility. Several network and
hypervisor plugins are still in poc/incomplete/unmaintained state.

Unless the API layer, and perhaps DB layer is re-architected there is

no

point in calling the next version 5.x as long as semver is followed.

In my opinion, the next major version 5.0 should have a restful

versioned

API layer, a new DB+upgrade framework that may support multiple db

servers,

a new UI, sandboxed plugin framework (right now a plugin can do

anything

it

wants to say the cloud db), a new agent-clustering framework (the

current

low level nio and rpc code goes away), a distributed message bus and
locking service (that we thought to introduce in 4.2,4.3 but

incomplete),

and refactor the 

Re: Why CloudStack 5

[Ivan Kudryavtsev]

Well, my intention is to prevent the community from doing revolutionary
changes intending to deliver redesigned 5.0, to keep going the current road
improving the codebase, removing the odd stuff like 'Citrix NetScaler',
'Juniper XYZ' if nobody supports them, improving current functionality and
adding new core features which are opensource without vendor lock-in, e.g.
SDNs (I know Wido is very into it) e.g. Cumulus infra support. I believe
current codebase is a pretty capable basement for future stable
functionality.

About new UI, etc stuff... Let's be honest. We develop CloudStack-UI
project for 1.5 years AFAIK. No single PR from other developers. Next,
Imagine, you have tree dedicated devs for CS5.X. Ok, it will take two years
to deliver new UI. Is it possible? NO.

Only gradual improvement can work for the current production team. We need
to put efforts to broaden the community, delivering the stuff which
helps new adopters to launch fast, e.g. as simple as Proxmox VE or oVirt or
VmWare ESXi. New users don't need much top-notch stuff, they need to
bootstrap fast.




сб, 26 янв. 2019 г. в 04:26, Rafael Weingärtner :

> I am 100% with @Rohit Yadav  with respect to
> 4.12. I do diverge regarding the next LTS version though.
>
> As you all guys said, the community is small, and as such, if we have the
> requirement for multiple major changes, before upgrading the "X" bit in a
> release, we will never go there (that is a fact). In my opinion, because
> the community is small, we should look for a single major change (e.g. new
> database upgrade method/scheme), and this should trigger the next major
> release. The ability to upgrade the "X" bit free us to remove things such
> as the basic network support (of course, we need to create a migration
> path), new database scheme management method, normalize log messages and
> logging framework and so on (many more issues can be listed here).
>
> I really do not understand why we have so much resistance from some people
> on this topic.
>
> On Thu, Jan 24, 2019 at 2:27 PM Suresh Kumar Anaparti <
> sureshkumar.anapa...@gmail.com> wrote:
>
> > Sounds good. Altogether, the makeover should be a new user experience and
> > leverage the latest hypervisor/storage tech and new/redesigned
> frameworks.
> >
> > -Suresh
> >
> > On Thu, Jan 24, 2019 at 10:13 AM Rohit Yadav 
> > wrote:
> >
> > > I'm in the favour of keeping the 4.x going because no API compatibility
> > is
> > > broken, and as long as we are following semver there is no need.
> Calling
> > a
> > > 4.x a 5.x just for the sake of bumping versions may cause some
> perception
> > > issue.
> > >
> > > Removal of unsupported/poc/incomplete features, plugins including APIs
> > > should not constitute breaking of compatibility. Several network and
> > > hypervisor plugins are still in poc/incomplete/unmaintained state.
> > >
> > > Unless the API layer, and perhaps DB layer is re-architected there is
> no
> > > point in calling the next version 5.x as long as semver is followed.
> > >
> > > In my opinion, the next major version 5.0 should have a restful
> versioned
> > > API layer, a new DB+upgrade framework that may support multiple db
> > servers,
> > > a new UI, sandboxed plugin framework (right now a plugin can do
> anything
> > it
> > > wants to say the cloud db), a new agent-clustering framework (the
> current
> > > low level nio and rpc code goes away), a distributed message bus and
> > > locking service (that we thought to introduce in 4.2,4.3 but
> incomplete),
> > > and refactor the networking/VR layer with a new VR. Not to mention
> > cleanup
> > > some technical debt. The keywords being major architectural and
> > > api/integrational changes. Some of this maybe on-going, but we'll get
> to
> > > 5.x with patience over time.
> > >
> > > Regards,
> > > Rohit Yadav
> > >
> > > 
> > > From: Ivan Kudryavtsev 
> > > Sent: Tuesday, January 22, 2019 9:15:29 AM
> > > To: users; dev
> > > Subject: Why CloudStack 5
> > >
> > > I decided whether to write it several weeks thinking about the stones
> and
> > > rotten potatoes, but still decided to do that. Hope it will not raise
> the
> > > stress level.
> > >
> > > Colleagues and ACS leaders, I would like to initiate the discussion.
> Why
> > go
> > > to CS5 rather than stay with 4.XX. Some thoughts are:
> > >
> > > 1. According to the versioning guide, the first number stands for
> radical
> > > changes like if the community decided to go from current ORM to
> > Hibernate.
> > > I don't see the capabilities for such changes and there are no
> intentions
> > > for the implementation.
> > >
> > > 2. I can realize that we 'stuck' with '4.XX' and the marketing can be
> > > disappointing from that point of view. Then, OK, let's just skip the
> > first
> > > number "4." and release, ACS 13.X, 14.X, 15.X and so on. Every version
> > will
> > > receive new impressing version number and everyone could be happy about
> > > that.
> > >
> > > Going 

Re: Why CloudStack 5

[Rafael Weingärtner]

I am 100% with @Rohit Yadav  with respect to
4.12. I do diverge regarding the next LTS version though.

As you all guys said, the community is small, and as such, if we have the
requirement for multiple major changes, before upgrading the "X" bit in a
release, we will never go there (that is a fact). In my opinion, because
the community is small, we should look for a single major change (e.g. new
database upgrade method/scheme), and this should trigger the next major
release. The ability to upgrade the "X" bit free us to remove things such
as the basic network support (of course, we need to create a migration
path), new database scheme management method, normalize log messages and
logging framework and so on (many more issues can be listed here).

I really do not understand why we have so much resistance from some people
on this topic.

On Thu, Jan 24, 2019 at 2:27 PM Suresh Kumar Anaparti <
sureshkumar.anapa...@gmail.com> wrote:

> Sounds good. Altogether, the makeover should be a new user experience and
> leverage the latest hypervisor/storage tech and new/redesigned frameworks.
>
> -Suresh
>
> On Thu, Jan 24, 2019 at 10:13 AM Rohit Yadav 
> wrote:
>
> > I'm in the favour of keeping the 4.x going because no API compatibility
> is
> > broken, and as long as we are following semver there is no need. Calling
> a
> > 4.x a 5.x just for the sake of bumping versions may cause some perception
> > issue.
> >
> > Removal of unsupported/poc/incomplete features, plugins including APIs
> > should not constitute breaking of compatibility. Several network and
> > hypervisor plugins are still in poc/incomplete/unmaintained state.
> >
> > Unless the API layer, and perhaps DB layer is re-architected there is no
> > point in calling the next version 5.x as long as semver is followed.
> >
> > In my opinion, the next major version 5.0 should have a restful versioned
> > API layer, a new DB+upgrade framework that may support multiple db
> servers,
> > a new UI, sandboxed plugin framework (right now a plugin can do anything
> it
> > wants to say the cloud db), a new agent-clustering framework (the current
> > low level nio and rpc code goes away), a distributed message bus and
> > locking service (that we thought to introduce in 4.2,4.3 but incomplete),
> > and refactor the networking/VR layer with a new VR. Not to mention
> cleanup
> > some technical debt. The keywords being major architectural and
> > api/integrational changes. Some of this maybe on-going, but we'll get to
> > 5.x with patience over time.
> >
> > Regards,
> > Rohit Yadav
> >
> > 
> > From: Ivan Kudryavtsev 
> > Sent: Tuesday, January 22, 2019 9:15:29 AM
> > To: users; dev
> > Subject: Why CloudStack 5
> >
> > I decided whether to write it several weeks thinking about the stones and
> > rotten potatoes, but still decided to do that. Hope it will not raise the
> > stress level.
> >
> > Colleagues and ACS leaders, I would like to initiate the discussion. Why
> go
> > to CS5 rather than stay with 4.XX. Some thoughts are:
> >
> > 1. According to the versioning guide, the first number stands for radical
> > changes like if the community decided to go from current ORM to
> Hibernate.
> > I don't see the capabilities for such changes and there are no intentions
> > for the implementation.
> >
> > 2. I can realize that we 'stuck' with '4.XX' and the marketing can be
> > disappointing from that point of view. Then, OK, let's just skip the
> first
> > number "4." and release, ACS 13.X, 14.X, 15.X and so on. Every version
> will
> > receive new impressing version number and everyone could be happy about
> > that.
> >
> > Going to version "5" currently looks like as an intention to refresh but
> > with very poor motivation. At least to me.
> >
> > The discussion is strongly welcome.
> >
> >
> >
> > --
> > With best regards, Ivan Kudryavtsev
> > Bitworks LLC
> > Cell RU: +7-923-414-1515
> > Cell USA: +1-201-257-1512
> > WWW: http://bitworks.software/ 
> >
> > rohit.ya...@shapeblue.com
> > www.shapeblue.com
> > Amadeus House, Floral Street, London  WC2E 9DPUK
> > @shapeblue
> >
> >
> >
> >
>


-- 
Rafael Weingärtner

Re: Why CloudStack 5

[Suresh Kumar Anaparti]

Sounds good. Altogether, the makeover should be a new user experience and
leverage the latest hypervisor/storage tech and new/redesigned frameworks.

-Suresh

On Thu, Jan 24, 2019 at 10:13 AM Rohit Yadav 
wrote:

> I'm in the favour of keeping the 4.x going because no API compatibility is
> broken, and as long as we are following semver there is no need. Calling a
> 4.x a 5.x just for the sake of bumping versions may cause some perception
> issue.
>
> Removal of unsupported/poc/incomplete features, plugins including APIs
> should not constitute breaking of compatibility. Several network and
> hypervisor plugins are still in poc/incomplete/unmaintained state.
>
> Unless the API layer, and perhaps DB layer is re-architected there is no
> point in calling the next version 5.x as long as semver is followed.
>
> In my opinion, the next major version 5.0 should have a restful versioned
> API layer, a new DB+upgrade framework that may support multiple db servers,
> a new UI, sandboxed plugin framework (right now a plugin can do anything it
> wants to say the cloud db), a new agent-clustering framework (the current
> low level nio and rpc code goes away), a distributed message bus and
> locking service (that we thought to introduce in 4.2,4.3 but incomplete),
> and refactor the networking/VR layer with a new VR. Not to mention cleanup
> some technical debt. The keywords being major architectural and
> api/integrational changes. Some of this maybe on-going, but we'll get to
> 5.x with patience over time.
>
> Regards,
> Rohit Yadav
>
> 
> From: Ivan Kudryavtsev 
> Sent: Tuesday, January 22, 2019 9:15:29 AM
> To: users; dev
> Subject: Why CloudStack 5
>
> I decided whether to write it several weeks thinking about the stones and
> rotten potatoes, but still decided to do that. Hope it will not raise the
> stress level.
>
> Colleagues and ACS leaders, I would like to initiate the discussion. Why go
> to CS5 rather than stay with 4.XX. Some thoughts are:
>
> 1. According to the versioning guide, the first number stands for radical
> changes like if the community decided to go from current ORM to Hibernate.
> I don't see the capabilities for such changes and there are no intentions
> for the implementation.
>
> 2. I can realize that we 'stuck' with '4.XX' and the marketing can be
> disappointing from that point of view. Then, OK, let's just skip the first
> number "4." and release, ACS 13.X, 14.X, 15.X and so on. Every version will
> receive new impressing version number and everyone could be happy about
> that.
>
> Going to version "5" currently looks like as an intention to refresh but
> with very poor motivation. At least to me.
>
> The discussion is strongly welcome.
>
>
>
> --
> With best regards, Ivan Kudryavtsev
> Bitworks LLC
> Cell RU: +7-923-414-1515
> Cell USA: +1-201-257-1512
> WWW: http://bitworks.software/ 
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> Amadeus House, Floral Street, London  WC2E 9DPUK
> @shapeblue
>
>
>
>

Re: Why CloudStack 5

[Ivan Kudryavtsev]

Well, I'm glad the topic raised the discussion. That's great. My point is
very carefully explained by Rohit. It's not a new idea - CloudStack
community is small. Some features are abandoned and broken because of no
developers behind them. I bet certain features still not tested in 4.11.2
because nobody uses them. When the feature owning vendor leaves the support
it's no way just to remove the feature like Midonet as Rafael said.

When I started the career, people used Perl5 and everyone was happy, but
Larry Wall decided to go to Perl6... And who knows where the Perl now?
People don't want something new because it's just renovated. Frankly, I
don't believe that deep CloudStack redesign could be delivered by the
community. But I believe CloudStack could evolve gradually, introducing new
features and fixing bugs. I believe, that if there is no vendor for
something it should be wiped out to keep the code sane and low fat. I don't
think it's right to push plugins into the upstream codebase. I think that
ACS community must keep eye on better features design and every version
must include one properly designed and voted feature aside of small
improvements and fixes. I believe that PRs must be moderated not only from
the code sense but also from the point that code is reflected in design
documents and documentation.

I don't think CS5 (deep redesign) is even required by users. The code is
pretty good, it works well. Just don't want to think it could end as Perl6.

чт, 24 янв. 2019 г. в 11:43, Rohit Yadav :

> I'm in the favour of keeping the 4.x going because no API compatibility is
> broken, and as long as we are following semver there is no need. Calling a
> 4.x a 5.x just for the sake of bumping versions may cause some perception
> issue.
>
> Removal of unsupported/poc/incomplete features, plugins including APIs
> should not constitute breaking of compatibility. Several network and
> hypervisor plugins are still in poc/incomplete/unmaintained state.
>
> Unless the API layer, and perhaps DB layer is re-architected there is no
> point in calling the next version 5.x as long as semver is followed.
>
> In my opinion, the next major version 5.0 should have a restful versioned
> API layer, a new DB+upgrade framework that may support multiple db servers,
> a new UI, sandboxed plugin framework (right now a plugin can do anything it
> wants to say the cloud db), a new agent-clustering framework (the current
> low level nio and rpc code goes away), a distributed message bus and
> locking service (that we thought to introduce in 4.2,4.3 but incomplete),
> and refactor the networking/VR layer with a new VR. Not to mention cleanup
> some technical debt. The keywords being major architectural and
> api/integrational changes. Some of this maybe on-going, but we'll get to
> 5.x with patience over time.
>
> Regards,
> Rohit Yadav
>
> 
> From: Ivan Kudryavtsev 
> Sent: Tuesday, January 22, 2019 9:15:29 AM
> To: users; dev
> Subject: Why CloudStack 5
>
> I decided whether to write it several weeks thinking about the stones and
> rotten potatoes, but still decided to do that. Hope it will not raise the
> stress level.
>
> Colleagues and ACS leaders, I would like to initiate the discussion. Why go
> to CS5 rather than stay with 4.XX. Some thoughts are:
>
> 1. According to the versioning guide, the first number stands for radical
> changes like if the community decided to go from current ORM to Hibernate.
> I don't see the capabilities for such changes and there are no intentions
> for the implementation.
>
> 2. I can realize that we 'stuck' with '4.XX' and the marketing can be
> disappointing from that point of view. Then, OK, let's just skip the first
> number "4." and release, ACS 13.X, 14.X, 15.X and so on. Every version will
> receive new impressing version number and everyone could be happy about
> that.
>
> Going to version "5" currently looks like as an intention to refresh but
> with very poor motivation. At least to me.
>
> The discussion is strongly welcome.
>
>
>
> --
> With best regards, Ivan Kudryavtsev
> Bitworks LLC
> Cell RU: +7-923-414-1515
> Cell USA: +1-201-257-1512
> WWW: http://bitworks.software/ 
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> Amadeus House, Floral Street, London  WC2E 9DPUK
> @shapeblue
>
>
>
>

-- 
With best regards, Ivan Kudryavtsev
Bitworks LLC
Cell RU: +7-923-414-1515
Cell USA: +1-201-257-1512
WWW: http://bitworks.software/ 

Re: Why CloudStack 5

[Rohit Yadav]

I'm in the favour of keeping the 4.x going because no API compatibility is 
broken, and as long as we are following semver there is no need. Calling a 4.x 
a 5.x just for the sake of bumping versions may cause some perception issue.

Removal of unsupported/poc/incomplete features, plugins including APIs should 
not constitute breaking of compatibility. Several network and hypervisor 
plugins are still in poc/incomplete/unmaintained state.

Unless the API layer, and perhaps DB layer is re-architected there is no point 
in calling the next version 5.x as long as semver is followed.

In my opinion, the next major version 5.0 should have a restful versioned API 
layer, a new DB+upgrade framework that may support multiple db servers, a new 
UI, sandboxed plugin framework (right now a plugin can do anything it wants to 
say the cloud db), a new agent-clustering framework (the current low level nio 
and rpc code goes away), a distributed message bus and locking service (that we 
thought to introduce in 4.2,4.3 but incomplete), and refactor the networking/VR 
layer with a new VR. Not to mention cleanup some technical debt. The keywords 
being major architectural and api/integrational changes. Some of this maybe 
on-going, but we'll get to 5.x with patience over time.

Regards,
Rohit Yadav


From: Ivan Kudryavtsev 
Sent: Tuesday, January 22, 2019 9:15:29 AM
To: users; dev
Subject: Why CloudStack 5

I decided whether to write it several weeks thinking about the stones and
rotten potatoes, but still decided to do that. Hope it will not raise the
stress level.

Colleagues and ACS leaders, I would like to initiate the discussion. Why go
to CS5 rather than stay with 4.XX. Some thoughts are:

1. According to the versioning guide, the first number stands for radical
changes like if the community decided to go from current ORM to Hibernate.
I don't see the capabilities for such changes and there are no intentions
for the implementation.

2. I can realize that we 'stuck' with '4.XX' and the marketing can be
disappointing from that point of view. Then, OK, let's just skip the first
number "4." and release, ACS 13.X, 14.X, 15.X and so on. Every version will
receive new impressing version number and everyone could be happy about
that.

Going to version "5" currently looks like as an intention to refresh but
with very poor motivation. At least to me.

The discussion is strongly welcome.



--
With best regards, Ivan Kudryavtsev
Bitworks LLC
Cell RU: +7-923-414-1515
Cell USA: +1-201-257-1512
WWW: http://bitworks.software/ 

rohit.ya...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 

Re: Why CloudStack 5

[Tutkowski, Mike]

That sounds reasonable to me.



From: Rafael Weingärtner 
Sent: Wednesday, January 23, 2019 5:25 PM
To: users
Cc: d...@cloudstack.apache.org
Subject: Re: Why CloudStack 5

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.




I would say that it is indeed a solid version. However, version 4.12 by
itself is not breaking anything. Therefore, according to the semantic
versioning, we cannot increase the ‘X’ bit.

It is also interesting to consider that 4.12 has over 188 PRs merged into
it. When we finish, we will probably hit almost 200 PRs. Many new features
were added, and we might have some hidden bugs that were not discovered
yet. Therefore, at least for me, it looks wiser to launch it as a normal
release and work on top of it to create 5.0.0 during July-August 2019. This
should provide 3-6 months of experimentation with the 4.12 version in
production.

On Wed, Jan 23, 2019 at 10:07 PM Tutkowski, Mike 
wrote:

> Is 4.12 a decent candidate to be branded 5.0 or might we be waiting for
> some specific set of backwards-incompatible updates?
>
>
> 
> From: Rafael Weingärtner 
> Sent: Wednesday, January 23, 2019 4:58 PM
> To: dev
> Cc: users
> Subject: Re: Why CloudStack 5
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
>
> Hello Ivan,
> Can you provide reasons why not move to a version 5?
>
> To help you, I will provide why I think we should move to 5.0.0 after 4.12.
> Therefore, I would expect this 5.0.0 to be an LTS version as well.
>
> 1. To begin with, technically, we should already be in version 5 if we
> had been following the semantic versioning we say we follow. We broke
> compatibility when Midonet plugin was removed in 4.10, and later, also,
> when public APIs from the IAM projects were removed. You can discuss if
> those features were broken or not, and if they count as a backward
> incompatibility. All in all, it is a removal of public APIs;
> 2. We want to remove the basic network, and with this move, we can
> delete a load of complications and replicated code, which causes more
> burden than anything else;
> 3. There are also some other small details in some PRs, where these
> issues with backward compatibility are holding our code and structure
> improvements. Therefore, a CloudStack 5.0.0 would free us from these
> anchors that we keep dragging around;
> 4. A new database upgrade scheme…. I do not even need to get into this
> topic; all DEVs here know what I am talking about;
> 5. A proper JPA implementation, a real restful API, adopt a standard
> rest framework, and other base technological improvements would be awesome,
> but I would say that they are far from here now. And they will be always
> distant if we keep holding ourselves back.
>
> All in all, to conclude; it is not about the version number and marketing.
> At least for me, I could care less about the number. This is about the
> community being able to adopt new trends, new technology, new methods, and
> understanding that to move on, we need to let somethings go.
>
> On Tue, Jan 22, 2019 at 1:45 AM Ivan Kudryavtsev  >
> wrote:
>
> > I decided whether to write it several weeks thinking about the stones and
> > rotten potatoes, but still decided to do that. Hope it will not raise the
> > stress level.
> >
> > Colleagues and ACS leaders, I would like to initiate the discussion. Why
> go
> > to CS5 rather than stay with 4.XX. Some thoughts are:
> >
> > 1. According to the versioning guide, the first number stands for radical
> > changes like if the community decided to go from current ORM to
> Hibernate.
> > I don't see the capabilities for such changes and there are no intentions
> > for the implementation.
> >
> > 2. I can realize that we 'stuck' with '4.XX' and the marketing can be
> > disappointing from that point of view. Then, OK, let's just skip the
> first
> > number "4." and release, ACS 13.X, 14.X, 15.X and so on. Every version
> will
> > receive new impressing version number and everyone could be happy about
> > that.
> >
> > Going to version "5" currently looks like as an intention to refresh but
> > with very poor motivation. At least to me.
> >
> > The discussion is strongly welcome.
> >
> >
> >
> > --
> > With best regards, Ivan Kudryavtsev
> > Bitworks LLC
> > Cell RU: +7-923-414-1515
> > Cell USA: +1-201-257-1512
> > WWW: http://bitworks.software/ <http://bw-sw.com/>
> >
>
>
> --
> Rafael Weingärtner
>


--
Rafael Weingärtner

Re: Why CloudStack 5

[Rafael Weingärtner]

I would say that it is indeed a solid version. However, version 4.12 by
itself is not breaking anything. Therefore, according to the semantic
versioning, we cannot increase the ‘X’ bit.

It is also interesting to consider that 4.12 has over 188 PRs merged into
it. When we finish, we will probably hit almost 200 PRs. Many new features
were added, and we might have some hidden bugs that were not discovered
yet. Therefore, at least for me, it looks wiser to launch it as a normal
release and work on top of it to create 5.0.0 during July-August 2019. This
should provide 3-6 months of experimentation with the 4.12 version in
production.

On Wed, Jan 23, 2019 at 10:07 PM Tutkowski, Mike 
wrote:

> Is 4.12 a decent candidate to be branded 5.0 or might we be waiting for
> some specific set of backwards-incompatible updates?
>
>
> 
> From: Rafael Weingärtner 
> Sent: Wednesday, January 23, 2019 4:58 PM
> To: dev
> Cc: users
> Subject: Re: Why CloudStack 5
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
>
> Hello Ivan,
> Can you provide reasons why not move to a version 5?
>
> To help you, I will provide why I think we should move to 5.0.0 after 4.12.
> Therefore, I would expect this 5.0.0 to be an LTS version as well.
>
> 1. To begin with, technically, we should already be in version 5 if we
> had been following the semantic versioning we say we follow. We broke
> compatibility when Midonet plugin was removed in 4.10, and later, also,
> when public APIs from the IAM projects were removed. You can discuss if
> those features were broken or not, and if they count as a backward
> incompatibility. All in all, it is a removal of public APIs;
> 2. We want to remove the basic network, and with this move, we can
> delete a load of complications and replicated code, which causes more
> burden than anything else;
> 3. There are also some other small details in some PRs, where these
> issues with backward compatibility are holding our code and structure
> improvements. Therefore, a CloudStack 5.0.0 would free us from these
> anchors that we keep dragging around;
> 4. A new database upgrade scheme…. I do not even need to get into this
> topic; all DEVs here know what I am talking about;
> 5. A proper JPA implementation, a real restful API, adopt a standard
> rest framework, and other base technological improvements would be awesome,
> but I would say that they are far from here now. And they will be always
> distant if we keep holding ourselves back.
>
> All in all, to conclude; it is not about the version number and marketing.
> At least for me, I could care less about the number. This is about the
> community being able to adopt new trends, new technology, new methods, and
> understanding that to move on, we need to let somethings go.
>
> On Tue, Jan 22, 2019 at 1:45 AM Ivan Kudryavtsev  >
> wrote:
>
> > I decided whether to write it several weeks thinking about the stones and
> > rotten potatoes, but still decided to do that. Hope it will not raise the
> > stress level.
> >
> > Colleagues and ACS leaders, I would like to initiate the discussion. Why
> go
> > to CS5 rather than stay with 4.XX. Some thoughts are:
> >
> > 1. According to the versioning guide, the first number stands for radical
> > changes like if the community decided to go from current ORM to
> Hibernate.
> > I don't see the capabilities for such changes and there are no intentions
> > for the implementation.
> >
> > 2. I can realize that we 'stuck' with '4.XX' and the marketing can be
> > disappointing from that point of view. Then, OK, let's just skip the
> first
> > number "4." and release, ACS 13.X, 14.X, 15.X and so on. Every version
> will
> > receive new impressing version number and everyone could be happy about
> > that.
> >
> > Going to version "5" currently looks like as an intention to refresh but
> > with very poor motivation. At least to me.
> >
> > The discussion is strongly welcome.
> >
> >
> >
> > --
> > With best regards, Ivan Kudryavtsev
> > Bitworks LLC
> > Cell RU: +7-923-414-1515
> > Cell USA: +1-201-257-1512
> > WWW: http://bitworks.software/ <http://bw-sw.com/>
> >
>
>
> --
> Rafael Weingärtner
>


-- 
Rafael Weingärtner

Re: Why CloudStack 5

[Tutkowski, Mike]

Is 4.12 a decent candidate to be branded 5.0 or might we be waiting for some 
specific set of backwards-incompatible updates?



From: Rafael Weingärtner 
Sent: Wednesday, January 23, 2019 4:58 PM
To: dev
Cc: users
Subject: Re: Why CloudStack 5

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.




Hello Ivan,
Can you provide reasons why not move to a version 5?

To help you, I will provide why I think we should move to 5.0.0 after 4.12.
Therefore, I would expect this 5.0.0 to be an LTS version as well.

1. To begin with, technically, we should already be in version 5 if we
had been following the semantic versioning we say we follow. We broke
compatibility when Midonet plugin was removed in 4.10, and later, also,
when public APIs from the IAM projects were removed. You can discuss if
those features were broken or not, and if they count as a backward
incompatibility. All in all, it is a removal of public APIs;
2. We want to remove the basic network, and with this move, we can
delete a load of complications and replicated code, which causes more
burden than anything else;
3. There are also some other small details in some PRs, where these
issues with backward compatibility are holding our code and structure
improvements. Therefore, a CloudStack 5.0.0 would free us from these
anchors that we keep dragging around;
4. A new database upgrade scheme…. I do not even need to get into this
topic; all DEVs here know what I am talking about;
5. A proper JPA implementation, a real restful API, adopt a standard
rest framework, and other base technological improvements would be awesome,
but I would say that they are far from here now. And they will be always
distant if we keep holding ourselves back.

All in all, to conclude; it is not about the version number and marketing.
At least for me, I could care less about the number. This is about the
community being able to adopt new trends, new technology, new methods, and
understanding that to move on, we need to let somethings go.

On Tue, Jan 22, 2019 at 1:45 AM Ivan Kudryavtsev 
wrote:

> I decided whether to write it several weeks thinking about the stones and
> rotten potatoes, but still decided to do that. Hope it will not raise the
> stress level.
>
> Colleagues and ACS leaders, I would like to initiate the discussion. Why go
> to CS5 rather than stay with 4.XX. Some thoughts are:
>
> 1. According to the versioning guide, the first number stands for radical
> changes like if the community decided to go from current ORM to Hibernate.
> I don't see the capabilities for such changes and there are no intentions
> for the implementation.
>
> 2. I can realize that we 'stuck' with '4.XX' and the marketing can be
> disappointing from that point of view. Then, OK, let's just skip the first
> number "4." and release, ACS 13.X, 14.X, 15.X and so on. Every version will
> receive new impressing version number and everyone could be happy about
> that.
>
> Going to version "5" currently looks like as an intention to refresh but
> with very poor motivation. At least to me.
>
> The discussion is strongly welcome.
>
>
>
> --
> With best regards, Ivan Kudryavtsev
> Bitworks LLC
> Cell RU: +7-923-414-1515
> Cell USA: +1-201-257-1512
> WWW: http://bitworks.software/ <http://bw-sw.com/>
>


--
Rafael Weingärtner

Re: Why CloudStack 5

[Rafael Weingärtner]

Hello Ivan,
Can you provide reasons why not move to a version 5?

To help you, I will provide why I think we should move to 5.0.0 after 4.12.
Therefore, I would expect this 5.0.0 to be an LTS version as well.

   1. To begin with, technically, we should already be in version 5 if we
   had been following the semantic versioning we say we follow. We broke
   compatibility when Midonet plugin was removed in 4.10, and later, also,
   when public APIs from the IAM projects were removed. You can discuss if
   those features were broken or not, and if they count as a backward
   incompatibility. All in all, it is a removal of public APIs;
   2. We want to remove the basic network, and with this move, we can
   delete a load of complications and replicated code, which causes more
   burden than anything else;
   3. There are also some other small details in some PRs, where these
   issues with backward compatibility are holding our code and structure
   improvements. Therefore, a CloudStack 5.0.0 would free us from these
   anchors that we keep dragging around;
   4. A new database upgrade scheme…. I do not even need to get into this
   topic; all DEVs here know what I am talking about;
   5. A proper JPA implementation, a real restful API, adopt a standard
   rest framework, and other base technological improvements would be awesome,
   but I would say that they are far from here now. And they will be always
   distant if we keep holding ourselves back.

All in all, to conclude; it is not about the version number and marketing.
At least for me, I could care less about the number. This is about the
community being able to adopt new trends, new technology, new methods, and
understanding that to move on, we need to let somethings go.

On Tue, Jan 22, 2019 at 1:45 AM Ivan Kudryavtsev 
wrote:

> I decided whether to write it several weeks thinking about the stones and
> rotten potatoes, but still decided to do that. Hope it will not raise the
> stress level.
>
> Colleagues and ACS leaders, I would like to initiate the discussion. Why go
> to CS5 rather than stay with 4.XX. Some thoughts are:
>
> 1. According to the versioning guide, the first number stands for radical
> changes like if the community decided to go from current ORM to Hibernate.
> I don't see the capabilities for such changes and there are no intentions
> for the implementation.
>
> 2. I can realize that we 'stuck' with '4.XX' and the marketing can be
> disappointing from that point of view. Then, OK, let's just skip the first
> number "4." and release, ACS 13.X, 14.X, 15.X and so on. Every version will
> receive new impressing version number and everyone could be happy about
> that.
>
> Going to version "5" currently looks like as an intention to refresh but
> with very poor motivation. At least to me.
>
> The discussion is strongly welcome.
>
>
>
> --
> With best regards, Ivan Kudryavtsev
> Bitworks LLC
> Cell RU: +7-923-414-1515
> Cell USA: +1-201-257-1512
> WWW: http://bitworks.software/ 
>


-- 
Rafael Weingärtner