Re: presenting a poster on juju at PyCon 2015
Hi Eric, I'm at pycon and I could give you a hand explaining Juju if you want. I'm the author of the python-django charm and other python related charms. I'll be around wearing a Juju t-shirt. Patrick Le jeudi 2 avril 2015, Michael Foord michael.fo...@canonical.com a écrit : On 29/03/15 07:08, Eric Snow wrote: Hey all, At the poster session (12 April) at PyCon 2015, I'll be presenting on Juju. [1] I'm excited to be sharing juju with folks in the Python community, particularly with the role that Python plays in dev ops as well as in Juju. The first draft of my poster (big: 120cm x 120cm) is pretty much done and I'd like to get some feedback. Please let me know what you think, what you like, and what I should fix. Keep in mind that I haven't worked too closely with the charm side of juju core and I've only written one simple charm myself. So it's likely I have missed something important and also have a few mistakes in there. I've attached a PDF and the ODG file is online. [2] Under charm store you should add charms for many common pieces of infrastructure (or something similar but better worded), possibly listing a few examples - especially openstack. The two geniuses of juju (to my mind) are the charm store (service component deployment and configuration encapsulated in charms) and service orchestration. That you can deploy many parts of your application stack and have juju configure them, and *reconfigure* them, to talk to each other. In my experience people haven't yet understood the power/utility of orchestration. So if you can find a way to communicate and emphasise orchestration that would be good... Michael As well note that the presentation format is highly interactive and amounts to me and one or more people standing around the poster talking about it. Different conference-goers will stop by over the course of 3-ish hours. I plan on laminating the poster so I can draw on it with dry-erase markers (hence the relative sparseness). Thanks! -eric [1] https://us.pycon.org/2015/schedule/presentation/446/ [2] https://drive.google.com/file/d/0B0aWHgOTQ1hNOTE4ei1tUldib1U -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: simple stream for runabove
2015-02-04 10:46 GMT-05:00 Nicolas Thomas nicolas.tho...@canonical.com: Patrick you should try : juju-metadata generate-image -a amd64 -u $OS_AUTH_URL -i $IMAGE_UUID -r $OS_REGION_NAME -s trusty juju-metadata generate-image -a amd64 -u $OS_AUTH_URL -i $IMAGE_UUID -r $OS_REGION_NAME -s precise Then upload the resulting (s)json file Yep it solve it for me. Thanks a lot Nicolas! Hope this helps, -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: simple stream for runabove
Bonjour Patrick,
Salut Thomas,
Can you give us the result of the following command:
juju metadata validate-tools
Tools are not a problem, images are:
u-ph:~$ juju metadata validate-images -e run
ERROR index file has no data for cloud {BHS-1 https://auth.runabove.io/v2.0}
not found
Resolve Metadata:
source: default cloud images
signed: false
indexURL: http://cloud-images.ubuntu.com/releases/streams/v1/index.json
ERROR subprocess encountered error code 1
u-ph:~$ juju metadata validate-tools -e run
Matching Tools Versions:
- 1.21.1-trusty-amd64
- 1.21.1-trusty-arm64
- 1.21.1-trusty-armhf
- 1.21.1-trusty-i386
- 1.21.1-trusty-ppc64el
Resolve Metadata:
source: default simplestreams
signed: true
indexURL: https://streams.canonical.com/juju/tools/streams/v1/index2.sjson
In my environment.yaml in the run section I have:
image-metadata-url:
https://storage.bhs-1.runabove.io/v1/AUTH_abcde.../ubuntu_stream/;
but it looks like juju metadata validate-images ignores it.
Did you check/follow this :
https://juju.ubuntu.com/docs/howto-privatecloud.html
Yep, I've follow this and copy the json structure from
http://cloud-images.ubuntu.com/releases/streams/v1/
Best regards,
On 03/02/2015 04:50, Patrick Hetu wrote:
Hi there,
I'm trying to get Runabove's openstack cloud to work with Juju but
I can't get the simple stream to work. Simplestream.go seems to
just skip to index2.json because of an error but it didn't report
any:
2015-02-03 02:38:34 INFO juju.cmd supercommand.go:37 running juju
[1.21.1-utopic-amd64 gc] 2015-02-03 02:38:34 INFO
juju.provider.openstack provider.go:248 opening environment run
2015-02-03 02:38:35 DEBUG juju.environs.configstore disk.go:336
writing jenv file to /home/avoine/.juju/environments/run.jenv
2015-02-03 02:38:35 INFO juju.network network.go:106 setting
prefer-ipv6 to false 2015-02-03 02:38:35 DEBUG juju.environs
imagemetadata.go:105 trying datasource keystone catalog
2015-02-03 02:38:35 DEBUG juju.environs.simplestreams
simplestreams.go:374 searching for metadata in datasource
image-metadata-url 2015-02-03 02:38:35 INFO juju.utils http.go:59
hostname SSL verification enabled 2015-02-03 02:38:35 DEBUG
juju.environs.simplestreams simplestreams.go:465 fetchData failed
for
https://storage.bhs-1.runabove.io/v1/AUTH_XXX/ubuntu_stream/streams/v1/index2.sjson
:
cannot find URL
https://storage.bhs-1.runabove.io/v1/AUTH_XXX/ubuntu_stream/streams/v1/index2.sjson
not found
[...]
This is what I have in my index.json
{ index: { com.ubuntu.cloud:released:runabove: { updated:
Mon, 02 Feb 2015 14:14:09 +, clouds: [ { region:
BHS-1, endpoint: https://auth.runabove.io/v2.0; }], format:
products:1.0, datatype: image-ids, cloudname: runabove,
products: [ com.ubuntu.cloud:server:12.04:amd64 ], path:
streams/v1/com.ubuntu.cloud:released:runabove.json } } }
and in com.ubuntu.cloud:released:runabove.json:
{ updated: Thu, 06 Nov 2014 13:28:28 +, datatype:
image-ids, content_id: com.ubuntu.cloud:released:runabove,
products: { com.ubuntu.cloud:server:12.04:amd64: { release:
precise, version: 12.04, arch: amd64, versions: {
20141015.1: { items: { BHS-1: { virt: kvm, crsn:
BHS-1, root_size: 8GB, id:
23b30a81-1b0f-45d3-8dc1-eed72091d020 } }, pubname: Ubuntu
Server 12.04 (amd64 20141015.1) - Image, label: release } } }
}, format: products:1.0, _aliases: { crsn: { BHS-1: {
region: BHS-1, endpoint: https://auth.runabove.io/v2.0; } }
} }
Tell me if you need more info. Also, should I bug the fact that
runabove is not in the offical stream?
Thanks,
Patrick
- --
Best Regards,
Nicolas Thomas - Solution Architect - Canonical
http://insights.ubuntu.com/?p=889
GPG FPR: D592 4185 F099 9031 6590 6292 492F C740 F03A 7EB9
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJU0HntAAoJEEkvx0DwOn65JBAH/2hwa14nFsZPj19EU7LLaGXa
3lqn/YKFYnLw6+JnS+oDsyOtcK8xz124g/Hg1yIzhothY1raudivcBphicqrE3+t
dDnrQz/VKzZBtdlkOSUU9Q318sCkzV4jKak3VMNFjGoKj1d97dLhjcxLVR2+Moqs
BnSkrmb9i/e2mulLzk3L/dnMPsCkV1P/mDMNgsW8qH/1YA0DqPiS0ShB8cvhzTuE
H8Y++Pj6q9CBCBwky/ktS65pHWU+Pn53UDHKvfudNZz9VAAuHiY5UzAVhViTqXX8
HXvgaIfePHXcCF8PItl03N9mOyABanUf6nYZC6jOtJ8A0Gnc/qoKMTQRIVKM18w=
=zMel
-END PGP SIGNATURE-
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
Re: django-python upgrade questions
Hi Sheila, Thank you for all your great ideas, for some backgrounds checkout a discussion about the future of the charm in this thread: http://comments.gmane.org/gmane.linux.ubuntu.juju.user/1649 I'm working to rewrite the charm using Ansible so I don't think I'll add new features to the current pure python charm. But all your comments are really welcome for helping building the new charm. 2015-01-09 10:29 GMT-05:00 sheila miguez she...@pobox.com: I need to have upgrade functionality for this charm. I'm not experienced with writing hooks, so I want to check my assumptions and ask questions. Here begins the wall of text. During install, configure_and_install[1] is called in the install hook to install Django and, optionally, South. configure_and_install is handling concerns that I think would be better to split out. Here is the current logic: * if the user specifies a ppa, it will add the ppa * if the user specifies a key, it will add the key * if the method is somehow called with an empty string, it bails * otherwise it defaults to pip I think it would be better to break this up. Adding apt repositories and keys should be done separately. Config items could be added for a ppa list and a key list. Install could check for those and add them regardless of any django or south concerns. I agree with you. The idea will be to create an aptkit ansible role that could be reuse as many time that you need in the charm's playbook see: http://bazaar.launchpad.net/~patrick-hetu/charms/precise/python-django/ansible_reboot/view/head:/playbooks/roles/aptkit/defaults/main.yml or you could use pure ansible modules in the in the pre_tasks section: http://docs.ansible.com/apt_repository_module.html Django and South versions/distro/whatever would proceed separately. The idea here was to create a django-app ansible role that handle is dependencies independently of the other apps: http://bazaar.launchpad.net/~patrick-hetu/charms/precise/python-django/ansible_reboot/view/head:/playbooks/roles/django-app/tasks/main.yml This makes upgrade simpler, I think. Upgrade would have similar steps to install, but I have a question about idempotence when adding apt repositories and keys. Are those idempotent? If not, then refactoring them out of that method makes it easier to idempotently handle Django and South dependencies. They should be idempotent because apt-add-repository, pip, apt-get are idempotent and in the pure-python charm they are checked every time configuration change. So changing the ppa should upgrade the packages. Now on to general plans for upgrade hook. It needs these to be added, but I want to know if my assumptions are mistaken: * ability to pull new src * ability to upgrade django and south * ability re-inject settings I think those actions could be done via configuration changes and not necessarily via an explicit upgrade but drawing the line is tricky. I'm trying to build the new charm in a way that it would be easier to be integrated in a continuous integration workflow but I'm really not sure how thing would work. And one general observation I have -- if I could remove some of the options this charm allows, it would be easier to deal with. e.g. not give many options for how packages are installed. Force people to do it only one way. Pick a recommended practice and stick with it. I recommend taking a look at what audryr and pydanny suggest, but ultimately, whatever devops people decide to want, I will roll with it. but pick one way. I don't think there is a clear recommended practice that I can stick with. To sum up, if you reached this far, I'd really like for my assumptions to be checked and corrected. Help! Ps. as a side note, you can see some of the tiny incremental changes I'm thinking about in my branch[2]. I need to have the ability to install a project from a tarball due to lack of access. I'm not sure I will ultimately request any merge for tarball functionality as it is really janky. but it's what I have to work with based on what we've been doing at work. Yeah, I can really see how this feature would be useful. Also, Micheal is working on something similar: https://github.com/absoludity/charm-ansible-roles/tree/master/wsgi-app Thanks again and sry to have took so long to answer. Patrick -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
simple stream for runabove
Hi there,
I'm trying to get Runabove's openstack cloud to work with Juju but I can't
get the simple stream to work. Simplestream.go seems to just skip to
index2.json because of an error but it didn't report any:
2015-02-03 02:38:34 INFO juju.cmd supercommand.go:37 running juju
[1.21.1-utopic-amd64 gc]
2015-02-03 02:38:34 INFO juju.provider.openstack provider.go:248 opening
environment run
2015-02-03 02:38:35 DEBUG juju.environs.configstore disk.go:336 writing
jenv file to /home/avoine/.juju/environments/run.jenv
2015-02-03 02:38:35 INFO juju.network network.go:106 setting prefer-ipv6 to
false
2015-02-03 02:38:35 DEBUG juju.environs imagemetadata.go:105 trying
datasource keystone catalog
2015-02-03 02:38:35 DEBUG juju.environs.simplestreams simplestreams.go:374
searching for metadata in datasource image-metadata-url
2015-02-03 02:38:35 INFO juju.utils http.go:59 hostname SSL verification
enabled
2015-02-03 02:38:35 DEBUG juju.environs.simplestreams simplestreams.go:465
fetchData failed for
https://storage.bhs-1.runabove.io/v1/AUTH_XXX/ubuntu_stream/streams/v1/index2.sjson:
cannot find URL
https://storage.bhs-1.runabove.io/v1/AUTH_XXX/ubuntu_stream/streams/v1/index2.sjson;
not found
[...]
This is what I have in my index.json
{
index: {
com.ubuntu.cloud:released:runabove: {
updated: Mon, 02 Feb 2015 14:14:09 +,
clouds: [
{
region: BHS-1,
endpoint: https://auth.runabove.io/v2.0;
}],
format: products:1.0,
datatype: image-ids,
cloudname: runabove,
products: [
com.ubuntu.cloud:server:12.04:amd64
],
path: streams/v1/com.ubuntu.cloud:released:runabove.json
}
}
}
and in com.ubuntu.cloud:released:runabove.json:
{
updated: Thu, 06 Nov 2014 13:28:28 +,
datatype: image-ids,
content_id: com.ubuntu.cloud:released:runabove,
products: {
com.ubuntu.cloud:server:12.04:amd64: {
release: precise,
version: 12.04,
arch: amd64,
versions: {
20141015.1: {
items: {
BHS-1: {
virt: kvm,
crsn: BHS-1,
root_size: 8GB,
id: 23b30a81-1b0f-45d3-8dc1-eed72091d020
}
},
pubname: Ubuntu Server 12.04 (amd64 20141015.1) - Image,
label: release
}
}
}
},
format: products:1.0,
_aliases: {
crsn: {
BHS-1: {
region: BHS-1,
endpoint: https://auth.runabove.io/v2.0;
}
}
}
}
Tell me if you need more info. Also, should I bug the fact that runabove is
not in the offical stream?
Thanks,
Patrick
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
Re: Migrating the python-django charm to Ansible
Let me know about the shims!
Well, I've just tested and it looks like it was fixed in Ansible 1.7 at
least for host_vars/...
So much cleaner code to come!
Also, let met know what your thinking about the changes I propose on how
relations
are handle in charm-ansible-roles.
Patrick
2014-11-07 15:33 GMT-05:00 Patrick Hetu patrick.h...@gmail.com:
Specifically, this is not the config.yaml you're talking about, but
the config file which is passed during deployment right? As in,
myconfig.yaml in:
juju deploy --config myconfig.yaml mycharm
yes, that's what I meant.
[1] Using a configuration file without that charm name at the top
was working in the past but now doesn't. Maybe this could be
re-enable without to much negative impact.
That might be worth a juju bug.
Done: https://bugs.launchpad.net/juju-core/+bug/1390525
Let me know about the shims!
Yes, sorry, I forgot to mention the main problem that shim is trying to
solve.
The major reason for shims is because Ansible can't redefined an
existing variable at runtime. Ansible evaluate the yaml as a jinja2
template
first and then run it.
So a shim is an assignement trick to get the right values in the playbook.
For example, I want to use to be able to customize the django_settings
variable
in the charm configuration but set it to the basename of the working_dir in
case it not set:
- name: set settings_module if django_settings != ''
set_fact: shim_settings_module={{ django_settings }}
when: django_settings != ''
- name: set settings_module if django_settings == ''
set_fact: shim_settings_module={{ shim_working_dir | basename
}}.settings
when: django_settings == ''
I've tried, the default() filter, set_fact module and with_first_found
helpers.
They are all great tools for simulating simple if.
But redefining a variable will fail silently or trigger an infinite loop.
You can check it out with this snippet:
- hosts: localhost
vars:
a: abc
tasks:
- debug: msg={{ a }}
- set_fact: a=b
- debug: msg={{ a }}
Then running it with -e to see the problem:
ansible-playbook redefine.yml -i local -e a=xyz
[2] https://github.com/absoludity/charm-ansible-roles
I've checked those roles and wanted to contribute to it but I got blocked.
I found that tagging the tasks with Juju's hook names make it difficult to
produce a reusable role.
Because you will have to set a tag to all your tasks in the role
and always be running untagged task.
This also make the charm specific to Juju.
I've chose to use tags only in the playbook and not in roles.
I use it in the python-django charm like that:
- role: wsgi-app
tags:
- wsgi-relation-joined
- wsgi-relation-changed
- website-relation-joined
- website-relation-changed
wsgi_user: {{ django_uid }}
wsgi_group: {{ django_gid }}
working_dir: {{ shim_working_dir }}
python_path: {{ shim_python_path_list }}
app_label: {{ sanitized_unit_name }}
wsgi_application: wsgi
working_dir: {{ shim_working_dir }}
settings_module: {{ shim_settings_module }}
And for task specific to a role, I filter in the roles with a when:
- name: Open port
when: relations['website']
- name: Reload wsgi
...
when: relations['wsgi']
or a better way could be to include base on relations in the playbook like
this:
- include: wsgi_apps/tasks/relations/wsgi.yml
when: relations['wsgi']
This is far from perfect but I can't see other way to keep the role
flexible but not specific to Juju.
That *should* be done by the existing charmhelpers (it writes out
/etc/ansible/host_vars/localhost on each hook execution with config,
relations and some other things like unit name, public and private
addresses)
It does, but they're not sanitized currently. Would be a good thing to
add a sanitized version of local/remote unit names to the ansible
host_vars.
I have open a bug about that:
https://bugs.launchpad.net/charm-helpers/+bug/1390535
So we have individual charms for each services, even if running from
the same codebase. Each charm supports only the relations and config
that it needs[1]. We utilise shared ansible roles as Michael said to
reduce the charm to pretty much the bare minimum needed for this
specific service: charm config, relations, writing the service config
to disk. Most other things are taken care of by the roles.
Yes that seems to be the way to go. So people would to build a custom
django charm
by adding only pieces that they want in there playbook.
our use-case is a bit different as we're not attempting to
write one charm to deploy any django project right now (we did try in
the past, but found it was adding unreasonable complexity for us,
unless the projects being deployed were very similar).
I think the python-django charm would be there only to show all the
possible features
available by the reusable roles and people would be encorage
Re: Migrating the python-django charm to Ansible
Specifically, this is not the config.yaml you're talking about, but
the config file which is passed during deployment right? As in,
myconfig.yaml in:
juju deploy --config myconfig.yaml mycharm
yes, that's what I meant.
[1] Using a configuration file without that charm name at the top
was working in the past but now doesn't. Maybe this could be
re-enable without to much negative impact.
That might be worth a juju bug.
Done: https://bugs.launchpad.net/juju-core/+bug/1390525
Let me know about the shims!
Yes, sorry, I forgot to mention the main problem that shim is trying to
solve.
The major reason for shims is because Ansible can't redefined an
existing variable at runtime. Ansible evaluate the yaml as a jinja2 template
first and then run it.
So a shim is an assignement trick to get the right values in the playbook.
For example, I want to use to be able to customize the django_settings
variable
in the charm configuration but set it to the basename of the working_dir in
case it not set:
- name: set settings_module if django_settings != ''
set_fact: shim_settings_module={{ django_settings }}
when: django_settings != ''
- name: set settings_module if django_settings == ''
set_fact: shim_settings_module={{ shim_working_dir | basename
}}.settings
when: django_settings == ''
I've tried, the default() filter, set_fact module and with_first_found
helpers.
They are all great tools for simulating simple if.
But redefining a variable will fail silently or trigger an infinite loop.
You can check it out with this snippet:
- hosts: localhost
vars:
a: abc
tasks:
- debug: msg={{ a }}
- set_fact: a=b
- debug: msg={{ a }}
Then running it with -e to see the problem:
ansible-playbook redefine.yml -i local -e a=xyz
[2] https://github.com/absoludity/charm-ansible-roles
I've checked those roles and wanted to contribute to it but I got blocked.
I found that tagging the tasks with Juju's hook names make it difficult to
produce a reusable role.
Because you will have to set a tag to all your tasks in the role
and always be running untagged task.
This also make the charm specific to Juju.
I've chose to use tags only in the playbook and not in roles.
I use it in the python-django charm like that:
- role: wsgi-app
tags:
- wsgi-relation-joined
- wsgi-relation-changed
- website-relation-joined
- website-relation-changed
wsgi_user: {{ django_uid }}
wsgi_group: {{ django_gid }}
working_dir: {{ shim_working_dir }}
python_path: {{ shim_python_path_list }}
app_label: {{ sanitized_unit_name }}
wsgi_application: wsgi
working_dir: {{ shim_working_dir }}
settings_module: {{ shim_settings_module }}
And for task specific to a role, I filter in the roles with a when:
- name: Open port
when: relations['website']
- name: Reload wsgi
...
when: relations['wsgi']
or a better way could be to include base on relations in the playbook like
this:
- include: wsgi_apps/tasks/relations/wsgi.yml
when: relations['wsgi']
This is far from perfect but I can't see other way to keep the role
flexible but not specific to Juju.
That *should* be done by the existing charmhelpers (it writes out
/etc/ansible/host_vars/localhost on each hook execution with config,
relations and some other things like unit name, public and private
addresses)
It does, but they're not sanitized currently. Would be a good thing to
add a sanitized version of local/remote unit names to the ansible
host_vars.
I have open a bug about that:
https://bugs.launchpad.net/charm-helpers/+bug/1390535
So we have individual charms for each services, even if running from
the same codebase. Each charm supports only the relations and config
that it needs[1]. We utilise shared ansible roles as Michael said to
reduce the charm to pretty much the bare minimum needed for this
specific service: charm config, relations, writing the service config
to disk. Most other things are taken care of by the roles.
Yes that seems to be the way to go. So people would to build a custom
django charm
by adding only pieces that they want in there playbook.
our use-case is a bit different as we're not attempting to
write one charm to deploy any django project right now (we did try in
the past, but found it was adding unreasonable complexity for us,
unless the projects being deployed were very similar).
I think the python-django charm would be there only to show all the
possible features
available by the reusable roles and people would be encorage to build a
charm per site.
Patrick
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
Migrating the python-django charm to Ansible
Since the last UDS, I'm trying to make the python-django charm evolve to use Ansible for is various tasks instead of using pure Python scripts. My previous attempt: lp:~patrick-hetu/charms/precise/python-django/ansible had some problems so I decided to restart from scratch here (work in progress): lp:~patrick-hetu/charms/precise/python-django/ansible_reboot Based on the following observations. Use roles that are not specific to Juju --- If you look at an Ansible role you will probably found a file defaults/main.yml or vars/main.yml. For me it was stunning how close those are to a charm configuration file. So why not grab this opportunity to use the same file (minus the charm name at the top [1]) with both Juju and Ansible and make Juju use the same roles that Ansible community are using by introducing shims in the charm playbook. [1] Using a configuration file without that charm name at the top was working in the past but now doesn't. Maybe this could be re-enable without to much negative impact. Couple the playbook with Juju with a shim - To get the playbook to work with an external role we could use a shim file that translate Juju's dynamic configuration and relation data to roles variables. I was thinking using a shim imported in the pre_tasks section of the charm's playbook that runs on all tags. (see: https://github.com/ansible/ansible/issues/3157) The shim would do things like: * Translating Juju variable to role variable * Sanitize variable like: unit_name, relation_name, etc * Ensure backward compatiblity Then using tags to dispatch based on the current relation to the corresponding roles. Build role for re-usability --- This have the potential to solve the problem of repetition of some high level tasks in other charm. Like adding ppa, fetching source code, adding ssl certificate, configuring backup, etc A little bit like what charmhelper is doing right now. I might not be clear so don't be afraid to ask clarification. I'm looking forward to receive your feedbacks Patrick -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: The PostgreSQL charm, AWS and robustness
I have a new project that I'm wanting to deploy and it is a django project backed with a postgresql database. Pretty simple really. If you plan to use the python-django charm be sure to use this branch: https://code.launchpad.net/~patrick-hetu/charms/precise/python-django/charmhelpers The charm was rewritten to use charmhelpers + Ansible and it have not landed yet. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
RackSpace support
Hello, I've tried to make Juju-core to work with RackSpace and it's not but here's the details of my quest: First, getting the list of the Flavors give back a 203 HTTP status (Non-Authoritative Information) instead of the expected 200. There is no SecurityGroup in RackSpace. The catalog returned with the token by Keystone had: * a different tenantid for object-store and compute * The compute service twice (v1.0, v2) The retry-after header is a complete date/time string instead of the expected float. In RackSpace's Ubuntu images cloud-init is not installed by default so you have to create a custom image and bootrap with it. For that you need to create public container (cdn) with the metadata. I discovered that the userdata field doesn't exist in the API but there is a field named personality that is doing more or less the same thing. So I've put the user-data in the personnality field but now I'm getting a 413 error (Request Entity Too Large). That's it for now. Patrick -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
the injection pattern for extending charms
Hi guys, I was looking for a way to extends the buildbot-master charm to be able to add configuration chunks from an other charm or a subordinate. For configuring the new OpenStack latent buildslave for example: http://docs.buildbot.net/current/manual/cfg-buildslaves.html?highlight=latent#openstack The way I was going to propose was to add a buildbot-settings provider to metadata.yaml file. Charms will then use it to send configuration that would be injected a juju_settings directory in the buildbot install directory. I would then add this python code at the end of the master.cfg file: import imp import glob from os.path import abspath, dirname, join PROJECT_DIR = abspath(dirname(__file__)) conffiles = glob.glob(join(PROJECT_DIR, 'juju_settings', '*.py')) for f in conffiles: execfile(abspath(f)) The code sent by charms or subordinates would be in this form: c['buildbotURL'] = http://my_new_url_here; c['builders'] += your_builder_code_here c['schedulers'] += your_schedulers_code_here etc This is the pattern I used in the python-django charm to extend the settings. So before spreading the pattern, I would like to have your opinion. Cheers, Patrick -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
