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