Setup Linstor Plugin for ACS

[Technology Rss]

Hello community!

I want to setup Linstorplugin for my ACS environment. Please let me know 
any user experience for any issue for production uses.


Also please share any technical details for setup it.

--

*Thanks & Regards.*

*Support Admin*



*Facebook  | Twitter 
 | YouTube 
 | LinkedIn 
*


*Address : *116/1 West Malibagh, D. I. T Road

Dhaka-1217, Bangladesh

*Mob :* +88 01716915504

*Email :* support.ad...@technologyrss.com

*Web :* www.technologyrss.com

Re: [PROPOSAL] version naming : drop the 4.

[Nux]

Then with this kind of thinking we'll need a truly monumental 
change/features to warrant a "v5".


On 2024-01-22 11:17, Wei ZHOU wrote:

+1 with 20.0

5.0 sounds like a leap with lots of significant changes. Unfortunately 
it

has not been discussed what needs to be done.
20.0 (or 24.0) looks better.

Wei

On Mon, 22 Jan 2024 at 12:01, Daan Hoogland  
wrote:



João,
I think we should not consider 5.0, but go to 20,0 that is more in
line with what we've actually been doing (semantic versioning from the
second digit)

On Mon, Jan 22, 2024 at 11:53 AM Nux  wrote:
>
> LGTM!
>
> On 2024-01-19 19:19, João Jandre Paraquetti wrote:
> > Hi all,
> >
> > I agree that our current versioning schema doesn't make much sense, as
> > "minors" introduce pretty big features; even backward incompatibilities
> > are introduced in minor versions sometimes.
> >
> > As the current plan is to have 4.20 by June, I think we should stick to
> > it and still have the next "minor", and make it the last minor version
> > of the major 4. After so much time in the same major version, we should
> > plan something relevant before changing it, and June 2024 is a bit of a
> > tight schedule for that.
> >
> > I think that we should plan to move to version 5.0.0, we could set the
> > release date to the end of 2024 or the start (January) of 2025; by
> > doing that, we have plenty of time for planning and developing amazing
> > features for version 5, while also preparing a cleanup of our current
> > APIs. For instance, we are working on the following major developments:
> > KVM differential snapshots/backups without needing extra software;
> > theme management system (white label portal for ACS); native
> > snapshot/backup for VMware (without needing Veeam) to make it similar
> > to what ACS does with XenServer and KVM; Operators backup (which are
> > different from end-user backups); and many other items.
> >
> > What do you guys think?
> >
> > Best regards,
> > João Jandre.
> >
> > On 1/19/24 10:39, Daan Hoogland wrote:
> >> devs, PMC,
> >>
> >> as we are closing in on 4.19 I want to propose that we drop the 4. in
> >> our versioning scheme. We've been discussing 5 but no real initiatives
> >> have been taken. Nowadays big features go into our "minor"
> >> dot-releases. In my opinion this warrants promoting those version to
> >> the status of major and dropping the 4..
> >>
> >> technically this won't be an issue as 20 > 4 and out upgrade scheme
> >> supports a step like that.
> >>
> >> any thoughts?
> >>



--
Daan

Re: new website design

[Sven Vogel]

+1 looks nice

Am Montag, den 01/22/2024 um 11:46 schrieb Nux:



+1 - do it.

On 2024-01-19 14:50, Daan Hoogland wrote:
> As we get no major issues on it and we already voted to have this
> design applied, is it alright to deploy this in the coming weeks?
> 
> On Wed, Jan 17, 2024 at 8:31 PM Daan Hoogland  
> wrote:
>> 
>> devs and users,
>> 
>> back in august we had a small discussion about a new website
design,
>> led by Ivet [1]. In the meanwhile Rohit had investigated using
>> docusaurus as a publishing mechanism for the site. After the last
few
>> weeks I have been working on integrating the two. The result so far
>> can be viewed on the staging site [2]
>> 
>> Please all have a look and give me any feedback you may have, so we
>> can move this forward.
>> 
>> [1]
https://lists.apache.org/thread/fopjc3r4hjkp9nbkj9xzoxv406rowkso
>> [2] https://cloudstack.staged.apache.org/
>> 
>> --
>> Daan

