from:"sheila miguez"

Re: upgrade-charm hook

2017-10-05 Thread sheila miguez

I'd like something like this.

The layer-snap's upgrade-hook cycle calls code[1] that checks for a
non-zero resource, and then checks whether that resource has changed. I bet
many charmers do this, and it would be useful to have a decorator that does
it for us.


[1]
https://github.com/stub42/layer-snap/blob/master/lib/charms/layer/snap.py#L53




On Tue, Sep 26, 2017 at 9:51 AM, James Beedy  wrote:

> That totally does! This sounds like a great path forward that would allow
> us to eventually migrate away from having 'upgrade-charm' fire when a
> resource is attached, while maintaining backward compat for the charms that
> use it until its deprecated.
>
> Well  I didn't mean to just imply that things should change to this ^
> way, but it seems sensible. Possibly we could have more of a conversation
> around this?
>
> ~James
>
>
>
> On Tue, Sep 26, 2017 at 12:41 AM, Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Does a `resource.changed` flag address your needs? That should be
>> possible to implement in charms.reactive, I think.
>>
>> 2017-09-24 17:53 GMT+02:00 James Beedy :
>>
>>> How do people feel about splitting the upgrade-charm hook into multiple
>>> hooks to facilitate better resource management?
>>>
>>> What I'm thinking would be super helpful would be to have the
>>> upgrade-charm hook still active for charm upgrades, and have separate hooks
>>> or flags that would indicate resource upgrades.
>>>
>>> I'm thinking something like:
>>>
>>> 'juju attach myapp myresource=myresource.file'
>>>
>>> Would cause the 'upgrade-resource-myresource'  hook to become active on
>>> instances of 'myapp'.
>>>
>>> I feel that having this affinity from resource ->
>>> resource-upgrade- hook would be a huge win for resource
>>> management.
>>>
>>> Thoughts?
>>>
>>>
>>>
>>>
>>> --
>>> Juju-dev mailing list
>>> juju-...@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju-dev
>>>
>>
>>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>


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

Re: wishlist: charm bundle for Read The Docs

2015-03-18 Thread sheila miguez

I bet it can!

I've been wanting to set aside a block of time to get some cleanups and
fixes in to the python-django charm and share an example mojo spec for
deploying a simple django site.

I think Read The Docs* could be an example, but I've been so busy outside
of work with other volunteer activities that my good juju intentions are
really stalled. It's been weeks since I meant to do this.

If someone else already has that would be most excellent.

* I work on pyvideo.org and would like use it as an example as well. I
haven't been using juju with it because we've been running it on donated
rackspace instances. but this won't happen because I don't have free time
to volunteer on it. I'm very happy to see that rackspace support is planned
for the future.

On Wed, Mar 18, 2015 at 9:25 AM, Zygmunt Krynicki 
zygmunt.kryni...@canonical.com wrote:

 +1000 for that!

 It's a django + celery + postgresql tool. Perhaps it can be contained
 in a generic-ish django charm?

 Best regards
 ZK

 On Wed, Mar 18, 2015 at 3:06 PM, sheila miguez she...@pobox.com wrote:
  Has anyone written a charm bundle for Read The Docs? I'd enjoy deploying
 it
  to a private environment, but I don't have free time to set it up.
 
  http://docs.readthedocs.org/en/latest/rtfd.html (may be krufty?)
 
  --
  she...@pobox.com
 
  --
  Juju mailing list
  Juju@lists.ubuntu.com
  Modify settings or unsubscribe at:
  https://lists.ubuntu.com/mailman/listinfo/juju
 




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

wishlist: charm bundle for Read The Docs

2015-03-18 Thread sheila miguez

Has anyone written a charm bundle for Read The Docs? I'd enjoy deploying it
to a private environment, but I don't have free time to set it up.

http://docs.readthedocs.org/en/latest/rtfd.html (may be krufty?)

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

Re: destroy local environment

2015-02-09 Thread sheila miguez

