"environment" vs "model" in the code

[Rick Harding]

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. 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.

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/20160119/5c2b6ff6/attachment.html>