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 <[email protected]
<mailto:[email protected]>> - 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
<[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).
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
[email protected] <mailto:[email protected]>
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
<https://lists.ubuntu.com/mailman/listinfo/juju>
--
Juju mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
