Re: Call for Charm School topics
Hey Simon! For example, imagine you have an Ansible charm which inside are some php settings applied like php memory limit, and then you relate a subordinated charm to it, that creates a new php.ini with custom configurations that the project needs. If the playbook of the subordinated charm makes a move that doesn't count with files or configurations generated by the other playbook in the main service charm, probably will result in a conflict, and errors will be shown. I was thinking in how to avoid this, leaving less customized configurations in the main charm. But!, it's difficult to know where's the limit. Cheers!, Sebas. Em 08/09/2014 12:03, Simon Davy bloodearn...@gmail.com escreveu: Hi Sebastian On 5 September 2014 18:54, Sebastian sebas5...@gmail.com wrote: - Subordinated charms, when and how to use it. Conflicts with Ansible Charms. Can you give more details on Conflicts with Ansible Charms? We use the ansible support in charm-helpers a lot, for both principle charms and subordinates, and have had no problems mixing those with non-ansible charms, so I'd be keen to hear your issues. Thanks -- Simon -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Call for Charm School topics
On 9 September 2014 18:45, Sebastian sebas5...@gmail.com wrote: Hey Simon! For example, imagine you have an Ansible charm which inside are some php settings applied like php memory limit, and then you relate a subordinated charm to it, that creates a new php.ini with custom configurations that the project needs. If the playbook of the subordinated charm makes a move that doesn't count with files or configurations generated by the other playbook in the main service charm, probably will result in a conflict, and errors will be shown. This seems to me more like a problem of conflicting on a single file, which is a problem for any subordinate, not specifically an ansible one. As I'm sure you know, it is generally better to use a directory of config files that are included from the main config file, so different things can own different files, and not conflict. Many tools support this OOTB. However, if you can't have includes in a the main php.ini file, then ansible can actually help you with this somewhat, all though in limited fashion. Check out the lineinfile module: http://docs.ansible.com/lineinfile_module.html I was thinking in how to avoid this, leaving less customized configurations in the main charm. But!, it's difficult to know where's the limit. Yeah, so getting the right responsibilities between subordinates/principles can be quite nuanced. A good example IMO is the gunicorn subordinate for running python applications. All configuration is done via the relation to the subordinate, and the subordinate owns the gunicorn config completely (going so far as to disable the debian sysv init packaging as it's quite limited). So the responsibilities are clearly divided. That may not be possible in your scenario, of course[1]. But it's easy for a principle charm to touch a file it really shouldn't be doing. We had some gunicorn using principle charms that invoked /etc/init.d/gunicorn restart directly, which was a real pain when we wanted to change how gunicorn was run. One further idea: pass your extra config to the subordinate (or vice versa) as a string in the relation data, and have the subordinate include that config in the generated php.ini. Not the cleanest solution, but it could work. Or even better, expose all the knobs you want to configure in the relation data, and allow them to be set by the principle (with sane defaults). This is what the gunicorn subordinate does, fyi. HTH [1] I know very little about modern[2] php deployment [2] I can probably help with PHP 3, though ;P -- Simon -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Bug 1365828 - mongo log spam
https://bugs.launchpad.net/juju-core/+bug/1365828 Hi mongo experts Mongo is filling up syslog with lots of spam. eg, as reported by a customer, https://clbin.com/XZ63i I have reduced this a little by tweaking the roles used to log in to the juju and presence databases, so the warnings are gone. But the spam remains. It seems to me these Mongo bugs might be relevant: https://jira.mongodb.org/browse/SERVER-5847 https://jira.mongodb.org/browse/SERVER-5952 I can't see from a brief look what Juju might be doing to directly cause the spam, nor what we can do to remove it. Does anyone with more Mongo knowledge have any insight as to what we can do to address this problem? -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Bug 1365828 - mongo log spam
On Tue, Sep 9, 2014 at 4:14 PM, John Meinel j...@arbash-meinel.com wrote: I don't think these are from authentication between mongo instances. Agreed, looks like the machine-0 jujud connecting over and over again. Perhaps the agent is unhappy and is bouncing. This looks more like a Mongo 2.4 vs 2.6 difference. We added stuff like clusterAdmin to priviledges that we give because of 2.6 support (I thought).. But if 2.4 doesn't know anything about clusterAdmin then whenever we log in, it goes through the list of roles and noisily ignores some of them. clusterAdmin is for replica sets, and is applicable to 2.4. In particular, in grants replSetInitiate. I went through and removed the extraneous stuff when I did the 2.6 support updates. See http://docs.mongodb.org/v2.4/reference/user-privileges/ Presumably the real fix is to only give roles that are 2.6 specific when we know we're running against 2.6 ? (I could be wrong on this, but I thought we had earlier bugs that we couldn't do the cluster reconfiguration on 2.6 because we had to add the clusterAdmin role.) John =:- On Tue, Sep 9, 2014 at 11:22 AM, Ian Booth ian.bo...@canonical.com wrote: https://bugs.launchpad.net/juju-core/+bug/1365828 Hi mongo experts Mongo is filling up syslog with lots of spam. eg, as reported by a customer, https://clbin.com/XZ63i I have reduced this a little by tweaking the roles used to log in to the juju and presence databases, so the warnings are gone. But the spam remains. It seems to me these Mongo bugs might be relevant: https://jira.mongodb.org/browse/SERVER-5847 https://jira.mongodb.org/browse/SERVER-5952 I can't see from a brief look what Juju might be doing to directly cause the spam, nor what we can do to remove it. Does anyone with more Mongo knowledge have any insight as to what we can do to address this problem? -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Bug 1365828 - mongo log spam
On Tue, Sep 9, 2014 at 12:27 PM, Andrew Wilkins andrew.wilk...@canonical.com wrote: On Tue, Sep 9, 2014 at 4:14 PM, John Meinel j...@arbash-meinel.com wrote: I don't think these are from authentication between mongo instances. Agreed, looks like the machine-0 jujud connecting over and over again. Perhaps the agent is unhappy and is bouncing. It is possible, but its also possible that the new session copying means we just have multiple connections (conn11) to the database, and each one is going to be authenticated. This looks more like a Mongo 2.4 vs 2.6 difference. We added stuff like clusterAdmin to priviledges that we give because of 2.6 support (I thought).. But if 2.4 doesn't know anything about clusterAdmin then whenever we log in, it goes through the list of roles and noisily ignores some of them. clusterAdmin is for replica sets, and is applicable to 2.4. In particular, in grants replSetInitiate. I went through and removed the extraneous stuff when I did the 2.6 support updates. See http://docs.mongodb.org/v2.4/reference/user-privileges/ Digging into it a bit more, it is only complaining about not having those roles on the juju and presence databases, they are probably present on the admin database. Looking at the code, the only place I see RoleClusterAdmin is while connected to the Admin database. clusterAdmin http://docs.mongodb.org/manual/reference/built-in-roles/#clusterAdmin is only applicable on the admin database, and does not confer any access to the local or config databases. I wonder if this is either: 1) Mongo just being overly verbose in warnings that aren't actually warnings. (You logged in with a user that has clusterAdmin, but that doesn't apply to this other database you are accessing.) 2) We somehow created a User on the Juju/Presence databases and then also gave it clusterAdmin rights there. The only place I see any of this is via the mongo.SetAdminMongoPassword call, though, and that does appear to forcibly only do the UpsertUser rights on admin. So I'm *guessing* we are running into (1). We are connecting directly to the juju database, and we are connecting as a user that has clusterAdmin but it just doesn't do anything in this context and mongo warns about it. An idea is that we always connect to admin and then switch databases once connected? I think that's how I've done it for connecting when using mongo the CLI client. John =:- Presumably the real fix is to only give roles that are 2.6 specific when we know we're running against 2.6 ? (I could be wrong on this, but I thought we had earlier bugs that we couldn't do the cluster reconfiguration on 2.6 because we had to add the clusterAdmin role.) John =:- On Tue, Sep 9, 2014 at 11:22 AM, Ian Booth ian.bo...@canonical.com wrote: https://bugs.launchpad.net/juju-core/+bug/1365828 Hi mongo experts Mongo is filling up syslog with lots of spam. eg, as reported by a customer, https://clbin.com/XZ63i I have reduced this a little by tweaking the roles used to log in to the juju and presence databases, so the warnings are gone. But the spam remains. It seems to me these Mongo bugs might be relevant: https://jira.mongodb.org/browse/SERVER-5847 https://jira.mongodb.org/browse/SERVER-5952 I can't see from a brief look what Juju might be doing to directly cause the spam, nor what we can do to remove it. Does anyone with more Mongo knowledge have any insight as to what we can do to address this problem? -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Bug 1365828 - mongo log spam
Before I sent the original email I put up a PR to reduce the noise by eliminating the warnings. eg we only apply the cluster admin role to the admin database, not the presence or juju databases. https://github.com/juju/juju/pull/714 This cuts down on the warnings but we still get repetitive syslog entries for mongo authentication on the connections. I also put in logging to see if we were calling login over and over and it appears we are not. The agent is not bouncing. From what I can tell, Juju only calls Login a finite number of times when the agent starts. Everything is working as expected. We do call session.Copy() when we perform a db interaction, but that to my understanding just reuses the credentials from the original session. Maybe that also causes mongo to create these log entries? From what I can see, this is a mongo logging issue that we have little control over. But I'd love to be wrong so we can fix it. On 09/09/14 18:53, John Meinel wrote: On Tue, Sep 9, 2014 at 12:27 PM, Andrew Wilkins andrew.wilk...@canonical.com wrote: On Tue, Sep 9, 2014 at 4:14 PM, John Meinel j...@arbash-meinel.com wrote: I don't think these are from authentication between mongo instances. Agreed, looks like the machine-0 jujud connecting over and over again. Perhaps the agent is unhappy and is bouncing. It is possible, but its also possible that the new session copying means we just have multiple connections (conn11) to the database, and each one is going to be authenticated. This looks more like a Mongo 2.4 vs 2.6 difference. We added stuff like clusterAdmin to priviledges that we give because of 2.6 support (I thought).. But if 2.4 doesn't know anything about clusterAdmin then whenever we log in, it goes through the list of roles and noisily ignores some of them. clusterAdmin is for replica sets, and is applicable to 2.4. In particular, in grants replSetInitiate. I went through and removed the extraneous stuff when I did the 2.6 support updates. See http://docs.mongodb.org/v2.4/reference/user-privileges/ Digging into it a bit more, it is only complaining about not having those roles on the juju and presence databases, they are probably present on the admin database. Looking at the code, the only place I see RoleClusterAdmin is while connected to the Admin database. clusterAdmin http://docs.mongodb.org/manual/reference/built-in-roles/#clusterAdmin is only applicable on the admin database, and does not confer any access to the local or config databases. I wonder if this is either: 1) Mongo just being overly verbose in warnings that aren't actually warnings. (You logged in with a user that has clusterAdmin, but that doesn't apply to this other database you are accessing.) 2) We somehow created a User on the Juju/Presence databases and then also gave it clusterAdmin rights there. The only place I see any of this is via the mongo.SetAdminMongoPassword call, though, and that does appear to forcibly only do the UpsertUser rights on admin. So I'm *guessing* we are running into (1). We are connecting directly to the juju database, and we are connecting as a user that has clusterAdmin but it just doesn't do anything in this context and mongo warns about it. An idea is that we always connect to admin and then switch databases once connected? I think that's how I've done it for connecting when using mongo the CLI client. John =:- Presumably the real fix is to only give roles that are 2.6 specific when we know we're running against 2.6 ? (I could be wrong on this, but I thought we had earlier bugs that we couldn't do the cluster reconfiguration on 2.6 because we had to add the clusterAdmin role.) John =:- On Tue, Sep 9, 2014 at 11:22 AM, Ian Booth ian.bo...@canonical.com wrote: https://bugs.launchpad.net/juju-core/+bug/1365828 Hi mongo experts Mongo is filling up syslog with lots of spam. eg, as reported by a customer, https://clbin.com/XZ63i I have reduced this a little by tweaking the roles used to log in to the juju and presence databases, so the warnings are gone. But the spam remains. It seems to me these Mongo bugs might be relevant: https://jira.mongodb.org/browse/SERVER-5847 https://jira.mongodb.org/browse/SERVER-5952 I can't see from a brief look what Juju might be doing to directly cause the spam, nor what we can do to remove it. Does anyone with more Mongo knowledge have any insight as to what we can do to address this problem? -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Bug 1365828 - mongo log spam
I'm pretty sure that is the wrong fix, as the API servers need clusterAdmin role so they can set up the Replica Sets when users use juju ensure-availability. The reconfiguring is done by the machine agent, not the user admin. John =:- On Tue, Sep 9, 2014 at 2:12 PM, Ian Booth ian.bo...@canonical.com wrote: Before I sent the original email I put up a PR to reduce the noise by eliminating the warnings. eg we only apply the cluster admin role to the admin database, not the presence or juju databases. https://github.com/juju/juju/pull/714 This cuts down on the warnings but we still get repetitive syslog entries for mongo authentication on the connections. I also put in logging to see if we were calling login over and over and it appears we are not. The agent is not bouncing. From what I can tell, Juju only calls Login a finite number of times when the agent starts. Everything is working as expected. We do call session.Copy() when we perform a db interaction, but that to my understanding just reuses the credentials from the original session. Maybe that also causes mongo to create these log entries? From what I can see, this is a mongo logging issue that we have little control over. But I'd love to be wrong so we can fix it. On 09/09/14 18:53, John Meinel wrote: On Tue, Sep 9, 2014 at 12:27 PM, Andrew Wilkins andrew.wilk...@canonical.com wrote: On Tue, Sep 9, 2014 at 4:14 PM, John Meinel j...@arbash-meinel.com wrote: I don't think these are from authentication between mongo instances. Agreed, looks like the machine-0 jujud connecting over and over again. Perhaps the agent is unhappy and is bouncing. It is possible, but its also possible that the new session copying means we just have multiple connections (conn11) to the database, and each one is going to be authenticated. This looks more like a Mongo 2.4 vs 2.6 difference. We added stuff like clusterAdmin to priviledges that we give because of 2.6 support (I thought).. But if 2.4 doesn't know anything about clusterAdmin then whenever we log in, it goes through the list of roles and noisily ignores some of them. clusterAdmin is for replica sets, and is applicable to 2.4. In particular, in grants replSetInitiate. I went through and removed the extraneous stuff when I did the 2.6 support updates. See http://docs.mongodb.org/v2.4/reference/user-privileges/ Digging into it a bit more, it is only complaining about not having those roles on the juju and presence databases, they are probably present on the admin database. Looking at the code, the only place I see RoleClusterAdmin is while connected to the Admin database. clusterAdmin http://docs.mongodb.org/manual/reference/built-in-roles/#clusterAdmin is only applicable on the admin database, and does not confer any access to the local or config databases. I wonder if this is either: 1) Mongo just being overly verbose in warnings that aren't actually warnings. (You logged in with a user that has clusterAdmin, but that doesn't apply to this other database you are accessing.) 2) We somehow created a User on the Juju/Presence databases and then also gave it clusterAdmin rights there. The only place I see any of this is via the mongo.SetAdminMongoPassword call, though, and that does appear to forcibly only do the UpsertUser rights on admin. So I'm *guessing* we are running into (1). We are connecting directly to the juju database, and we are connecting as a user that has clusterAdmin but it just doesn't do anything in this context and mongo warns about it. An idea is that we always connect to admin and then switch databases once connected? I think that's how I've done it for connecting when using mongo the CLI client. John =:- Presumably the real fix is to only give roles that are 2.6 specific when we know we're running against 2.6 ? (I could be wrong on this, but I thought we had earlier bugs that we couldn't do the cluster reconfiguration on 2.6 because we had to add the clusterAdmin role.) John =:- On Tue, Sep 9, 2014 at 11:22 AM, Ian Booth ian.bo...@canonical.com wrote: https://bugs.launchpad.net/juju-core/+bug/1365828 Hi mongo experts Mongo is filling up syslog with lots of spam. eg, as reported by a customer, https://clbin.com/XZ63i I have reduced this a little by tweaking the roles used to log in to the juju and presence databases, so the warnings are gone. But the spam remains. It seems to me these Mongo bugs might be relevant: https://jira.mongodb.org/browse/SERVER-5847 https://jira.mongodb.org/browse/SERVER-5952 I can't see from a brief look what Juju might be doing to directly cause the spam, nor what we can do to remove it. Does anyone with more Mongo knowledge have any insight as to what we can do to address this problem? -- Juju-dev mailing list
Re: reviewboard
On Mon, Sep 8, 2014 at 8:05 PM, Tim Penhey tim.pen...@canonical.com wrote: On 09/09/14 04:32, Eric Snow wrote: To install rbt: sudo pip install --allow-unverified rbtools --allow-external rbtools rbtools Ah... no. Perhaps in a virtual env. Is it the sudo or the flags to which you object? :) Using a virtualenv would indeed be a good idea! So, as a correction to my previous instructions: virtualenv ~/.venvs/reviewboard ~/.venvs/reviewboard/bin/pip install --allow-unverified rbtools --allow-external rbtools rbtools alias rbt='~/.venvs/reviewboard/bin/rbt' -eric -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Juju Actions - Use Cases
Hi; We're looking for use cases for Juju Actions, mostly to make sure we expose the right API. I'm hoping for a few different use cases from the Juju Web UI folks, but I'd appreciate input from anyone wanting to use Juju Actions in their charms too. I've started a document with some example use cases to prime the pump: please contribute to this document and don't feel constrained to the style or layout I adopted for the examples. If you have any interest or investment in using or publishing Actions for Juju please review and contribute! Google Docs Link https://docs.google.com/document/d/1uYffkkGA1njQ1oego_h8BYBMrlGpmN_lwsnrOZFxE9Q/edit?usp=sharing Thanks -- John Weldon -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: reviewboard
Thanks Eric, Taking it for a spin now, looks pretty cool Matty On Tue, Sep 9, 2014 at 3:47 PM, Eric Snow eric.s...@canonical.com wrote: On Mon, Sep 8, 2014 at 8:05 PM, Tim Penhey tim.pen...@canonical.com wrote: On 09/09/14 04:32, Eric Snow wrote: To install rbt: sudo pip install --allow-unverified rbtools --allow-external rbtools rbtools Ah... no. Perhaps in a virtual env. Is it the sudo or the flags to which you object? :) Using a virtualenv would indeed be a good idea! So, as a correction to my previous instructions: virtualenv ~/.venvs/reviewboard ~/.venvs/reviewboard/bin/pip install --allow-unverified rbtools --allow-external rbtools rbtools alias rbt='~/.venvs/reviewboard/bin/rbt' -eric -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Please don't use bash when there are syscalls available
A user just complained that he can't bootstrap because Juju is parsing stderr text from flock, and his server isn't in English, so the error message isn't matching. https://github.com/juju/juju/blob/master/environs/sshstorage/storage.go#L254 Now, I think we all know that parsing error text is a bad idea, but I think I understand why it was done - it looks like flock the application only returns 1 on this failure, so it's not exactly a unique error code. However, flock the system call returns several different error codes, which are quite unique and easy to handle in a way that is not dependent on the language of the machine. It also happens to be already implemented in the syscalls package: http://golang.org/pkg/syscall/#Flock So let's fix this, and try not to call out to bash unless there's absolutely no other way. -Nate -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Please don't use bash when there are syscalls available
Worth keeping in mind the usual gotcha: the API of syscall is different for different OSes. On Tue, Sep 9, 2014 at 5:45 PM, Nate Finch nate.fi...@canonical.com wrote: A user just complained that he can't bootstrap because Juju is parsing stderr text from flock, and his server isn't in English, so the error message isn't matching. https://github.com/juju/juju/blob/master/environs/sshstorage/storage.go#L254 Now, I think we all know that parsing error text is a bad idea, but I think I understand why it was done - it looks like flock the application only returns 1 on this failure, so it's not exactly a unique error code. However, flock the system call returns several different error codes, which are quite unique and easy to handle in a way that is not dependent on the language of the machine. It also happens to be already implemented in the syscalls package: http://golang.org/pkg/syscall/#Flock So let's fix this, and try not to call out to bash unless there's absolutely no other way. -Nate -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- gustavo @ http://niemeyer.net -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Important Blocking Bug
https://bugs.launchpad.net/juju-core/+bug/1367431 Someone from the down under crew, please take a look at this, since the US is currently at EOD or nearly so. -Nate -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Important Blocking Bug
Given that I merged a big upgrade related change yesterday, this could be me (although I did test it extensively manually). I'll take a look. On 10 September 2014 09:01, Nate Finch nate.fi...@canonical.com wrote: https://bugs.launchpad.net/juju-core/+bug/1367431 Someone from the down under crew, please take a look at this, since the US is currently at EOD or nearly so. -Nate -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: reviewboard
On 10/09/14 02:47, Eric Snow wrote: On Mon, Sep 8, 2014 at 8:05 PM, Tim Penhey tim.pen...@canonical.com wrote: On 09/09/14 04:32, Eric Snow wrote: To install rbt: sudo pip install --allow-unverified rbtools --allow-external rbtools rbtools Ah... no. Perhaps in a virtual env. Is it the sudo or the flags to which you object? :) Using a virtualenv would indeed be a good idea! So, as a correction to my previous instructions: It is the combination of sudo, pip, and allow-unverified. All my python packages that are not installed by system debs are in virtual environments. Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Important Blocking Bug
I've looked into this a bit and the problem is due to one of the machines being unable to download tools for the upgrade. This could be due to the recent changes in tools storage. Ian has now taken over. On 10 September 2014 09:11, Menno Smits menno.sm...@canonical.com wrote: Given that I merged a big upgrade related change yesterday, this could be me (although I did test it extensively manually). I'll take a look. On 10 September 2014 09:01, Nate Finch nate.fi...@canonical.com wrote: https://bugs.launchpad.net/juju-core/+bug/1367431 Someone from the down under crew, please take a look at this, since the US is currently at EOD or nearly so. -Nate -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Important Blocking Bug
Yep, most likely related to my changes. I'm taking a look too. Thanks Menno. On Wed, Sep 10, 2014 at 6:11 AM, Menno Smits menno.sm...@canonical.com wrote: I've looked into this a bit and the problem is due to one of the machines being unable to download tools for the upgrade. This could be due to the recent changes in tools storage. Ian has now taken over. On 10 September 2014 09:11, Menno Smits menno.sm...@canonical.com wrote: Given that I merged a big upgrade related change yesterday, this could be me (although I did test it extensively manually). I'll take a look. On 10 September 2014 09:01, Nate Finch nate.fi...@canonical.com wrote: https://bugs.launchpad.net/juju-core/+bug/1367431 Someone from the down under crew, please take a look at this, since the US is currently at EOD or nearly so. -Nate -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Please don't use bash when there are syscalls available
On Wed, Sep 10, 2014 at 4:45 AM, Nate Finch nate.fi...@canonical.com wrote: A user just complained that he can't bootstrap because Juju is parsing stderr text from flock, and his server isn't in English, so the error message isn't matching. https://github.com/juju/juju/blob/master/environs/sshstorage/storage.go#L254 Now, I think we all know that parsing error text is a bad idea, but I think I understand why it was done - it looks like flock the application only returns 1 on this failure, so it's not exactly a unique error code. However, flock the system call returns several different error codes, which are quite unique and easy to handle in a way that is not dependent on the language of the machine. It also happens to be already implemented in the syscalls package: http://golang.org/pkg/syscall/#Flock So let's fix this, and try not to call out to bash unless there's absolutely no other way. This is running on a remote system before there is any code deployed. I won't say there's *no other way*, but you can't invoke syscalls from out of thin air. Finally, that error message check has nothing to do with flock. It's checking the result of I/O redirection to base64. Agreed that parsing the message is dumb. We can fix this with an explicit file existence check in the command executed ((test -e $path || echo blah2)||base64$path) or so. In the not too distant future, we will have no need for sshstorage at all (except in past, supported releases). -Nate -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Please don't use bash when there are syscalls available
If we do need to parse the error message, we could use the LANG=C trick. But yes, I'd rather avoid it if possible. John =:- On Wed, Sep 10, 2014 at 2:56 AM, Andrew Wilkins andrew.wilk...@canonical.com wrote: On Wed, Sep 10, 2014 at 4:45 AM, Nate Finch nate.fi...@canonical.com wrote: A user just complained that he can't bootstrap because Juju is parsing stderr text from flock, and his server isn't in English, so the error message isn't matching. https://github.com/juju/juju/blob/master/environs/sshstorage/storage.go#L254 Now, I think we all know that parsing error text is a bad idea, but I think I understand why it was done - it looks like flock the application only returns 1 on this failure, so it's not exactly a unique error code. However, flock the system call returns several different error codes, which are quite unique and easy to handle in a way that is not dependent on the language of the machine. It also happens to be already implemented in the syscalls package: http://golang.org/pkg/syscall/#Flock So let's fix this, and try not to call out to bash unless there's absolutely no other way. This is running on a remote system before there is any code deployed. I won't say there's *no other way*, but you can't invoke syscalls from out of thin air. Finally, that error message check has nothing to do with flock. It's checking the result of I/O redirection to base64. Agreed that parsing the message is dumb. We can fix this with an explicit file existence check in the command executed ((test -e $path || echo blah2)||base64$path) or so. In the not too distant future, we will have no need for sshstorage at all (except in past, supported releases). -Nate -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Juju Actions - Use Cases
On 10/09/14 06:59, John Weldon wrote: Hi; We're looking for use cases for Juju Actions, mostly to make sure we expose the right API. I'm hoping for a few different use cases from the Juju Web UI folks, but I'd appreciate input from anyone wanting to use Juju Actions in their charms too. I've started a document with some example use cases to prime the pump: please contribute to this document and don't feel constrained to the style or layout I adopted for the examples. If you have any interest or investment in using or publishing Actions for Juju please review and contribute! Google Docs Link https://docs.google.com/document/d/1uYffkkGA1njQ1oego_h8BYBMrlGpmN_lwsnrOZFxE9Q/edit?usp=sharing I'd love to see explicit backup/restore actions for the postgresql charm. Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
