Open Stack

It sounds like there is some interest in this topic. With the Summit
just around the corner, I propose we get together while many
of us are there and explore this area further. I'm in the process of
researching the availability of a time and place, shooting for early
morning, prior to when the conference starts. I recognized a lot of names
on this thread, but not all, including the original poster, Alexandre. A
face-to-face I think would really help in this case and I'm assuming most
of the Ceilometer team will be at the Summit.

As a team, it would be good to understand and identify the primary
goals, areas of overlap and differences between where Ceilometer is
focused right now and monitoring as a service.

>From an HP perspective, I can share what we've done with Jahmon so far and
our plans. We've given this area and our direction considerable thought.
We see
Ceilometer as synergistic with our direction and have developed
a Ceilometer pipeline publisher to send samples to Jahmon. Jahmon
will be open-sourced and has a significant amount of code and the backing
of 
a strong team right now, but we would like to start working in earnest
with the open-source community.

--Roland


On 5/6/14, 10:25 AM, "Clint Byrum" <clint at fewbar.com> wrote:

>Excerpts from Sandy Walsh's message of 2014-05-06 07:02:05 -0700:
>> On 5/6/2014 10:04 AM, Thierry Carrez wrote:
>> > John Dickinson wrote:
>> >> One of the advantages of the program concept within OpenStack is
>>that separate code projects with complementary goals can be managed
>>under the same program without needing to be the same codebase. The most
>>obvious example across every program are the "server" and "client"
>>projects under most programs.
>> >>
>> >> This may be something that can be used here, if it doesn't make
>>sense to extend the ceilometer codebase itself.
>> > +1
>> >
>> > Being under the Telemetry umbrella lets you make the right technical
>> > decision between same or separate codebase, as both would be supported
>> > by the organizational structure.
>> >
>> > It also would likely give you an initial set of contributors
>>interested
>> > in the same end goals. So at this point I'd focus on engaging with the
>> > Telemetry program folks and see if they would be interested in that
>> > capability (inside or outside of the Ceilometer code base).
>> 
>> This is interesting.
>> 
>> I'd be curious to know more what "managed" means in this situation? Is
>> the core project expected to allocate time in the IRC meeting to the
>> concerns of these adjacent projects? What if the core project doesn't
>> agree with the direction or deems there's too much overlap? Does the
>> core team instantly have sway over the adjacent project?
>> 
>
>Yes, the core team instantly has sway. It is not to be taken lightly.
>
>We absorbed Tuskar into the Deployment program, and our PTL, Robert
>Collins, was able to get involved with the design of Tuskar early and
>convince them to stay more aligned with other OpenStack projects. So
>the benefit is now Tuskar can focus on the thing that they _do_ need
>to do that are unique.  Likewise, their core team was given core status
>in the deployment program, and was able to influence the pieces of the
>Deployment program that they needed to work better.
>
>This has created a nice cycle of contribution where many aspects of the
>Deployment program's projects have been improved as a result. Had Tuskar
>decided to just stay out of the Deployment program, they might have
>reimplemented many of the things we had already done, and thus would
>be less adoptable by users and they would receive less contribution as
>a whole.
>