Adding a project to oVirt

[Anthony Liguori]

On 09/13/2011 08:56 AM, Carl Trieloff wrote:
> On 09/12/2011 05:02 PM, Anthony Liguori wrote:
>> On 09/12/2011 03:46 PM, Carl Trieloff wrote:
>>> On 09/12/2011 03:41 PM, Anthony Liguori wrote:
>>>> On 09/12/2011 02:30 PM, Carl Trieloff wrote:
>>>>>
>>>>> (URL REDACTED - INFO: http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
>>>>>
>>>>>
>>>>>
>>>>> Anthony, I believe I have your comments worked into this doc, please
>>>>> take a look.
>>>>>
>>>>> Itamar, please review the two project rules.
>>>>
>>>> What is a "published API"?  Does the board vote on what constitutes a
>>>> published API, or does any API that is published by an accepted
>>>> project automatically become an oVirt published API?
>>>>
>>>
>>>
>>> I was thinking of votes in term of VDSM, the Admin REST API. or we want
>>> to add a reporting API etc. not the contents, just which team drives it,
>>> and that it is an agreed point we 'support' with some or other ABI.
>>>
>>> We should define that out a bit more.
>>
>> I was trying to understand how something like QEMU would fit into oVirt.
>>
>> Since this requires that the each project consumes or provides a
>> supported API, QEMU exposes an API that it supports (QMP), but it's
>> not published through oVirt (or would it be?).  oVirt Engine consumes
>> it via a very indirect path (through VDSM, then through libvirt, and
>> then QMP).
>
>
> that is why I phrased it provides or consume directly or indirectly, to
> cover these cases. That should cover things like QEMU or other modules
> down the stack.  It also allow for someone to build a proxy or something
> else ontop of the REST API, and then have a project that uses that
> project would also be able to be included.
>
> The key is that engine is the 'glue' project and then we want to be able
> to relate all project to it, either on top of the engine, or under it.
>
>
>>
>> I don't think Apache has any real requirement that projects under
>> Apache.org integrates with apache directly, right?  Maybe it would be
>> best if we avoided being overly specific here.
>
> No, Apache has not such rule
>
>>
>> How does Eclipse handle this?
>
> Eclipse is the model here we want to use for this part. They have a set
> of frameworks, a core platform which also ships as RCP (the morel
> equivalent of or engine) and then a set of API. They also have an arch
> list.  All projects have to:
>
> - integrate with the core framework (effectively RCP)  {this means
> cut/copy/ paste etc etc all work between the projects for example so
> between WTP and STP even those there is zero overlap in dev between
> these projects or between WTP and any 3rd party plugin}
>      then optionally support additional API's
>
> - some projects also create API's for consumption, there is an arch team
> that coordinates and agrees which projects expose project wide
> supportable API's
>
> The second rule is that each project must support the release schedule.
> the project is free to choose what it is going to put onto the 'release
> train' as they call it
>
>
> They have a few more rules, but I think we only need these two to get
> what we need to keep oVirt consistent and simple. As we mature we can as
> needed.
>
> I'll try find some docs on it and mail out the link for reference.

Thanks, this is helpful background info.

Regards,

Anthony Liguori

>
> Carl.