Re: [PROPOSAL] version naming : drop the 4.

[Wei ZHOU]

+1 with 20.0

5.0 sounds like a leap with lots of significant changes. Unfortunately it
has not been discussed what needs to be done.
20.0 (or 24.0) looks better.

Wei

On Mon, 22 Jan 2024 at 12:01, Daan Hoogland  wrote:

> João,
> I think we should not consider 5.0, but go to 20,0 that is more in
> line with what we've actually been doing (semantic versioning from the
> second digit)
>
> On Mon, Jan 22, 2024 at 11:53 AM Nux  wrote:
> >
> > LGTM!
> >
> > On 2024-01-19 19:19, João Jandre Paraquetti wrote:
> > > Hi all,
> > >
> > > I agree that our current versioning schema doesn't make much sense, as
> > > "minors" introduce pretty big features; even backward incompatibilities
> > > are introduced in minor versions sometimes.
> > >
> > > As the current plan is to have 4.20 by June, I think we should stick to
> > > it and still have the next "minor", and make it the last minor version
> > > of the major 4. After so much time in the same major version, we should
> > > plan something relevant before changing it, and June 2024 is a bit of a
> > > tight schedule for that.
> > >
> > > I think that we should plan to move to version 5.0.0, we could set the
> > > release date to the end of 2024 or the start (January) of 2025; by
> > > doing that, we have plenty of time for planning and developing amazing
> > > features for version 5, while also preparing a cleanup of our current
> > > APIs. For instance, we are working on the following major developments:
> > > KVM differential snapshots/backups without needing extra software;
> > > theme management system (white label portal for ACS); native
> > > snapshot/backup for VMware (without needing Veeam) to make it similar
> > > to what ACS does with XenServer and KVM; Operators backup (which are
> > > different from end-user backups); and many other items.
> > >
> > > What do you guys think?
> > >
> > > Best regards,
> > > João Jandre.
> > >
> > > On 1/19/24 10:39, Daan Hoogland wrote:
> > >> devs, PMC,
> > >>
> > >> as we are closing in on 4.19 I want to propose that we drop the 4. in
> > >> our versioning scheme. We've been discussing 5 but no real initiatives
> > >> have been taken. Nowadays big features go into our "minor"
> > >> dot-releases. In my opinion this warrants promoting those version to
> > >> the status of major and dropping the 4..
> > >>
> > >> technically this won't be an issue as 20 > 4 and out upgrade scheme
> > >> supports a step like that.
> > >>
> > >> any thoughts?
> > >>
>
>
>
> --
> Daan
>

Re: [PROPOSAL] version naming : drop the 4.

[Daan Hoogland]

João,
I think we should not consider 5.0, but go to 20,0 that is more in
line with what we've actually been doing (semantic versioning from the
second digit)

On Mon, Jan 22, 2024 at 11:53 AM Nux  wrote:
>
> LGTM!
>
> On 2024-01-19 19:19, João Jandre Paraquetti wrote:
> > Hi all,
> >
> > I agree that our current versioning schema doesn't make much sense, as
> > "minors" introduce pretty big features; even backward incompatibilities
> > are introduced in minor versions sometimes.
> >
> > As the current plan is to have 4.20 by June, I think we should stick to
> > it and still have the next "minor", and make it the last minor version
> > of the major 4. After so much time in the same major version, we should
> > plan something relevant before changing it, and June 2024 is a bit of a
> > tight schedule for that.
> >
> > I think that we should plan to move to version 5.0.0, we could set the
> > release date to the end of 2024 or the start (January) of 2025; by
> > doing that, we have plenty of time for planning and developing amazing
> > features for version 5, while also preparing a cleanup of our current
> > APIs. For instance, we are working on the following major developments:
> > KVM differential snapshots/backups without needing extra software;
> > theme management system (white label portal for ACS); native
> > snapshot/backup for VMware (without needing Veeam) to make it similar
> > to what ACS does with XenServer and KVM; Operators backup (which are
> > different from end-user backups); and many other items.
> >
> > What do you guys think?
> >
> > Best regards,
> > João Jandre.
> >
> > On 1/19/24 10:39, Daan Hoogland wrote:
> >> devs, PMC,
> >>
> >> as we are closing in on 4.19 I want to propose that we drop the 4. in
> >> our versioning scheme. We've been discussing 5 but no real initiatives
> >> have been taken. Nowadays big features go into our "minor"
> >> dot-releases. In my opinion this warrants promoting those version to
> >> the status of major and dropping the 4..
> >>
> >> technically this won't be an issue as 20 > 4 and out upgrade scheme
> >> supports a step like that.
> >>
> >> any thoughts?
> >>



