Re: Having trouble with the block-storage-broker and ec2

[Tim Penhey]

On 15/08/14 15:27, Charles Butler wrote:
> Thread Necromancy,
> 
> 
> Have we had any movement on this Tim? If not I'd like to file a bug to
> move the BSP off of the euca2ools and instead use either the AWS SDK or
> write API client wrappers for this.

I've not done anything, but I'd agree that the best approach would be to
move BSP off euca2ools.  Or at least have the trusty one work a
different API.

Tim




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

Re: Having trouble with the block-storage-broker and ec2

[Charles Butler]

Thread Necromancy,


Have we had any movement on this Tim? If not I'd like to file a bug to move
the BSP off of the euca2ools and instead use either the AWS SDK or write
API client wrappers for this.

Thanks!


On Thu, Jun 26, 2014 at 5:07 AM, Tim Penhey 
wrote:

> On 07/06/14 00:29, Andreas Hasenack wrote:
> > On Fri, Jun 6, 2014 at 7:39 AM, Tim Penhey  > > wrote:
> >
> > options:
> > provider: ec2
> > key: 
> > endpoint: WHAT_GOES_HERE???
> > secret: 
> >
> >
> >
> > For ec2, it's like https://ec2.us-west-2.amazonaws.com (adjust for your
> > region).
> >
> > For openstack, it's keystone.
>
> OK, finally got back around to trying to get postresql working with the
> storage subordinate and the block-storage-broker.
>
> But adding the relations causes the following error (I hope this stack
> trace is shown better for you than me):
>
> INFO juju-log block-storage:2: Validated charm configuration credentials
> have access to block storage service
> INFO block-storage-relation-changed Traceback (most recent call last):
> INFO block-storage-relation-changed   File
>
> "/var/lib/juju/agents/unit-block-storage-broker-0/charm/hooks/block-storage-relation-changed",
> line 144, i05:07 INFO block-storage-relation-changed
> hooks.execute(sys.argv)
> INFO block-storage-relation-changed   File
>
> "/var/lib/juju/agents/unit-block-storage-broker-0/charm/hooks/charmhelpers/core/hookenv.py",
> line 381, in 07 INFO block-storage-relation-changed
> self._hooks[hook_name]()
> INFO block-storage-relation-changed   File
>
> "/var/lib/juju/agents/unit-block-storage-broker-0/charm/hooks/block-storage-relation-changed",
> line 128, i06-26 08:05:07 INFO block-storage-relation-changed
> volume_label=volume_label)
> INFO block-storage-relation-changed   File
> "/var/lib/juju/agents/unit-block-storage-broker-0/charm/hooks/util.py",
> line 159, in attach_volume
> INFO block-storage-relation-changed volume_id =
> self.get_volume_id(volume_label)
> INFO block-storage-relation-changed   File
> "/var/lib/juju/agents/unit-block-storage-broker-0/charm/hooks/util.py",
> line 93, in get_volume_id
> INFO block-storage-relation-changed volumes = self.describe_volumes()
> INFO block-storage-relation-changed   File
> "/var/lib/juju/agents/unit-block-storage-broker-0/charm/hooks/util.py",
> line 83, in describe_volumes
> INFO block-storage-relation-changed return method(volume_id)
> INFO block-storage-relation-changed   File
> "/var/lib/juju/agents/unit-block-storage-broker-0/charm/hooks/util.py",
> line 267, in _ec2_describe_volumes
> INFO block-storage-relation-changed volumes = command.main()
> INFO block-storage-relation-changed   File
> "/usr/lib/python2.7/dist-packages/requestbuilder/request.py", line 182,
> in main
> INFO block-storage-relation-changed response = self.send()
> INFO block-storage-relation-changed   File
> "/usr/lib/python2.7/dist-packages/requestbuilder/request.py", line 130,
> in send
> INFO block-storage-relation-changed data=self.body)
> INFO block-storage-relation-changed   File
> "/usr/lib/python2.7/dist-packages/requestbuilder/service.py", line 204,
> in send_request
> INFO block-storage-relation-changed data, headers)
> INFO block-storage-relation-changed   File
> "/usr/lib/python2.7/dist-packages/requestbuilder/service.py", line 264,
> in __log_and_send_request
> INFO block-storage-relation-changed self.auth(request)
> INFO block-storage-relation-changed   File
> "/usr/lib/python2.7/dist-packages/requestbuilder/auth.py", line 249, in
> __call__
> INFO block-storage-relation-changed signature =
> self.sign_string(to_sign)
> INFO block-storage-relation-changed   File
> "/usr/lib/python2.7/dist-packages/requestbuilder/auth.py", line 265, in
> sign_string
> INFO block-storage-relation-changed req_hmac =
> hmac.new(self.args['secret_key'], digestmod=hashlib.sha256)
> INFO block-storage-relation-changed   File "/usr/lib/python2.7/hmac.py",
> line 133, in new
> INFO block-storage-relation-changed return HMAC(key, msg, digestmod)
> INFO block-storage-relation-changed   File "/usr/lib/python2.7/hmac.py",
> line 72, in __init__
> INFO block-storage-relation-changed
> self.outer.update(key.translate(trans_5C))
> INFO block-storage-relation-changed TypeError: character mapping must
> return integer, None or unicode
>
> google tells me that the python hmac function doesn't accept unicode,
> but I'm not sure where that is coming from.
>
> I have taken the precise charms for postgresql, storage, and
> block-storage-broker and deployed them on trusty for this.
>
> Anyone got suggestions?
>
> Tim
>
> --
> 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: No icon = no promulgation?