On Mon, Feb 9, 2015 at 3:15 PM, Nicolás Pace nicop...@gmail.com wrote:

 how can i destroy my local lxc environment, without using 'juju
 destroy-environment local' (it is not responding, as i got out of disk
 space :S)


 Just to complete the answer, lazyPower answered me.
 What i did was juju destroy-environment local -y --force
 then, there was a hanged lxc environment, so i  did lxc-destroy it.
 That was all i needed.


I found out about a plugin for this the last time it happened to me. I got
much help in #juju as well.

https://github.com/juju/plugins/blob/master/juju-clean

This also checks some processes and cleans up other files for you.

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

Re: Rackspace OpenStack configuration

2015-02-09 Thread sheila miguez

Did you hear anything back from them? I've been hoping to re-use work I've
already done that works with openstack to target a rackspace environment.

On Wed, Jan 28, 2015 at 2:28 AM, Sajith Vijesekara saji...@hsenidmobile.com
wrote:

Thanks Mark,

I will contact them and find out what is the solution for this problem.

Thanks regards
Sajith

On Wed, Jan 28, 2015 at 1:56 PM, Mark Shuttleworth m...@ubuntu.com
wrote:

On 28/01/15 10:17, Mark Shuttleworth wrote:
On 28/01/15 09:38, Sajith Vijesekara wrote:
I got your point.So i followed this (

http://askubuntu.com/questions/166102/how-do-i-configure-juju-for-deployment-on-rackspace-cloud
)
documentation to bootstrap openstack in rack-space. But documentation
is
not clear at all. If rackspace doesn't use same openstack i want to
know
that Rackspace clearly support for juju.
It shouldn't be too much work to make a customised version of the
OpenStack juju driver that adapts to Rackspace's API. I'll dig into this
with the Juju leads next week, hope to get you a good answer quickly.

In the meanwhile, you might want to ask Rackspace what their roadmap is
for adding the OpenStack APIs; might be that they will have them up soon.

Mark

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

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

Re: python-django test plan

2015-02-02 Thread sheila miguez

I'm grateful and happy to see this. I've been working off of a branch of
python-django and haven't put together merge requests because I'm
relatively new to this and wasn't sure how to go through the process of
testing changes. I've been using mojo as a brute force way to tell when
I've broken something with a change. I'll subscribe and start adding
comments.




On Thu, Jan 29, 2015 at 3:08 PM, Nicolás Pace nicop...@gmail.com wrote:

 Hi guys,
 I've defined a test plan for the Python-Django charm.
 I would like to know your thoughts about the scenaries, and propose any
 other that you might thought important.
 https://bugs.launchpad.net/charms/+source/python-django/+bug/1416108

 Thanks,

 --
 Ing. Nicolás Pace

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




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

Re: An Open Question: Charm Dependency Management

2015-01-20 Thread sheila miguez

A Makefile that has a target to install dependencies suffices, but I think
suggested conventions are still helpful. For example, in my case I prefer
python virtualenvs over system packages.

Once you establish some conventions (perhaps even just documentation
conventions), A charmer can document the approach taken so that devs will
be aware and can take measures. e.g. if I want to make a MR to a charm that
needs system packages, I will know to do my development and testing inside
of a container.


On Tue, Jan 20, 2015 at 11:58 AM, Marco Ceppi ma...@ondina.co wrote:

 I don't see how a Makefile in a charm doesn't resolve this issue. As long
 as we define what targets a user should create in the Makefile, the
 Makefile can then do everything required: create a virtualenv and install
 deps, install ruby and execute bundler, npm for node, etc. Since charms are
 so varies in how they're written and what language they're implemented in
 this seems to make the most sense.

 Marco

 On Tue Jan 20 2015 at 12:37:00 PM Charles Butler 
 charles.but...@canonical.com wrote:

 Greetings,

 If you work on charms in any capacity: this affects you, and I would love
 to have your feedback.

 While working the review queue I've encountered a few charm merges that
 are failing our testing infrastructure due to missing dependencies. This
 also has implications that reach beyond our testing infrastructure: Anyone
 that is submitting a new charm, Patches being accepted to existing charms,
 and even our documentation efforts over on the  Charm Authorship Docs.

  There seems to be a bit of confusion about what the recommended process
 is to ensure all our dependencies are encapsulated in the charm.

 Having spoken with various members of the development community, I feel
 like our dependency encapsulation process for charms is still very much a
 grey area with several different ideologies on how to manage them, thus far
 I've seen:

