8:41 p.m.
This vote is to accept into oVirt the memory overcommit manager (mom)
project either to be used as a dependency in VDSM or as a daemon
alongside VDSM. This detail will be worked during integration.
If the project is accepted and given it is our first community submitted
project to be voted we will create an infrastructure setup list which I
will record. This can then be used to make it easier for the next
project joining.
Please vote -1, 0, +1 whether you would like to include this project
into oVirt. I'll leave the vote open at least 72 hours.
regards
Carl.
8:47 p.m.
I'm non-voting - but STRONGLY recommend.
Aic
----- Original Message -----
From: "Carl Trieloff" <cctrieloff(a)redhat.com>
To: board(a)ovirt.org
Sent: Tuesday, September 27, 2011 1:41:03 PM
Subject: [VOTE] Inclusion of memory overcommit manager
This vote is to accept into oVirt the memory overcommit manager (mom)
project either to be used as a dependency in VDSM or as a daemon
alongside VDSM. This detail will be worked during integration.
If the project is accepted and given it is our first community
submitted
project to be voted we will create an infrastructure setup list which
I
will record. This can then be used to make it easier for the next
project joining.
Please vote -1, 0, +1 whether you would like to include this project
into oVirt. I'll leave the vote open at least 72 hours.
regards
Carl.
_______________________________________________
Board mailing list
Board(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/board
9 p.m.
Andy, you can +1.
I'll tally all the votes binding and also list unbinding.
Carl.
On 09/27/2011 01:47 PM, Andrew Cathrow wrote:
I'm non-voting - but STRONGLY recommend.
Aic
----- Original Message -----
> From: "Carl Trieloff" <cctrieloff(a)redhat.com>
> To: board(a)ovirt.org
> Sent: Tuesday, September 27, 2011 1:41:03 PM
> Subject: [VOTE] Inclusion of memory overcommit manager
>
>
> This vote is to accept into oVirt the memory overcommit manager (mom)
> project either to be used as a dependency in VDSM or as a daemon
> alongside VDSM. This detail will be worked during integration.
>
> If the project is accepted and given it is our first community
> submitted
> project to be voted we will create an infrastructure setup list which
> I
> will record. This can then be used to make it easier for the next
> project joining.
>
> Please vote -1, 0, +1 whether you would like to include this project
> into oVirt. I'll leave the vote open at least 72 hours.
>
> regards
> Carl.
> _______________________________________________
> Board mailing list
> Board(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/board
>
9:05 p.m.
+1 -- I am excited to see MOM working together with the rest of the oVirt
components!
On Tue, Sep 27, 2011 at 01:41:03PM -0400, Carl Trieloff wrote:
This vote is to accept into oVirt the memory overcommit manager (mom)
project either to be used as a dependency in VDSM or as a daemon
alongside VDSM. This detail will be worked during integration.
If the project is accepted and given it is our first community submitted
project to be voted we will create an infrastructure setup list which I
will record. This can then be used to make it easier for the next
project joining.
Please vote -1, 0, +1 whether you would like to include this project
into oVirt. I'll leave the vote open at least 72 hours.
regards
Carl.
_______________________________________________
Board mailing list
Board(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/board
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
9:31 p.m.
On 9/27/11 1:41 PM, "Carl Trieloff" <cctrieloff(a)redhat.com> wrote:
This vote is to accept into oVirt the memory overcommit manager (mom)
project either to be used as a dependency in VDSM or as a daemon
alongside VDSM. This detail will be worked during integration.
If the project is accepted and given it is our first community submitted
project to be voted we will create an infrastructure setup list which I
will record. This can then be used to make it easier for the next
project joining.
Please vote -1, 0, +1 whether you would like to include this project
into oVirt. I'll leave the vote open at least 72 hours.
regards
Carl.
_______________________________________________
Board mailing list
Board(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/board
+1
Jon Benedict
Technical Marketing Engineer
Virtualization & Cloud
Blog http://captainkvm.com | Twitter @CaptainKVM
NetApp
919.476.5093 Direct
919.757.7789 Mobile
Jon.Benedict(a)netapp.com
www.netapp.com
9:34 p.m.
-0.9
I don't think we should rush into adding projects. I think there's an open
question of whether MOM should be folded into VDSM or whether it should be stand
alone.
I'd like to see a roadmap for either integrating into VDSM or a clear (agreed
upon) description of what components own what functionality.
My concern is that having MOM be an oVirt project would discourage attempts to
merge MOM into VDSM.
N.B. my vote is non-binding.
Regards,
Anthony Liguori
On 09/27/2011 12:41 PM, Carl Trieloff wrote:
This vote is to accept into oVirt the memory overcommit manager (mom)
project either to be used as a dependency in VDSM or as a daemon
alongside VDSM. This detail will be worked during integration.
If the project is accepted and given it is our first community submitted
project to be voted we will create an infrastructure setup list which I
will record. This can then be used to make it easier for the next
project joining.
Please vote -1, 0, +1 whether you would like to include this project
into oVirt. I'll leave the vote open at least 72 hours.
regards
Carl.
_______________________________________________
Board mailing list
Board(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/board
9:48 p.m.
On 09/27/2011 02:34 PM, Anthony Liguori wrote:
-0.9
I don't think we should rush into adding projects. I think there's an
open question of whether MOM should be folded into VDSM or whether it
should be stand alone.
I'd like to see a roadmap for either integrating into VDSM or a clear
(agreed upon) description of what components own what functionality.
My concern is that having MOM be an oVirt project would discourage
attempts to merge MOM into VDSM.
-1
I tend to agree here. I think adding the functionality from MOM into
VDSM makes a lot of sense, but if we go through the process of adding a
formal sub-project to oVirt only to have the functionality merged into
VDSM, then setting up the separate infrastructure (mailing lists,
maintainers, etc) seems like a lot of overhead that would need to be undone.
I suppose the crux of it is: If MOM is applicable only to being
integrated with VDSM, then let's do that and the MOM developers can
become part of the VDSM team. If it it's useful outside of the context
of VDSM, where else might it be used? Let's figure that out first
before we make a decision here.
So I vote -1 for the time being, but am open to further debate on this
topic.
10:13 p.m.
On Tue, Sep 27, 2011 at 02:48:42PM -0400, Perry Myers wrote:
On 09/27/2011 02:34 PM, Anthony Liguori wrote:
> -0.9
>
> I don't think we should rush into adding projects. I think there's an
> open question of whether MOM should be folded into VDSM or whether it
> should be stand alone.
>
> I'd like to see a roadmap for either integrating into VDSM or a clear
> (agreed upon) description of what components own what functionality.
>
> My concern is that having MOM be an oVirt project would discourage
> attempts to merge MOM into VDSM.
-1
I tend to agree here. I think adding the functionality from MOM into
VDSM makes a lot of sense, but if we go through the process of adding a
formal sub-project to oVirt only to have the functionality merged into
VDSM, then setting up the separate infrastructure (mailing lists,
maintainers, etc) seems like a lot of overhead that would need to be undone.
I suppose the crux of it is: If MOM is applicable only to being
integrated with VDSM, then let's do that and the MOM developers can
become part of the VDSM team. If it it's useful outside of the context
of VDSM, where else might it be used? Let's figure that out first
before we make a decision here.
I have been approached with questions by several people who are using MOM in
their current environments as a simple auto-ballooning/KSM daemon. I am not
certain that these people are all ready to adopt oVirt tomorrow and would be
content to continue using MOM as a standalone tool. On another thread I also
posed the idea that MOM could be deployed infrastructure that will not be
running VDSM (eg. a NFS server). At this time, it seems to make the most sense
to keep the two projects separate and begin to discuss VDSM's dynamic tuning
requirements.
So I vote -1 for the time being, but am open to further debate on
this
topic.
_______________________________________________
Board mailing list
Board(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/board
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
10:04 p.m.
On 09/27/2011 02:34 PM, Anthony Liguori wrote:
-0.9
I don't think we should rush into adding projects. I think there's an
open question of whether MOM should be folded into VDSM or whether it
should be stand alone.
I'd like to see a roadmap for either integrating into VDSM or a clear
(agreed upon) description of what components own what functionality.
My concern is that having MOM be an oVirt project would discourage
attempts to merge MOM into VDSM.
N.B. my vote is non-binding.
Regards,
Anthony Liguori
On 09/27/2011 12:41 PM, Carl Trieloff wrote:
>
> This vote is to accept into oVirt the memory overcommit manager (mom)
> project either to be used as a dependency in VDSM or as a daemon
> alongside VDSM. This detail will be worked during integration.
>
> If the project is accepted and given it is our first community submitted
> project to be voted we will create an infrastructure setup list which I
> will record. This can then be used to make it easier for the next
> project joining.
>
> Please vote -1, 0, +1 whether you would like to include this project
> into oVirt. I'll leave the vote open at least 72 hours.
It sounds like the next step is for the mom and vdsm project to have a
discussion and come back to the list. The discussion should clarify.
a.) mom is an additional daemon that wdsm would use
b.) mom is a library that vdsm would use
c.) mom gets included into vdsm.
Either (a or b) would mean we create another project. (c) would mean we
deal with it as a code contribution to the vdsm project.
Anthony, Perry, I take it your concern is we don't want to setup a
project if technically we include the mom as a code submission - option
(c). I had assumed a or b, your concern as I read it is to rule c
in/out before completed this vote.
regards
Carl.
10:19 p.m.
On 09/27/2011 02:04 PM, Carl Trieloff wrote:
On 09/27/2011 02:34 PM, Anthony Liguori wrote:
> -0.9
>
> I don't think we should rush into adding projects. I think there's an
> open question of whether MOM should be folded into VDSM or whether it
> should be stand alone.
>
> I'd like to see a roadmap for either integrating into VDSM or a clear
> (agreed upon) description of what components own what functionality.
>
> My concern is that having MOM be an oVirt project would discourage
> attempts to merge MOM into VDSM.
>
> N.B. my vote is non-binding.
>
> Regards,
>
> Anthony Liguori
>
>
> On 09/27/2011 12:41 PM, Carl Trieloff wrote:
>>
>> This vote is to accept into oVirt the memory overcommit manager (mom)
>> project either to be used as a dependency in VDSM or as a daemon
>> alongside VDSM. This detail will be worked during integration.
>>
>> If the project is accepted and given it is our first community submitted
>> project to be voted we will create an infrastructure setup list which I
>> will record. This can then be used to make it easier for the next
>> project joining.
>>
>> Please vote -1, 0, +1 whether you would like to include this project
>> into oVirt. I'll leave the vote open at least 72 hours.
It sounds like the next step is for the mom and vdsm project to have a
discussion and come back to the list. The discussion should clarify.
a.) mom is an additional daemon that wdsm would use
b.) mom is a library that vdsm would use
c.) mom gets included into vdsm.
Either (a or b) would mean we create another project. (c) would mean we
deal with it as a code contribution to the vdsm project.
Anthony, Perry, I take it your concern is we don't want to setup a
project if technically we include the mom as a code submission - option
(c). I had assumed a or b, your concern as I read it is to rule c
in/out before completed this vote.
Correct.
Regards,
Anthony Liguori
11:29 p.m.
On 09/27/2011 03:19 PM, Anthony Liguori wrote:
On 09/27/2011 02:04 PM, Carl Trieloff wrote:
> On 09/27/2011 02:34 PM, Anthony Liguori wrote:
>> -0.9
>>
>> I don't think we should rush into adding projects. I think there's an
>> open question of whether MOM should be folded into VDSM or whether it
>> should be stand alone.
>>
>> I'd like to see a roadmap for either integrating into VDSM or a clear
>> (agreed upon) description of what components own what functionality.
>>
>> My concern is that having MOM be an oVirt project would discourage
>> attempts to merge MOM into VDSM.
>>
>> N.B. my vote is non-binding.
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>
>> On 09/27/2011 12:41 PM, Carl Trieloff wrote:
>>>
>>> This vote is to accept into oVirt the memory overcommit manager (mom)
>>> project either to be used as a dependency in VDSM or as a daemon
>>> alongside VDSM. This detail will be worked during integration.
>>>
>>> If the project is accepted and given it is our first community
>>> submitted
>>> project to be voted we will create an infrastructure setup list
>>> which I
>>> will record. This can then be used to make it easier for the next
>>> project joining.
>>>
>>> Please vote -1, 0, +1 whether you would like to include this project
>>> into oVirt. I'll leave the vote open at least 72 hours.
>
> It sounds like the next step is for the mom and vdsm project to have a
> discussion and come back to the list. The discussion should clarify.
>
> a.) mom is an additional daemon that wdsm would use
> b.) mom is a library that vdsm would use
> c.) mom gets included into vdsm.
>
> Either (a or b) would mean we create another project. (c) would mean we
> deal with it as a code contribution to the vdsm project.
>
> Anthony, Perry, I take it your concern is we don't want to setup a
> project if technically we include the mom as a code submission - option
> (c). I had assumed a or b, your concern as I read it is to rule c
> in/out before completed this vote.
Here is my +1,
Here is the IRC log from our IRC channel discussing the issue with Perry.
(04:19:55 PM) cctrieloff: pmyers: ping
(04:19:59 PM) pmyers: pong
(04:20:16 PM) cctrieloff: wanted to kick around the comments on the vote
a bit
(04:20:57 PM) cctrieloff: Based on Adams comments, as mom is also used
by other projects, then those users would need to move to vdsm if c was
executed. As mom already has other users I believe it may be more
pragmatic to get results using (a or b) and then we can always combine
the projects if all can be served from vdsm and if that simplifies things
(04:21:01 PM) cctrieloff: thoughts?
(04:21:11 PM) pmyers: well
(04:21:18 PM) pmyers: if it has other users outside of the oVirt use case
(04:21:25 PM) pmyers: then should it be in oVirt at all? :)
(04:21:32 PM) pmyers: maybe yes, but I just wanted to pose the question
(04:21:32 PM) cctrieloff: why not?
(04:21:53 PM) cctrieloff: if it focuses to serve oVirt then I would say yes.
(04:22:02 PM) pmyers: well things like libvirt and matahari don't make
sense inside of oVirt community because they have too many use cases
outside of oVirt
(04:22:06 PM) cctrieloff: it could just be a lib that ovirt vdsm uses
(04:22:07 PM) pmyers: at least that was what we discussed
(04:22:27 PM) cctrieloff: that can be debated either way
(04:22:31 PM) pmyers: yep
(04:22:36 PM) pmyers: and that's sort of what I'm debating here
(04:22:41 PM) *djasa [/~djasa(a)ip-62-245-123-239.net.upcbroadband.cz/]
entered the room.*
(04:22:44 PM) pmyers: i'm not violently opposed to MOM being a full project
(04:22:57 PM) pmyers: just wanted to raise what I saw as a possible issue
(04:22:57 PM) cctrieloff: point is if someone wants to be in the
community, and they add value and integrate, then I believe we should
say yes
(04:23:01 PM) pmyers: ok
(04:23:11 PM) pmyers: so you would be open to matahari then? :)
(04:23:13 PM) cctrieloff: I agree with the question
(04:23:18 PM) cctrieloff: yes, I would
(04:23:22 PM) pmyers: k
(04:23:29 PM) cctrieloff: I think it would help matahari with visibility etc
(04:23:30 PM) pmyers: we can circle back round to that question later
(04:23:31 PM) pmyers: ack
(04:23:38 PM) pmyers: then no objection to MOM
(04:23:53 PM) pmyers: my only real concern was overhead of setting up
lists and other infra
(04:23:57 PM) pmyers: if in the end it would be integrated
(04:24:02 PM) pmyers: if it looks like it will stay standalone
(04:24:05 PM) pmyers: then those concerns are moot
(04:24:06 PM) cctrieloff: ack.
(04:24:41 PM) cctrieloff: personally, my guess is that it might want
it's API to be integrated in vdsm and if the users come across to vdsm
then they should integrate
(04:24:55 PM) pmyers: yeo
(04:24:59 PM) pmyers: yep that is
(04:25:10 PM) cctrieloff: to me the question is does the community
figure this out over time, or do we make them figure it out upfront.
(04:25:19 PM) pmyers: heh
(04:25:22 PM) pmyers: over time :)
(04:25:30 PM) pmyers: can't make a community do anything by fiat
(04:25:35 PM) cctrieloff: ack
(04:25:57 PM) cctrieloff: ok, based on this interaction, I'm going to
vote +1.
(04:26:17 PM) cctrieloff: do you mind if I post the IRC log to the list?
(04:26:36 PM) pmyers: nope, go ahead
(04:26:39 PM) cctrieloff: thx
4:37 a.m.
board-bounces(a)ovirt.org wrote on 09/28/2011 04:29:48 AM:
(04:19:55 PM) cctrieloff: pmyers: ping
(04:19:59 PM) pmyers: pong
(04:20:16 PM) cctrieloff: wanted to kick around the comments on the vote
a bit
(04:20:57 PM) cctrieloff: Based on Adams comments, as mom is also
used by other projects, then those users would need to move to vdsm
if c was executed. As mom already has other users I believe it may
be more pragmatic to get results using (a or b) and then we can
always combine the projects if all can be served from vdsm and if
that simplifies things
(04:21:01 PM) cctrieloff: thoughts?
(04:21:11 PM) pmyers: well
(04:21:18 PM) pmyers: if it has other users outside of the oVirt use case
(04:21:25 PM) pmyers: then should it be in oVirt at all? :)
(04:21:32 PM) pmyers: maybe yes, but I just wanted to pose the question
(04:21:32 PM) cctrieloff: why not?
(04:21:53 PM) cctrieloff: if it focuses to serve oVirt then I would say
yes.
(04:22:02 PM) pmyers: well things like libvirt and matahari
don't
make sense inside of oVirt community because they have too many use
cases outside of oVirt
(04:22:06 PM) cctrieloff: it could just be a lib that ovirt vdsm uses
(04:22:07 PM) pmyers: at least that was what we discussed
(04:22:27 PM) cctrieloff: that can be debated either way
(04:22:31 PM) pmyers: yep
(04:22:36 PM) pmyers: and that's sort of what I'm debating here
(04:22:41 PM) djasa [~djasa(a)ip-62-245-123-239.net.upcbroadband.cz]
entered the room.
(04:22:44 PM) pmyers: i'm not violently opposed to MOM being a full
project
(04:22:57 PM) pmyers: just wanted to raise what I saw as a possible
issue
(04:22:57 PM) cctrieloff: point is if someone wants to be in the
community, and they add value and integrate, then I believe we should say
yes
(04:23:01 PM) pmyers: ok
(04:23:11 PM) pmyers: so you would be open to matahari then? :)
(04:23:13 PM) cctrieloff: I agree with the question
(04:23:18 PM) cctrieloff: yes, I would
(04:23:22 PM) pmyers: k
(04:23:29 PM) cctrieloff: I think it would help matahari with visibility
etc
(04:23:30 PM) pmyers: we can circle back round to that question
later
(04:23:31 PM) pmyers: ack
(04:23:38 PM) pmyers: then no objection to MOM
(04:23:53 PM) pmyers: my only real concern was overhead of setting
up lists and other infra
(04:23:57 PM) pmyers: if in the end it would be integrated
(04:24:02 PM) pmyers: if it looks like it will stay standalone
(04:24:05 PM) pmyers: then those concerns are moot
(04:24:06 PM) cctrieloff: ack.
(04:24:41 PM) cctrieloff: personally, my guess is that it might want
it's API to be integrated in vdsm and if the users come across to
vdsm then they should integrate
(04:24:55 PM) pmyers: yeo
(04:24:59 PM) pmyers: yep that is
(04:25:10 PM) cctrieloff: to me the question is does the community
figure this out over time, or do we make them figure it out upfront.
(04:25:19 PM) pmyers: heh
(04:25:22 PM) pmyers: over time :)
(04:25:30 PM) pmyers: can't make a community do anything by fiat
(04:25:35 PM) cctrieloff: ack
(04:25:57 PM) cctrieloff: ok, based on this interaction, I'm going to
vote +1.
(04:26:17 PM) cctrieloff: do you mind if I post the IRC log to the
list?
(04:26:36 PM) pmyers: nope, go ahead
(04:26:39 PM) cctrieloff: thx
I think I'd err on adding a sub-project even if later on closer examination
it was found to be completely consumed..
re: Matahari.. Not sure why it shouldn't be considered part of oVirt.. at
least from directions I had heard/seen, seemed there was good synergy..
It didn't seem that it was JUST about oVirt, but that doesn't matter, as
long as it does provide value to the KVM managed ecosystem. That should be
the main criteria...
Cheers,
Frank
-----------------------------------------------------------------------------------------------------------------------
Frank Novak ( 诺帆 nuò、fān )
STSM, SCEM Open Hypervisor
IBM Linux Technology Center
-------------------------------------------------------------------------------------------------------------------------
12:10 a.m.
* Carl Trieloff <cctrieloff(a)redhat.com> [2011-09-27 12:45]:
This vote is to accept into oVirt the memory overcommit manager (mom)
project either to be used as a dependency in VDSM or as a daemon
alongside VDSM. This detail will be worked during integration.
If the project is accepted and given it is our first community submitted
project to be voted we will create an infrastructure setup list which I
will record. This can then be used to make it easier for the next
project joining.
Please vote -1, 0, +1 whether you would like to include this project
into oVirt. I'll leave the vote open at least 72 hours.
+1 for inclusion into oVirt.
regards
Carl.
_______________________________________________
Board mailing list
Board(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/board
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh(a)us.ibm.com
7:42 a.m.
On 09/27/2011 08:41 PM, Carl Trieloff wrote:
This vote is to accept into oVirt the memory overcommit manager (mom)
project either to be used as a dependency in VDSM or as a daemon
alongside VDSM. This detail will be worked during integration.
If the project is accepted and given it is our first community submitted
project to be voted we will create an infrastructure setup list which I
will record. This can then be used to make it easier for the next
project joining.
Please vote -1, 0, +1 whether you would like to include this project
into oVirt. I'll leave the vote open at least 72 hours.
regards
Carl.
_______________________________________________
Can we get some info on how many people are active in this project? How
committed they are?
Livnat
5:07 p.m.
On Wed, Sep 28, 2011 at 07:42:58AM +0300, Livnat Peer wrote:
On 09/27/2011 08:41 PM, Carl Trieloff wrote:
>
> This vote is to accept into oVirt the memory overcommit manager (mom)
> project either to be used as a dependency in VDSM or as a daemon
> alongside VDSM. This detail will be worked during integration.
>
> If the project is accepted and given it is our first community submitted
> project to be voted we will create an infrastructure setup list which I
> will record. This can then be used to make it easier for the next
> project joining.
>
> Please vote -1, 0, +1 whether you would like to include this project
> into oVirt. I'll leave the vote open at least 72 hours.
>
> regards
> Carl.
> _______________________________________________
Can we get some info on how many people are active in this project? How
committed they are?
Up until now, I am the sole maintainer and principle contributor to the project.
I remain very committed to the project. Integration with a "branded" KVM stack
has always been the goal for MOM because automatic integration and deployment is
the key to delivering this type of optimization out of the box to end users.
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
10:27 a.m.
I think this vote is too early,
I would first like to check MOM more, and see the strong/weak points of either
option.
My gut feeling is that MOM's code should help VDSM to cpmplete its memory
menagement police (or the entire policy engine).
There memory policy handling is also required as a part of the VM execution
(e.g. Monday Morning efect), and as I recall MOM does not handle that.
Bottom line I wouldn't rush too fast,
but if I have to decide now based on what I know and the roadmap ahead I would
-1
for adding it as a new ovirt project.
but I would certainly start investigate how can the VDSM utilize MOM's code.
Thanks
Barak Azulay
On Tuesday 27 September 2011 20:41:03 Carl Trieloff wrote:
This vote is to accept into oVirt the memory overcommit manager
(mom)
project either to be used as a dependency in VDSM or as a daemon
alongside VDSM. This detail will be worked during integration.
If the project is accepted and given it is our first community submitted
project to be voted we will create an infrastructure setup list which I
will record. This can then be used to make it easier for the next
project joining.
Please vote -1, 0, +1 whether you would like to include this project
into oVirt. I'll leave the vote open at least 72 hours.
regards
Carl.
_______________________________________________
Board mailing list
Board(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/board
10:46 a.m.
-1
Can we please not do votes until we have a process on how to evaluate new project
proposals? This feels very rushed.
That said, I would probably vote +1 as soon as that process is in place (and from what I
know about mom so far). I just don't like to rush things. So +1 for mom, -1 for the
early vote :).
Alex
Am 27.09.2011 um 19:41 schrieb Carl Trieloff <cctrieloff(a)redhat.com>:
This vote is to accept into oVirt the memory overcommit manager (mom)
project either to be used as a dependency in VDSM or as a daemon
alongside VDSM. This detail will be worked during integration.
If the project is accepted and given it is our first community submitted
project to be voted we will create an infrastructure setup list which I
will record. This can then be used to make it easier for the next
project joining.
Please vote -1, 0, +1 whether you would like to include this project
into oVirt. I'll leave the vote open at least 72 hours.
regards
Carl.
_______________________________________________
Board mailing list
Board(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/board
12:44 p.m.
On 09/28/2011 10:46 AM, Alexander Graf wrote:
-1
Can we please not do votes until we have a process on how to evaluate new project
proposals? This feels very rushed.
That said, I would probably vote +1 as soon as that process is in place (and from what I
know about mom so far). I just don't like to rush things. So +1 for mom, -1 for the
early vote :).
I also agree this feels a but rushed, and need a bit more looking into.
i don't think anyone disagrees on the need for something like that, or
even on that exact implementation, but lets understand a bit better.
my main concern is if this is going to be "the" policy engine for vdsm
going forward, is if it shouldn't be established on something which is a
rule based technology (say, pacemaker).
could be it alrady is, could be it's not relevant, but let's understand
the scope and strategy for something which will be the node level policy
engine.
Alex
Am 27.09.2011 um 19:41 schrieb Carl Trieloff<cctrieloff(a)redhat.com>:
>
> This vote is to accept into oVirt the memory overcommit manager (mom)
> project either to be used as a dependency in VDSM or as a daemon
> alongside VDSM. This detail will be worked during integration.
>
> If the project is accepted and given it is our first community submitted
> project to be voted we will create an infrastructure setup list which I
> will record. This can then be used to make it easier for the next
> project joining.
>
> Please vote -1, 0, +1 whether you would like to include this project
> into oVirt. I'll leave the vote open at least 72 hours.
>
> regards
> Carl.
> _______________________________________________
> Board mailing list
> Board(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/board
_______________________________________________
Board mailing list
Board(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/board
4:49 p.m.
board-bounces(a)ovirt.org wrote on 09/28/2011 05:44:56 AM:
my main concern is if this is going to be "the" policy engine for vdsm
going forward, is if it shouldn't be established on something which is a
rule based technology (say, pacemaker).
I think this is way too much speculation. I don't think anyone has proposed
that MOM should be a general-purpose policy engine or that it should be
"the" policy engine for VDSM. In fact Adam pointed out that in some actual
deployments MOM is used discretely from VDSM and that is a concrete
advantage of having a separate daemon. Further, redesigning the project or
proposing a re-implementation on a different technology base is way beyond
the discussion. In fact, that latter suggestion in particular is something
that the MOM project should consider. The former (inclusion into VDSM) is
something the VDSM project should consider.
+1
Thanks,
Mike
Mike Day
IBM Distinguished Engineer
Chief Virtualization Architect, Open Systems Development
Cell: +1 919 371-8786 | mdday(a)us.ibm.com
http://code.ncultra.org
5:43 p.m.
On 09/28/2011 08:49 AM, Michael D Day wrote:
board-bounces(a)ovirt.org wrote on 09/28/2011 05:44:56 AM:
>
> my main concern is if this is going to be "the" policy engine for vdsm
> going forward, is if it shouldn't be established on something which is a
> rule based technology (say, pacemaker).
I think this is way too much speculation. I don't think anyone has proposed
that MOM should be a general-purpose policy engine or that it should be
"the" policy engine for VDSM.
I think the reason for the speculation is that we aren't being formal enough in
our proposals. I think Fedora Features are a good model for making proposals
like this:
http://fedoraproject.org/wiki/Features/Policy/Proposals
I'll work on some ovirt wiki pages for a similar project inclusion template this
afternoon.
Regards,
Anthony Liguori
In fact Adam pointed out that in some actual
deployments MOM is used discretely from VDSM and that is a concrete
advantage of having a separate daemon. Further, redesigning the project or
proposing a re-implementation on a different technology base is way beyond
the discussion. In fact, that latter suggestion in particular is something
that the MOM project should consider. The former (inclusion into VDSM) is
something the VDSM project should consider.
+1
Thanks,
Mike
Mike Day
IBM Distinguished Engineer
Chief Virtualization Architect, Open Systems Development
Cell: +1 919 371-8786 | mdday(a)us.ibm.com
http://code.ncultra.org
_______________________________________________
Board mailing list
Board(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/board
5:51 p.m.
On 09/28/2011 10:43 AM, Anthony Liguori wrote:
On 09/28/2011 08:49 AM, Michael D Day wrote:
>
> board-bounces(a)ovirt.org wrote on 09/28/2011 05:44:56 AM:
>>
>> my main concern is if this is going to be "the" policy engine for vdsm
>> going forward, is if it shouldn't be established on something which
>> is a
>> rule based technology (say, pacemaker).
>
> I think this is way too much speculation. I don't think anyone has
> proposed
> that MOM should be a general-purpose policy engine or that it should be
> "the" policy engine for VDSM.
I think the reason for the speculation is that we aren't being formal
enough in our proposals. I think Fedora Features are a good model for
making proposals like this:
http://fedoraproject.org/wiki/Features/Policy/Proposals
I'll work on some ovirt wiki pages for a similar project inclusion
template this afternoon.
From the board meeting call, we discussed creating a bit more
structure
to bring in new projects. Jim has volunteered to write this up for us
and circulate.
In light of this, I'm going to suspend the vote, so we can get that
drafted and reviewed on the board list. Then we will work with Adam to
get that info written up and we and resume. Adman, thx for the working
with us, mom is the first one with the full board assembled so you are
helping us get the kinks out of the process and get it written down.
This should hopefully resolve the concerns raised and allow us to not
create a precedent that we don't want to follow for later project
submissions.
sound good?
Carl.
7:21 p.m.
On Wed, Sep 28, 2011 at 10:51:39AM -0400, Carl Trieloff wrote:
From the board meeting call, we discussed creating a bit more
structure
to bring in new projects. Jim has volunteered to write this up for us
and circulate.
In light of this, I'm going to suspend the vote, so we can get that
drafted and reviewed on the board list. Then we will work with Adam to
get that info written up and we and resume. Adman, thx for the working
with us, mom is the first one with the full board assembled so you are
helping us get the kinks out of the process and get it written down.
No problem. I fully expected this to be a test/validation of the process.
This should hopefully resolve the concerns raised and allow us to not
create a precedent that we don't want to follow for later project
submissions.
sound good?
Yes, I agree that this is the best course to take.
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
4804
days inactive
4805
days old
21 comments
13 participants
participants (13)
-
Adam Litke -
Alexander Graf -
Andrew Cathrow -
Anthony Liguori -
Barak Azulay -
Benedict, Jon -
Carl Trieloff -
Frank Novak -
Itamar Heim -
Livnat Peer -
Michael D Day -
Perry Myers -
Ryan Harper