Matrix Testing Release

[Tom Barber]

Hi folks,

We're formulating some plans for big data solutions on JAAS coming in the
second half of 2017 assuming the support aspects etc can be ironed out
between now and then.

Anyway, when we were in Gent Pete gave a cool demo of the Matrix testing
solution which is idea for the stuff we're working on, whats the status of
that? Are we likely to see a release any time soon?

Thanks

Tom

-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim 

Schedule a meeting with me 

GB: +44(0)5603641316
US: +18448141689


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

Big Data, JAAS and Juju

[Tom Barber]

Hello folks,

I figured I'd spin a yarn before going home for the day about Juju and its
importance ot my company.

For those of you who don't know me my day job is a developer at NASA JPL
which is contractual and ongoing for the foreseeable future but clearly not
infinite (as much as I'd like it to be). To facilitate my involvement at
NASA I founded Spicule as a payment conduit and experimental business to
tinker with some ideas.

Anyway, that aside, as most of you who do know me will know, I've always
been a fan of Juju since Sam twisted my arm into writing some charm stuff 2
years ago and Jorge forced me (yes.. forced) to come to Gent 14 months ago.
My, and now our plan as I've been hiring a few folks dedicated to Juju
development and support over the last couple of months, has been to ramp up
the Juju stuff from June-ish onwards, and maybe before if we can get our
stuff together. Of course a few things have always caused us problems as
people wanting to make a living out of a fantastic platform like Juju,
monetization being pretty key. Me hiring people for a platform I've yet to
figure out how to leverage fully clearly exposes me to more risk, but risk
I feel is worth taking.

I know there are plans afoot to allow us to provide support through the
portal, and if someone needs some testers, or wants to explain it nicely so
we can figure out how best to support it please feel free to reach out. I'm
very much up for providing generic Big Data/Small Data services support
based on Juju charms, Juju charm development support and other stuff and
this is what we (Spicule) are working towards.

At the end of the day we all(the community at large) need to make some
money out of Juju, be it through development services, support services or
building products on top of Juju, so from the outside asking in, please let
us know what we can do to help facilitate that so we can all win.

Thanks

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

Re: Matrix Testing Release

[Pete Vander Giessen]

Hiya Tom,

> Anyway, when we were in Gent Pete gave a cool demo of the Matrix testing
solution which is idea for the stuff we're working on, whats the status of
that? Are we likely to see a release any time soon?

Since Ghent, juju-matrix has acquired conjure-up support, been packaged in
a snap ("sudo snap install --classic --edge juju-matrix"), acquired support
for auto discovery of end-to-end tests, and had lots of bug fixes.

You're welcome to install the snap, and help find bugs to add to the issue
tracker here: https://github.com/juju-solutions/matrix/milestone/1

(You'll note that we basically have one race condition to fix, and JaaS
support to finalize before it graduates from alpha to beta.)

The docs live at
https://jujucharms.com/docs/devel/developer-testing#matrix, and
I'm always pingable on this list or on IRC if you have any questions :-)

~ PeteVG
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

charms.reactive bi-weekly catch-up

[Cory Johns]

Greeting,

Alex Kavanagh, Merlijn Sebrechts, Tim Van Steenburgh, and myself met for
the regular charms.reactive development discussions.

We discussed Merlijn's addition to the 2.0 discussion PR [1], "The case for
triggers; the apt layer" [2].  We had discussed this idea some before, but
I think we are coming around to an agreement on the need for this and what
the API should look like.

This transitioned into discussing the idea that certain flags should be
managed by the framework and "reserved," such that they are never modified
directly by any given layer, and that triggers should be used to create
per-layer "copies" of these flags that the layer would then be safe in
using as needed.  Reserved flags would include things like the current
config.changed flags, as well as interface / relation flags so that we
could do away with @hook usage in interface layers (which would have the
nice benefit of enabling an upgrade path from non-reactive to reactive
charms).

Another aspect of that idea is that we should formalize the notion that
handlers react to *changes* in flags, rather than the flags themselves, and
the "changed" state of flags should not be tied to hook invocations and
persist until an actual, meaningful change happens to that flag.  This
would remove the surprising current behavior that handlers are reinvoked
repeatedly as long as their conditions match, simply because a hook
triggered even if it didn't represent anything meaningful to the particular
handler.

Finally, we started outlining the creation of a Juju plugin which would aid
debugging of reactive charms, providing functionality such as an easy way
to inspect the flags that are set and when they were last changed, what the
history of handler invocation was, etc.

Given the recent shake-ups at Canonical, there is some uncertainty about
specific timelines, but we set ourselves a deadline of two months hence for
the trigger feature, with some other work being done in parallel.


[1]: https://github.com/juju-solutions/charms.reactive/pull/101
[2]:
https://github.com/juju-solutions/charms.reactive/blob/2.0/2.0-proposal/the-case-for-triggers.md
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[ANN] Bigtop-1.2 charms/bundles have been released

[Kevin Monroe]

Hi folks!

After over a year in development, Apache Bigtop 1.2 was released earlier
this month.  Today, we released updated charms and bundles for this release
to the appropriate stable channels.

HIGHLIGHTS:

+ Software versions:
- hadoop-namenode 2.7.3
- hadoop-plugin 2.7.3
- hadoop-resourcemanager 2.7.3
- hadoop-slave 2.7.3
- hbase 1.1.3-1 **
- kafka 0.10.1.1-1
- mahout 0.12.2-1 **
- pig 0.15.0
- spark 2.1.0-1
- zeppelin 0.7.0
- zookeeper 3.4.6-1 **

** There is a planned bigtop-1.2.1 point release to bring in hotfixes.
This will likely include hbase-1.1.9, mahout-0.13, and zookeeper-3.4.10.
No charm changes are required; when these debs hit the upstream repo, the
charms will provide the new version.

+ Juju 2.0 or greater
- To leverage Juju Resources, bigtop-related charms now require Juju 2 or
greater.

+ Usability
- Refreshed READMEs and actions for a consistent UX

+ Hadoop-Spark
- Reduced resource requirements.  Spark is not in HA mode in this bundle,
so we removed 3 unnecessary zookeeper units.

+ Spark
- New configuration to change driver/executor memory at runtime.
- Improved spark reliability when changing execution mode (local,
standalone, yarn).


KNOWN ISSUES:

+ GCE
- https://bugs.launchpad.net/juju/+bug/1674871
- Most of our applications require a minimum of 7g ram.  We set a generic
memory constraint in our bundles for a consistent experience across all
clouds.  However, with GCE, mem=7G results in a "highcpu" instance type.
These are significantly more expensive than "standard" instance types.
- If "highcpu" instances are not required, workaround this issue by
modifying a local copy of bundle.yaml.  For example:

$ charm pull hadoop-processing
cs:bundle/hadoop-processing-58
$ cd hadoop-processing/
$ sed -ie 's/mem=7G/instance-type=n1-standard-2/' bundle.yaml
$ juju deploy ./bundle.yaml

+ Zeppelin
- https://issues.apache.org/jira/browse/BIGTOP-2742
- The init script for the zeppelin service is broken.  The charm will work
around this during install and relation changes, but users may find that
things like "sudo systemctl  zeppelin" on the unit do not work.
- We'll update the zeppelin charm once an appropriate fix lands upstream.


Please let me know if you have any questions or issues with the bigtop-1.2
release.  Thanks!
-Kevin Monroe
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Set status message in Juju GUI

[fengxia]

Hi Juju,

I have tried status_set(), which will show up in juju debug-log, but how 
to make some message appear on Juju GUI?


I'm building a charm that I want to feedback user of progress. What's 
the right tool for this?


--
Feng xia
Engineer
Lenovo USA

Phone: 5088011794
fx...@lenovo.com

Lenovo.com
Twitter | Facebook | Instagram | Blogs | Forums


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

Re: Set status message in Juju GUI

[Jeff Pihach]

Hello,

You should see the messages from status_set() in the applications inspector
under the unit list.

To get there, click on the application icon, then you'll see "Units", under
which will be separate lists for the units in the various states
(uncommitted, pending, error, etc). Clicking on these lists will show you
the individual units and their workload status. You're then able to click
through again into each unit individually.

If you're not seeing these messages there, be sure you're running the
latest GUI by running `juju upgrade-gui`. JAAS at jujucharms.com is always
running the most recent version of the GUI so you should see them there.

Hope this helps!
-Jeff


On Tue, Apr 25, 2017 at 12:18 PM, fengxia  wrote:

> Hi Juju,
>
> I have tried status_set(), which will show up in juju debug-log, but how
> to make some message appear on Juju GUI?
>
> I'm building a charm that I want to feedback user of progress. What's the
> right tool for this?
>
> --
> Feng xia
> Engineer
> Lenovo USA
>
> Phone: 5088011794
> fx...@lenovo.com
>
> Lenovo.com
> Twitter | Facebook | Instagram | Blogs | Forums
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: charms.reactive bi-weekly catch-up

[Menno Smits]

On 26 April 2017 at 02:37, Cory Johns  wrote:

>
> Another aspect of that idea is that we should formalize the notion that
> handlers react to *changes* in flags, rather than the flags themselves, and
> the "changed" state of flags should not be tied to hook invocations and
> persist until an actual, meaningful change happens to that flag.  This
> would remove the surprising current behavior that handlers are reinvoked
> repeatedly as long as their conditions match, simply because a hook
> triggered even if it didn't represent anything meaningful to the particular
> handler.
>

​This sounds ​like a great improvement. Thanks for the update.

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