Feedback from a new charm author

Dean Maniatis dean.maniatis at gmail.com
Mon Dec 5 19:05:11 UTC 2016


Hello Charles,

I recall your name from an IRC session several months back when i was 
first looking into Juju 1.x and you did assist me with my questions. 
Hopefully, i will spend more time now in 2.x :-). Please find my 
comments in line.


On 05/12/2016 06:33 μμ, Charles Butler wrote:
> Greetings Dean,
>
> First of all, great feedback. Thank you for posting this to the 
> community list so others can learn from your experience.
>
> I'll attempt to address your concerns corresponding to the numbers 
> they were posted under.
>
> 1. Centos series charms, I haven't done a lot of work in this 
> department, but I do know that centos series charms do work, at least, 
> under the MAAS provider. This should be true for the other cloud 
> providers but I'll need to confirm with the core devs that this is the 
> case, as centos support was contributed by our partners over at Cloud 
> Base Solutions.
>
> 2. This is a limitation of subordinates, that they must only co-locate 
> with the same series. You can define a multi-series charm, but once 
> the subordinate has been related to a series, i believe it will then 
> be locked to the series it was originally related to. I would need to 
> run a simulation to disprove that statement, as I haven't gotten my 
> hands very dirty with multi-series subordinates.
>
> 3.  It's expected that the subordinate itself would control the 
> exposing of the website, as its managing the workload. Any other 
> scenario would need to be coordinated with the principal charm and the 
> principal charm would have to perform those actions. It may be obtuse 
> to do it this way, however, as it's not obvious where the 
> encapsulation begins/ends with this pattern. I'm happy to take a look 
> if you link the code in question.
>
Please have a look at my code 
https://github.com/deanmaniatis/netdata-charm. This small application 
I'm porting is exposing an HTTP interface at 19999 and I can see /1/ 
that is exposed when using `juju status` but not on the web UI.

/1/
http://paste.ubuntu.com/23584699/

>
> 4. Removing the entire application bundle does sound like an 
> interesting idea, but it's not something we've explored to date. I 
> would highly recommend filing a bug for this functionality so we can 
> discuss it and get it on the roadmap.
>
> Thanks and all the best,
>
> Charles
>
>
>
> Charles Butler <charles.butler at canonical.com 
> <mailto:charles.butler at canonical.com>> - Juju Charmer
> Come see the future of modeling your datacenter: http://jujucharms.com 
> <http://jujucharms.com/>
>
> On Mon, Dec 5, 2016 at 10:21 AM, Dean Maniatis 
> <dean.maniatis at gmail.com <mailto:dean.maniatis at gmail.com>> wrote:
>
>     Hello,
>
>     I'm a new charm author trying to learn the basics and decided to
>     start with a simple bash template. I'm working on porting netdata
>     <https://github.com/firehol/netdata> as a subordinate charm which
>     is a lightweight real-time performance and health monitoring tool.
>     On my first charm revision
>     <https://github.com/deanmaniatis/netdata-charm> i managed to
>     deploy it and test it with Xenial and Trusty both on LXD and AWS.
>     I have identified the following challenges/questions and since i
>     couldn't find any information from docs i decided to post here.
>     Some maybe more related to feature requests than actual questions
>     so please treat the following as a mixed feedback from a newbie.
>
>
>     1. How to test centos7 series? The upstream developer has put a
>     lot of effort to support all major Linux distributions but i can't
>     seem to be able to find any information regarding "charming" in
>     regards with Centos7. After some quick research it seems that
>     currently centos7 image is not supported in either AWS or
>     localhost provider <https://bugs.launchpad.net/juju/+bug/1495978>.
>     In addition, it seems there are no centos7 charms to look into
>     their code nor even a simple blank centos7 charm to be used as a
>     sandbox (similar to the ubuntu charm).
>
>     2. When i first deployed my subordinate charm i couldn't figure
>     why i was able to relate it to only to a few charms and not all
>     available on the canvas. Later i understood that i have to deploy
>     at least one for each series which somehow doesn't provide this
>     really cool user experience of application modeling, i.e. deploy a
>     single subordinate charm and during relation let the system/charm
>     code handle the intricate details and provide meaningful message
>     in case the relation is not feasible, e.g. this charm is not
>     supported for this series. There is an informative message when
>     using CLI but on the GUI it simply grays out the target charm and
>     it is not really clear why that's not possible.
>
>     3. When a subordinate charm enables a new service on the principal
>     charm shouldn't that service be listed under the `Expose
>     application` GUI section? For example my charm enables a web UI
>     dashboard on port 19999 so i would expect that to be added to
>     whatever other service is listed under the principal charm. I've
>     define this service on metadata.yaml with `provides: website:
>     interface: http` and with `open-port 19999` on install hook but
>     doesn't seem to be working. What am i doing wrong?
>
>     4.I can easily deploy an application bundle with one command but
>     the opposite is not available except manually removing each
>     service or destroying completely the model. Shouldn't `juju remove
>     kubernetes-core` just work?
>
>
>     Dean
>
>
>
>     --
>     Juju mailing list
>     Juju at lists.ubuntu.com <mailto:Juju at lists.ubuntu.com>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/mailman/listinfo/juju
>     <https://lists.ubuntu.com/mailman/listinfo/juju>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20161205/876f9b5c/attachment.html>


More information about the Juju mailing list