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