"environment" vs "model" in the code

[Kapil Thangavelu]

On Mon, Jan 18, 2016 at 8:24 PM, Rick Harding <rick.harding at canonical.com>
wrote:

> No, there's not been a public note yet. It's work going into the 2.0
> updates currently.
>
> The gist of the reason is that as support for things such as networking,
> storage, and workloads expand out the idea is that Juju is doing more to
> model your infrastructure and workloads vs an environment.
>

networking and storage are very much part of an application's deployment
environment. ie. there different from dev, stage, prod. not sure what
workloads are (renamed or built on actions i presume).


> So far it's helped one of the issue that Juju has had in that it takes
> time to explain what it's actually doing before folks 'get it'.
>
Starting from the point of 'take what you have running and let Juju model
> it' seems to be clicking with new folks more.
>

so its a verb, its an instance/noun, does it also apply to templates
(previously known as bundles)?

i'm curious to try out the re-branding on some guinea pigs. re what's
commonly running to model, autoscale groups, elbs, multiple networks,
security groups, iam roles, rds.

thanks,

Kapil



>
> On Mon, Jan 18, 2016 at 9:15 AM Kapil Thangavelu <kapilt at gmail.com> wrote:
>
>> out of curiosity is there any public explanation on the reason for the
>> change? environments map fairly naturally to various service topology
>> stages, ie my prod, qa, dev environments. while model is a rather opaque
>> term that doesn't convey much.
>>
>> On Thu, Jan 14, 2016 at 7:16 PM, Menno Smits <menno.smits at canonical.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> We've committed to renaming "environment" to "model" in Juju's CLI and
>>> API but what do we want to do in Juju's internals? I'm currently adding
>>> significant new model/environment related functionality to the state
>>> package which includes adding new database collections, structs and
>>> functions which could include either "env/environment" or "model" in their
>>> names.
>>>
>>> One approach could be that we only use the word "model" at the edges -
>>> the CLI, API and GUI - and continue to use "environment" internally. That
>>> way the naming of environment related things in most of Juju's code and
>>> database stays consistent.
>>>
>>> Another approach is to use "model" for new work[1] with a hope that
>>> it'll eventually become the dominant name for the concept. This will
>>> however result in a long period of widespread inconsistency, and it's
>>> unlikely that things we'll ever completely get rid of all uses of
>>> "environment".
>>>
>>> I think we need arrive at some sort of consensus on the way to tackle
>>> this. FWIW, I prefer the former approach. Having good, consistent names for
>>> things is important[2].
>>>
>>> Thoughts?
>>>
>>> - Menno
>>>
>>> [1] - but what defines "new" and what do we do when making significant
>>> changes to existing code?
>>> [2] - http://martinfowler.com/bliki/TwoHardThings.html
>>>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>
>>>
>> --
>> Juju-dev mailing list
>> Juju-dev at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160120/15a5b4fd/attachment.html>