7:17 a.m.
with 3.3.0 coming soon, one of the questions I heard is "what about
3.3.1" considering the number of patches fox bugs that went into master
branch since since we branched to stabilize 3.3.0.
i.e., most of the work in master branch has been focused on bug fixes)
so my suggestion is for 3.3.1 that we rebase from master, then move to
backporting patches to that branch for the rest of 3.3 time frame.
while this poses a small risk, i believe its the best course forward to
making ovirt 3.3 a more robust and stable version going forward.
this is mostly about ovirt-engine, and probably vdsm. for the other
projects, its up to the maintainer, based on risk/benefit.
thoughts?
Thanks,
Itamar
8:19 a.m.
On 09/09/2013 08:17 AM, Itamar Heim wrote:
with 3.3.0 coming soon, one of the questions I heard is "what
about
3.3.1" considering the number of patches fox bugs that went into master
branch since since we branched to stabilize 3.3.0.
i.e., most of the work in master branch has been focused on bug fixes)
so my suggestion is for 3.3.1 that we rebase from master, then move to
backporting patches to that branch for the rest of 3.3 time frame.
while this poses a small risk, i believe its the best course forward to
making ovirt 3.3 a more robust and stable version going forward.
this is mostly about ovirt-engine, and probably vdsm. for the other
projects, its up to the maintainer, based on risk/benefit.
I have no objections as long as we're not taking features into the 3.3.1
release and we're not changing the package set. We had an issue with
one of the 3.2.x updates where we pulled a change in vdsm that removed
the vdsm-gluster package. As long as we're making every effort to avoid
features and avoid packaging changes, then I'm happy.
Mike
thoughts?
Thanks,
Itamar
_______________________________________________
Arch mailing list
Arch(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/arch
8:28 a.m.
On 09/09/2013 04:19 PM, Mike Burns wrote:
On 09/09/2013 08:17 AM, Itamar Heim wrote:
> with 3.3.0 coming soon, one of the questions I heard is "what about
> 3.3.1" considering the number of patches fox bugs that went into master
> branch since since we branched to stabilize 3.3.0.
> i.e., most of the work in master branch has been focused on bug fixes)
>
> so my suggestion is for 3.3.1 that we rebase from master, then move to
> backporting patches to that branch for the rest of 3.3 time frame.
>
> while this poses a small risk, i believe its the best course forward to
> making ovirt 3.3 a more robust and stable version going forward.
>
> this is mostly about ovirt-engine, and probably vdsm. for the other
> projects, its up to the maintainer, based on risk/benefit.
>
I have no objections as long as we're not taking features into the 3.3.1
release and we're not changing the package set. We had an issue with
one of the 3.2.x updates where we pulled a change in vdsm that removed
the vdsm-gluster package. As long as we're making every effort to avoid
features and avoid packaging changes, then I'm happy.
i think there is a feature or two, but i think the version would still
be way better off with this, considering the ratio of patches that went
into it.
I do expect us to do a bit more testing on it than if we didn't rebase,
but i think its worth it.
(as a side note, i also think it will be worth while to release
hosted-engine in async to beta testing / release).
Mike
> thoughts?
>
> Thanks,
> Itamar
> _______________________________________________
> Arch mailing list
> Arch(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
8:31 a.m.
On 09/09/2013 09:28 AM, Itamar Heim wrote:
On 09/09/2013 04:19 PM, Mike Burns wrote:
> On 09/09/2013 08:17 AM, Itamar Heim wrote:
>> with 3.3.0 coming soon, one of the questions I heard is "what about
>> 3.3.1" considering the number of patches fox bugs that went into master
>> branch since since we branched to stabilize 3.3.0.
>> i.e., most of the work in master branch has been focused on bug fixes)
>>
>> so my suggestion is for 3.3.1 that we rebase from master, then move to
>> backporting patches to that branch for the rest of 3.3 time frame.
>>
>> while this poses a small risk, i believe its the best course forward to
>> making ovirt 3.3 a more robust and stable version going forward.
>>
>> this is mostly about ovirt-engine, and probably vdsm. for the other
>> projects, its up to the maintainer, based on risk/benefit.
>>
>
> I have no objections as long as we're not taking features into the 3.3.1
> release and we're not changing the package set. We had an issue with
> one of the 3.2.x updates where we pulled a change in vdsm that removed
> the vdsm-gluster package. As long as we're making every effort to avoid
> features and avoid packaging changes, then I'm happy.
i think there is a feature or two, but i think the version would still
be way better off with this, considering the ratio of patches that went
into it.
Ok, can we at least make sure we call them out so we can list them in
announcement email?
I do expect us to do a bit more testing on it than if we didn't rebase,
but i think its worth it.
(as a side note, i also think it will be worth while to release
hosted-engine in async to beta testing / release).
Yes, hosted-engine is something we had discussed as an async feature and
there were no objections to it going async.
Mike
>
> Mike
>
>> thoughts?
>>
>> Thanks,
>> Itamar
>> _______________________________________________
>> Arch mailing list
>> Arch(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>
_______________________________________________
Infra mailing list
Infra(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
8:34 a.m.
On 09/09/2013 04:31 PM, Mike Burns wrote:
On 09/09/2013 09:28 AM, Itamar Heim wrote:
> On 09/09/2013 04:19 PM, Mike Burns wrote:
>> On 09/09/2013 08:17 AM, Itamar Heim wrote:
>>> with 3.3.0 coming soon, one of the questions I heard is "what about
>>> 3.3.1" considering the number of patches fox bugs that went into master
>>> branch since since we branched to stabilize 3.3.0.
>>> i.e., most of the work in master branch has been focused on bug fixes)
>>>
>>> so my suggestion is for 3.3.1 that we rebase from master, then move to
>>> backporting patches to that branch for the rest of 3.3 time frame.
>>>
>>> while this poses a small risk, i believe its the best course forward to
>>> making ovirt 3.3 a more robust and stable version going forward.
>>>
>>> this is mostly about ovirt-engine, and probably vdsm. for the other
>>> projects, its up to the maintainer, based on risk/benefit.
>>>
>>
>> I have no objections as long as we're not taking features into the 3.3.1
>> release and we're not changing the package set. We had an issue with
>> one of the 3.2.x updates where we pulled a change in vdsm that removed
>> the vdsm-gluster package. As long as we're making every effort to avoid
>> features and avoid packaging changes, then I'm happy.
>
> i think there is a feature or two, but i think the version would still
> be way better off with this, considering the ratio of patches that went
> into it.
Ok, can we at least make sure we call them out so we can list them in
announcement email?
goes without saying.
I'm thinking we should create that branch asap (say, post wednesday
ovirt meeting), to be able to start testing it, to be able to release
3.3.1 in a few weeks.
probably with a mini test day around install flows and upgrade from 3.2
and 3.3.0.
>
> I do expect us to do a bit more testing on it than if we didn't rebase,
> but i think its worth it.
>
> (as a side note, i also think it will be worth while to release
> hosted-engine in async to beta testing / release).
Yes, hosted-engine is something we had discussed as an async feature and
there were no objections to it going async.
Mike
>
>
>>
>> Mike
>>
>>> thoughts?
>>>
>>> Thanks,
>>> Itamar
>>> _______________________________________________
>>> Arch mailing list
>>> Arch(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>
>
> _______________________________________________
> Infra mailing list
> Infra(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
6:04 p.m.
On Mon, Sep 09, 2013 at 03:17:35PM +0300, Itamar Heim wrote:
with 3.3.0 coming soon, one of the questions I heard is "what
about
3.3.1" considering the number of patches fox bugs that went into
master branch since since we branched to stabilize 3.3.0.
i.e., most of the work in master branch has been focused on bug fixes)
so my suggestion is for 3.3.1 that we rebase from master, then move
to backporting patches to that branch for the rest of 3.3 time
frame.
while this poses a small risk, i believe its the best course forward
to making ovirt 3.3 a more robust and stable version going forward.
this is mostly about ovirt-engine, and probably vdsm. for the other
projects, its up to the maintainer, based on risk/benefit.
To make this happen for Vdsm, we need to slow things down a bit,
stabilize what we have, and test it out.
Most of our work since ovirt-3.3 was bug fixing (23 patches), but some
of the 101 patches we've got are related to refactoring (19), cleanups
(27), test improvements (21), behind-the-scenes features (6), and
visible features (5).
Refactoring included Zhou Zheng Sheng's Ubuntu-readiness patches, which
may still incur surprises to sysV/systemd/upstart service framework, and
changes to how network configurators are to be used.
Behind-the-scenes features include speedup to block-based storage:
- One shot teardown.
- Avoid Img and Vol produces in fileVolume.getV*Size
- Make lvm.listPVNames() be based on vgs information.
- One shot prepare.
- Introduce lvm short filters.
Visible features are few, and only one of them:
- clientIF: automatically unpause vms in EIO when SD becomes active
carries some kind of a risk to a timely release. The rest of them are:
- Support for multiple heads for Qxl display device
- Add support for direct setting of cpu_shares when creating a VM
- Introducing hidden_vlans configurable.
- macspoof hooks: new hook script to enable macspoof filtering per vnic.
I think we can release vdsm-4.13.0 within a week if we put a hold on new
features and big changes, and put enough effort into testing the
mostly-changed areas:
- service framework
- VM lifecycle over block storage (including auto unpause)
- network configuration
Then, we could release vdsm-4.13.z without risking the stability of
ovirt-3.3.1.
Let's do it!
Dan.
3871
days inactive
3880
days old
5 comments
3 participants
participants (3)
-
Dan Kenigsberg -
Itamar Heim -
Mike Burns