[Sebastian]

Something to think, if we want to deliver quality experience to our users,
details such the icon will impact aggressively. So yes, for me as a user
and charm developer, having an icon was one of the first things I did, and
wasn't all that difficult, it's well documented and material design (the
provided svg file).

Would like to quote a philosophy inspired in what Steve Jobs said ones.

- He said that his father refused to use poor wood for the back of
cabinets, or to build a fence that wasn’t constructed as well on the back
side as it was the front. Jobs likened it to using a piece of plywood on
the back of a beautiful chest of drawers. “For you to sleep well at night,
the aesthetic, the quality, has to be carried all the way through.”
Source:
http://thenextweb.com/apple/2011/10/24/steve-jobs-obsession-with-the-quality-of-the-things-unseen/

Cheers,
Sebas.
Em 14/08/2014 17:02, "José Antonio Rey"  escreveu:

>
> On Aug 14, 2014 12:24 PM, "Richard Harding" 
> wrote:
> > I'd suggest to work with the author to use either the default charm icon
> or
> > a category icon and move the charm forward.
>
> As far as I know, the default category icon is applied when no icon is
> available.
>
> On the other hand, there are currently charms with no icon. How would we
> deal with those?
>
> --
> 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: No icon = no promulgation?

[José Antonio Rey]

On Aug 14, 2014 12:24 PM, "Richard Harding" 
wrote:
> I'd suggest to work with the author to use either the default charm icon
or
> a category icon and move the charm forward.

As far as I know, the default category icon is applied when no icon is
available.

On the other hand, there are currently charms with no icon. How would we
deal with those?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: A highlight on Personal Namespace charms in the Juju Charm Store

[Sebastian]

Thanks Charles!! Awesome post and subject.

Cheers,
Sebas.
Em 14/08/2014 16:05, "Charles Butler"  escreveu:

> I wrote a quick blog post over the preferred charm submission process when
> getting involved with Juju. Not many users understand the process of
> personal namespace charming, how it works, and WHY it's such a great method
> to get moving with charming.
>
> http://blog.dasroot.net/the-power-of-community-charming/
>
>
>
> --
> 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

A highlight on Personal Namespace charms in the Juju Charm Store

[Charles Butler]

I wrote a quick blog post over the preferred charm submission process when
getting involved with Juju. Not many users understand the process of
personal namespace charming, how it works, and WHY it's such a great method
to get moving with charming.

http://blog.dasroot.net/the-power-of-community-charming/
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: No icon = no promulgation?

[Richard Harding]

On Wed, 13 Aug 2014, José Antonio Rey wrote:

> Hello,
>
> As I am subscribed to all bugs in Juju (as some of you may also be),
> today I got an email from a CakePHP charm review. On this one, a charmer
> had to reject the submission because, when promulgating, the tool runs
> `charm proof` to make sure things are not broken, not promulgating if
> any Error or Warning pops up. And there was a problem: this charm did
> not have an icon (which throws a Warning in `charm proof`, making it
> impossible to promulgate it.

Yes, charm checks are broken down into a couple of classes.

Warnings are things that allow a personal charm to be uploaded and served
to other users, but are required to be updated for promulgation.

Errors, are obvious things that we think are issues for charms regardless
of a personal branch or not. If a user uploads a charm with a proof error
it will never be ingested and put forth to users.

> I totally understand what has been done. Now, a charm cannot be
> promulgated when there are Errors or Warnings. But since not having an
> icon is a Warning, it will not allow a charmer to promulgate any charms
> which do not contain an icon, may it be because the author is asking for
> official permission (like in this case), because the service has no
> icon, or any other reasons. In some of the cases, it may be a
> fully-working charm, with no other issues apart from not having an icon.
> We even have lots of charms with no icon in the store. And about
> proposing a temporary icon, when I proposed an icon which was just an
> orange background with the service name, it got rejected. So, I don't
> know what may be an idea for a 'temporary' or 'provisional' icon.

We supply a starter file for an icon. The policy/proof is that the file is
there and is an svg image of the right sizes. I think that there are a
number of ways around this by helping the author use our default icon or
even one of our category icons that might fit in place in order to meet the
requirement for now.

> I believe having an icon is not that of a priority, and that we should
> focus in having charms that provide working services. Still, we should
> try to ensure and promote the idea of charms having icons, but I do not
> see it as a fatal error like to prevent promulgation.

Sorry, I hate to disagree here. We're building tools like the Juju GUI in
order to help users have a nice experience browsing charms. Every other
store, from Firefox/Chrome extensions to Apple/Android app stores require
an icon and sometimes even more to submit material. Promulgated material is
meant to go through curation to make sure we filter material to those that
provide the best experience and represent Juju. I think an icon is part of
that, not functionally I admit, but visually in the GUI environment and
browsing experience.

> In this case, I would be for demoting the level of the warning issued by
> `charm proof` from Warning to Information. This, as it is not something
> critical, and charms/services will still work, even with no icon. It
> doesn't affect functionality, but it only removes the pretty part (that
> can be added later) of the GUI. By doing this, we will throw something
> when `charm proof` is ran, but still allow promulgation if there is no icon.
>
> What do you guys think about it?

I'd suggest to work with the author to use either the default charm icon or
a category icon and move the charm forward. I also think it'd be good to
work with the author and perhaps provide some additional help in getting
permission for a real icon. In checking the license, it's a CC license, but
is no derivatives. Perhaps our community folks can help the author
demonstrate that permitting a derivative in the case of the charm is only
good for CakePHP users.

Please let me know if you disagree or want to setup a chat in person. I
understand the frustration of the icon, but I feel it's very important in
getting our best foot forward to users of Juju out there.

--

Rick Harding

Juju UI Engineering
https://launchpad.net/~rharding
@mitechie

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

Re: No icon = no promulgation?

[David Britton]

Also... the docs for authoring an icon are really quite straight-forward
and well explained.  Even myself with negative-artistic ability was able
to do it on a couple of occasions.  :)

https://juju.ubuntu.com/docs/authors-charm-icon.html

-- 
David Britton 

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

Re: No icon = no promulgation?

[Matt Bruzek]

Hello José,

Thanks for sending this email out.  Your commitment to the Juju community
is pretty impressive.  What you did not mention in your email is the reason
you were subscribed to this bug is because you performed a community review
of this charm for us.  That is something I really appreciate, and want to
thank you again for reviewing the charm.

What we have here is a policy question.  Should we be able to promulgate
charms without icons?  In an ideal world, I want an icon for each charm but
in the real world I live in, not every charm has an icon.  Do I want to
make that better?  Heck yeah I do!  So I agree with the policy.

