Re: [Openstack-operators] Adding v1 LIKE support to python-glanceclient releases 1.x.x

2015-09-14 Thread Flavio Percoco 

On 09/09/15 21:46 -0400, Clayton O'Neill wrote:

I'd be glad to see the backwards compatibility parts go in.  I got bitten by
this earlier this week and ended up switching my scripts over to using the
python-openstackclient library to work around it.



Hey Clayton,

Thanks for the feedback.

Could you be more precise on what incompatibility affected you?

The patch that Nikhil linked in his email brings in several
"compatibilities" with v1. I personally think they should be examined
1 by 1 rather than pulling them all in, hence my question.

Switching to python-openstack client must have required some effort
and I'm curious to know why you decided to do that rather than
adapting your scripts to use the v2 cli. Do you have Glance's v2
deployed?

Ideally, I think we should just move to use openstackclient, really.
But glanceclient is what we have now and that's what the Glance team
has focused on the most lately so I'd appreaciate as much feedback as
possible from you and others.

Thanks for your time,
Flavio



On Wed, Sep 9, 2015 at 6:41 PM, Nikhil Komawar  wrote:

   Hi all,

   We recently release python-glanceclient 1.0.0 and it has the default
   shell version as v2. This may result into some scripts not detecting the
   change by default and discomfort to an extent.

   So, I am reaching out to this list with the hope of getting some
   feedback on the requirements, pros and cons you all think exist for
   adding some support for v1 like calls as hidden command to the default
   python-glanceclient shell API that is v2 centric by default. This should
   unbreak the scripts to an extent and give a warning to users to update
   the scripts in a stipulated time period so that they use the v2 API.

   Here's the proposed patch https://review.openstack.org/#/c/219802/ . We
   are not yet sure if we need to get it merged by tomorrow so that it can
   be in stable/liberty by the end of the week. There has been one request
   to get those in and the feedback we received from the developer
   community was neutral.

   In order to form an opinion on what's best for our users, we need some
   feedback on this topic. Please send us your thoughts as soon as possible
   and we will try to accommodate the same if permissible within the
   technical limitations:

   1. Whether you would like these commands added as hidden commands so
   that shell API works like before (to extent possible).
   2. You would like to use v2 shell API of the client by default and don't
   care about this commit.
   3. You don't care about the change. Your scripts are awesome and can
   adjust to the upgrade of the client easily.
   4. Anything else.
  
   --


   Thanks,
   Nikhil


   ___
   OpenStack-operators mailing list
   OpenStack-operators@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators





___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



--
@flaper87
Flavio Percoco


pgpdHvfcNV6Cq.pgp
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Adding v1 LIKE support to python-glanceclient releases 1.x.x

2015-09-14 Thread Clayton O'Neill 
I ran into this issue on my laptop where I had just pip installed glance
client and gotten the latest version.  The script I was working on I want
to run in multiple environments, so it was easier to rely on the openstack
client which has the same CLI API (and generally easier to integrate with)
than to make it work with two versions of the glance client or to force a
specific version on systems I may not control.

I don't remember the exact behavior change that bit me, but since it was
trying to upload an image if it didn't already exist by name, I suspect
that it was the --is-public/--is-protected change.

I think one of the issues here is that a lot of our users also install from
pip, and from their standpoint this is an "unannounced" change.  Not
because it's literally unannounced, but because many of them probably don't
install specific versions of the clients even though we do recommend
specific versions.  From their standpoint I think they consider this
"unannounced" mostly because I doubt any of them follow any of the mailing
lists where it would have been announced.  I'm not sure what the right
answer here is, but it's definitely a difficult situation.

On Mon, Sep 14, 2015 at 7:18 AM, Flavio Percoco  wrote:

> On 09/09/15 21:46 -0400, Clayton O'Neill wrote:
>
>> I'd be glad to see the backwards compatibility parts go in.  I got bitten
>> by
>> this earlier this week and ended up switching my scripts over to using the
>> python-openstackclient library to work around it.
>>
>
>
> Hey Clayton,
>
> Thanks for the feedback.
>
> Could you be more precise on what incompatibility affected you?
>
> The patch that Nikhil linked in his email brings in several
> "compatibilities" with v1. I personally think they should be examined
> 1 by 1 rather than pulling them all in, hence my question.
>
> Switching to python-openstack client must have required some effort
> and I'm curious to know why you decided to do that rather than
> adapting your scripts to use the v2 cli. Do you have Glance's v2
> deployed?
>
> Ideally, I think we should just move to use openstackclient, really.
> But glanceclient is what we have now and that's what the Glance team
> has focused on the most lately so I'd appreaciate as much feedback as
> possible from you and others.
>
> Thanks for your time,
> Flavio
>
>
>
>> On Wed, Sep 9, 2015 at 6:41 PM, Nikhil Komawar 
>> wrote:
>>
>>Hi all,
>>
>>We recently release python-glanceclient 1.0.0 and it has the default
>>shell version as v2. This may result into some scripts not detecting
>> the
>>change by default and discomfort to an extent.
>>
>>So, I am reaching out to this list with the hope of getting some
>>feedback on the requirements, pros and cons you all think exist for
>>adding some support for v1 like calls as hidden command to the default
>>python-glanceclient shell API that is v2 centric by default. This
>> should
>>unbreak the scripts to an extent and give a warning to users to update
>>the scripts in a stipulated time period so that they use the v2 API.
>>
>>Here's the proposed patch https://review.openstack.org/#/c/219802/ .
>> We
>>are not yet sure if we need to get it merged by tomorrow so that it can
>>be in stable/liberty by the end of the week. There has been one request
>>to get those in and the feedback we received from the developer
>>community was neutral.
>>
>>In order to form an opinion on what's best for our users, we need some
>>feedback on this topic. Please send us your thoughts as soon as
>> possible
>>and we will try to accommodate the same if permissible within the
>>technical limitations:
>>
>>1. Whether you would like these commands added as hidden commands so
>>that shell API works like before (to extent possible).
>>2. You would like to use v2 shell API of the client by default and
>> don't
>>care about this commit.
>>3. You don't care about the change. Your scripts are awesome and can
>>adjust to the upgrade of the client easily.
>>4. Anything else.
>>  --
>>
>>Thanks,
>>Nikhil
>>
>>
>>___
>>OpenStack-operators mailing list
>>OpenStack-operators@lists.openstack.org
>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
> --
> @flaper87
> Flavio Percoco
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Gnocchi] Some update on Grafana support

2015-09-14 Thread Julien Danjou 
Hi folks,

I've just published a little blog post about the job we've been working
on with the rest of the Gnocchi team: adding support for Gnocchi¹ in
Grafana². As Gordon pointed out, that might be of some interest for some
of you, so I'll leave that here:

  https://julien.danjou.info/blog/2015/openstack-gnocchi-grafana


Feel free to reach me if you have questions.


¹  http://launchpad.net/gnocchi

²  http://grafana.org

-- 
Julien Danjou
-- Free Software hacker
-- http://julien.danjou.info


signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-operators] Announcement! We have everything ready to get to Stackforge!

2015-09-14 Thread JJ Asghar 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 9/2/15 2:21 PM, JJ Asghar wrote:
> 
> I've put the review[1] and it looks like it's pretty good.

I'd like to announce it has been merged!

> 
> I've created a launchpad[2] with both answers[3] and bugs[4] to help
> organize this code base.
> 
> I've also created an initial wiki[5] page too to start help
> bootstrapping this.
> 
> [1]: https://review.openstack.org/#/c/219760/
> [2]: http://launchpad.net/osops
> [3]: https://answers.launchpad.net/osops
> [4]: https://bugs.launchpad.net/osops
> [5]: https://wiki.openstack.org/wiki/Osops
> 

Now the real work starts. It seems the core reviewers havent been set up
yet, I'm taking this Action Item to get resolved asap. I've reached out
to a lot of yall, and thank you for agreeing to step up.

Any other relevant info I'll pass along, otherwise this is great news!

- -J
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV9zZSAAoJEDZbxzMH0+jTd90P/2L3AsqZbh/T8eHSb8rC+hLb
Fp+v/rNXWmtPGCdzoc1ala8eZfQxFviJGz9ksljlQICGbEZJRl5HNdbbyLZmsxEA
Kld+fPC/OdWKmtWXcHT3kAiHTbBwfsbucitqBN79Z0u/Fj0tKF0h7EoBDEH4kFAw
SsZNT7ZE5kJkXVvwZnV5MWa7kPiFCCF8eIQW2N4eal9Q6hzfOkgoP9vDhjJH9MX0
ei8eIwJuH2TZK8w3iRBsxolnnCdI5QzBp3rrUq4ESLUbPjSuEMGP2/lws1purKlk
ZlDlLwRalr0tCITVjCIvMWBkyOznoJtfBcingcr8aZJRCkoJhWVl/2cutIXWSiAT
++v790lUPtAyc652VCQURV0BB4hOyDkhAuxVN27/JNbP3+sFlFqlIrYtjf5rGgVc
7sK3mXtzsfMNmVDk344JTCb5VF/vtlvPuMDbVeIIA2fyhdITkb7cinoB/l6Kg0bM
SLnN7zjsciw5IaoEzjcS80lLfiRD3VmNBPj8wHok3YLKo/APVZjORSKP142Tci6Z
Lfp7ktuLXJc9pspVaIcFnHqvq2/zbZR6dBbb5qCs9HombU+W2FUb2qFHFOs2VXdF
yMWIoH1ZBjoBL8FCPktkqjMrdEA5uLt2UhGtqanBZqdGcj2ZYTpHNYU0l8ul9gvu
we+X3XiUqr4XjtfbtPgX
=eGuQ
-END PGP SIGNATURE-

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [tags] Results of PAO Ops Meeting