-- 
Daan

[VOTE] Apache CloudStack 4.19.0.0 RC3

[Abhishek Kumar]

Hi All,

I've created a 4.19.0.0 release (RC3), with the following artifacts up for
a vote:

Git Branch and Commit SH:
https://github.com/apache/cloudstack/tree/4.19.0.0-RC20240122T1028
Commit: 43066e4020cf48108e6d0bb125be7d24fc2d609f

Source release (checksums and signatures are available at the same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.19.0.0/

PGP release keys (signed using 65518106473A09D7AF26B384A70BD2EAA74E2866):
https://dist.apache.org/repos/dist/release/cloudstack/KEYS

For testing purposes, I have uploaded the different distro packages to:
http://download.cloudstack.org/testing/4.19.0.0-RC3/

Since 4.16 the system VM template registration is no longer mandatory
before upgrading, however, it can be downloaded from here if needed:
https://download.cloudstack.org/systemvm/4.19/

The vote will be open for 72 hours.

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)

Regards,
Abhishek

Re: [PROPOSAL] version naming : drop the 4.

[Nux]

LGTM!

On 2024-01-19 19:19, João Jandre Paraquetti wrote:

Hi all,

I agree that our current versioning schema doesn't make much sense, as 
"minors" introduce pretty big features; even backward incompatibilities 
are introduced in minor versions sometimes.


As the current plan is to have 4.20 by June, I think we should stick to 
it and still have the next "minor", and make it the last minor version 
of the major 4. After so much time in the same major version, we should 
plan something relevant before changing it, and June 2024 is a bit of a 
tight schedule for that.


I think that we should plan to move to version 5.0.0, we could set the 
release date to the end of 2024 or the start (January) of 2025; by 
doing that, we have plenty of time for planning and developing amazing 
features for version 5, while also preparing a cleanup of our current 
APIs. For instance, we are working on the following major developments: 
KVM differential snapshots/backups without needing extra software; 
theme management system (white label portal for ACS); native 
snapshot/backup for VMware (without needing Veeam) to make it similar 
to what ACS does with XenServer and KVM; Operators backup (which are 
different from end-user backups); and many other items.


What do you guys think?

Best regards,
João Jandre.

On 1/19/24 10:39, Daan Hoogland wrote:

devs, PMC,

as we are closing in on 4.19 I want to propose that we drop the 4. in
our versioning scheme. We've been discussing 5 but no real initiatives
have been taken. Nowadays big features go into our "minor"
dot-releases. In my opinion this warrants promoting those version to
the status of major and dropping the 4..

technically this won't be an issue as 20 > 4 and out upgrade scheme
supports a step like that.

any thoughts?

Re: new website design

[Nux]

+1 - do it.

On 2024-01-19 14:50, Daan Hoogland wrote:

As we get no major issues on it and we already voted to have this
design applied, is it alright to deploy this in the coming weeks?

On Wed, Jan 17, 2024 at 8:31 PM Daan Hoogland  
wrote:


devs and users,

back in august we had a small discussion about a new website design,
led by Ivet [1]. In the meanwhile Rohit had investigated using
docusaurus as a publishing mechanism for the site. After the last few
weeks I have been working on integrating the two. The result so far
can be viewed on the staging site [2]

Please all have a look and give me any feedback you may have, so we
can move this forward.

[1] https://lists.apache.org/thread/fopjc3r4hjkp9nbkj9xzoxv406rowkso
[2] https://cloudstack.staged.apache.org/

--
Daan