The old saying goes there is an exception to every rule.  I believe this
charm qualifies for an exception because of the circumstances.  The author
has asked for approval to use an official icon and has received no
response.  So my question to the group is:  Should there be an exception
process that we can follow for situations like this?  For example could the
charmers take a vote on the issue, or send a message to the community.  I
am looking for a pragmatic way to handle a minor exception to policy.

Incidentally, I am working with the author to create an icon for this charm
and hope to have something *soon* so we an add CakePHP to our ecosystem!

   - Matt Bruzek 


On Wed, Aug 13, 2014 at 11:48 PM, José Antonio Rey  wrote:

> Hello,
>
> As I am subscribed to all bugs in Juju (as some of you may also be),
> today I got an email from a CakePHP charm review. On this one, a charmer
> had to reject the submission because, when promulgating, the tool runs
> `charm proof` to make sure things are not broken, not promulgating if
> any Error or Warning pops up. And there was a problem: this charm did
> not have an icon (which throws a Warning in `charm proof`, making it
> impossible to promulgate it.
>
> I totally understand what has been done. Now, a charm cannot be
> promulgated when there are Errors or Warnings. But since not having an
> icon is a Warning, it will not allow a charmer to promulgate any charms
> which do not contain an icon, may it be because the author is asking for
> official permission (like in this case), because the service has no
> icon, or any other reasons. In some of the cases, it may be a
> fully-working charm, with no other issues apart from not having an icon.
> We even have lots of charms with no icon in the store. And about
> proposing a temporary icon, when I proposed an icon which was just an
> orange background with the service name, it got rejected. So, I don't
> know what may be an idea for a 'temporary' or 'provisional' icon.
>
> I believe having an icon is not that of a priority, and that we should
> focus in having charms that provide working services. Still, we should
> try to ensure and promote the idea of charms having icons, but I do not
> see it as a fatal error like to prevent promulgation.
>
> In this case, I would be for demoting the level of the warning issued by
> `charm proof` from Warning to Information. This, as it is not something
> critical, and charms/services will still work, even with no icon. It
> doesn't affect functionality, but it only removes the pretty part (that
> can be added later) of the GUI. By doing this, we will throw something
> when `charm proof` is ran, but still allow promulgation if there is no
> icon.
>
> What do you guys think about it?
>
> --
> José Antonio Rey
>
> --
> 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: ~charmers Application - David Britton

[Matt Bruzek]

David,

You have been a great member of the Juju community.  There have been
several occasions that you have helped me out and I really appreciate
that.

+ 1 from me on promotion to charmer status!

   - Matt Bruzek 


On Fri, Aug 8, 2014 at 9:31 PM, David Britton 
wrote:

>
> Hi Charmers --
>
> Here you will find my application for inclusion into the charmers group.
>
> I have been using and developing charms for juju since the pyjuju days,
> while it was being renamed to juju from ensemble.  I have authored a
> number of charms (Some public, some just for personal use), and made
> significant contributions to many more.
>
> At my day job, I work for Canonical on the Landscape team.  This has
> afforded me the opportunity to work on those charms we use most to
> faciliate our products (apache2, postgresql, haproxy).  I have made a
> number of visible contributions to these from small bug fixes to large
> features.
>
> Our own charms (landscape-server, landscape-client) are maintained under
> the "~landcape-charmers" team, of which I'm a member.  We even have a
> separate project (landscape-charm) in launchpad for tighter control of
> our development process on our landscape-server charm -- these charms
> are both fully open source (GPLv2).
>
> We have a fairly extensive internal testing infrastructure for our
> landscape charms where we spin them up in different combinations daily
> (trusty, precise, multiple versions of Landscape, etc).  We do this all
> with "juju test" at an integration level.  We also have a full and
> comprehensive unit test suites for each of our charms.
>
> Recently, I desinged, implemented and now maintain (with much help from
> my fellow team members) the storage charm, and the block-storage-broker
> charm.  These charms allow other services to request, assiociate and
> mount cloud storage in a juju-friendly way.  I'm hoping to see wider
> adoption of these.
>
> I have contributed to the openstack charm collection in a number of
> ways, testing, debugging, contributing patches, etc.
>
> Past these charm specific contributions, I also test, file bugs and
> contribute patches back to other juju products (juju-deployer,
> charm-tools, charm-helpers, juju-core, juju-gui, ...) on a regular
> basis.
>
> Lastly, I am a heavy user of Juju, maintaining many of our teams
> internal services with it -- so I undersatnd the need to have charm
> quality and robustness.  I also am very aware of making sure full
> solutions work, not *just* individual charms.
>
> Here are some of the charms where I've made significant contributions
> (authorship-level):
>
> https://jujucharms.com/precise/landscape-server
> https://jujucharms.com/precise/landscape-client
> https://jujucharms.com/precise/storage
> https://jujucharms.com/precise/block-storage-broker
>
> Charms I've conrtibuted major changes to:
>
> https://jujucharms.com/precise/haproxy
> https://jujucharms.com/precise/apache2
>
> A couple larger MPs that I have authored:
>
>
> https://code.launchpad.net/~davidpbritton/charms/precise/haproxy/fix-service-entries/+merge/202387
>
> https://code.launchpad.net/~davidpbritton/charms/precise/apache2/vhost-config-relation/+merge/220295
>
> https://code.launchpad.net/~davidpbritton/charms/trusty/apache2/avoid-regen-cert/+merge/223990
>
>
> Feel free to ask me any questions, and thanks for your consideration.
>
> :-)
>
> --
> David Britton 
>
> --
> 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: No icon = no promulgation?

