Hello Marco,
Thank you for sharing your insight. You have something really great here
with Juju and I'm a strong supporter. Please find my comments in line.
Dean
On 05/12/2016 06:32 μμ, Marco Ceppi wrote:
Hey Dean! Thanks for the email. I've got some replies in line.
On Mon, Dec 5, 2016 at 11:22 AM Dean Maniatis <[email protected]
<mailto:[email protected]>> 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).
This is a good point. I'll make sure we update with a "centos" charm
much like the Ubuntu one! Cloudbase has done a lot of the Centos charm
enablement and charms. I'll have them weigh in with some examples.
I think it has to do more with the fact that two of the most used cloud
providers (my guess), AWS and LXD are not able to pull Centos7 image to
use. Or maybe it is supported just fine in other cloud providers but an
upstream developer wanting to repackage his/her work most probably will
enroll to your excellent free AWS for charmers program and/or use local
LXD for quick development. I did find this reference/1/ for LXD and how
it is planned to be solved in 2.1.0?
/1/
https://bugs.launchpad.net/juju/+bug/1495978
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.
This bit me, again, recently. I filed this as a bug to get it
addressed soon. https://bugs.launchpad.net/juju/+bug/1638199
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?
Not sure I understand, you should be able to expose the subordinate at
anytime. Since the port and metadata relationships are defined as part
of that charm, `juju expose netdata` should do what you want.
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?
So, ideally yes. However bundles aren't modelled in juju past the
deployment. Bundles themselves are just a static representation of a
snapshot of a model. As such, when you `juju deploy kubernetes-core`
you're really replaying the applications and relations (and
configuration) for that bundle. To date, juju controller doesn't track
that past the deploy. I think there is work in the future to improve
bundles, but I'm not sure if this is considered as one of them.
Well, strictly speaking as an end-user, the same way i use `juju deploy
<bundle>` i would also want to use something like `juju remove-bundle
<bundle>`. More than often i find my self experimenting with model
configurations and it "costs" more to destroy the model and reconfigure
it again. In my case, i don't care much about the current state of the
machines involved in a bundle, simply want to remove them in a single
command instead of issuing x
--
Juju mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
