[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Fwd: Us2538 and comments



Forwarding this to the public list for discussion.

A comment inline:

----- Forwarded Message -----
> 
> 
> ----- Original Message -----
> > From: "Clayton Coleman" <ccoleman redhat com>
> > To: "Rajat Chopra" <rchopra redhat com>, "Krishna Raman"
> > <kraman redhat com>
> > Sent: Monday, September 17, 2012 7:25:28 PM
> > Subject: Us2538 and comments
> > 
> > Looked over what's in master and went through some stuff - had some
> > questions and suggestions
> > 
> > - gear groups don't have scaling info.  Need this for our stories
> > (thought we agreed to add it here) - we've said the gear group is
> > the unit that scales, correct?  So we'd add scales from, scales to,
> > and scales with to the group directly so we can set it?  We've
> > modeled it as a sub resource of a cartridge, but according to the
> > model the group is what is scaling, so it certainly feels like
> > those
> > would be direct attributes of the group (and hence settable via
> > patch on the group).   Or, if we're not ready to expose it on gear
> > groups, we'll need to make that settable via cartridge.  I'm
> > ambivalent on this - i need to retrieve the info from gear groups
> > but I don't care how we model setting it.
> 
> Yeah, we agreed on the gear groups. But the new refactored code also
> has singleton elements in the group. With which I started doubting
> whether its the group scaling really or are we going to say the
> cartridge scaled. Krishna, whats your idea?
> Although, now I feel I should bring back the scaling info in group,
> but also list what singletons exist explicity to clarify who
> respects the scaling info.
> 

Krishna reminded me the scaling info in applications/<app>/cartridges.json is from the manifest - I think it might just be good to remove current_scale from being visible inside the scaling_info element to reduce potential confusion.

> > 
> > - cartridge has scales_from and scales_to, app has scale_max and
> > scale_min.  Given discussions about scaling multiple carts (and
> > typeless gears) maybe we should clarify these attributes apply to
> > the web cartridge and rename them to match the attri names we use
> > on
> > the cart (or web_scales_from, etc).  Scalable will eventually mean
> > something different than today.
> 
> App's scale_min and scale_max will clearly change. In the new model,
> there is a user's min/max setting per group. So, I say we get rid of
> the scale_min/scale_max in application, and get the user's min/max
> whenever we are ready.
> 

Multiple cartridges will eventually scale, so a single attribute will probably never suffice.  I'm ok as well with removing/deprecating these until such a time as we have a clear need to expose them.

> 
> > 
> > - JSON serialization of non build able app feels non canonical now
> > that I'm looking at the resource.  We're returning build_info:
> > {building_with: null, ... } vs build_info: null or build_info: {}.
> >  Thoughts or existing examples from API?
> > 
> 
> Shall we change it to 'build_info : null'? It appears better to me.
> 
> 

I tend to agree, especially from a JS usage:

if (build_info) { // buildable }


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]