[Marco Ceppi]

It's not an Informational, it's actually a warning because it negatively
impacts the juju ecosystem OR is part of charm policy (both of which are
true). I sympathize with the author and am super appreciative of the amount
of work the author is doing by getting proper permission for use of their
logo in the icon. However, I don't see an issue with the author creating a
temporary icon with text on an appropriate background while waiting to
receive proper permission for the icon. An icon is better than no icon.

As for your experience, I don't recall temporary icons being rejected,
could it be that you didn't make it clear it was a temporary icon?

Finally, and a very *very* important piece of information. The charm *is* in
the charm store. It's available under their namespace cs:~lpuser/charm and
nothing stopping it from being found
https://jujucharms.com/~fgimenez/trusty/cakephp-7/ There's nothing wrong
with saying "You've done a great job, but an icon is needed to be
considered */a recommended charm/*" which is what the review process is
doing. Promoting it to a "reviewed" status, not promoting it to the charm
store.

Not a final say, but my opinion on the situation.

Marco


On Thu, Aug 14, 2014 at 12:48 AM, José Antonio Rey  wrote:

> Hello,
>
> As I am subscribed to all bugs in Juju (as some of you may also be),
> today I got an email from a CakePHP charm review. On this one, a charmer
> had to reject the submission because, when promulgating, the tool runs
> `charm proof` to make sure things are not broken, not promulgating if
> any Error or Warning pops up. And there was a problem: this charm did
> not have an icon (which throws a Warning in `charm proof`, making it
> impossible to promulgate it.
>
> I totally understand what has been done. Now, a charm cannot be
> promulgated when there are Errors or Warnings. But since not having an
> icon is a Warning, it will not allow a charmer to promulgate any charms
> which do not contain an icon, may it be because the author is asking for
> official permission (like in this case), because the service has no
> icon, or any other reasons. In some of the cases, it may be a
> fully-working charm, with no other issues apart from not having an icon.
> We even have lots of charms with no icon in the store. And about
> proposing a temporary icon, when I proposed an icon which was just an
> orange background with the service name, it got rejected. So, I don't
> know what may be an idea for a 'temporary' or 'provisional' icon.
>
> I believe having an icon is not that of a priority, and that we should
> focus in having charms that provide working services. Still, we should
> try to ensure and promote the idea of charms having icons, but I do not
> see it as a fatal error like to prevent promulgation.
>
> In this case, I would be for demoting the level of the warning issued by
> `charm proof` from Warning to Information. This, as it is not something
> critical, and charms/services will still work, even with no icon. It
> doesn't affect functionality, but it only removes the pretty part (that
> can be added later) of the GUI. By doing this, we will throw something
> when `charm proof` is ran, but still allow promulgation if there is no
> icon.
>
> What do you guys think about it?
>
> --
> José Antonio Rey
>
> --
> 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