Re: LTS release or not

[Daan Hoogland]

Rene, I would advice to support 4.7 as LTS. It adheres to the new
development/release process unlike 4.5 and any bugfixes there can
automatically be merged forward to newer releases to reduce the chance of
regression.

I am in favour of the general concept.

On Sun, Jan 10, 2016 at 12:12 AM, Rubens Malheiro  wrote:

> +1
> Em 9 de jan de 2016 8:55 PM, "Rene Moser"  escreveu:
>
> > Hi
> >
> > I recently started a discussion about the current release process. You
> > may have noticed that CloudStack had a few releases in the last 2 months.
> >
> > My concerns were that many CloudStack users will be confused about these
> > many releases (which one to take? Are fixes backported? How long will it
> > receive fixes? Do I have to upgrade?).
> >
> > We leads me to the question: Does CloudStack need an LTS version? To me
> > it would make sense in many ways:
> >
> > * Users in restrictive cloud environments can choose LTS for getting
> > backwards compatible bug fixes only.
> >
> > * Users in agile cloud environments can choose latest stable and getting
> > new features fast.
> >
> > * CloudStack developers must only maintain the latest stable (mainline)
> > and the LTS version.
> >
> > * CloudStack developers and mainline users can accept, that mainline may
> > break environments but will receive fast forward fixes.
> >
> > To me this would make a lot of sense. I am actually thinking about
> > maintaining 4.5 as a LTS by myself.
> >
> > Any thoughts? +1/-1?
> >
> > Regards
> > René
> >
>



-- 
Daan

Re: Cloud-init works

[Pierre-Luc Dion]

S.Tolga,

Did you tried latest version of cloud-init  ~0.7.7? They added fixes that
was solving password set and reset for root or custom user, fixed  ssh_key
and  user-data.
here a presentation [1] I did few months ago about cloud-init + cloudstack
if it can help...

PL

[1]
http://events.linuxfoundation.org/sites/events/files/slides/cloud-init_cloudstackdays-austin_0.4.pdf

On Thu, Dec 31, 2015 at 9:53 AM, Naresh Kumar  wrote:

> Sorry for the confusion, I actually posted/added problem I’m facing.
>
> But now I have mange to get this working, I tried again with CentOS7 and
> its working.
>
> Answer to your question is that you can use “Reset password” option on VM
> quick view or VM details page, incase you forgot the root password and want
> to reset it.
>
>
> Naresh Kumar
> bishno...@gmail.com
>
>
>
>
> > On 31-Dec-2015, at 6:19 PM, Semih Tolga DEMİR 
> wrote:
> >
> > Thanks Naresh for your answer,
> >
> > But i want to learn how can use cloud-init to set again when i forget or
> > reset root password, and this question is not only for CentOS 5.5
> template,
> > I want general solution for all OS. If i can not use again cloud-init
> which
> > alternative solution recommend
> >
> > Thanks,
> > S.Tolga Demir
> >
> > 2015-12-31 12:36 GMT+02:00 Naresh Kumar :
> >
> >> Hi,
> >>
> >>
> >> I tired it as well on in-built CentOS 5.5 template(KVM):
> >>
> >> 1. ssh key works
> >> 2. password does’t work, default password “password” is working.
> >> 3. user-data post startup is not working . getting "ImportError: No
> module
> >> named DataSourceCloudStack” error.
> >>
> >> Thanks,
> >> Naresh Kumar
> >> bishno...@gmail.com
> >>
> >>
> >>> On 31-Dec-2015, at 2:41 PM, Semih Tolga DEMİR <
> semihtolgade...@gmail.com>
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I've configured cloudstack and installed cloud-init for my vm to set
> >>> something such as ssh-key, root password etc. But i've one question
> about
> >>> cloud-init works. Cloud-init works one time in default, so, if i forget
> >> my
> >>> root password how i will set new password with cloud-init?
> >>>
> >>> Best Regards,
> >>> S.Tolga Demir
> >>
> >>
>
>

Re: LTS release or not

[Rene Moser]

Daan

Have not yet decided which version, but fixes will be backported into
LTS not the other way around.

But I see what you mean. The code base may have much diverted before 4.7
right?

It is not really a problem. It only means more work (argh...). Sooner or
later this will happen for every release we choose.

I would like to use 4.5 for several reasons, one obvious is, that we
know that it is in production on several clouds, including us.


On 01/10/2016 12:40 PM, Daan Hoogland wrote:
> Rene, I would advice to support 4.7 as LTS. It adheres to the new
> development/release process unlike 4.5 and any bugfixes there can
> automatically be merged forward to newer releases to reduce the chance of
> regression.
> 
> I am in favour of the general concept.
> 
> On Sun, Jan 10, 2016 at 12:12 AM, Rubens Malheiro > wrote:
> 
>> +1
>> Em 9 de jan de 2016 8:55 PM, "Rene Moser"  escreveu:
>>
>>> Hi
>>>
>>> I recently started a discussion about the current release process. You
>>> may have noticed that CloudStack had a few releases in the last 2 months.
>>>
>>> My concerns were that many CloudStack users will be confused about these
>>> many releases (which one to take? Are fixes backported? How long will it
>>> receive fixes? Do I have to upgrade?).
>>>
>>> We leads me to the question: Does CloudStack need an LTS version? To me
>>> it would make sense in many ways:
>>>
>>> * Users in restrictive cloud environments can choose LTS for getting
>>> backwards compatible bug fixes only.
>>>
>>> * Users in agile cloud environments can choose latest stable and getting
>>> new features fast.
>>>
>>> * CloudStack developers must only maintain the latest stable (mainline)
>>> and the LTS version.
>>>
>>> * CloudStack developers and mainline users can accept, that mainline may
>>> break environments but will receive fast forward fixes.
>>>
>>> To me this would make a lot of sense. I am actually thinking about
>>> maintaining 4.5 as a LTS by myself.
>>>
>>> Any thoughts? +1/-1?
>>>
>>> Regards
>>> René
>>>
>>
> 
> 
> 

Re: LTS release or not

[Rene Moser]

On 01/10/2016 10:07 PM, Wido den Hollander wrote:
> Ok, understood. However, it will be up to users on their own to pick
> this LTS maintainment up.

It would be up to the devs making fixes small (so no squashing for
fixes) and notify the one maintaining the LTS version if they feel the
fix is that important to be in LTS. Wouldn't be that hard work.

> That means testing, releasing, testing, backporting, testing, releasing.
> 
> Certain users will focus on getting new releases out and others on doing
> LTS work.

The process of backporting is not defined yet, but I would like to adopt
the Linux kernel long term policy:

* Fix must be already in mainline
* Fix must be important.
* Fix must be obvious and small.

Which means, we only fix stuff in LTS which is already fixed in
mainline. Important stuff only.

We can even define, the mainline version must be released with the fix,
before getting into LTS. So even the LTS releases would be behind the
mainline releases and the fix has been tested in mainline.