Re: "environment" vs "model" in the code

2016-01-18 Thread Kapil Thangavelu 
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 
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@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: "environment" vs "model" in the code

2016-01-18 Thread 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  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 
> 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@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

jujubigdata 6.0.0 is released

2016-01-18 Thread Kevin Monroe 
(x-post to juju for awareness of library incompatibility affecting Big Data
charms)

Hi folks, the jujubigdata 6.0.0 release is now generally available:

https://pypi.python.org/pypi/jujubigdata/6.0.0

All charms referencing "jujubigdata>=6.0.0,<7.0.0" will pick up the most
recent 6.x.x release during deployment.  This major release includes MapReduce
compression and logging configuration that makes it incompatible with
charms that require jujubigdata < 6.

If there are no objections from users of charms in the ~bigdata-dev
development namespace, we will move ~bigdata-dev charms from v5 to v6 later
this week.  Promulgated Big Data charms will continue to use v4 while v6 is
scrutinized -- there are no plans to promulgate charms using jujubigdata v5.

Commit log from 5.0.0 - 6.0.0:

342d86f [Kevin W Monroe] bump VERSION for major release
81bbcb2 [Kevin W Monroe] fix e731 lint error
e67499e [Kevin W Monroe] remove unused envars
87cd5d9 [Kevin W Monroe] mapred changes: use log_dir, remove unused
pid_dir, add config so historyserver shows job history
8e3fade [Andrew McLeod] added compression to core-site.xml and
mapred-site.xml
7de5f4f [Cory Johns] Enable DistConfig to accept data as param instead of
file
896cf62 [Cory Johns] Fixed HDFS.configure_client for layered charms
c80cc87 [Kevin W Monroe] bump VERSION for bugfix release
b3fc4ce [Kevin W Monroe] charmhelpers docs lie! getrange does not return an
empty dict, nor is there an unset range method. fix both instances where we
were lead astray.
526f923 [Kevin W Monroe] bump version for minor release
93e67a2 [Cory Johns] Fixed java version handling if release not in version
b7dc0f0 [Cory Johns] Fixed typo in method name
56b04a7 [Cory Johns] Update remove_kv_host(s) helper
91a902b [Cory Johns] Fix backwards compatibility
977823f [Cory Johns] Fix error in hack-around
f21e9fd [Cory Johns] Added remove_kv_hosts helper
0279cb9 [Cory Johns] Added helpers for layered charms
359c75e [Cory Johns] Fixes for the hadoop-base and apache-hadoop-namenode
495ccc3 [Kevin W Monroe] bump VERSION for bugfix release
fd5b14a [Konstantinos Tsakalozos] Iterate over dict items in a py2 & py3
compatible way
0ffb495 [Andrew McLeod] re-fixed as per PR # 26 req
3d87a03 [Andrew McLeod] re-fixed as per PR # 26 req
e51e117 [Andrew McLeod] added decode of utf8 for split
fbfb109 [Kevin W Monroe] bump VERSION for major release

If you'd like to discuss these changes, chime in on bigd...@lists.ubuntu.com
or find us in #juju on Freenode.

Thanks!
-Kevin Monroe
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju