Re: django-python upgrade questions

2015-02-03 Thread Patrick Hetu
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


django-python upgrade questions

2015-01-09 Thread sheila miguez
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.

Django and South versions/distro/whatever would proceed separately.

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.


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

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.

To sum up, if you reached this far, I'd really like for my assumptions to
be checked and corrected. Help!

Thanks!

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.

[1]
http://bazaar.launchpad.net/~charmers/charms/trusty/python-django/trunk/view/head:/hooks/hooks.py#L151

[2]
https://code.launchpad.net/~codersquid/charms/trusty/python-django/tgz-projects




-- 
she...@pobox.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju