<br><br><div class="gmail_quote">On Mon, Nov 26, 2012 at 11:06 AM, Eoghan Glynn <span dir="ltr"><<a href="mailto:eglynn@redhat.com" target="_blank">eglynn@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
[...]<br>
<div class="im">> > The pollster or notification handler would basically just stuff all<br>
> > the available raw data into the sample kwargs. The transformers would<br>
> > then have to know which named args to expect and how to interpret the<br>
> > resource_obj.<br>
><br>
><br>
><br>
> In previous API designs I have always found it easier to have<br>
> well-defined classes passing data between the layers, rather than<br>
> accepting variable, undefined, arguments like this. The new<br>
> developer coming along to add a feature has far less work to do when<br>
> figuring out what data to emit as output or take as input to a new<br>
> plugin, and it almost always turns out to be easier to create<br>
> components that can be recombined in unexpected ways because of the<br>
> standard data structures. Using a class also means fewer changes<br>
> when new fields are added (because you only have to find where they<br>
> are constructed, not every call to a plugin) or removed (because you<br>
> can provide a backwards-compatibility @property method).<br>
<br>
</div>That's fair enough, hopefully we can achieve the strongly-typed<br>
interaction between pollster and transformer without an undue<br>
proliferation of new types.<br></blockquote><div><br></div><div>The types will exist by virtue of the interfaces existing. I'm just suggesting that we create them in a way that makes them to easier to document. :-)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<br>
> All of the notification and pollsters should continue to emit a<br>
> common object (either Counter instances or some updated thing that<br>
> meets our needs better). All of the transformers should accept<br>
> instances of those objects as input. Each publisher should define a<br>
> class representing what it wants as inputs -- no dictionaries,<br>
> tuples, etc. Use classes that can be documented clearly (even if<br>
> just as namedtuples). Since each transformer will be bound to a<br>
> publisher, it will know which type of object(s) to emit (I assume a<br>
> transformation may cause one Counter instance to become several<br>
> inputs to a publisher).<br>
<br>
</div>Yes, agreed, the publisher and transformer relationship is an<br>
intimate one, and the transformer will know what type the publisher<br>
expects (which may be a type defined by the publisher itself, or<br>
by some third party library such as boto if that's more convenient).<br>
<br>
<br>
[...]<br>
<div class="im">> > Yeah, that's an idea. Wouldn't transformers have to be chained in<br>
> > that case? So for example the relevant CW transformer chain would be:<br>
> ><br>
> > generic-transformer-calculating-cpu-util-from-cumulative-time --><br>
> > CW-specific-transformer-outputting-as-CPUUtilization-datapoint<br>
> ><br>
> > That would be fine, just wanted to call out a potential extra<br>
> > bit of complexity to capture in the pipeline config.<br>
><br>
> Would we expect users to configure that pipeline?<br>
<br>
</div>Rarely, it should be more of a side-effect of deployment (e.g.<br>
rolling out a CW service would require corresponding updates to<br>
the ceilo compute agent config).<br></blockquote><div><br></div><div>That seems a little brittle. We probably want a set of files, instead of a monolithic config, to make it easier to add and remove pieces using tools like chef and puppet.</div>
<div><br></div><div>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Eoghan<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br>