Re: [Openstack-operators] [openstack-operators] Announcement! We have everything ready to get to Stackforge!
-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
[Openstack-operators] [Gnocchi] Some update on Grafana support
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] Adding v1 LIKE support to python-glanceclient releases 1.x.x
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
Re: [Openstack-operators] Adding v1 LIKE support to python-glanceclient releases 1.x.x
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] [tags] Results of PAO Ops Meeting
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
Re: [Openstack-operators] [tags] Results of PAO Ops Meeting
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