- A Virtualenv per project to manage python dependencies
- make targets that sudo install packages on the host system
- Zero Dependency management

 This is indeed a difficult topic to approach and digest as we're
 supporting basically everything out there. Not everyone uses the same
 tool-chain to accomplish the goal of dependency isolation - and several
 different Config Management tools have a different approach to this that
 assume it is installed on the host. this leaves a broken experience for:

- new charm authors
- CI
- Anyone that comes along and runs the test targets or bundletester

 If we're going to ask our community to contribute to charms, is it fair
 to make them run down dependencies that may or may not exist on their host?
 It seems like we can do a better job of highlighting this, and providing a
 quick start style development target to install these pre-deps which would
 satisfy CI and Development. With this being the proposal, I follow it with
 some questions:

- How have *we* solved this problem in other areas of our ecosystem?
- How have other platforms solved this problem?
- Can we emulate / improve on that pattern?
- If a package management solution exists for a technology (eg:
virtualenv for python, bundler for ruby, npm for node, berkshelf for chef)
- can we adopt these and get started by templating in the dependency
management into the charm generator template?


 I'm hoping this email is seen more as a conversation starter vs me being
 pedantic - I'm more concerned with getting the right set of information to
 our users/community than I am in solving some meta problem of packaging
 charms and their Development Environments.

 --
 All the best,

 Charles Butler charles.but...@canonical.com - Juju Charmer
 Come see the future of datacenter orchestration: http://jujucharms.com
  --
 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




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

Re: python-django charm and absent python-yaml package

2015-01-16 Thread sheila miguez

I notice the Makefile does not install test dependencies. I'll mention it
in the issue.

On Fri, Jan 16, 2015 at 3:38 AM, Vahric Muhtaryan vah...@doruk.net.tr
wrote:


 Hello All

 Newly i tried to install the python-django charm.
 Installation is failed, when i debug i saw that python-yaml package is not
 installed after manually install it i can resubmit the charm deployment and
 its succeed .

 Looks like Patrick Hetu is the maintainer , is this list right place to
 inform such things ?  i would like to ask do you aware about such issue ?

 Regards
 Vahric Muhtaryan




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




-- 
she...@pobox.com
-- 
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

python-django charm questions

2014-12-02 Thread sheila miguez

Hi all,

I'm working with the assumption that the pure-python fork of python-django
will be in trunk soon, and will be around until the ansible reboot fork
replaces it. If this is a bad assumption, let me know.

There are some nice to haves that I'd like to have in the python-django
charm before the ansible reboot hits. Since I'm new to juju and to charming
things, I'd like sanity checks before I start proposing changes. I'm using
a personal fork for now.

Pip wishes

* pip_extra_args support so that I can use --no-index
--find-links=/path/to/wheels (this is in my fork)
* remove --upgrade --use-mirrors, leave it up to the user (in my fork)

Django wishes

* call collectstatic (in my fork). I see a pending MR with something like
this, but it enforces dj-static, which I would not do.
* allow installing from tgz (in my fork)
* fail on install/config changed if django-admin.py is not found.
discovered this doesn't happen when it isn't installed, while working on
the pip changes. otherwise it fails (in my fork)
* allow users to inject custom templates. e.g. conditionally add
django-debug-toolbar based on DEBUG.

Newbie Questions

* My fork adds a couple of lines to website_relation_joined_changed because
the unit_name and port were not available to populate my apache2 template
otherwise, but this could be due to user error. How do other people do this?

*
Why is django_extra_settings used in config_changed but not during install?


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

Re: python-django charm questions