2015-09-14 Thread Gareth 
There's rally meeting tonight. I would like to ask him :) I guess
Boris like this very much

On Mon, Sep 14, 2015 at 2:26 PM, Tom Fifield  wrote:
> On 14/09/15 13:12, Gareth wrote:
>>
>> BTW, does Boris reply the "works in rally" tag?
>
>
> Noone's asked yet :) Anyone feel like asking the Rally team?
>
>
>
>> On Mon, Sep 14, 2015 at 12:49 PM, Tom Fifield  wrote:
>>>
>>> Hi all,
>>>
>>> A quick update from our tags team meeting in Palo Alto last month.
>>>
>>> 1) Containerizable - new tag
>>>
>>> David Medberry suggested and then submitted a patch to start discussion
>>> around a tag for whether or not a service is containerizable  - which is
>>> hard-won knowledge that was deemed nice to have during the containers
>>> session of the meetup.
>>>
>>> Read and comment on the review here:
>>> https://review.openstack.org/#/c/214801/
>>>
>>>
>>> 2) Scalable - not possible to tag
>>>
>>> Using the large number of scaling problems with Ceilometer as an example,
>>> in
>>> addition to many other ideas, we did a deep dive into how a tag related
>>> to
>>> scalability would be implemented.
>>>
>>> The end conclusion was that whether a service scales or not is extremely
>>> complex information and has an associated decision making process that
>>> means
>>> it isn't possible to condense into a tag or even a few tags. The only
>>> real
>>> way to do this is to provide information about example deployments (eg
>>> rax,
>>> cern)
>>>
>>> 3) "works in rally" - new tag suggestion
>>>
>>> There was general interest in asking the Rally team to consider making a
>>> "works in rally" tag, since the rally tests were deemed 'good'.
>>>
>>>
>>>
>>> There were a number of other suggestions, including some items to propose
>>> to
>>> the software projects for consideration. All that and more can be found
>>> at
>>> the etherpad: https://etherpad.openstack.org/p/PAO-ops-tags
>>>
>>> Your comments are welcome, and as always, patches visible and submitted
>>> to:
>>>
>>>
>>> https://review.openstack.org/#/q/status:open+project:stackforge/ops-tags-team,n,z
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>> Tom
>>>
>>> ___
>>> OpenStack-operators mailing list
>>> OpenStack-operators@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
>>
>



-- 
Gareth

Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball
OpenStack contributor, kun_huang@freenode
My promise: if you find any spelling or grammar mistakes in my email
from Mar 1 2013, notify me
and I'll donate $1 or ￥1 to an open organization you specify.

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [tags] Results of PAO Ops Meeting

2015-09-14 Thread Thierry Carrez 
Tom Fifield wrote:
> A quick update from our tags team meeting in Palo Alto last month.
> [...]
> 1) Containerizable - new tag 

Great idea, and having downstream assess that is certainly the best
approach.

> [...]
> 3) "works in rally" - new tag suggestion
> 
> There was general interest in asking the Rally team to consider making a
> "works in rally" tag, since the rally tests were deemed 'good'.

This one is part of a larger family of tags describing cross-project
support (like "has an horizon plugin", or "has heat teamplates") that we
started to work on on the upstream side as well. Those would be simple
yes/no binary tags, and maintained by the related project team directly.

Do you expect the "works in rally" answer to be more complex than a
binary yes/no ? Do you think the tag should be maintained by operators
rather than directly by the Rally project team ? If not, it's probably
fine to get that one defined as other upstream-maintained tags in the
same family.

Cheers,

-- 
Thierry Carrez (ttx)

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [tags] Results of PAO Ops Meeting

2015-09-14 Thread Tom Fifield 

On 14/09/15 16:35, Thierry Carrez wrote:

Tom Fifield wrote:

3) "works in rally" - new tag suggestion

There was general interest in asking the Rally team to consider making a
"works in rally" tag, since the rally tests were deemed 'good'.


This one is part of a larger family of tags describing cross-project
support (like "has an horizon plugin", or "has heat teamplates") that we
started to work on on the upstream side as well. Those would be simple
yes/no binary tags, and maintained by the related project team directly.

Do you expect the "works in rally" answer to be more complex than a
binary yes/no ? Do you think the tag should be maintained by operators
rather than directly by the Rally project team ? If not, it's probably
fine to get that one defined as other upstream-maintained tags in the
same family.


Up to the rally team :) The ops present were just interested in seeing 
it happen!



___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators