[openstack-dev] [Nova] [feature freeze exception] Move to oslo.db

[Andrey Kurilin]

Hi All!

I'd like to ask for a feature freeze exception for porting nova to use
oslo.db.

This change not only removes 3k LOC, but fixes 4 bugs(see commit message
for more details) and provides relevant, stable common db code.

Main maintainers of oslo.db(Roman Podoliaka and Victor Sergeyev) are OK
with this.

Joe Gordon and Matt Riedemann are already signing up, so we need one more
vote from Core developer.

By the way a lot of core projects are using already oslo.db for a while:
keystone, cinder, glance, ceilometer, ironic, heat, neutron and sahara. So
migration to oslo.db won’t produce any unexpected issues.

Patch is here: https://review.openstack.org/#/c/101901/

--
Best regards,
Andrey Kurilin.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Oslo final releases ready

[Andrey Kurilin]

Here you are!:)
https://review.openstack.org/#/c/122667

On Fri, Sep 19, 2014 at 9:02 AM, Michael Still mi...@stillhq.com wrote:

 I would like to do a python-novaclient release, but this requirements
 commit hasn't yet turned into a requirements proposal for novaclient
 (that I can find). Can someone poke that for me?

 Michael

 On Fri, Sep 19, 2014 at 12:04 AM, Doug Hellmann d...@doughellmann.com
 wrote:
  All of the final releases for the Oslo libraries for the Juno cycle are
 available on PyPI. I’m working on a couple of patches to the global
 requirements list to update the baseline in the applications. In all cases,
 the final release is a second tag on a previously released version.
 
  - oslo.config - 1.4.0 (same as 1.4.0.0a5)
  - oslo.db - 1.0.0 (same as 0.5.0)
  - oslo.i18n - 1.0.0 (same as 0.4.0)
  - oslo.messaging - 1.4.0 (same as 1.4.0.0a5)
  - oslo.rootwrap - 1.3.0 (same as 1.3.0.0a3)
  - oslo.serialization - 1.0.0 (same as 0.3.0)
  - oslosphinx - 2.2.0 (same as 2.2.0.0a3)
  - oslotest - 1.1.0 (same as 1.1.0.0a2)
  - oslo.utils - 1.0.0 (same as 0.3.0)
  - cliff - 1.7.0 (previously tagged, so not a new release)
  - stevedore - 1.0.0 (same as 1.0.0.0a2)
 
  Congratulations and *Thank You* to the Oslo team for doing an amazing
 job with graduations this cycle!
 
  Doug
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 --
 Rackspace Australia

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




-- 
Best regards,
Andrey Kurilin.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [python-*client] moving to WebOb exceptions

[Andrey Kurilin]

Hi,

While working on unification of clients code we try to unify various
exceptions in different client projects.
We have module apiclient.exceptions in oslo-incubator[1]. Since our
apiclient is an oslo-inclubator library and not a standalone lib this
doesn't help in case we need to process exceptions from several clients.

Please, look at horizon module exceptions:
https://github.com/openstack/horizon/blob/master/openstack_dashboard/exceptions.py
From interpreter point of view apiclient exceptions will be different
classes since they are copy-pasted between projects.

The solution would be to use exceptions from external library - Module
WebOb.exc[2] for example (since WebOb is already used in other openstack
projects). This exceptions cover all our custom http exceptions.

We propose to move to webob.exc in three stages(I already have patches for
this in oslo-incubator and I've added link here as an example):
1) In clients: create aliases in module `exceptions` for all http
exceptions which are duplicated with webob.exc. This will help us safely
move to webob.exc without breaking tempest, horizon and other projects.
Usage of such exceptions will not cause significant changes. -
https://review.openstack.org/#/c/71916/
2) In all projects: importing exceptions and use them directly from
webob.exc - https://review.openstack.org/#/c/76198/
3) In clients: remove aliases for webob.exc. (at the end of backwards
compatibility period)

Please share your thoughts about this topic.

[1] -
https://github.com/openstack/oslo-incubator/blob/master/openstack/common/apiclient/exceptions.py
[2] -
http://turbogears.org/2.0/docs/modules/thirdparty/webob.html#module-webob.exc

-- 

Looking forward for your reply,
Andrey Kurilin.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] plan for moving to using oslo.db

[Andrey Kurilin]

 Any updates?


Eugeniya Kudryashova is working hard on using oslo.db in nova.
Please, look at https://review.openstack.org/#/c/101901/


On Fri, Aug 1, 2014 at 2:59 PM, Ihar Hrachyshka ihrac...@redhat.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 On 13/05/14 17:55, Matt Riedemann wrote:
 
 
  On 5/13/2014 7:35 AM, Doug Hellmann wrote:
  On Mon, May 12, 2014 at 3:25 PM, Roman Podoliaka
  rpodoly...@mirantis.com wrote:
  Hi all,
 
  Yes, once the oslo.db initial release is cut, we expect the
  migration from using of its oslo-incubator version to a library
  one to be as simple as following the steps you've mentioned.
  Though, we still need to finish the setup of oslo.db repo
  (AFAIK, this is currently blocked by the fact we don't run gate
  tests for oslo.db patches. Doug, Victor, please correct me, if
  I'm wrong).
 
  Yes, we need to work out the best way to test pre-releases of
  the libraries with apps before we have anything depending on
  those libraries so we can avoid breaking anything in a way that
  is hard to find or fix. We have a summit session scheduled for
  Thursday morning [1].
 
  Doug
 
  1 -
 
 http://junodesignsummit.sched.org/event/4f92763857fbe0686fe0436fecae8fbc
 
 
 
 
 Thanks,
  Roman
 
  On Mon, May 5, 2014 at 7:47 AM, Matt Riedemann
  mrie...@linux.vnet.ibm.com wrote:
  Just wanted to get some thoughts down while they are in my
  head this morning.
 
  Oslo DB is now a library [1].  I'm trying to figure out what
  the steps are to getting Nova to using that so we can rip out
  the sync'ed common db code.
 
  1. Looks like it's not in global-requirements yet [2], so
  that's probably a first step.
 
  2. We'll want to cut a sqlalchemy-migrate release once this
  patch is merged [3]. This moves a decent chunk of unique
  constraint patch code out of oslo and into sqlalchemy-migrate
  where it belongs so we can run unit tests with sqlite to drop
  unique constraints.
 
  3. Rip this [4] out of oslo.db once migrate is updated and
  released.
 
  4. Replace nova.openstack.common.db with oslo.db.
 
  5. ???
 
  6. Profit!
 
  Did I miss anything?
 
  [1] http://git.openstack.org/cgit/openstack/oslo.db/ [2]
 
 http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt
 
 
 
 [3] https://review.openstack.org/#/c/87773/
  [4] https://review.openstack.org/#/c/31016/
 
  --
 
  Thanks,
 
  Matt Riedemann
 
 
  ___ OpenStack-dev
  mailing list OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 ___
  OpenStack-dev mailing list OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 ___
  OpenStack-dev mailing list OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
  Just an update on progress, step 2 is complete, the review for step
  3 is here:
 
  https://review.openstack.org/#/c/92393/
 

 Any updates? I'm interested in making nova using oslo.db, this is
 needed for ongoing effort to make openstack services mysql-connector
 aware [we have some code for this in oslo.db but nit in oslo-incubator].

 Cheers,
 /Ihar
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQEcBAEBCgAGBQJT24EPAAoJEC5aWaUY1u57LGcIANJAGPVk61sIyY77Me1Xn3Sx
 Z/lx6C4/zdXi6PmBUgVMzdnh/r7cjw0Twe7B1D495qDD0rA/OwrP229WaM4wHBnz
 bqtih+Bl9rwP6Dij57O6D9cHmcW1gmAxEiqX6iva9RomIWMyB8cAJoEsnD95Dw+q
 3PIeZyikDy42p1BTnVlXRLNJhC9RaZyw8wVQ9aUVe6ydYkerbGBALQTOTirlUa8y
 cq1k3GrKczB53zFpZT1i07wIP4cl9J0xXWcQTjH5cA4Sw/5kxGplT18DHX2/rrs9
 YGSYIlpu1UDKyofVB69DMu6/Ryov3bBEf91NGZ3wJwqkdNu7f9qzFOM4mrT7Qq8=
 =LYQX
 -END PGP SIGNATURE-

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




-- 
Best regards,
Andrey Kurilin.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Rally] Tempest + Rally: first success

[Andrey Kurilin]

Hi stackers,

I would like to share with you great news.
We all know that it's quite hard to use Tempest out of gates, especially
when you are going to benchmark different clouds, run just part of tests
and would like to store somewhere results. As all this stuff doesn't belong
to Tempest, we decided to make it in Rally.

More details about how to use Tempest in one click in my tutorial:
http://www.mirantis.com/blog/rally-openstack-tempest-testing-made-simpler/

-- 
Best regards,
Andrey Kurilin.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Rally] Tempest + Rally: first success

[Andrey Kurilin]

Hey, Om!
Can you launch Rally in debug mode and share logs?
 rally -vd verify start --set image


On Tue, Jun 3, 2014 at 3:49 PM, om prakash pandey pande...@gmail.com
wrote:

 Hi Andrey,

 Thanks a ton for putting together this blog on using tempest + rally.

 I followed all the steps listed and managed to get tempest successfully
 installed.

 However, I was not able to proceed beyond and couldn't manage to run
 tempest even once. I am getting the below error:

 om@desktop2:~/rally$ rally verify start --set image
 Command failed, please check log for more info
 2014-06-03 18:14:56.029 8331 CRITICAL rally [-] IndexError: list index out
 of range

 What did I mess up while following the blog?

 Regards
 Om


 On Sat, May 31, 2014 at 3:46 AM, Andrey Kurilin akuri...@mirantis.com
 wrote:

 Hi stackers,

 I would like to share with you great news.
 We all know that it's quite hard to use Tempest out of gates, especially
 when you are going to benchmark different clouds, run just part of tests
 and would like to store somewhere results. As all this stuff doesn't belong
 to Tempest, we decided to make it in Rally.

 More details about how to use Tempest in one click in my tutorial:
 http://www.mirantis.com/blog/rally-openstack-tempest-testing-made-simpler/

 --
 Best regards,
 Andrey Kurilin.

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



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




-- 
Best regards,
Andrey Kurilin.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Rally] Tempest + Rally: first success

[Andrey Kurilin]

/local/lib/python2.7/dist-packages/rally/utils.py, line 162, in
 wrapper
 2014-06-04 02:32:14.071 1939 TRACE rally result = f(self, *args,
 **kwargs)
 2014-06-04 02:32:14.071 1939 TRACE rally   File
 /usr/local/lib/python2.7/dist-packages/rally/verification/verifiers/tempest/tempest.py,
 line 153, in _prepare_and_run
 2014-06-04 02:32:14.071 1939 TRACE rally self.generate_config_file()
 2014-06-04 02:32:14.071 1939 TRACE rally   File
 /usr/local/lib/python2.7/dist-packages/rally/verification/verifiers/tempest/tempest.py,
 line 95, in generate_config_file
 2014-06-04 02:32:14.071 1939 TRACE rally conf =
 config.TempestConf(self.deploy_id).generate()
 2014-06-04 02:32:14.071 1939 TRACE rally   File
 /usr/local/lib/python2.7/dist-packages/rally/verification/verifiers/tempest/config.py,
 line 220, in generate
 2014-06-04 02:32:14.071 1939 TRACE rally self._set_network()
 2014-06-04 02:32:14.071 1939 TRACE rally   File
 /usr/local/lib/python2.7/dist-packages/rally/verification/verifiers/tempest/config.py,
 line 191, in _set_network
 2014-06-04 02:32:14.071 1939 TRACE rally subnet =
 neutron.list_subnets(network_id=net_id)['subnets'][0]
 2014-06-04 02:32:14.071 1939 TRACE rally IndexError: list index out of
 range
 2014-06-04 02:32:14.071 1939 TRACE rally
 Command failed, please check log for more info


 On Tue, Jun 3, 2014 at 7:09 PM, Andrey Kurilin akuri...@mirantis.com
 wrote:

 Hey, Om!
 Can you launch Rally in debug mode and share logs?
  rally -vd verify start --set image


 On Tue, Jun 3, 2014 at 3:49 PM, om prakash pandey pande...@gmail.com
 wrote:

 Hi Andrey,

 Thanks a ton for putting together this blog on using tempest + rally.

 I followed all the steps listed and managed to get tempest successfully
 installed.

 However, I was not able to proceed beyond and couldn't manage to run
 tempest even once. I am getting the below error:

 om@desktop2:~/rally$ rally verify start --set image
 Command failed, please check log for more info
 2014-06-03 18:14:56.029 8331 CRITICAL rally [-] IndexError: list index
 out of range

 What did I mess up while following the blog?

 Regards
 Om


 On Sat, May 31, 2014 at 3:46 AM, Andrey Kurilin akuri...@mirantis.com
 wrote:

 Hi stackers,

 I would like to share with you great news.
 We all know that it's quite hard to use Tempest out of gates,
 especially when you are going to benchmark different clouds, run just part
 of tests and would like to store somewhere results. As all this stuff
 doesn't belong to Tempest, we decided to make it in Rally.

 More details about how to use Tempest in one click in my tutorial:
 http://www.mirantis.com/blog/rally-openstack-tempest-testing-made-simpler/

 --
 Best regards,
 Andrey Kurilin.

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



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




 --
 Best regards,
 Andrey Kurilin.

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



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




-- 
Best regards,
Andrey Kurilin.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Python-novaclient] Python-novaclient tests fail

[Andrey Kurilin]

Simple way to run tests is using tox:
$ tox -epy27

For more details, look at nova guide:
http://docs.openstack.org/developer/nova/devref/unit_tests.html

PS: Why novaclient guide recommends to use python setup.py test? A bit
strange for me.

On Mon, Oct 13, 2014 at 1:19 PM, Daniele Casini 
daniele.cas...@dektech.com.au wrote:

  Hi All,

 I am trying to test *python-novaclient* using *python setup.py test* as 
 reported
 in http://docs.openstack.org/developer/python-novaclient/
 ?ui=2ik=fc0b506fdfview=attth=1490909bfc88b13cattid=0.0.1.1disp=embzwatsh=0
 .
 In order to figure out the test logic I ran tests but an error is occurred:

 Exception:
 Traceback (most recent call last):
   File /usr/local/lib/python2.7/dist-packages/pip/basecommand.py, line
 122, in main
 status = self.run(options, args)
   File /usr/local/lib/python2.7/dist-packages/pip/commands/install.py,
 line 283, in run
 requirement_set.install(install_options, global_options,
 root=options.root_path)
   File /usr/local/lib/python2.7/dist-packages/pip/req.py, line 1431, in
 install
 requirement.uninstall(auto_confirm=True)
   File /usr/local/lib/python2.7/dist-packages/pip/req.py, line 598, in
 uninstall
 paths_to_remove.remove(auto_confirm)
   File /usr/local/lib/python2.7/dist-packages/pip/req.py, line 1836, in
 remove
 renames(path, new_path)
   File /usr/local/lib/python2.7/dist-packages/pip/util.py, line 295, in
 renames
 shutil.move(old, new)
   File /usr/lib/python2.7/shutil.py, line 300, in move
 rmtree(src)
   File /usr/lib/python2.7/shutil.py, line 247, in rmtree
 rmtree(fullname, ignore_errors, onerror)
   File /usr/lib/python2.7/shutil.py, line 252, in rmtree
 onerror(os.remove, fullname, sys.exc_info())
   File /usr/lib/python2.7/shutil.py, line 250, in rmtree
 os.remove(fullname)
 OSError: [Errno 13] Permission denied:
 '/usr/local/lib/python2.7/dist-packages/hacking/tests/test_doctest.pyc'

 Storing debug log for failure in /home/devstack/.pip/pip.log

 I am working on *master branch* and *no source code modification* are
 performed.

 Do you know how to fix it?

 Thanks,

 Daniele.


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




-- 
Best regards,
Andrey Kurilin.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Python-novaclient] Python-novaclient tests fail

[Andrey Kurilin]

 the novaclient docs should really be updated.

simple fix: https://review.openstack.org/#/c/127971/
but, imo, docs should contains more information(I will fix it a little bit
later, if no one takes this)

On Mon, Oct 13, 2014 at 7:49 PM, Ben Nemec openst...@nemebean.com wrote:

 On 10/13/2014 08:08 AM, Daniele Casini wrote:
  I have already used sudo but it still fails:
 
  ImportError: cannot import name exceptions
  Ran 63 tests in 0.146s (+0.014s)
  FAILED (id=3, failures=63)
  error: testr failed (1)
 
  So, it is quite strange because I do not modify the source code.
  Let me know if you have some suggestions.

 This is probably because of missing dependencies.  tox takes care of
 that by building a virtual environment with all of the dependencies
 installed, but if you're running setup.py directly you'd have to take
 care of that.

 As Andrey noted, tox is used in the gate so the novaclient docs should
 really be updated.

 
  Thanks,
 
  Daniele.
 
  On 10/13/2014 01:19 PM, Murugan, Visnusaran wrote:
 
  Just a permission issue. Use a “sudo”. You could alternatively install
  novaclient under a virtualenv and run the same “python setup.py test”
  without sudo.
 
  -Vishnu
 
  *From:*Daniele Casini [mailto:daniele.cas...@dektech.com.au]
  *Sent:* Monday, October 13, 2014 3:50 PM
  *To:* openstack-dev@lists.openstack.org
  *Subject:* [openstack-dev] [Python-novaclient] Python-novaclient tests
  fail
 
  Hi All,
 
  I am trying to test *python-novaclient* using
  */python/**//**/setup.py/**//**/test/*asreported in
  http://docs.openstack.org/developer/python-novaclient/
  cid:part1.07080205.06020204@dektech.com.au.
  In order to figure out the test logic I ran tests but an error is
  occurred:
 
  Exception:
  Traceback (most recent call last):
File /usr/local/lib/python2.7/dist-packages/pip/basecommand.py,
  line 122, in main
  status = self.run(options, args)
File
  /usr/local/lib/python2.7/dist-packages/pip/commands/install.py, line
  283, in run
  requirement_set.install(install_options, global_options,
  root=options.root_path)
File /usr/local/lib/python2.7/dist-packages/pip/req.py, line 1431,
  in install
  requirement.uninstall(auto_confirm=True)
File /usr/local/lib/python2.7/dist-packages/pip/req.py, line 598,
  in uninstall
  paths_to_remove.remove(auto_confirm)
File /usr/local/lib/python2.7/dist-packages/pip/req.py, line 1836,
  in remove
  renames(path, new_path)
File /usr/local/lib/python2.7/dist-packages/pip/util.py, line 295,
  in renames
  shutil.move(old, new)
File /usr/lib/python2.7/shutil.py, line 300, in move
  rmtree(src)
File /usr/lib/python2.7/shutil.py, line 247, in rmtree
  rmtree(fullname, ignore_errors, onerror)
File /usr/lib/python2.7/shutil.py, line 252, in rmtree
  onerror(os.remove, fullname, sys.exc_info())
File /usr/lib/python2.7/shutil.py, line 250, in rmtree
  os.remove(fullname)
  OSError: [Errno 13] Permission denied:
  '/usr/local/lib/python2.7/dist-packages/hacking/tests/test_doctest.pyc'
 
  Storing debug log for failure in /home/devstack/.pip/pip.log
 
  I am working on *master branch* and *no source code modification* are
  performed.
 
  Do you know how to fix it?
 
  Thanks,
 
  Daniele.
 
 
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


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




-- 
Best regards,
Andrey Kurilin.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][oslo] projects still using obsolete oslo modules

[Andrey Kurilin]

: pastedeploy
 openstack/trove: rpc
 openstack/trove: strutils
 openstack/trove: testutils
 openstack/trove: timeutils
 openstack/trove: utils
 openstack/trove: wsgi

 openstack/sahara: config.generator
 openstack/sahara: excutils
 openstack/sahara: importutils
 openstack/sahara: middleware.base
 openstack/sahara: strutils
 openstack/sahara: wsgi
 openstack/sahara: xmlutils

 openstack/python-saharaclient: importutils
 openstack/python-saharaclient: strutils

 openstack/python-tuskarclient: importutils

 openstack/nova: gettextutils
 openstack/nova: jsonutils

 openstack/python-heatclient: importutils
 openstack/python-heatclient: gettextutils
 openstack/python-heatclient: strutils

 openstack/python-neutronclient: gettextutils
 openstack/python-neutronclient: jsonutils
 openstack/python-neutronclient: strutils
 openstack/python-neutronclient: timeutils

 openstack/heat: gettextutils
 openstack/heat: middleware.base
 openstack/heat: middleware.request_id

 openstack/os-cloud-config: gettextutils

 openstack/gantt: db
 openstack/gantt: db.sqlalchemy
 openstack/gantt: excutils
 openstack/gantt: flakes
 openstack/gantt: gettextutils
 openstack/gantt: importutils
 openstack/gantt: jsonutils
 openstack/gantt: log_handler
 openstack/gantt: network_utils
 openstack/gantt: notifier
 openstack/gantt: rootwrap
 openstack/gantt: rpc
 openstack/gantt: strutils
 openstack/gantt: timeutils
 openstack/gantt: xmlutils

 openstack/designate: fixture.config
 openstack/designate: timeutils
 openstack/designate: xmlutils

 openstack/ironic-python-agent: config.generator
 openstack/ironic-python-agent: gettextutils

 openstack/python-cinderclient: py3kcompat
 openstack/python-cinderclient: strutils

 openstack/python-kiteclient: jsonutils
 openstack/python-kiteclient: timeutils

 openstack/horizon: excutils
 openstack/horizon: gettextutils
 openstack/horizon: importutils
 openstack/horizon: jsonutils
 openstack/horizon: strutils
 openstack/horizon: timeutils

 openstack/glance: gettextutils
 openstack/glance: test

 openstack/python-zaqarclient: importutils

 openstack/pycadf: gettextutils
 openstack/pycadf: importutils
 openstack/pycadf: jsonutils

 openstack-infra/jenkins-job-builder: setup
 openstack-infra/jenkins-job-builder: version

 openstack-infra/subunit2sql: importlib

 openstack-infra/statusbot: setup
 openstack-infra/statusbot: version
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Best regards,
Andrey Kurilin.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [novaclient] E12* rules

[Andrey Kurilin]

Hi everyone!

I'm working on enabling E12* PEP8 rules in novaclient(status of my work
listed below). Imo, PEP8 rules should be ignored only in extreme cases/for
important reasons and we should decrease a number of ignored rules. This
helps to keep code in more strict, readable form, which is very important
when working in community.

While working on rule E126, we started discussion with Joe Gordon about
demand of these rules. I have no idea about reasons of why they should be
ignored, so I want to know:
- Why these rules should be ignored?
- What do you think about enabling these rules?

Please, leave your opinion about E12* rules.

Already enabled rules:
  E121,E125 - https://review.openstack.org/#/c/122888/
  E122 - https://review.openstack.org/#/c/123830/
  E123 - https://review.openstack.org/#/c/123831/

Abandoned rule:
  E124 - https://review.openstack.org/#/c/123832/

Pending review:
  E126 - https://review.openstack.org/#/c/123850/
  E127 - https://review.openstack.org/#/c/123851/
  E128 - https://review.openstack.org/#/c/127559/
  E129 - https://review.openstack.org/#/c/123852/


-- 
Best regards,
Andrey Kurilin.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] python 2.6 support for oslo libraries

[Andrey Kurilin]

Just a joke: Can we drop supporting Python 2.6, when several project still
have hooks for Python 2.4?

https://github.com/openstack/python-novaclient/blob/master/novaclient/exceptions.py#L195-L203
https://github.com/openstack/python-cinderclient/blob/master/cinderclient/exceptions.py#L147-L155

On Wed, Oct 22, 2014 at 9:15 PM, Doug Hellmann d...@doughellmann.com
wrote:

 The application projects are dropping python 2.6 support during Kilo, and
 I’ve had several people ask recently about what this means for Oslo.
 Because we create libraries that will be used by stable versions of
 projects that still need to run on 2.6, we are going to need to maintain
 support for 2.6 in Oslo until Juno is no longer supported, at least for
 some of our projects. After Juno’s support period ends we can look again at
 dropping 2.6 support in all of the projects.


 I think these rules cover all of the cases we have:

 1. Any Oslo library in use by an API client that is used by a supported
 stable branch (Icehouse and Juno) needs to keep 2.6 support.

 2. If a client library needs a library we graduate from this point
 forward, we will need to ensure that library supports 2.6.

 3. Any Oslo library used directly by a supported stable branch of an
 application needs to keep 2.6 support.

 4. Any Oslo library graduated during Kilo can drop 2.6 support, unless one
 of the previous rules applies.

 5. The stable/icehouse and stable/juno branches of the incubator need to
 retain 2.6 support for as long as those versions are supported.

 6. The master branch of the incubator needs to retain 2.6 support until we
 graduate all of the modules that will go into libraries used by clients.


 A few examples:

 - oslo.utils was graduated during Juno and is used by some of the client
 libraries, so it needs to maintain python 2.6 support.

 - oslo.config was graduated several releases ago and is used directly by
 the stable branches of the server projects, so it needs to maintain python
 2.6 support.

 - oslo.log is being graduated in Kilo and is not yet in use by any
 projects, so it does not need python 2.6 support.

 - oslo.cliutils and oslo.apiclient are on the list to graduate in Kilo,
 but both are used by client projects, so they need to keep python 2.6
 support. At that point we can evaluate the code that remains in the
 incubator and see if we’re ready to turn of 2.6 support there.


 Let me know if you have questions about any specific cases not listed in
 the examples.

 Doug

 PS - Thanks to fungi and clarkb for helping work out the rules above.
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Best regards,
Andrey Kurilin.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tempest] [devstack] Generic scripts for Tempest configuration

[Andrey Kurilin]

Hi Timur!
https://review.openstack.org/#/c/94473/ - this is what you need:)

On Fri, Oct 24, 2014 at 2:05 PM, Timur Nurlygayanov 
tnurlygaya...@mirantis.com wrote:

 Hi all,

 we are using Tempest tests to verify every changes in different OpenStack
 components and we have scripts in devstack, which allow to configure
 Tempest.
 We want to use Tempest tests to verify different clouds, not only
 installed with devstack and to do this we need to configure Tempest
 manually (or with some no-generic scripts, which allow to configure tempest
 for specific lab configuration).

 Looks like we can improve these scripts for configuration of the Tempest,
 which we have in devstack repository now and create generic scripts for
 Tempest, which can be used by devstack scripts or manually, to configure
 Tempest for any private/public OpenStack clouds. These scripts should allow
 to easily configure Tempest: user should provide only Keystone endpoint and
 logins/passwords, other parameters can be optional and can be configured
 automatically.

 The idea is to have the generic scripts, which will allow to easily
 configure Tempest from-the-box, without deep inspection of lab
 configuration (but with the ability to change optional parameters too, if
 it is required).

 --

 Timur,
 Senior QA Engineer
 OpenStack Projects
 Mirantis Inc

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




-- 
Best regards,
Andrey Kurilin.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [python-novaclient] Status of novaclient V3

[Andrey Kurilin]

Hi!

While working on fixing wrong import in novaclient v3 shell, I have found
that a lot of commands, which are listed in V3 shell(novaclient.v3.shell),
are broken, because appropriate managers are missed from V3
client(novaclient.V3.client.Client).

Template of error is ERROR (AttributeError): 'Client' object has no
attribute 'attr', where attr can be floating_ip_pools,
floating_ip, security_groups, dns_entries and etc.

I know that novaclient V3 is not finished yet, and I guess it will be not
finished. So the main question is:
 What we should do with implemented code of novaclient V3 ? Should it be
ported to novaclient V2.1 or it can be removed?

-- 
Best regards,
Andrey Kurilin.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [python-novaclient] Status of novaclient V3

[Andrey Kurilin]

Thank for answers.
I sent a patch to novaclient : https://review.openstack.org/#/c/138694/

On Wed, Dec 3, 2014 at 1:59 PM, Christopher Yeoh cbky...@gmail.com
javascript:_e(%7B%7D,'cvml','cbky...@gmail.com'); wrote:




 On 3 Dec 2014, at 10:00 pm, Joe Gordon joe.gord...@gmail.com
 javascript:_e(%7B%7D,'cvml','joe.gord...@gmail.com'); wrote:



 On Tue, Dec 2, 2014 at 5:21 PM, Andrey Kurilin akuri...@mirantis.com
 javascript:_e(%7B%7D,'cvml','akuri...@mirantis.com'); wrote:

 Hi!

 While working on fixing wrong import in novaclient v3 shell, I have found
 that a lot of commands, which are listed in V3 shell(novaclient.v3.shell),
 are broken, because appropriate managers are missed from V3
 client(novaclient.V3.client.Client).

 Template of error is ERROR (AttributeError): 'Client' object has no
 attribute 'attr', where attr can be floating_ip_pools,
 floating_ip, security_groups, dns_entries and etc.

 I know that novaclient V3 is not finished yet, and I guess it will be not
 finished. So the main question is:
  What we should do with implemented code of novaclient V3 ? Should it be
 ported to novaclient V2.1 or it can be removed?


 I think it can be removed, as we are not going forward with the V3 API.
 But I will defer to Christopher Yeoh/Ken’ichi Ohmichi for the details.



 I think it can all just be removed now. We're going to need to enhance
 nova client to understand micro versions instead. But for now v2.1 should
 look just like v2

 Chris





 --
 Best regards,
 Andrey Kurilin.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 javascript:_e(%7B%7D,'cvml','OpenStack-dev@lists.openstack.org');
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 javascript:_e(%7B%7D,'cvml','OpenStack-dev@lists.openstack.org');
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Best regards,
Andrey Kurilin.


-- 
Best regards,
Andrey Kurilin.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] novaclient support for V2.1 micro versions

[Andrey Kurilin]

Hi!
As I know, there is no support of microversions in novaclient. Only
os-compute-api-version is supported, but it do nothing(and I start a thread
to clarify this question -
http://lists.openstack.org/pipermail/openstack-dev/2015-January/055027.html)

On Fri, Jan 23, 2015 at 6:53 PM, Day, Phil philip@hp.com wrote:

  Hi Folks,



 Is there any support yet in novaclient for requesting a specific
 microversion ?   (looking at the final leg of extending clean-shutdown to
 the API, and wondering how to test this in devstack via the novaclient)



 Phil





 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [python-novaclient][nova] future of --os-compute-api-version option and whole api versioning

[Andrey Kurilin]

First results is https://review.openstack.org/#/c/152569/

 - if os-compute-api-version is not supplied don't send any header at all
 - it is probably worth doing a bit version parsing to see if it makes
sense eg of format:
  r^([1-9]\d*)\.([1-9]\d*|0)$ or latest

implemented


- handle  HTTPNotAcceptable if the user asked for a version which is not
supported
  (can also get a badrequest if its badly formatted and got through the
novaclient filter)
Based on https://review.openstack.org/#/c/150641/ , HTTPNotFound (404) will
be returned by API, so the current implementation of novaclient is not
required any changes.

 - show the version header information returned
Imo, API should return exception with proper message which already include
this information.

On Mon, Feb 2, 2015 at 2:02 PM, Andrey Kurilin akuri...@mirantis.com
wrote:

 Thanks for the summary, I'll try to send first patch(maybe WIP) in few
 days.

 On Mon, Feb 2, 2015 at 1:43 PM, Christopher Yeoh cbky...@gmail.com
 wrote:



 On Sat, Jan 31, 2015 at 4:09 AM, Andrey Kurilin akuri...@mirantis.com
 wrote:

 Thanks for the answer. Can I help with implementation of novaclient part?


 Sure! Do you think its something you can get proposed into Gerrit by the
 end of the week or very soon after?
 Its the sort of timeframe we're looking for to get microversions enabled
 asap I guess just let me know if it
 turns out you don't have the time.

 So I think a short summary of what is needed is:
 - if os-compute-api-version is not supplied don't send any header at all
 - it is probably worth doing a bit version parsing to see if it makes
 sense eg of format:
  r^([1-9]\d*)\.([1-9]\d*|0)$ or latest
 - handle  HTTPNotAcceptable if the user asked for a version which is not
 supported
   (can also get a badrequest if its badly formatted and got through the
 novaclient filter)
 - show the version header information returned

 Regards,

 Chris


 On Wed, Jan 28, 2015 at 11:50 AM, Christopher Yeoh cbky...@gmail.com
 wrote:

 On Fri, 23 Jan 2015 15:51:54 +0200
 Andrey Kurilin akuri...@mirantis.com wrote:

  Hi everyone!
  After removing nova V3 API from novaclient[1], implementation of v1.1
  client is used for v1.1, v2 and v3 [2].
  Since we moving to micro versions, I wonder, do we need such
  mechanism of choosing api version(os-compute-api-version) or we can
  simply remove it, like in proposed change - [3]?
  If we remove it, how micro version should be selected?
 

 So since v3 was never officially released I think we can re-use
 os-compute-api-version for microversions which will map to the
 X-OpenStack-Compute-API-Version header. See here for details on what
 the header will look like. We need to also modify novaclient to handle
 errors when a version requested is not supported by the server.

 If the user does not specify a version number then we should not send
 anything at all. The server will run the default behaviour which for
 quite a while will just be v2.1 (functionally equivalent to v.2)


 http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/api-microversions.html


 
  [1] - https://review.openstack.org/#/c/138694
  [2] -
 
 https://github.com/openstack/python-novaclient/blob/master/novaclient/client.py#L763-L769
  [3] - https://review.openstack.org/#/c/149006
 




 --
 Best regards,
 Andrey Kurilin.



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Best regards,
 Andrey Kurilin.




-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [python-novaclient][nova] future of --os-compute-api-version option and whole api versioning

[Andrey Kurilin]

Thanks for the summary, I'll try to send first patch(maybe WIP) in few days.

On Mon, Feb 2, 2015 at 1:43 PM, Christopher Yeoh cbky...@gmail.com wrote:



 On Sat, Jan 31, 2015 at 4:09 AM, Andrey Kurilin akuri...@mirantis.com
 wrote:

 Thanks for the answer. Can I help with implementation of novaclient part?


 Sure! Do you think its something you can get proposed into Gerrit by the
 end of the week or very soon after?
 Its the sort of timeframe we're looking for to get microversions enabled
 asap I guess just let me know if it
 turns out you don't have the time.

 So I think a short summary of what is needed is:
 - if os-compute-api-version is not supplied don't send any header at all
 - it is probably worth doing a bit version parsing to see if it makes
 sense eg of format:
  r^([1-9]\d*)\.([1-9]\d*|0)$ or latest
 - handle  HTTPNotAcceptable if the user asked for a version which is not
 supported
   (can also get a badrequest if its badly formatted and got through the
 novaclient filter)
 - show the version header information returned

 Regards,

 Chris


 On Wed, Jan 28, 2015 at 11:50 AM, Christopher Yeoh cbky...@gmail.com
 wrote:

 On Fri, 23 Jan 2015 15:51:54 +0200
 Andrey Kurilin akuri...@mirantis.com wrote:

  Hi everyone!
  After removing nova V3 API from novaclient[1], implementation of v1.1
  client is used for v1.1, v2 and v3 [2].
  Since we moving to micro versions, I wonder, do we need such
  mechanism of choosing api version(os-compute-api-version) or we can
  simply remove it, like in proposed change - [3]?
  If we remove it, how micro version should be selected?
 

 So since v3 was never officially released I think we can re-use
 os-compute-api-version for microversions which will map to the
 X-OpenStack-Compute-API-Version header. See here for details on what
 the header will look like. We need to also modify novaclient to handle
 errors when a version requested is not supported by the server.

 If the user does not specify a version number then we should not send
 anything at all. The server will run the default behaviour which for
 quite a while will just be v2.1 (functionally equivalent to v.2)


 http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/api-microversions.html


 
  [1] - https://review.openstack.org/#/c/138694
  [2] -
 
 https://github.com/openstack/python-novaclient/blob/master/novaclient/client.py#L763-L769
  [3] - https://review.openstack.org/#/c/149006
 




 --
 Best regards,
 Andrey Kurilin.



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-operators][rally][docker] Rally docker images are available on Docker hub now!

[Andrey Kurilin]

Great news for everyone!:)

On Wed, Feb 18, 2015 at 9:28 PM, Boris Pavlovic bo...@pavlovic.me wrote:

 Hi stackers,

 For those who likes to keep system clean, Rally team is happy to say that
 Docker images with Rally are automatically published to docker hub now.

 Repo with images is here:
 https://hub.docker.com/u/rallyforge/rally/

 In repo you can find images for:
 1) Every release - image name is the same as release tag
 2) Master image - it is updated on every merge to Rally repo.


 By the way, there is a nice tutorial about how to use Rally in container:
 https://hub.docker.com/u/rallyforge/rally/


 Best regards,
 Boris Pavlovic

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] release request for python-novaclient

[Andrey Kurilin]

Imo, neutron has wrong usage of novaclient.
https://review.openstack.org/#/c/152907/ should fix this issue.

On Thursday, February 19, 2015, Terry Wilson twil...@redhat.com
javascript:_e(%7B%7D,'cvml','twil...@redhat.com'); wrote:

  Sorry, I dropped the ball here. This is now released. Unfortunately, the
 new novaclient release ended up completely breaking the neutron gate. The
 v1_1 deprecation broke our (voting) pylint test:
 https://jenkins04.openstack.org/job/gate-neutron-pylint/1383/console
 2015-02-19 18:37:06.932 |  Module neutron.notifiers.nova 2015-02-19
 18:37:06.932 |  No name 'client' in module 'novaclient.v1_1' (
 no-name-in-module) 2015-02-19 18:37:06.932 |  No name 'contrib' in module
 'novaclient.v1_1' (no-name-in-module 2015-02-19 18:37:06.932 |  Module
 neutron.plugins.cisco.l3.service_vm_lib 2015-02-19 18:37:06.932 |  No name
 'client' in module 'novaclient.v1_1' no-name-in-module Terry
 __
 OpenStack Development Mailing List (not for usage questions) Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] release request for python-novaclient

[Andrey Kurilin]

Neutron should not depend on versioning implementation in novaclient.

There is get_contrib_module function in
https://review.openstack.org/#/c/152569/9/novaclient/client.py , which
should help to renounce the use of direct import of versioning stuff of
novaclient, but now, imo, we should use workaround like
https://review.openstack.org/#/c/152907/

On Fri, Feb 20, 2015 at 12:38 AM, Terry Wilson twil...@redhat.com wrote:



 - Original Message -
  On Feb 19, 2015, at 11:52, Terry Wilson twil...@redhat.com wrote:
 
   Unfortunately, the new novaclient release ended up completely breaking
 the
   neutron gate. The v1_1 deprecation broke our (voting) pylint test:
   https://jenkins04.openstack.org/job/gate-neutron-pylint/1383/console
  
   2015-02-19 18:37:06.932 | Module neutron.notifiers.nova[0m
   2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1'
   (no-name-in-module)
   2015-02-19 18:37:06.932 | No name 'contrib' in module
   'novaclient.v1_1'(no-name-in-module)
   2015-02-19 18:37:06.932 | Module
 neutron.plugins.cisco.l3.service_vm_lib
   2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1'
   (no-name-in-module)
 
  Hi Terry,
 
  Sorry to hear about this. I looked into this and the problem is pylint
 can't
  parse the backward-compatibility we have for the v1_1 deprecation:
 
 
 https://review.openstack.org/#/c/149006/13/novaclient/v1_1/__init__.py,cm
 
  The actual code should work but pylint static checking will fail to
 follow
  it. So far, the options I see to handle it are to either patch
  s/novaclient.v1_1/novaclient.v2/ in neutron or suppress the specific
 pylint
  check that's failing (if it's not too broad).
 
  Do you find either of these options acceptable, or have another idea?

 We've currently just disabled the pylint gate tests, and I've posted a
 patch for neutron to resolve the issue. Looks like there was a similar
 patch already up for review as well, though it only catches one of our uses
 of novaclient. There's still a bit of an issue that there is no
 version-neutral way to import the 'contrib' stuff like there is for
 'client'. So:

 from novaclient.v1_1.contrib import server_external_events

 has to become

 from novaclient.v2.contrib import server_external_events

 which doesn't work on previous versions of novaclient. It's possible to
 hack around it using importutils, but it's pretty ugly.

 Terry

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [python-novaclient][nova] future of --os-compute-api-version option and whole api versioning

[Andrey Kurilin]

Thanks for the answer. Can I help with implementation of novaclient part?

On Wed, Jan 28, 2015 at 11:50 AM, Christopher Yeoh cbky...@gmail.com
wrote:

 On Fri, 23 Jan 2015 15:51:54 +0200
 Andrey Kurilin akuri...@mirantis.com wrote:

  Hi everyone!
  After removing nova V3 API from novaclient[1], implementation of v1.1
  client is used for v1.1, v2 and v3 [2].
  Since we moving to micro versions, I wonder, do we need such
  mechanism of choosing api version(os-compute-api-version) or we can
  simply remove it, like in proposed change - [3]?
  If we remove it, how micro version should be selected?
 

 So since v3 was never officially released I think we can re-use
 os-compute-api-version for microversions which will map to the
 X-OpenStack-Compute-API-Version header. See here for details on what
 the header will look like. We need to also modify novaclient to handle
 errors when a version requested is not supported by the server.

 If the user does not specify a version number then we should not send
 anything at all. The server will run the default behaviour which for
 quite a while will just be v2.1 (functionally equivalent to v.2)


 http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/api-microversions.html


 
  [1] - https://review.openstack.org/#/c/138694
  [2] -
 
 https://github.com/openstack/python-novaclient/blob/master/novaclient/client.py#L763-L769
  [3] - https://review.openstack.org/#/c/149006
 




-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [python-novaclient][nova] future of --os-compute-api-version option and whole api versioning

[Andrey Kurilin]

Hi everyone!
After removing nova V3 API from novaclient[1], implementation of v1.1
client is used for v1.1, v2 and v3 [2].
Since we moving to micro versions, I wonder, do we need such mechanism of
choosing api version(os-compute-api-version) or we can simply remove it,
like in proposed change - [3]?
If we remove it, how micro version should be selected?


[1] - https://review.openstack.org/#/c/138694
[2] -
https://github.com/openstack/python-novaclient/blob/master/novaclient/client.py#L763-L769
[3] - https://review.openstack.org/#/c/149006

-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [all][qa][gabbi][rally][tempest] Extend rally verfiy to unify work with Gabbi, Tempest and all in-tree functional tests

[Andrey Kurilin]

I have an alternative solution for `rally verify project start` command.
What do you think about similar management stuff for verifiers as we have
for deployments?

It requires several changes:
 - `rally verifiers` command: Implementation of new command, which will
manage(install, reinstall, remove, configure) verifiers(tempest,
project-specific functional tests, gabbi and etc), will allow users to have
several tempest verifiers with different configurations or branches and
easily switch between them.
 - `rally verify` command: The original verification command will check
selected verifier and contain only verifier-specific sub-commands.
 - db changes: we will need to store information about verifiers


On Thu, Mar 12, 2015 at 2:33 AM, Boris Pavlovic bo...@pavlovic.me wrote:

 Alex,


   * rally plugin should be a part of project (for example, located in
 functional tests directory)


 There are 2 issues with such solution:

   1) If rally didn't load plugin, command rally verify project won't
 exist
   2) Putting some strange Rally plugin to source of other projects will be
 quite complicated task.
   I believe we should have at least POC before even asking for such
 stuff.

   * use {project url} instead of {project name} in rally verify command,
 example:


 I agree here with Andrey, it is bad UX. Forcing people to write every time
 URLs is terrible.
 They will build own tools on top of such solution.

 What  about rally verify nova start --url  where --url is optional
 argument?
 If --url is not specified default url is used.


 Best regards,
 Boris Pavlovic






 On Wed, Mar 11, 2015 at 7:14 PM, Andrey Kurilin akuri...@mirantis.com
 wrote:

  $ rally verify https://github.com/openstack/nova start

 As one of end-users of Rally, I dislike such construction, because I
 don't want to remember links to repos, they are too long for me:)

 On Wed, Mar 11, 2015 at 12:49 PM, Aleksandr Maretskiy 
 amarets...@mirantis.com wrote:

 The idea is great, but IMHO we can move all project-specific code out of
 rally, so:

   * rally plugin should be a part of project (for example, located in
 functional tests directory)
   * use {project url} instead of {project name} in rally verify command,
 example:

 $ rally verify https://github.com/openstack/nova start


 On Tue, Mar 10, 2015 at 6:01 PM, Timur Nurlygayanov 
 tnurlygaya...@mirantis.com wrote:

 Hi,

 I like this idea, we use Rally for OpenStack clouds verification at
 scale and it is the real issue - how to run all functional tests from each
 project with the one script. If Rally will do this, I will use Rally to run
 these tests.

 Thank you!

 On Mon, Mar 9, 2015 at 6:04 PM, Chris Dent chd...@redhat.com wrote:

 On Mon, 9 Mar 2015, Davanum Srinivas wrote:

  2. Is there a test project with Gabbi based tests that you know of?


 In addition to the ceilometer tests that Boris pointed out gnocchi
 is using it as well:

https://github.com/stackforge/gnocchi/tree/master/gnocchi/
 tests/gabbi

  3. What changes if any are needed in Gabbi to make this happen?


 I was unable to tell from the original what this is and how gabbi
 is involved but the above link ought to be able to show you how
 gabbi can be used. There's also the docs (which could do with some
 improvement, so suggestions or pull requests welcome):

http://gabbi.readthedocs.org/en/latest/

 --
 Chris Dent tw:@anticdent freenode:cdent
 https://tank.peermore.com/tanks/cdent

 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
 unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --

 Timur,
 Senior QA Engineer
 OpenStack Projects
 Mirantis Inc


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Best regards,
 Andrey Kurilin.

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [all][qa][gabbi][rally][tempest] Extend rally verfiy to unify work with Gabbi, Tempest and all in-tree functional tests

[Andrey Kurilin]

 $ rally verify https://github.com/openstack/nova start

As one of end-users of Rally, I dislike such construction, because I don't
want to remember links to repos, they are too long for me:)

On Wed, Mar 11, 2015 at 12:49 PM, Aleksandr Maretskiy 
amarets...@mirantis.com wrote:

 The idea is great, but IMHO we can move all project-specific code out of
 rally, so:

   * rally plugin should be a part of project (for example, located in
 functional tests directory)
   * use {project url} instead of {project name} in rally verify command,
 example:

 $ rally verify https://github.com/openstack/nova start


 On Tue, Mar 10, 2015 at 6:01 PM, Timur Nurlygayanov 
 tnurlygaya...@mirantis.com wrote:

 Hi,

 I like this idea, we use Rally for OpenStack clouds verification at scale
 and it is the real issue - how to run all functional tests from each
 project with the one script. If Rally will do this, I will use Rally to run
 these tests.

 Thank you!

 On Mon, Mar 9, 2015 at 6:04 PM, Chris Dent chd...@redhat.com wrote:

 On Mon, 9 Mar 2015, Davanum Srinivas wrote:

  2. Is there a test project with Gabbi based tests that you know of?


 In addition to the ceilometer tests that Boris pointed out gnocchi
 is using it as well:

https://github.com/stackforge/gnocchi/tree/master/gnocchi/tests/gabbi

  3. What changes if any are needed in Gabbi to make this happen?


 I was unable to tell from the original what this is and how gabbi
 is involved but the above link ought to be able to show you how
 gabbi can be used. There's also the docs (which could do with some
 improvement, so suggestions or pull requests welcome):

http://gabbi.readthedocs.org/en/latest/

 --
 Chris Dent tw:@anticdent freenode:cdent
 https://tank.peermore.com/tanks/cdent

 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
 unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --

 Timur,
 Senior QA Engineer
 OpenStack Projects
 Mirantis Inc

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-operators][rally] What's new in Rally v0.0.2

[Andrey Kurilin]

Good news!

 Our goal is to cut releases ever 2 weeks.

+1 for it. End-users will be able to use new features quicker.

On Thu, Mar 12, 2015 at 7:03 PM, Boris Pavlovic bo...@pavlovic.me wrote:

 Hi stackers,

 For those who doesn't know Rally team started making releases.

 There are 3 major reasons why we started doing releases:

  * A lot of people started using Rally in their CI/CD.

 Usually they don't like to depend on something that is from master.
 And would like to have smooth testable upgrades between versions

  * Rally is used in gates of many projects.

 As far as you know in Rally everything is plugable. These plugins can
 be
 put  in project tree. This is nice flexibility for all projects. But
 it blocks a lot
development of Rally. To resolve this issue we are going to allow
 projects t
specify which version of Rally to run in their trees. This resolves 2
 issues:
1) projects gates won't depend on Rally master
2) projects have smooth, no downtime, testable way to switch to newer
version of Rally

  * Release notes - as a simple way to track project changes.



 Release stats:
 +--+-+
 | Commits  | **100** |
 +--+-+
 | Bug fixes| **18**  |
 +--+-+
 | Dev cycle|   **45 days**   |
 +--+-+
 | Release date | **12/Mar/2015** |
 +--+-+


 Release notes:

 https://rally.readthedocs.org/en/latest/release_notes/v0.0.2.html


 Pypi:

 https://pypi.python.org/pypi/rally/0.0.2


 Future goals:

 Our goal is to cut releases ever 2 weeks.  As far as project is quite
 bugless and stable we don't need feature freeze at all, so I don't think
 that it will be hard to achieve this goal.


 Best regards,
 Boris Pavlovic

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] novaclient 'stable-compat-jobs-{name}' broken

[Andrey Kurilin]

Given that, is it okay if I propose a patch to remove the
'stable-compat-jobs-{name}' build jobs for python-novaclient in
project-config?

I suppose we should remove 'stable-compat-jobs-{name}', since novaclient is
already blocked for one week and it looks like there are no another
solutions for now.

On Fri, Apr 10, 2015 at 8:02 AM, melanie witt melwi...@gmail.com wrote:

 Hi all,

 The following 'stable-compat-jobs-{name}' build jobs have been broken the
 past two days, blocking all novaclient patches from passing jenkins checks:

 gate-tempest-dsvm-neutron-src-python-novaclient-icehouse
 gate-tempest-dsvm-neutron-src-python-novaclient-juno

 The original purpose of these jobs was to check that patches proposed to
 master wouldn't break in stable branches. This was before we started
 pinning novaclient versions on stable branches. Now that we've pinned, the
 way these jobs were passing was by installing the current novaclient, then
 uninstalling it, then installing a version from pypi that fits within the
 global requirements for the branch in question (icehouse or juno), then
 running the tests.

 Well, recently this stopped working because for some reason, devstack is
 no longer able to uninstall the latest version:

 Found existing installation: python-novaclient 2.23.0.post14
 Can't uninstall 'python-novaclient'. No files were found to uninstall.

 And then I see the following error as a result:

 pkg_resources.ContextualVersionConflict: (python-novaclient 2.23.0.post14
 (/opt/stack/new/python-novaclient),
 Requirement.parse('python-novaclient=2.20.0,=2.18.0'),
 set(['ceilometer']))

 I asked about this in #openstack-infra and was told we really shouldn't be
 running the src build jobs on patches proposed to master anyhow, and that
 it's not the right flow for devstack to install the latest, then uninstall
 it, then install an older global reqs compatible version anyway.

 Given that, is it okay if I propose a patch to remove the
 'stable-compat-jobs-{name}' build jobs for python-novaclient in
 project-config?

 Then after that, how are we supposed to go about cutting stable branches
 for novaclient? And how can we get the 'stable-compat-jobs-{name}' jobs
 running on only those respective branches? In project-config I didn't
 understand how to limit build jobs to only patches proposed to a stable
 branch.

 I'd appreciate any insights.

 Thanks,
 melanie (melwitt)





 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side

[Andrey Kurilin]

There are no so much messages, since first mail was published 2 weeks ago,
so I don't want spend a lot of time waiting comments, which may not appear.

Btw, some questions appeared in my head related to your suggestions:)

When user execute cmd without --os-compute-version. The nova client should
discover the nova server supported version. Then cmd choice the latest
version supported both by client and server.

In that case, why X-Compute-API-Version can accept latest value? Also,
such discovery will require extra request to API side for every client call.

'--os-compute-version=None' can be supported, that means will return the
min version of server supported.

From my point of view '--os-compute-version=None' is equal to not specified
value. Maybe, it would be better to accept value min for
os-compute-version option.

The supported version can be discovered by version API (Thanks to Ken'ichi
fix this):

Yeah. I saw his patch to novaclient, which adds ability to display
supported microversions - https://review.openstack.org/#/c/173711/

3. if the microversion non-supported, but user call cmd with
--os-compute-version, this should return failed.

Imo, it should be implemented on API side(return BadRequest when
X-Compute-API-Version header is presented in V2)

On Fri, Apr 24, 2015 at 12:42 PM, Alex Xu sou...@gmail.com wrote:



 2015-04-24 17:24 GMT+08:00 Andrey Kurilin akuri...@mirantis.com:

 Thank you for suggestions! I'll try modify patches as soon as possible.


 np, it's better waiting for more comment before you begin to update the
 code first. avoid you need rework again I think :)



 On Fri, Apr 24, 2015 at 6:56 AM, Alex Xu sou...@gmail.com wrote:

 Thanks Andrey for hard work on the microverison client support.

 Wrote down some my thought:

 I also agreed we will have only one endpoint 'compute'. Hope we can
 switch v2.1 export as '/v2' in the api-paste.conf as default very soon~

 let's say what expected after we only have v2.1 in the world first:

 There are two cases for use nova client.
 1. user use nova client command line. I think command line should
 support version discover. Provide most convenient way let the user try nova.
 2. user use nova client as library. user should call the client code to
 discover the version and decided what version he want to use by himself.

 For the command line, the behavior can be:

 When user execute cmd without --os-compute-version. The nova client
 should discover the nova server supported version. Then cmd choice the
 latest version supported both by client and server. This is good for us to
 introduce the new feature to the user.

 Also user can specified a version he want to by --os-compute-version.

 '--os-compute-version=None' can be supported, that means will return the
 min version of server supported.

 The supported version can be discovered by version API (Thanks to
 Ken'ichi fix this):
 GET '/'

 https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L25

 But reality is the v2 and v2.1 will existed at same time.

 So the v2 or v2.1 code both can run under the endpoint 'compute' with
 url '/v2'. It depend on the admin's deployment.

 So I think the cmd also can discover whether the api supported
 microversion under the 'compute' endpoint.

 This can be discovered by version api also.

 GET '/v2/' will return the endpoint version info. Then we can check the
 version and min_version properties to know whether the api support
 microversion or not.

 The behavior can be:
 1. If the microversion supported, the cmd behavior is same as the
 description at the top of this mail
 2. If the microversion non-supported, user call cmd without
 --os-compute-version, we use the min version.
 3. if the microversion non-supported, but user call cmd with
 --os-compute-version, this should return failed.

 Hope those thoughts are helpful.

 Looks like this need some change in current patchset also :( I know
 Andrey already pay lot of on this. But if we like this way, I also can give
 some help on the coding :)

 Thanks
 Alex


 2015-04-10 19:30 GMT+08:00 Andrey Kurilin akuri...@mirantis.com:

 Hi all!
 I working on implementation of support microversions in novaclient.
 Patches are ready for review, but there is one opened question: what we
 should do with v2.1 endpoint(computev21 service type)?

 compute is a default value of service type and keystone returns v2
 api endpoint for it(at least in devstack), so version header will be
 ignored on API side.

 On the one hand, each deployment can have it's own configuration of
 service catalog and endpoints, so default value of service type should be
 strict and support as much deployments as we can. On the other hand,
 dependency of service type for microversion feature is not good and
 end-users should not take care about choice of correct service type when
 they want to execute simple command.

 Possible solutions:

1. leave everything as is: use --service-type

Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side

[Andrey Kurilin]

Thank you for suggestions! I'll try modify patches as soon as possible.

On Fri, Apr 24, 2015 at 6:56 AM, Alex Xu sou...@gmail.com wrote:

 Thanks Andrey for hard work on the microverison client support.

 Wrote down some my thought:

 I also agreed we will have only one endpoint 'compute'. Hope we can switch
 v2.1 export as '/v2' in the api-paste.conf as default very soon~

 let's say what expected after we only have v2.1 in the world first:

 There are two cases for use nova client.
 1. user use nova client command line. I think command line should support
 version discover. Provide most convenient way let the user try nova.
 2. user use nova client as library. user should call the client code to
 discover the version and decided what version he want to use by himself.

 For the command line, the behavior can be:

 When user execute cmd without --os-compute-version. The nova client should
 discover the nova server supported version. Then cmd choice the latest
 version supported both by client and server. This is good for us to
 introduce the new feature to the user.

 Also user can specified a version he want to by --os-compute-version.

 '--os-compute-version=None' can be supported, that means will return the
 min version of server supported.

 The supported version can be discovered by version API (Thanks to Ken'ichi
 fix this):
 GET '/'

 https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L25

 But reality is the v2 and v2.1 will existed at same time.

 So the v2 or v2.1 code both can run under the endpoint 'compute' with url
 '/v2'. It depend on the admin's deployment.

 So I think the cmd also can discover whether the api supported
 microversion under the 'compute' endpoint.

 This can be discovered by version api also.

 GET '/v2/' will return the endpoint version info. Then we can check the
 version and min_version properties to know whether the api support
 microversion or not.

 The behavior can be:
 1. If the microversion supported, the cmd behavior is same as the
 description at the top of this mail
 2. If the microversion non-supported, user call cmd without
 --os-compute-version, we use the min version.
 3. if the microversion non-supported, but user call cmd with
 --os-compute-version, this should return failed.

 Hope those thoughts are helpful.

 Looks like this need some change in current patchset also :( I know Andrey
 already pay lot of on this. But if we like this way, I also can give some
 help on the coding :)

 Thanks
 Alex


 2015-04-10 19:30 GMT+08:00 Andrey Kurilin akuri...@mirantis.com:

 Hi all!
 I working on implementation of support microversions in novaclient.
 Patches are ready for review, but there is one opened question: what we
 should do with v2.1 endpoint(computev21 service type)?

 compute is a default value of service type and keystone returns v2 api
 endpoint for it(at least in devstack), so version header will be ignored on
 API side.

 On the one hand, each deployment can have it's own configuration of
 service catalog and endpoints, so default value of service type should be
 strict and support as much deployments as we can. On the other hand,
 dependency of service type for microversion feature is not good and
 end-users should not take care about choice of correct service type when
 they want to execute simple command.

 Possible solutions:

1. leave everything as is: use --service-type computev21 for each
microversioned command
2. move default value of service type to environment
variables(default value is hardcoded in novaclient code now)
3. add additional option --compute-api-type. Proposed etherpad by
Christopher Yeoh
https://etherpad.openstack.org/p/novaclient_microversions_design .
Implementation is already finished -
https://review.openstack.org/#/c/167577/ . This proposal still
requires addition cli option, but compute-api-type looks more 
 user-friendly


 Current implementation uses compute as default value for service type.
 Patches are pass all gates, except stable branches and ready for review:

- https://review.openstack.org/#/c/169378/  - deprecate v1.1 and
remove references to v3 in code
- https://review.openstack.org/#/c/152569/  - Implements
'microversions' api type - Part 1 (usage of
nova.api.openstack.api_version_request:APIVersionRequest class with
https://review.openstack.org/#/c/169292/ )
- https://review.openstack.org/#/c/167408/  - Implements
'microversions' api type - Part 2 (adds new decorators and substitution
mechanism using nova.api.openstack.versioned_method )
- https://review.openstack.org/#/c/136458/  - Implementation of 2.2
microversion


 --
 Best regards,
 Andrey Kurilin.

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http

Re: [openstack-dev] [opentack-dev][meetings] Proposing changes in Rally meetings

[Andrey Kurilin]

  - We should start making agenda for each meeting and publish it to Rally
wiki

+1

 * Second is release management meeting, where we are discussing
priorities for
   current  next release. So core team will know what to review
first.

It would be nice to post list of high priority patches to etherpad or
google docs after each meeting

  - Move meetings from #openstack-meeting to #openstack-rally chat.

doesn't matter for me:)

   - We should adjust better time for current Rally team.

yeah. Current time is not good:( +1 for 15:00 UTC

  - Do meetings every Monday and Wednesday

Monday?) Monday is very hard day...

On Fri, Apr 17, 2015 at 4:26 PM, Boris Pavlovic bo...@pavlovic.me wrote:

 Rally team,


 I would like to propose next changes in Rally meetings:

   - We should start making agenda for each meeting and publish it to Rally
 wiki

   - We should do 2 meeting per week:

  * First is regular meeting (like we have now) where we are discussing
 everything

  * Second is release management meeting, where we are discussing
 priorities for
current  next release. So core team will know what to review
 first.

   - Move meetings from #openstack-meeting to #openstack-rally chat.

   - We should adjust better time for current Rally team. Like at the
 moment it is too late
  for few of cores in Rally. it's 17:00 UTC and I would like to suggest
 to make at 15:00 UTC.

   - Do meetings every Monday and Wednesday


 Thoughts ?


 Best regards,
 Boris Pavlovic




-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

[Andrey Kurilin]

Why does alternative implementation need to implement all 50 versions?
As far as I understand, API side should not support all versions, that is
why version info returns min and max versions
https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L25-L26

On Tue, Jun 16, 2015 at 11:36 AM, Alex Xu sou...@gmail.com wrote:



 2015-06-16 5:24 GMT+08:00 Clint Byrum cl...@fewbar.com:

 Excerpts from Sean Dague's message of 2015-06-15 14:00:43 -0700:
  On 06/15/2015 04:50 PM, Jim Rollenhagen wrote:
   On Mon, Jun 15, 2015 at 01:07:39PM -0400, Jay Pipes wrote:
   It has come to my attention in [1] that the microversion spec for
 Nova [2]
   and Ironic [3] have used the project name -- i.e. Nova and Ironic --
 instead
   of the name of the API -- i.e. OpenStack Compute and OpenStack
 Bare
   Metal -- in the HTTP header that a client passes to indicate a
 preference
   for or knowledge of a particular API microversion.
  
   The original spec said that the HTTP header should contain the name
 of the
   service type returned by the Keystone service catalog (which is also
 the
   official name of the REST API). I don't understand why the spec was
 changed
   retroactively and why Nova has been changed to return
   X-OpenStack-Nova-API-Version instead of
 X-OpenStack-Compute-API-Version HTTP
   headers [4].
  
   To be blunt, Nova is the *implementation* of the OpenStack Compute
 API.
   Ironic is the *implementation* of the OpenStack BareMetal API.
  
   While I tend to agree in principle, do we reasonably expect that other
   implementations of these APIs will implement every one of these
   versions? Can we even reasonably expect another implementation of
 these
   APIs?
  
   // jim
 
  Yeh, honestly, I'm not really convinced that thinking we are doing this
  for alternative implementations is really the right approach (or even
  desireable). Honestly, the transition to microversions makes alternative
  implementations harder because there isn't a big frozen API for a long
  period of time.
 

 Actually that makes an alternative implementation more valuable. Without
 microversions those alternative implementations would have to wait a long
 time to implement fixes to the API, but now can implement and publish
 the fix as soon as the microversion lands. This means that alternative
 implementations will lag _less_ behind the primary.


 So if our min_version is 2.1 and the max_version is 2.50. That means
 alternative implementations need implement all the 50 versions api...that
 sounds pain...



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements] why merging 2.6 requirements for non 2.6 supporting projects

[Andrey Kurilin]

Hi!
It looks like novaclient still supports py26 :) At least, there is a
gate-python-novaclient-python26 job.
Also, I checked several commands(boot, *list, delete ) with python 2.6 env
and they work as expected for me.

On Tue, Jul 14, 2015 at 2:03 PM, Sean Dague s...@dague.net wrote:

 I just saw this Nova review come in -
 https://review.openstack.org/#/c/200908

 Why are we merging 2.6 requirements for projects that don't support 2.6?
 That seems potentially confusing to end users that now think the project
 does, because there are still references in the code.

 -Sean

 --
 Sean Dague
 http://dague.net

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder][nova] gate-cinder-python34 failing test_nova_timeout after novaclient 2.33 release

[Andrey Kurilin]

1/
>>>
>>> At least with the cinder change above we're OK for mitaka, and
>>> logstash
>>> isn't yet showing failures for cinder in stable/liberty, but
>>> given the
>>> requirements there it will be a failure in cinder python34
>>> tests in
>>> stalbe/liberty also - so we can backport the cinder fix or
>>> block the
>>> 2.33 novaclient version on stable/liberty global-requirements
>>> depending
>>> on what we do with the proposed novaclient revert.
>>>
>>>
>>> I have an alternative to the revert here:
>>>
>>> https://review.openstack.org/#/c/239963/
>>>
>>> That makes novaclient.exceptions.RequestTimeout extend
>>> requests.Timeout so that older cinder continues to work.
>>>
>>> I also have changes to block novaclient 2.33.0 in g-r on master and
>>> stable/liberty:
>>>
>>>
>>>
>>> https://review.openstack.org/#/q/I6e7657b60308b30eed89b269810c1f37cce43063,n,z
>>>
>>>
>>> I personally think we need to block 2.33.0 since it breaks cinder,
>>> then release a new version of novaclient with either the revert or
>>> the alternative change to extend requests.Timeout.
>>>
>>> If we block novaclient 2.33.0 then we can also revert the workaround
>>> in cinder (which would start breaking if we reverted the new
>>> exception type out of novaclient w/o blacklisting 2.33 first).
>>>
>>>
>>> --
>>>
>>> Thanks,
>>>
>>> Matt Riedemann
>>>
>>>
>>>
>>>
>>> __
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>
>>> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>>
>>> __
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> The novaclient revert patch is approved:
>>
>> https://review.openstack.org/#/c/239941/
>>
>> Once that is merged I'll propose a release request for novaclient.
>>
>> I've got g-r patches for master and stable/liberty to block 2.33:
>>
>>
>> https://review.openstack.org/#/q/I6e7657b60308b30eed89b269810c1f37cce43063,n,z
>>
>>
>> Once those land and we've synced the change to cinder, we can revert the
>> cinder workaround.
>>
>>
> So the revert is merged [1] but now I'm stuck as to the version and/or git
> commit to use for the next release.
>
> The changes since 2.33.0 are:
>
> mriedem@ubuntu:~/git/python-novaclient$ git log --oneline --no-merges
> 2.33.0..
> 63c7a57 Revert "Do not expose exceptions from requests library"
> 217e7c1 Updated from global requirements
> 0cd5812 Remove novaclient.v1_1 module
>
> And when I requested the 2.33.0 release [2], it was on 217e7c1 but they
> changed it to be w/o 0cd5812 because that is considered a backward
> incompatible change. But it was released with 2961e82 which was the
> backward incompatible requests exception change, which we now have a fix
> for that we want to release, but would include 0cd5812.
>
> So do we just release novaclient trunk as 3.0? We still have the g-r
> blacklist changes for 2.33.0 in mitaka and liberty so we wouldn't be using
> that version in tests (assuming that's merged in g-r). So then people have
> to move up to 3.0 if they want the latest novaclient changes.
>
> This is a bit gross.
>
> [1] https://review.openstack.org/#/c/239941/
> [2] https://review.openstack.org/#/c/239450/
>
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Graduate cliutils.py into oslo.utils

[Andrey Kurilin]

On Tue, Nov 10, 2015 at 4:25 PM, Sean Dague <s...@dague.net> wrote:

> On 11/10/2015 08:24 AM, Andrey Kurilin wrote:
> >>It was also proposed to reuse openstackclient or the openstack SDK.
> >
> > Openstack SDK was proposed a long time ago(it looks like it was several
> > cycles ago) as "alternative" for cliutils and apiclient, but I don't
> > know any client which use it yet. Maybe openstacksdk cores should try to
> > port any client as an example of how their project should be used.
>
> The SDK is targeted for end user applications, not service clients. I do
> get there was lots of confusion over this, but SDK is not the answer
> here for service clients.
>

Ok, thanks for explanation, but there is another question in my head: If
openstacksdk is not for python-*clients, why apiclient(which is actually
used by python-*clients) was marked as deprecated due to openstacksdk?

>
> The service clients are *always* going to have to exist in some form.
> Either as libraries that services produce, or by services deciding they
> don't want to consume the libraries of other clients and just put a
> targeted bit of rest code in their own tree to talk to other services.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Graduate apiclient library

[Andrey Kurilin]

y to the new apiclient library and implement
> find_resource method in the manila client.
> We prefer to implement option #1.
>
>
> Please have a look at it and let us know your suggestions on the same.
> Currently we are having Diwali Vacation in India and once we are back from
> the vacation, based on your inputs I will update the oslo-specs [3] and
> upload it for community review.
>
> [1]:
> https://mitakadesignsummit.sched.org/event/a98e66b41bf5a8bec8db81dd15f77671
> [2]:
> https://docs.google.com/spreadsheets/d/1ZpnEl5QoZz6kv4_ElvqIZULQ4UrVFkxmIuUo_zsyVnE
> [3]: https://review.openstack.org/#/c/235200/
>
> Thank you in advance.
>
> Abhishek Kekane
>
> __
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Graduate cliutils.py into oslo.utils

[Andrey Kurilin]

>It was also proposed to reuse openstackclient or the openstack SDK.

Openstack SDK was proposed a long time ago(it looks like it was several
cycles ago) as "alternative" for cliutils and apiclient, but I don't know
any client which use it yet. Maybe openstacksdk cores should try to port
any client as an example of how their project should be used.



On Tue, Nov 10, 2015 at 12:29 PM, Victor Stinner <vstin...@redhat.com>
wrote:

> Hi,
>
> At Tokyo, we discussed quickly what to do with cliutils.py of
> oslo-incubator, but for me the plan is not really concrete.
>
> https://etherpad.openstack.org/p/mitaka-oslo-incubator-cleanup
>
> I don't like dims' suggestion to move code inside clients, it means
> duplicating 280 lines of python in 11 clients.
>
> It was also proposed to reuse openstackclient or the openstack SDK. I
> don't understand how novaclient can use openstackclient, since
> openstackclient depends on python-novaclient... The OpenStack SDK project
> is also a large library no? (I don't know well the OpenStack SDK project.)
>
> I would prefer to move cliutils.py to oslo.utils. Only 3 clients use
> cliutils.py but don't depend on oslo.utils yet. The 8 remaining clients
> using cliutils.py already depends on oslo.utils.
>
> An alternative is to create yet another oslo library. But it means
> creating a library for a single file of 280 lines.
>
> What do you think?
>
> --
>
> On 29 "python-*client" projects, I found 11 clients using cliutils.py:
>
> python-ceilometerclient
> python-cloudkittyclient
> python-heatclient
> python-ironicclient
> python-magnumclient
> python-manilaclient
> python-mistralclient
> python-novaclient
> python-saharaclient
> python-solumclient
> python-tuskarclient
>
> 9 clients are almost synchronized with oslo-incubator: only the new
> optional 'dict_value' parameter of the print_list() function is missing,
> not a big deal (since the parameter is optional, it doesn't break the API).
>
> magnumclient and mistralclient have larger changes.
>
> magnumclient adds a recursive keys_and_vals_to_strs() function which casts
> all dictionary keys and values to string. We may copy this feature in the
> upstream code (oslo incubator), it makes sense to me.
>
> cliutils.py of mistralclient looks outdated, but a find_resource()
> function was also added. We can move find_resource() out of cliutils.py, to
> put it somewhere in mistralclient.
>
> On the 11 clients using cliutils.py, 8 depend oslo.utils, whereas 3 don't.
>
> Victor
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [murano] python versions

[Andrey Kurilin]

Hi folks!
Can anyone share status of porting muranoclient to Python 3?

On Tue, Jun 16, 2015 at 4:54 PM, Serg Melikyan <smelik...@mirantis.com>
wrote:

> Stan, +100500
>
> On Fri, Jun 12, 2015 at 3:13 PM, Stan Lagun <sla...@mirantis.com> wrote:
> >
> > I'd rather go with Heat approach (job first) because it makes easier to
> track what is left to port to Py34 and track progress in this area
> >
> > Sincerely yours,
> > Stan Lagun
> > Principal Software Engineer @ Mirantis
> >
> >
> > On Mon, Jun 8, 2015 at 2:46 PM, Kirill Zaitsev <kzait...@mirantis.com>
> wrote:
> >>
> >> I’ve looked into several OS projects, and they first seen to implement
> py3 support and create a job later. (Except for heat. They already have a
> non-voting py34, which seem to fail every time =))
> >>
> >> I suggest we do the same: first make murano work on py34, then make a
> py34 job. I’ll file a blueprint shortly.
> >>
> >> --
> >> Kirill Zaitsev
> >> Murano team
> >> Software Engineer
> >> Mirantis, Inc
> >>
> >> On 2 Jun 2015 at 15:58:17, Serg Melikyan (smelik...@mirantis.com)
> wrote:
> >>
> >> Hi Kirill,
> >>
> >> I agree with Alexander that we should not remove support for python
> >> 2.6 in python-muranoclient.
> >>
> >> Regarding adding python-3 jobs - great idea! But we need to migrate
> >> python-muranoclient to yaql 1.0 first and then add python-3 jobs,
> >> because previous versions of yaql are not compatible with python-3.
> >>
> >> On Tue, Jun 2, 2015 at 3:33 PM, Alexander Tivelkov
> >> <ativel...@mirantis.com> wrote:
> >> > Hi Kirill,
> >> >
> >> > Client libraries usually have wider range of python requirements, as
> they
> >> > may be run on various kinds of legacy environments, including the
> ones with
> >> > python 2.6. only.
> >> > Murano is definitely not the only project in Openstack which still
> maintains
> >> > py26 compatibility for its client: nova, glance, cinder and other
> integrated
> >> > ones do this.
> >> >
> >> > So, I would not drop py26 support for client code without any good
> reasons
> >> > to. Are there any significant reasons to do it?
> >> > Regarding py3.4 - this is definitely a good idea.
> >> >
> >> >
> >> > --
> >> > Regards,
> >> > Alexander Tivelkov
> >> >
> >> > On Tue, Jun 2, 2015 at 3:04 PM, Kirill Zaitsev <kzait...@mirantis.com
> >
> >> > wrote:
> >> >>
> >> >> It seems that python-muranoclient is the last project from
> murano-official
> >> >> group, that still supports python2.6. Other projects do not have a
> 2.6
> >> >> testing job (correct me if I’m wrong).
> >> >>
> >> >> Personally I think it’s time to drop support for 2.6 completely, and
> add
> >> >> (at least non-voting) jobs with python3.4 support tests.
> >> >> It seems to fit the whole process of moving OS projects towards
> python 3:
> >> >> https://etherpad.openstack.org/p/liberty-cross-project-python3
> >> >>
> >> >> What do you think? Does anyone have any objections?
> >> >>
> >> >> --
> >> >> Kirill Zaitsev
> >> >> Murano team
> >> >> Software Engineer
> >> >> Mirantis, Inc
> >> >>
> >> >>
> __
> >> >> OpenStack Development Mailing List (not for usage questions)
> >> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >>
> >> >
> >> >
> >> >
> __
> >> > OpenStack Development Mailing List (not for usage questions)
> >> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >>
> >>
> >>
> >> --
> >> Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
> >> http://mirantis.com | smelik...@mirantis.com
> >>
> >>
> __

Re: [openstack-dev] [tox/pep8] different result between running tox and pep8

[Andrey Kurilin]

Running pep8 ., a lot of pep8 mistkes come out.

1) `pep8 .` checks all files in directory(including build files, envs and
etc).
2) `pep8 .` doesn't use tox.ini file, which can contain list of ignored
rules. For example, it can looks like:
[flake8]
ignore = H703

3) Most of OpenStack projects use flake8 instead of pep8




On Fri, Jul 10, 2015 at 6:15 AM, Gareth academicgar...@gmail.com wrote:

 Hi guys

 My problem looks simple:

 Running tox -e pep8, the result says ok, not pep8 mistakes.
 Running pep8 ., a lot of pep8 mistkes come out.

 But in your project's tox.ini, there isn't such a long ignore list. So
 what makes this difference happen?

 Kun

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][python-novaclient] Functional test fail due to publicURL endpoint for volume service not found

[Andrey Kurilin]

Hi!
It looks like cause of issue is a disabling Cinder API V1 in gates by
default(
http://lists.openstack.org/pipermail/openstack-dev/2015-September/075689.html)
which was merged yesterday( https://review.openstack.org/#/c/194726/17 ).

Since Cinder V1 is disabled, python-novaclient has several issues:
 - "nova volume-* does not work when using cinder v2 API" -
https://bugs.launchpad.net/python-novaclient/+bug/1392846
 - "nova volume-* managers override service_type to 'volume', which is
missed in gates" - https://bugs.launchpad.net/python-novaclient/+bug/1501258


On Wed, Sep 30, 2015 at 5:56 AM, Zhenyu Zheng <zhengzhenyul...@gmail.com>
wrote:

> Hi, all
>
> I submitted a patch for novaclient last night:
> https://review.openstack.org/#/c/228769/ , and it turns out the
> functional test has failed due to:  publicURL endpoint for volume service
> not found. I also found out that another novaclient patch:
> https://review.openstack.org/#/c/217131/ also fails due to this error, so
> this must be a bug. Any idea on how to fix this?
>
> Thanks,
>
> BR,
>
> Zheng
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] how to address boot from volume failures

[Andrey Kurilin]

>1) fix the client without a revert

I prefer to go with this option, since fix already done and pending review.

>This means that until people upgrade their
>client they loose access to this function on the server.

This applies to any of the proposed options.

On Thu, Oct 1, 2015 at 12:03 AM, Sean Dague <s...@dague.net> wrote:

> Today we attempted to branch devstack and grenade for liberty, and are
> currently blocked because in liberty with openstack client and
> novaclient, it's not possible to boot a server from volume using just
> the volume id.
>
> That's because of this change in novaclient -
> https://review.openstack.org/#/c/221525/
>
> That was done to resolve the issue that strong schema validation in Nova
> started rejecting the kinds of calls that novaclient was making for boot
> from volume, because the bdm 1 and 2 code was sharing common code and
> got a bit tangled up. So 3 bdm 2 params were being sent on every request.
>
> However, https://review.openstack.org/#/c/221525/ removed the ==1 code
> path. If you pass in just {"vda": "$volume_id"} the code falls through,
> volume id is lost, and nothing is booted. This is how the devstack
> exercises and osc recommends booting from volume. I expect other people
> might be doing that as well.
>
> There seem to be a few options going forward:
>
> 1) fix the client without a revert
>
> This would bring back a ==1 code path, which is basically just setting
> volume_id, and move on. This means that until people upgrade their
> client they loose access to this function on the server.
>
> 2) revert the client and loose up schema validation
>
> If we revert the client to the old code, we also need to accept the fact
> that novaclient has been sending 3 extra parameters to this API call
> since as long as people can remember. We'd need a nova schema relax to
> let those in and just accept that people are going to pass those.
>
> 3) fix osc and novaclient cli to not use this code path. This will also
> require everyone upgrades both of those to not explode in the common
> case of specifying boot from volume on the command line.
>
> I slightly lean towards #2 on a compatibility front, but it's a chunk of
> change at this point in the cycle, so I don't think there is a clear win
> path. It would be good to collect opinions here. The bug tracking this
> is - https://bugs.launchpad.net/python-openstackclient/+bug/1501435
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [murano] Fix order of arguments in assertEqual

[Andrey Kurilin]

Hi everyone!

I agree that wrong order of arguments misleads while debugging errors, BUT
how we can prevent regression? Imo, this is not a good idea to make patches
like https://review.openstack.org/#/c/64415/ in each release(without check
in CI, such patches are redundant).


PS: This question relates not only for murano.

On Thu, Sep 24, 2015 at 11:48 AM, Kekane, Abhishek <
abhishek.kek...@nttdata.com> wrote:

> Hi,
>
> There is a bug for this, you can add murano projects to this bug.
>
> https://bugs.launchpad.net/heat/+bug/1259292
>
> Thanks,
>
> Abhishek Kekane
>
> -Original Message-
> From: Bulat Gaifullin [mailto:bgaiful...@mirantis.com]
> Sent: 24 September 2015 13:29
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [murano] Fix order of arguments in assertEqual
>
> +1
>
> > On 24 Sep 2015, at 10:45, Tetiana Lashchova <tlashch...@mirantis.com>
> wrote:
> >
> > Hi folks!
> >
> > Some tests in murano code use incorrect order of arguments in
> assertEqual.
> > The correct order expected by the testtools is
> >
> > def assertEqual(self, expected, observed, message=''):
> > """Assert that 'expected' is equal to 'observed'.
> >
> > :param expected: The expected value.
> > :param observed: The observed value.
> > :param message: An optional message to include in the error.
> > """
> >
> > Error message has the following format:
> >
> > raise mismatch_error
> > testtools.matchers._impl.MismatchError: !=:
> > reference = 
> > actual= 
> >
> > Use of arguments in incorrect order could make debug output very
> confusing.
> > Let's fix it to make debugging easier.
> >
> > Best regards,
> > Tetiana Lashchova
> > __
> >  OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Performance][Proposal] Moving IRC meeting from 15:00 UTC to 16:00 UTC

[Andrey Kurilin]

Hi!
15-00 or 16-00 - it does not matter to me :)

On Fri, Dec 4, 2015 at 11:46 AM, Dina Belova <dbel...@mirantis.com> wrote:

> Dear performance folks,
>
> There is a suggestion to move our meeting time from 15:00 UTC (Tuesdays
> <https://wiki.openstack.org/wiki/Meetings/Performance#Meeting_Times>) to
> 16:00 UTC (also Tuesdays
> <https://wiki.openstack.org/wiki/Meetings/Performance#Meeting_Times>) to
> make them more comfortable for US guys.
>
> Please leave your +1 / -1 here in the email thread.
>
> Btw +1 from me :)
>
> Cheers,
> Dina
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [python-novaclient] history of virtual-interface commands

[Andrey Kurilin]

Hi stackers!

I have found code in novaclient related to virtual-interfaces extension[1],
but there are no cli commands for it. Since rackspace docs include
reference to `virtual-interface-list` command[2], I wonder, is there a
reason for which commands related to virtual-interfaces are missed from
upstream master?
Does anyone know the history of virtual-interfaces extension and CLI
entrypoint for it?

[1] -
https://github.com/openstack/python-novaclient/blob/2.35.0/novaclient/v2/virtual_interfaces.py
[2] -
http://docs.rackspace.com/servers/api/v2/cs-gettingstarted/content/nova_list_virt_interfaces_for_server.html

-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] [python-novaclient] microversions support

[Andrey Kurilin]

Hi stackers!
This week I added 5 patches to enable 2.7-2.11 microversions in
novaclient[1][2][3][4][5]. I'm not bragging. Just want to ask everyone who
are working on new microversions: Please, do not forget to add support of
your microversion to official Nova client.

[1] - https://review.openstack.org/#/c/251483
[2] - https://review.openstack.org/#/c/251484
[3] - https://review.openstack.org/#/c/251485
[4] - https://review.openstack.org/#/c/251486
[5] - https://review.openstack.org/#/c/253095

-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] [python-novaclient] microversions support

[Andrey Kurilin]

+1 for Kevin's proposal.

On Fri, Dec 4, 2015 at 8:37 PM, Chen CH Ji <jiche...@cn.ibm.com> wrote:

> +1 , added a doc change just now  https://review.openstack.org/#/c/253644
>
> -"Kevin L. Mitchell" <kevin.mitch...@rackspace.com> wrote: -
> To: <openstack-dev@lists.openstack.org>
> From: "Kevin L. Mitchell" <kevin.mitch...@rackspace.com>
> Date: 12/04/2015 06:25PM
> Subject: Re: [openstack-dev] [nova] [python-novaclient] microversions
> support
>
>
> On Fri, 2015-12-04 at 18:58 +0200, Andrey Kurilin wrote:
> > This week I added 5 patches to enable 2.7-2.11 microversions in
> > novaclient[1][2][3][4][5]. I'm not bragging. Just want to ask everyone
> > who are working on new microversions: Please, do not forget to add
> > support of your microversion to official Nova client.
>
> Perhaps this is something we should add to the review guidelines—no API
> change can be merged to nova unless there is a pending change to
> novaclient to add support?  We already more or less enforce the criteria
> that no addition to novaclient can be added unless the corresponding
> nova change has been merged…
> --
> Kevin L. Mitchell <kevin.mitch...@rackspace.com>
> Rackspace
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [python-novaclient] history of virtual-interface commands

[Andrey Kurilin]

Hi Tomi,
It looks like CLI was not added from the beginning of virtual-interface
history[1]. Jichenjc works on patch[2] to fix this issue.

[1] - https://review.openstack.org/#/c/3368/
[2] - https://review.openstack.org/#/c/254707/




On Thu, Dec 10, 2015 at 1:26 PM, Juvonen, Tomi (Nokia - FI/Espoo) <
tomi.juvo...@nokia.com> wrote:

> Hi,
>
>
>
> Also hitting this as making new microversion and would need to have
> support in CLI. Seems CLI works just by bumping API_MAX_VERSION (as I am
> only adding one new attribute to existing API). Anyhow cannot do this
> because microversion 2.12 is not implemented (actually API_MAX_VERSION is
> currently 2.9, but 2.7-2.11 should be under way).
>
>
>
> Br,
>
> Tomi
>
>
>
> *From:* EXT Andrey Kurilin [mailto:akuri...@mirantis.com]
> *Sent:* Friday, December 04, 2015 3:42 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [python-novaclient] history of
> virtual-interface commands
>
>
>
> Hi stackers!
>
>
> I have found code in novaclient related to virtual-interfaces
> extension[1], but there are no cli commands for it. Since rackspace docs
> include reference to `virtual-interface-list` command[2], I wonder, is
> there a reason for which commands related to virtual-interfaces are missed
> from upstream master?
> Does anyone know the history of virtual-interfaces extension and CLI
> entrypoint for it?
>
>
>
> [1] -
> https://github.com/openstack/python-novaclient/blob/2.35.0/novaclient/v2/virtual_interfaces.py
> [2] -
> http://docs.rackspace.com/servers/api/v2/cs-gettingstarted/content/nova_list_virt_interfaces_for_server.html
>
> --
>
> Best regards,
> Andrey Kurilin.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] Python 2.6 should rise from the dead

[Andrey Kurilin]

Hi all,
As you may know, support of Python 2.6 was dropped this month from most of
OpenStack projects. Also infrastructure team dropped Centos 6.x jobs.

I'm ok with dropping Python 2.6 support from the master(Mitaka), but what
about stable/kilo and stable/liberty ? Kilo and Liberty were released with
Python 2.6 support and most of projects have py26 classifiers there.
Without py26 jobs in stable branches, it is hard to backport any changes.
Also, requirements for stable/liberty do not contain upper caps for
python-*clients and oslo.* libraries, so most of projects already have
broken py26 support in Liberty.

-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Python 2.6 should rise from the dead

[Andrey Kurilin]

>If it had py26 classifiers, that was an error.

The list of libraries with py26 classifiers is too huge:
astara - stable/kilo, stable/liberty
astara-appliance - stable/kilo, stable/liberty
astara-horizon - stable/kilo, stable/liberty
astara-neutron - stable/kilo, stable/liberty
bifrost - stable/liberty
ceilometermiddleware - stable/kilo, stable/liberty
cloudkitty-dashboard - stable/kilo
compute-hyperv - stable/kilo, stable/liberty
congress - stable/kilo, stable/liberty
debtcollector - stable/kilo, stable/liberty
designate - stable/kilo, stable/liberty
designate-dashboard - stable/liberty
glance_store - stable/kilo
group-based-policy - stable/kilo
group-based-policy-automation - stable/kilo
group-based-policy-ui - stable/kilo
instack-undercloud - stable/liberty
keystoneauth - stable/liberty
keystonemiddleware - stable/kilo
magnum - stable/kilo, stable/liberty
magnum-ui - stable/liberty
manila-ui - stable/kilo, stable/liberty
mox3 - stable/liberty
networking-bagpipe - stable/kilo, stable/liberty
networking-bgpvpn - stable/kilo, stable/liberty
networking-hyperv - stable/kilo, stable/liberty
networking-infoblox - stable/liberty
networking-l2gw - stable/kilo, stable/liberty
networking-nec - stable/kilo
networking-ovs-dpdk - stable/kilo, stable/liberty
networking-plumgrid - stable/kilo, stable/liberty
networking-vsphere - stable/kilo, stable/liberty
nova-docker - stable/kilo, stable/liberty
nova-solver-scheduler - stable/kilo
os-brick - stable/liberty
os-client-config - stable/liberty
oslo-incubator - stable/kilo
oslo.cache - stable/liberty
oslo.concurrency - stable/kilo, stable/liberty
oslo.config - stable/kilo, stable/liberty
oslo.context - stable/kilo, stable/liberty
oslo.db - stable/kilo, stable/liberty
oslo.i18n - stable/kilo, stable/liberty
oslo.log - stable/kilo, stable/liberty
oslo.messaging - stable/kilo
oslo.middleware - stable/kilo, stable/liberty
oslo.policy - stable/kilo, stable/liberty
oslo.reports - stable/liberty
oslo.rootwrap - stable/kilo, stable/liberty
oslo.serialization - stable/kilo, stable/liberty
oslo.service - stable/liberty
oslo.utils - stable/kilo, stable/liberty
oslo.versionedobjects - stable/kilo
oslo.vmware - stable/kilo, stable/liberty
oslosphinx - stable/kilo, stable/liberty
oslotest - stable/kilo, stable/liberty
pycadf - stable/kilo, stable/liberty
python-barbicanclient - stable/kilo, stable/liberty
python-ceilometerclient - stable/kilo, stable/liberty
python-cinderclient - stable/kilo, stable/liberty
python-congressclient - stable/kilo, stable/liberty
python-designateclient - stable/kilo, stable/liberty
python-glanceclient - stable/kilo, stable/liberty
python-group-based-policy-client - stable/kilo
python-heatclient - stable/kilo, stable/liberty
python-ironicclient - stable/kilo, stable/liberty
python-keystoneclient - stable/kilo, stable/liberty
python-magnumclient - stable/kilo, stable/liberty
python-neutronclient - stable/kilo, stable/liberty
python-novaclient - stable/kilo, stable/liberty
python-openstackclient - stable/kilo, stable/liberty
python-saharaclient - stable/kilo, stable/liberty
python-swiftclient - stable/kilo, stable/liberty
python-tackerclient - stable/kilo, stable/liberty
python-troveclient - stable/kilo, stable/liberty
python-zaqarclient - stable/kilo, stable/liberty
requirements - stable/kilo, stable/liberty
stevedore - stable/liberty
swift - stable/kilo
tacker - stable/kilo, stable/liberty
tacker-horizon - stable/kilo, stable/liberty
taskflow - stable/kilo
tooz - stable/kilo
tripleo-common - stable/liberty
yaql - stable/kilo, stable/liberty
zaqar - stable/kilo, stable/liberty


On Wed, Dec 16, 2015 at 1:52 PM, Andreas Jaeger <a...@suse.com> wrote:

> On 2015-12-16 12:33, Andrey Kurilin wrote:
>
>> Hi all,
>> As you may know, support of Python 2.6 was dropped this month from most
>> of OpenStack projects. Also infrastructure team dropped Centos 6.x jobs.
>>
>> I'm ok with dropping Python 2.6 support from the master(Mitaka), but
>> what about stable/kilo and stable/liberty ? Kilo and Liberty were
>> released with Python 2.6 support and most of projects have py26
>> classifiers there. Without py26 jobs in stable branches, it is hard to
>> backport any changes.
>>
>
> Kilo and liberty was not released and neither tested on our server
> projects for Python 2.6. If it had py26 classifiers, that was an error.
>
> It was tested only on the client projects so that new python client
> libraries could connect to an older installation.
>
> Andreas
>
> Also, requirements for stable/liberty do not contain upper caps for
>> python-*clients and oslo.* libraries, so most of projects already have
>> broken py26 support in Liberty.
>>
>> --
>> Best regards,
>> Andrey Kurilin.
>>
>>
>> __
>> OpenStack Development Mailing List (not for u

Re: [openstack-dev] [QA][Tempest] Use tempest-config for tempest-cli-improvements

[Andrey Kurilin]

Sorry for wrong numbers. The bug-fix for issue with counters is merged.
Correct numbers(latest result from rally's gate[1]):
 - total number of executed tests: 1689
 - success: 1155
 - skipped: 534 (neutron,heat,sahara,ceilometer are disabled. [2] should
enable them)
 - failed: 0

[1] -
http://logs.openstack.org/27/246627/11/gate/gate-rally-dsvm-verify-full/800bad0/rally-verify/7_verify_results_--html.html.gz
[2] - https://review.openstack.org/#/c/250540/

On Thu, Nov 26, 2015 at 3:23 PM, Yaroslav Lobankov <yloban...@mirantis.com>
wrote:

> Hello everyone,
>
> Yes, I am working on this now. We have some success already, but there is
> a lot of work to do. Of course, some things don't work ideally. For
> example, in [2] from the previous letter we have not 24 skipped tests,
> actually much more. So we have a bug somewhere :)
>
> Regards,
> Yaroslav Lobankov.
>
> On Thu, Nov 26, 2015 at 3:59 PM, Andrey Kurilin <akuri...@mirantis.com>
> wrote:
>
>> Hi!
>> Boris P. and I tried to push a spec[1] for automation tempest config
>> generator, but we did not succeed to merge it. Imo, qa-team doesn't want to
>> have such tool:(
>>
>> >However, there is a big concern:
>> >If the script contain a bug and creates the configuration which makes
>> >most tests skipped, we cannot do enough tests on the gate.
>> >Tempest contains 1432 tests and difficult to detect which tests are
>> >skipped as unexpected.
>>
>> Yaroslav Lobankov is working on improvement for tempest config generator
>> in Rally. Last time when we launch full tempest run[2], we got 1154 success
>> tests and only 24 skipped. Also, there is a patch, which adds x-fail
>> mechanism(it based on subunit-filter): you can transmit a file with test
>> names + reasons and rally will modify results.
>>
>> [1] - https://review.openstack.org/#/c/94473/
>>
>> [2] -
>> http://logs.openstack.org/49/242849/8/check/gate-rally-dsvm-verify/e91992e/rally-verify/7_verify_results_--html.html.gz
>>
>> On Thu, Nov 26, 2015 at 1:52 PM, Ken'ichi Ohmichi <ken1ohmi...@gmail.com>
>> wrote:
>>
>>> Hi Daniel,
>>>
>>> Thanks for pointing this up.
>>>
>>> 2015-11-25 1:40 GMT+09:00 Daniel Mellado <daniel.mellado...@ieee.org>:
>>> > Hi All,
>>> >
>>> > As you might already know, within Red Hat's tempest fork, we do have
>>> one
>>> > tempest configuration script which was built in the past by David
>>> Kranz [1]
>>> > and that's been actively used in our CI system. Regarding this topic,
>>> I'm
>>> > aware that quite some effort has been done in the past [2] and I would
>>> like
>>> > to complete the implementation of this blueprint/spec.
>>> >
>>> > My plan would be to have this script under the /tempest/cmd or
>>> > /tempest/tools folder from tempest so it can be used to configure not
>>> the
>>> > tempest gate but any cloud we'd like to run tempest against.
>>> >
>>> > Adding the configuration script was discussed briefly at the Mitaka
>>> summit
>>> > in the QA Priorities meting [3]. I propose we use the existing
>>> etherpad to
>>> > continue the discussion around and tracking of implementing "tempest
>>> > config-create" using the downstream config script as a starting point.
>>> [4]
>>> >
>>> > If you have any questions, comments or opinion, please let me know.
>>>
>>> This topic have happened several times, and I also felt this kind of
>>> tool was very useful for Tempest users, because Tempest contains 296
>>> options($ grep cfg * -R | grep Opt | wc -l) now and it is difficult to
>>> set the configuration up.
>>> However, there is a big concern:
>>> If the script contain a bug and creates the configuration which makes
>>> most tests skipped, we cannot do enough tests on the gate.
>>> Tempest contains 1432 tests and difficult to detect which tests are
>>> skipped as unexpected.
>>> Actually we faced unexpected skipped tests on the gate before due to
>>> some bug, then the problem has been fixed.
>>> But I can imagine this kind of problem happens after implementing this
>>> kind of script.
>>>
>>> So now I am feeling Tempest users need to know what cloud they want to
>>> test with Tempest, and need to know what tests run with Tempest.
>>> Testers need to know what test target/items they are testing basically.
>>>
>>> Thanks
>>> Ken O

Re: [openstack-dev] [QA][Tempest] Use tempest-config for tempest-cli-improvements

[Andrey Kurilin]

Hi!
Boris P. and I tried to push a spec[1] for automation tempest config
generator, but we did not succeed to merge it. Imo, qa-team doesn't want to
have such tool:(

>However, there is a big concern:
>If the script contain a bug and creates the configuration which makes
>most tests skipped, we cannot do enough tests on the gate.
>Tempest contains 1432 tests and difficult to detect which tests are
>skipped as unexpected.

Yaroslav Lobankov is working on improvement for tempest config generator in
Rally. Last time when we launch full tempest run[2], we got 1154 success
tests and only 24 skipped. Also, there is a patch, which adds x-fail
mechanism(it based on subunit-filter): you can transmit a file with test
names + reasons and rally will modify results.

[1] - https://review.openstack.org/#/c/94473/

[2] -
http://logs.openstack.org/49/242849/8/check/gate-rally-dsvm-verify/e91992e/rally-verify/7_verify_results_--html.html.gz

On Thu, Nov 26, 2015 at 1:52 PM, Ken'ichi Ohmichi <ken1ohmi...@gmail.com>
wrote:

> Hi Daniel,
>
> Thanks for pointing this up.
>
> 2015-11-25 1:40 GMT+09:00 Daniel Mellado <daniel.mellado...@ieee.org>:
> > Hi All,
> >
> > As you might already know, within Red Hat's tempest fork, we do have one
> > tempest configuration script which was built in the past by David Kranz
> [1]
> > and that's been actively used in our CI system. Regarding this topic, I'm
> > aware that quite some effort has been done in the past [2] and I would
> like
> > to complete the implementation of this blueprint/spec.
> >
> > My plan would be to have this script under the /tempest/cmd or
> > /tempest/tools folder from tempest so it can be used to configure not the
> > tempest gate but any cloud we'd like to run tempest against.
> >
> > Adding the configuration script was discussed briefly at the Mitaka
> summit
> > in the QA Priorities meting [3]. I propose we use the existing etherpad
> to
> > continue the discussion around and tracking of implementing "tempest
> > config-create" using the downstream config script as a starting point.
> [4]
> >
> > If you have any questions, comments or opinion, please let me know.
>
> This topic have happened several times, and I also felt this kind of
> tool was very useful for Tempest users, because Tempest contains 296
> options($ grep cfg * -R | grep Opt | wc -l) now and it is difficult to
> set the configuration up.
> However, there is a big concern:
> If the script contain a bug and creates the configuration which makes
> most tests skipped, we cannot do enough tests on the gate.
> Tempest contains 1432 tests and difficult to detect which tests are
> skipped as unexpected.
> Actually we faced unexpected skipped tests on the gate before due to
> some bug, then the problem has been fixed.
> But I can imagine this kind of problem happens after implementing this
> kind of script.
>
> So now I am feeling Tempest users need to know what cloud they want to
> test with Tempest, and need to know what tests run with Tempest.
> Testers need to know what test target/items they are testing basically.
>
> Thanks
> Ken Ohmichi
>
> ---
>
> > ---
> > [1]
> >
> https://github.com/redhat-openstack/tempest/blob/master/tools/config_tempest.py
> > [2]
> https://blueprints.launchpad.net/tempest/+spec/tempest-config-generator
> > [3] https://etherpad.openstack.org/p/mitaka-qa-priorities
> > [4] https://etherpad.openstack.org/p/tempest-cli-improvements
> >
> >
> https://github.com/openstack/qa-specs/blob/master/specs/tempest/tempest-cli-improvements.rst
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

[Andrey Kurilin]

Hi!
I'm not fuel developer, so opinion below is based on user-view.
As far as I remember from the last usage of fuel master node, there was
Centos + py26 installation. Python 2.6 is old enough and sometimes it is
hard to launch some application on fuel node without docker (image with
py27/py3). Are you planning to provide py27 at least or my note is outdated
and I can already use py27 from the box?

On Thu, Nov 19, 2015 at 4:59 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Dear colleagues,
>
> As might remember, we introduced Docker containers on the master node a
> while ago when we implemented first version of Fuel upgrade feature. The
> motivation behind was to make it possible to rollback upgrade process if
> something goes wrong.
>
> Now we are at the point where we can not use our tarball based upgrade
> approach any more and those patches that deprecate upgrade tarball has been
> already merged. Although it is a matter of a separate discussion, it seems
> that upgrade process rather should be based on kind of backup and restore
> procedure. We can backup Fuel data on an external media, then we can
> install new version of Fuel from scratch and then it is assumed backed up
> Fuel data can be applied over this new Fuel instance. The procedure itself
> is under active development, but it is clear that rollback in this case
> would be nothing more than just restoring from the previously backed up
> data.
>
> As for Docker containers, still there are potential advantages of using
> them on the Fuel master node, but our current implementation of the feature
> seems not mature enough to make us benefit from the containerization.
>
> At the same time there are some disadvantages like
>
>- it is tricky to get logs and other information (for example, rpm
>-qa) for a service like shotgun which is run inside one of containers.
>- it is specific UX when you first need to run dockerctl shell
>{container_name} and then you are able to debug something.
>- when building IBP image we mount directory from the host file system
>into mcollective container to make image build faster.
>- there are config files and some other files which should be shared
>among containers which introduces unnecessary complexity to the whole
>system.
>- our current delivery approach assumes we wrap into rpm/deb packages
>every single piece of the Fuel system. Docker images are not an exception.
>And as far as they depend on other rpm packages we forced to build
>docker-images rpm package using kind of specific build flow. Besides this
>package is quite big (300M).
>- I'd like it to be possible to install Fuel not from ISO but from RPM
>repo on any rpm based distribution. But it is double work to support both
>Docker based and package based approach.
>
> Probably some of you can give other examples. Anyway, the idea is to get
> rid of Docker containers on the master node and switch to plane package
> based approach that we used before.
>
> As far as there is nothing new here, we just need to use our old site.pp
> (with minimal modifications), it looks like it is possible to implement
> this during 8.0 release cycle. If there are no principal objections, please
> give me a chance to do this ASAP (during 8.0), I know it is a huge risk for
> the release, but still I think I can do this.
>
>
>
>
> Vladimir Kozhukalov
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [rally] "Failed to create the requested number of tenants" error

[Andrey Kurilin]

ist-hypervisors.yaml
> -
> > > but
> > > > > he keeps getting the error "Completed: Exit context: `users`\nTask
> > > > > config is invalid: `Unable to setup context 'users': 'Failed to
> create
> > > > > the requested number of tenants.'`"
> > > > >
> > > > > This is against an Icehouse environment with Mitaka Rally; When I
> run
> > > > > Rally with debug logging I see:
> > > > >
> > > > > 2016-06-08 18:59:24.692 11197 ERROR rally.common.broker
> > > EndpointNotFound:
> > > > > admin endpoint for identity service in  region not found
> > > > >
> > > > > However I note that $OS_AUTH_URL is set in the Rally deployment...
> see
> > > > > http://paste.openstack.org/show/509002/ for the full log.
> > > > >
> > > > > Any ideas you could give me would be much appreciated.  Thanks!
> > > > >
> > > > > --N.
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> __
> > > > > OpenStack Development Mailing List (not for usage questions)
> > > > > Unsubscribe:
> > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > > > >
> > >
> > > >
> > >
> ______
> > > > OpenStack Development Mailing List (not for usage questions)
> > > > Unsubscribe:
> > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > >
> > >
> __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
>
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] python-novaclient region setting

[Andrey Kurilin]

Hi!

>didn't work for me in this particular case because of a bug in novaclient

Can you tell more about bug in novaclient or share a bug report?

On Wed, Feb 24, 2016 at 8:42 AM, Xav Paice <xavpa...@gmail.com> wrote:

> fwiw, the second part of Monty's message is in the docs, sans region - it
> would be a fairly swift change to add that and I'll probably submit a
> gerrit for it soon.
>
> Regards os_client_config,
> http://docs.openstack.org/developer/os-client-config/ is great.
> Unfortunately it didn't work for me in this particular case because of a
> bug in novaclient, but that's beside the point - os_client_config is doing
> exactly the right thing and I'm really happy with that approach in most
> cases (and am changing some of our tooling to reflect that).
>
> On 24 February 2016 at 05:05, Matt Riedemann <mrie...@linux.vnet.ibm.com>
> wrote:
>
>>
>>
>> On 2/22/2016 8:02 AM, Monty Taylor wrote:
>>
>>> On 02/21/2016 11:40 PM, Andrey Kurilin wrote:
>>>
>>>> Hi!
>>>> `novaclient.client.Client` entry-point supports almost the same
>>>> arguments as `novaclient.v2.client.Client`. The difference is only in
>>>> api_version, so you can set up region via `novaclient.client.Client` in
>>>> the same way as `novaclient.v2.client.Client`.
>>>>
>>>
>>> The easiest way to get a properly constructed nova Client is with
>>> os-client-config:
>>>
>>> import os_client_config
>>>
>>> OS_PROJECT_NAME="d8af8a8f-a573-48e6-898a-af333b970a2d"
>>> OS_USERNAME="0b8c435b-cc4d-4e05-8a47-a2ada0539af1"
>>> OS_PASSWORD="REDACTED"
>>> OS_AUTH_URL="http://auth.vexxhost.net;
>>> OS_REGION_NAME="ca-ymq-1"
>>>
>>> client = os_client_config.make_client(
>>>  'compute',
>>>  auth_url=OS_AUTH_URL, username=OS_USERNAME,
>>>  password=OS_PASSWORD, project_name=OS_PROJECT_NAME,
>>>  region_name=OS_REGION_NAME)
>>>
>>> The upside is that the constructor interface is the same for all of the
>>> rest of the client libs too (just change the first argument) - and it
>>> will also read in OS_ env vars or named clouds from clouds.yaml if you
>>> have them set.
>>>
>>> (The 'simplest' way is to put your auth and region information into a
>>> clouds.yaml file like this:
>>>
>>>
>>> http://docs.openstack.org/developer/os-client-config/#site-specific-file-locations
>>>
>>>
>>> Such as:
>>>
>>> # ~/.config/openstack/clouds.yaml
>>> clouds:
>>>vexxhost:
>>>   profile: vexxhost
>>>   auth:
>>> project_name: d8af8a8f-a573-48e6-898a-af333b970a2d
>>> username: 0b8c435b-cc4d-4e05-8a47-a2ada0539af1
>>> password: REDACTED
>>>   region_name: ca-ymq-1
>>>
>>>
>>> And do:
>>>
>>> client = os_client_config.make_client('compute', cloud='vexxhost')
>>>
>>>
>>> If you don't want to do that for some reason but you'd like to construct
>>> a novaclient Client object by hand:
>>>
>>>
>>> from keystoneauth1 import loading
>>> from keystoneauth1 import session as ksa_session
>>> from novaclient import client as nova_client
>>>
>>> OS_PROJECT_NAME="d8af8a8f-a573-48e6-898a-af333b970a2d"
>>> OS_USERNAME="0b8c435b-cc4d-4e05-8a47-a2ada0539af1"
>>> OS_PASSWORD="REDACTED"
>>> OS_AUTH_URL="http://auth.vexxhost.net;
>>> OS_REGION_NAME="ca-ymq-1"
>>>
>>> # Get the auth loader for the password auth plugin
>>> loader = loading.get_plugin_loader('password')
>>> # Construct the auth plugin
>>> auth_plugin = loader.load_from_options(
>>>  auth_url=OS_AUTH_URL, username=OS_USERNAME, password=OS_PASSWORD,
>>>  project_name=OS_PROJECT_NAME)
>>>
>>> # Construct a keystone session
>>> # Other arguments that are potentially useful here are:
>>> #  verify - bool, whether or not to verify SSL connection validity
>>> #  cert - SSL cert information
>>> #  timout - time in seconds to use for connection level TCP timeouts
>>> session = ksa_session.Session(auth_plugin)
>>>
>>> # Now make the client
>>> # Other arguments you may be interested in:
>>> #  service_name - if you need to specify a service name for finding the
>>> # right service in the c

Re: [openstack-dev] [rally]how can I give admin role to rally

[Andrey Kurilin]

Hi!
Since I don't found such scenario in our upstream repo, I assume that this
is your custom plugin and I can propose you several solutions:

1) `nova evacuate` is allowed only for admin user, so you can use admin
client in your scenario without changing roles for users. Also,
`required_openstack` validator will check for you that admin client is
specified for your deployment. An example:

from rally.plugins.openstack import scenario


class MyPlugin(scenario.OpenStackScenario):
"""My awesome plugin."""

@validation.required_openstack(admin=True, users=True)
@scenario.configure()
def some_scenario(self):
# do something with nova via simple user
user_novaclient = self.clients("nova")
server = user_novaclient.servers.boot(...)

# do something with nova via admin user
admin_novaclient = self.admin_clients("nova")
admin_novaclient.servers.evacuate(...)


2) Rally supports "roles" context, which can assign roles to users. If you
specify your task as below, self.clients("nova") will return novaclient
initialized by user with "admin" and "another_name_of_role_if_needed" roles:

---
  MyPlugin.some_scenario:
-
  runner:
type: "constant"
times: 10
concurrency: 2
  context:
users:
  tenants: 2
  users_per_tenant: 3
roles:
  - "admin"
  - "another_name_of_role_if_needed"




On Tue, Feb 23, 2016 at 8:20 AM, Wu, Liming <wulm.f...@cn.fujitsu.com>
wrote:

> Hi
>
>   When I run a scenario about "nova evacuate **",  error message was
>   Show as follows.  How can I give the admin role to rally user.
>
> 2016-02-23 09:18:25.631 6212 INFO rally.task.runner [-] Task
> e2ad6390-8cde-4ed7-a595-f5c36d5e2a08 | ITER: 0 END: Error Forbidden: User
> does not have admin privileges (HTTP 403) (Request-ID:
> req-45312185-56e5-46c4-a39a-68f5e346715e)
> 2016-02-23 09:18:25.636 5995 INFO
> rally.plugins.openstack.context.cleanup.context [-] Task
> e2ad6390-8cde-4ed7-a595-f5c36d5e2a08 | Starting:  user resources cleanup
>
> Best regards
> wuliming
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] python-novaclient region setting

[Andrey Kurilin]

Hi!
`novaclient.client.Client` entry-point supports almost the same arguments
as `novaclient.v2.client.Client`. The difference is only in api_version, so
you can set up region via `novaclient.client.Client` in the same way as
`novaclient.v2.client.Client`.

On Mon, Feb 22, 2016 at 6:11 AM, Xav Paice <xavpa...@gmail.com> wrote:

> Hi,
>
> In http://docs.openstack.org/developer/python-novaclient/api.html it's
> got some pretty clear instructions not to use novaclient.v2.client.Client
> but I can't see another way to specify the region - there's more than one
> in my installation, and no param for region in novaclient.client.Client
>
> Shall I hunt down/write a blueprint for that?
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][infra] revert new gerrit

[Andrey Kurilin]

> If you haven't tried gertty yet, I highly recommend it.

I have an opened tab with it and I should try it, but I wonder why we need
gerrit if it a bad thing for a lot of contributors? Is there an alternative
for it?
Btw, I'm ready to have local instance of gerrit for myself. But I didn't
find a way to configure it to use upstream API.

> Someone should make a mobile-native app (android/ios) for gerrit now
since the new interface is so bad. Hopefully someone somewhere can come up
with the time for it. (I haven't had the time myself).

It looks like there is an app for android -
https://play.google.com/store/apps/details?id=com.jbirdvegas.mgerrit , but,
unfortunately, I have a phone from Apple and I didn't find anything for it.

I'm upset that classic theme was able to be used on mobile phones and new
one do not...


On Fri, Mar 18, 2016 at 5:40 PM, Morgan Fainberg <morgan.fainb...@gmail.com>
wrote:

>
>
> On Fri, Mar 18, 2016 at 8:35 AM, Monty Taylor <mord...@inaugust.com>
> wrote:
>
>> On 03/18/2016 08:31 AM, Andrey Kurilin wrote:
>>
>>> Hi all!
>>>
>>> I want to start this thread because I'm tired. I spent a lot of time,
>>> but I can't review as easy as it was with old interface. New Gerrit is
>>> awful. Here are several issues:
>>>
>>> * It is not possible to review patches at mobile phone. "New" "modern"
>>> theme is not adopted for small screens.
>>> * Leaving comments is a hard task. Position of page can jump anytime.
>>> * It is impossible to turn off hot-keys. position of page changed->I
>>> don't see that comment pop-up is closed->continue type several
>>> letters->make unexpected things(open edit mode, modify something, save,
>>> exit...)
>>> * patch-dependency tree is not user-friendly
>>> * summary table doesn't include status of patch(I need list to the end
>>> of a page to know if patch is merged or not)
>>> * there is no button "Comment"/"Reply" at the end of page(after all
>>> comments).
>>> * it is impossible to turn off "new" search mechanism
>>>
>>> Does it possible to return old, classic theme? It was a good time when
>>> we have old and new themes together...
>>>
>>
>> Sadly no. Upstream is pretty tied to the new very terrible interface.
>> We're not sure why.
>>
>> If you haven't tried gertty yet, I highly recommend it.
>>
>
> Someone should make a mobile-native app (android/ios) for gerrit now since
> the new interface is so bad. Hopefully someone somewhere can come up with
> the time for it. (I haven't had the time myself).
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] [CI] Tempest configuration in Tripleo CI jobs

[Andrey Kurilin]

> 'bare',
> disk_format  => 'qcow2',
> is_public=> 'yes',
> source   => '
> http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img',
>   }
>   glance_image { 'cirros_alt':
> ensure   => present,
> container_format => 'bare',
> disk_format  => 'qcow2',
> is_public=> 'yes',
> source   => '
> http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img',
>   }
>
> And then you run actually puppet tempest with configuration values, most
> of them you set by yourself:
>
> class { '::tempest':
>
>
> debug => true,
> use_stderr => false,
> log_file => 'tempest.log',
> tempest_clone_owner => $::id,
> git_clone => true,
> setup_venv => true,
> tempest_clone_path => '/tmp/openstack/tempest',
> lock_path => '/tmp/openstack/tempest',
> tempest_config_file => '/tmp/openstack/tempest/etc/tempest.conf',
> configure_images => true,
> configure_networks => true,
> allow_tenant_isolation => true,
> identity_uri => "${testt::config::keystone_auth_uri}/v2.0",
> identity_uri_v3 => "${testt::config::keystone_auth_uri}/v3",
> admin_username => "${testt::config::os_username}",
> admin_tenant_name => "${testt::config::os_tenant_name}",
> admin_password => "${testt::config::os_password}",
> admin_domain_name => 'Default',
> auth_version => 'v3',
> image_name => 'cirros',
> image_name_alt => 'cirros_alt',
> cinder_available => true,
> glance_available => true,
> horizon_available => $horizon,
> nova_available => true,
> neutron_available => true,
> ceilometer_available => $ceilometer,
> aodh_available => $aodh,
> trove_available => $trove,
> sahara_available => $sahara,
> heat_available => $heat,
> swift_available => true,
> ironic_available => $ironic,
> public_network_name => 'nova',
> dashboard_url => "${testt::config::host_url}",
> flavor_ref => 'pup_tempest_custom_nano',
> flavor_ref_alt => 'pup_tempest_custom_micro',
> image_ssh_user => 'cirros',
> image_alt_ssh_user => 'cirros',
> img_file => 'cirros-0.3.4-x86_64-disk.img',
> compute_build_interval => 10,
> ca_certificates_file => "${testt::config::ca_bundle_cert_path}",
> img_dir => '/tmp/openstack/tempest',
> }
>
> But it's not enough, you need also to make some workarounds and additional
> configurations, for example:
>
> tempest_config { 'object-storage/operator_role':
>   value => 'SwiftOperator',
>   path  => "${tempest_clone_path}/etc/tempest.conf",
> }
> }
>
> After this run puppet on controller node:
>
> sudo puppet apply --verbose --debug --detailed-exitcodes -e "include
> ::testt" | tee ~/puppet_run.log
>
> After everything is finished, you need to copy the folder with tempest to
> your node:
> scp -r -heat-admin@${CONTROLLER}:/tmp/openstack /tmp/
>
> After this run within this directory testr init and run tests:
> /tmp/tempest/tools/with_venv.sh testr init
> /tmp/tempest/tools/with_venv.sh testr run
>
> There are still holes in this configuration and most likely you'd fix it
> by another workarounds and tempest_config runs, because it's still a few of
> skipped tests, so configuration is not full as it would be done with
> config_tempest.py.
> You don't have also any possibility to add custom configuration in running
> the manifest, for each config change you need to change the manifest itself
> which makes it maintenance harder and more complex.
>
> I would say that conclusion is quite obvious for me and it's much easier
> even to write tempest.conf manually from scratch or simple template and use
> 5 bash lines, then use puppet for things it's completely not fit to.
>
> P.S. In this script I used ideas from puppet-openstack-integration and
> packstack projects.
>
> [1] https://review.openstack.org/#/c/295844/
> [2] https://git.openstack.org/openstack-infra/tripleo-ci
>
> --
> Best regards
> Sagi Shnaidman
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Infra] Gerrit performance

[Andrey Kurilin]

Guys,

My twitter-status was published long time ago and it is more about how bad
gerrit is itself.
I know you are doing your best to make it work. Thanks a lot for your work!



On Sun, Apr 10, 2016 at 3:52 PM, Jeremy Stanley <fu...@yuggoth.org> wrote:

> On 2016-04-10 12:43:06 +0300 (+0300), Andrey Kurilin wrote:
> > https://twitter.com/andrey_kurilin/status/681861838263443457
>
> A lot of the Infra team (me included) aren't on social media Web
> sites like that one, but Andreas Jaeger helpfully mentioned it in
> the #openstack-infra IRC channel on Freenode a few minutes ago and I
> restarted the service.
>
> We're still on track to replace the server with one tomorrow that
> has twice the memory capacity, and are hoping that relieves the load
> issues from the JVM's periodic GC runs.
>
> http://lists.openstack.org/pipermail/openstack-dev/2016-April/091274.html
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Infra] Gerrit performance

[Andrey Kurilin]

https://twitter.com/andrey_kurilin/status/681861838263443457

On Sun, Apr 10, 2016 at 10:39 AM, Gary Kotton <gkot...@vmware.com> wrote:

> Hi,
> Is anyone else having problems with gerrit:
>
>1. Sometimes get a proxy error
>2. Performance is very bad
>
> Thanks
> Gary
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all][infra] revert new gerrit

[Andrey Kurilin]

Hi all!

I want to start this thread because I'm tired. I spent a lot of time, but I
can't review as easy as it was with old interface. New Gerrit is awful.
Here are several issues:

* It is not possible to review patches at mobile phone. "New" "modern"
theme is not adopted for small screens.
* Leaving comments is a hard task. Position of page can jump anytime.
* It is impossible to turn off hot-keys. position of page changed->I don't
see that comment pop-up is closed->continue type several letters->make
unexpected things(open edit mode, modify something, save, exit...)
* patch-dependency tree is not user-friendly
* summary table doesn't include status of patch(I need list to the end of a
page to know if patch is merged or not)
* there is no button "Comment"/"Reply" at the end of page(after all
comments).
* it is impossible to turn off "new" search mechanism

Does it possible to return old, classic theme? It was a good time when we
have old and new themes together...

-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][infra] revert new gerrit

[Andrey Kurilin]

Hi Zago,


On Fri, Mar 18, 2016 at 6:35 PM, Zaro <zaro0...@gmail.com> wrote:

> There is a new web and android interface that's being developed by
> guys at Google however it's not available on our version of Gerrit.  I
> think it probably won't be ready until Gerrit ver 2.13+
>
> web interface (polymer+gerrit = polygerrit):
> This interface is already very usable in Gerrit 2.12.  Currently it's
> only available on the gerrit-review.googlesource.com server.  If you
> like you can try it out by creating an account there and access this
> new UI is "https://gerrit-review.googlesource.com/?polygerrit;.  I'm
> sure they would welcome your feedback.
>
>
UI of polygerrit looks better, but it is still unusable from mobile device
:(


> The android interface will be announced soon it's still in early
> development at this time.
>

Which kind of interface it will be? Android app or web-based application
which should potentially work for other devices?


> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Do we need a microversion to return a 501 from GET os-virtual-interfaces?

[Andrey Kurilin]

Hi!
I did not find any usage "virtual_interfaces" with try...except block, so
we can easily change error code without new microversion.

I'm +1 for proper code.

On Mon, Mar 7, 2016 at 6:32 PM, Ken'ichi Ohmichi <ken1ohmi...@gmail.com>
wrote:

> 2016-03-06 15:41 GMT-08:00 Jay Pipes <jaypi...@gmail.com>:
> > On 03/06/2016 02:21 PM, Matt Riedemann wrote:
> >>
> >> Thanks, good point. I think 400 would be best here. And according to our
> >> handy-dandy docs [1] it should be OK to do this without a microversion.
> >
> >
> > Yup, 400 is correct and yes, you should not need a new microversion
> addition
> > to the API.
>
> +1 for unnecessary microversion bumping.
>
> Thanks
> Ken Ohmichi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

[Andrey Kurilin]

Hi Ivan!

On Wed, Mar 2, 2016 at 1:25 PM, Ivan Kolodyazhny <e...@e0ne.info> wrote:

> Hi Team,
>
> Here are my thoughts and proposals how to make Cinder testing process
> better. I won't cover "3rd party CI's" topic here. I will share my opinion
> about current and feature jobs.
>
>
> Unit-tests
>
>- Long-running tests. I hope, everybody will agree that unit-tests
>must be quite simple and very fast. Unit tests which takes more than 3-5
>seconds should be refactored and/or moved to 'integration' tests.
>Thanks to Tom Barron for several fixes like [1]. IMO, we it would be
>good to have some hacking checks to prevent such issues in a future.
>
>- Tests coverage. We don't check it in an automatic way on gates.
>Usually, we require to add some unit-tests during code review process. Why
>can't we add coverage job to our CI and do not merge new patches, with
>will decrease tests coverage rate? Maybe, such job could be voting in a
>future to not ignore it. For now, there is not simple way to check coverage
>because 'tox -e cover' output is not useful [2].
>
> There is a script in Rally which can help you to check coverage rate -
https://github.com/openstack/rally/blob/master/tests/ci/cover.sh

Functional tests for Cinder
>
> We introduced some functional tests last month [3]. Here is a patch to
> infra to add new job [4]. Because these tests were moved from unit-tests, I
> think we're OK to make this job voting. Such tests should not be a
> replacement for Tempest. They even could tests Cinder with Fake Driver to
> make it faster and not related on storage backends issues.
>
>
> Tempest in-tree tests
>
> Sean started work on it [5] and I think it's a good idea to get them in
> Cinder repo to run them on Tempest jobs and 3-rd party CIs against a real
> backend.
>
>
> Functional tests for python-brick-cinderclient-ext
>
> There are patches that introduces functional tests [6] and new job [7].
>
>
> Functional tests for python-cinderclient
>
> We've got a very limited set of such tests and non-voting job. IMO, we can
> run them even with Cinder Fake Driver to make them not depended on a
> storage backend and make it faster. I believe, we can make this job voting
> soon. Also, we need more contributors to this kind of tests.
>
>
> Integrated tests for python-cinderclient
>
> We need such tests to make sure that we won't break Nova, Heat or other
> python-cinderclient consumers with a next merged patch. There is a thread
> in openstack-dev ML about such tests [8] and proposal [9] to introduce them
> to python-cinderclient.
>
>
> Rally tests
>
> IMO, it would be good to have new Rally scenarios for every patches like
> 'improves performance', 'fixes concurrency issues', etc. Even if we as a
> Cinder community don't have enough time to implement them, we have to ask
> for them in reviews, openstack-dev ML, file Rally bugs and blueprints if
> needed.
>
>
> [1] https://review.openstack.org/#/c/282861/
> [2] http://paste.openstack.org/show/488925/
> [3] https://review.openstack.org/#/c/267801/
> [4] https://review.openstack.org/#/c/287115/
> [5] https://review.openstack.org/#/c/274471/
> [6] https://review.openstack.org/#/c/265811/
> [7] https://review.openstack.org/#/c/265925/
> [8]
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088027.html
> [9] https://review.openstack.org/#/c/279432/
>
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
> ______
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Proposing Andrey Kurilin for python-novaclient core

[Andrey Kurilin]

I am glad to have joined the Team!

On Fri, Apr 15, 2016 at 6:00 PM, Matt Riedemann <mrie...@linux.vnet.ibm.com>
wrote:

>
>
> On 4/13/2016 12:53 PM, Matt Riedemann wrote:
>
>> I'd like to propose that we make Andrey Kurilin core on python-novaclient.
>>
>> He's been doing a lot of the maintenance the last several months and a
>> lot of times is the first to jump on any major issue, does a lot of the
>> microversion work, and is also working on cleaning up docs and helping
>> me with planning releases.
>>
>> His work is here [1].
>>
>> Review stats for the last 4 months (although he's been involved in the
>> project longer than that) [2].
>>
>> Unless there is disagreement I plan to make Andrey core by the end of
>> the week.
>>
>> [1]
>>
>> https://review.openstack.org/#/q/owner:akurilin%2540mirantis.com+project:openstack/python-novaclient
>>
>> [2] http://stackalytics.com/report/contribution/python-novaclient/120
>>
>>
> Alright, the yays have it, Andrey is now a part of the
> python-novaclient-core group. Welcome, Andrey!
>
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Nova commands

[Andrey Kurilin]

Hi!
Please, launch novaclient in debug mode, i.e `nova --debug list` and share
traceback from output.

On Tue, Apr 19, 2016 at 2:31 PM, Kenny Ji-work <jenkins-...@qq.com> wrote:

> Hi all,
>
> I have installed openstack mitaka, when I execute any nova's commands with
> the result displayed below:
>
> [root@devstack scripts]# nova list
> *ERROR (AttributeError): 'unicode' object has no attribute 'get'*
>
> I installed openstack as the
> http://docs.openstack.org/mitaka/install-guide-rdo/ shows. Is there
> somebody who encountered the issue? Thank you for answering!
>
> Sincerely!
> Kenny Ji
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Replace OSTF with Rally

[Andrey Kurilin]

Hi!

On Mon, Jun 27, 2016 at 4:23 PM, Alex Schultz <aschu...@mirantis.com> wrote:

>
>
> On Mon, Jun 27, 2016 at 7:10 AM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Dear colleagues,
>>
>> I'd like to suggest to replace Fuel-ostf with Rally. Rally is quite
>> popular project and as far as I know it has all necessary features
>> (including dashboard). We only need to implement testing scenarios.
>>
>> In particular the suggestion is as follows
>>
>> 1) Implement necessary testing scenarios to achieve feature parity with
>> Fuel-ostf (including those which test Fuel HA features).
>> 2) Prepare necessary rpm/deb packages (Rally itself + scenarios)
>> 3) Modify Fuel-qa so it uses Rally instead of Fuel-ostf.
>> 4) Deprecate Fuel-ostf (including removal of ostf tab on UI). I'd prefer
>> Fuel users to rely on Rally user interface (both CLI and dashboard).
>>
>> What do you think? Are there any volunteers to implement this?
>>
>>
> I thought Rally was more for benchmarking.  Wouldn't Tempest make more
> sense?
>
>
Rally is not only about benchmarking, it provides a flexible interface
which allows to do whatever you want:)


> -Alex
>
>
>>
>> Vladimir Kozhukalov
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Replace OSTF with Rally

[Andrey Kurilin]

On Mon, Jun 27, 2016 at 4:46 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
wrote:

>
> > On Jun 27, 2016, at 16:23, Alex Schultz <aschu...@mirantis.com> wrote:
> >
> > I thought Rally was more for benchmarking.  Wouldn't Tempest make more
> sense?
>
> According to Rally wiki page [1], it seems they have a verification layer
> (Tempest so far). Hm, I wonder does it mean we will need to rewrite our
> scenarios for Tempest?
>
>
Rally consists of two main components: Rally Task and Rally Verification.
They are totally separated.
Task component is fully pluggable and you can run there whatever you want
in whatever you want way.
Verification component is hardcoded now. It was designed for
managing(install, configure) and launching(execute and store results)
Tempest. But we have a spec to make this component pluggable too.


> - igor
>
>
> [1] https://wiki.openstack.org/wiki/Rally
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

[Andrey Kurilin]

On Thu, Feb 2, 2017 at 6:40 PM, Sean Dague <s...@dague.net> wrote:

> On 02/02/2017 11:16 AM, Matthew Treinish wrote:
> 
> > <oops, forgot to finish my though>
> >
> > We definitely aren't saying running a single worker is how we recommend
> people
> > run OpenStack by doing this. But it just adds on to the differences
> between the
> > gate and what we expect things actually look like.
>
> I'm all for actually getting to the bottom of this, but honestly real
> memory profiling is needed here. The growth across projects probably
> means that some common libraries are some part of this. The ever growing
> requirements list is demonstrative of that. Code reuse is good, but if
> we are importing much of a library to get access to a couple of
> functions, we're going to take a bunch of memory weight on that
> (especially if that library has friendly auto imports in top level
> __init__.py so we can't get only the parts we want).
>

Sounds like the new version of "oslo-incubator" idea.


>
> Changing the worker count is just shuffling around deck chairs.
>
> I'm not familiar enough with memory profiling tools in python to know
> the right approach we should take there to get this down to individual
> libraries / objects that are containing all our memory. Anyone more
> skilled here able to help lead the way?
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [rally][release] How rally release version

[Andrey Kurilin]

On Mon, Feb 13, 2017 at 3:17 PM, Jeffrey Zhang <zhang.lei@gmail.com>
wrote:

> @Andrey, thanks for the explanation.
>
> The issue is: how can i know which tag works with certain OpenStack
> branch? For example, which tag
> works with OpenStack Ocata release? There is no place recording this.
>
>
Rally project doesn't have alignment to any OpenStack release, since we do
not depend much on them. Latest release of Rally should work for all
OpenStack releases.


> I also found there are some other project do not use "project/releases"
> project. May they are using
> the same solution as rally.
>
> On Mon, Feb 13, 2017 at 6:14 PM, Andrey Kurilin <akuri...@mirantis.com>
> wrote:
>
>> Hi Jeffrey,
>>
>> Rally team do not use "releases" repo at all, that is why information at
>> [2] is outdated.
>> Our release workflow is making a proper tag and pushing it via Gerrit. I
>> find it more convenient.
>>
>>
>>
>> On Mon, Feb 13, 2017 at 9:13 AM, Jeffrey Zhang <zhang.lei@gmail.com>
>> wrote:
>>
>>> Hey guys,
>>>
>>> I found rally already releases its 0.8.1 tag from[0][1]. But
>>> I found nothing in openstack/releases project[2]. How rally
>>> create tag?
>>>
>>> [0] http://tarballs.openstack.org/rally/
>>> [1] https://github.com/openstack/rally/releases
>>> [2] https://github.com/openstack/releases/blob/master/delive
>>> rables/_independent/rally.yaml#L45
>>>
>>> --
>>> Regards,
>>> Jeffrey Zhang
>>> Blog: http://xcodest.me
>>>
>>> ________
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Best regards,
>> Andrey Kurilin.
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [governance][tc][rally] Rally (Re: [rally][release] How rally release version)

[Andrey Kurilin]

Hi Dims!

I do not want to say except question "why you are proposing to do that?".

I tried to find any rules about releasing at
https://governance.openstack.org, but I could not.
Please point me what rule I broke.

On Mon, Feb 13, 2017 at 3:57 PM, Davanum Srinivas <dava...@gmail.com> wrote:

> Andrey, Rally team,
>
> Do you want Rally to be dropped from Governance and Releases repository?
>
> Thanks,
> Dims
>
> On Mon, Feb 13, 2017 at 8:17 AM, Jeffrey Zhang <zhang.lei@gmail.com>
> wrote:
> > @Andrey, thanks for the explanation.
> >
> > The issue is: how can i know which tag works with certain OpenStack
> branch?
> > For example, which tag
> > works with OpenStack Ocata release? There is no place recording this.
> >
> > I also found there are some other project do not use "project/releases"
> > project. May they are using
> > the same solution as rally.
> >
> > On Mon, Feb 13, 2017 at 6:14 PM, Andrey Kurilin <akuri...@mirantis.com>
> > wrote:
> >>
> >> Hi Jeffrey,
> >>
> >> Rally team do not use "releases" repo at all, that is why information at
> >> [2] is outdated.
> >> Our release workflow is making a proper tag and pushing it via Gerrit. I
> >> find it more convenient.
> >>
> >>
> >>
> >> On Mon, Feb 13, 2017 at 9:13 AM, Jeffrey Zhang <zhang.lei@gmail.com
> >
> >> wrote:
> >>>
> >>> Hey guys,
> >>>
> >>> I found rally already releases its 0.8.1 tag from[0][1]. But
> >>> I found nothing in openstack/releases project[2]. How rally
> >>> create tag?
> >>>
> >>> [0] http://tarballs.openstack.org/rally/
> >>> [1] https://github.com/openstack/rally/releases
> >>> [2]
> >>> https://github.com/openstack/releases/blob/master/
> deliverables/_independent/rally.yaml#L45
> >>>
> >>> --
> >>> Regards,
> >>> Jeffrey Zhang
> >>> Blog: http://xcodest.me
> >>>
> >>>
> >>> 
> __
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> Andrey Kurilin.
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> >
> > --
> > Regards,
> > Jeffrey Zhang
> > Blog: http://xcodest.me
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [governance][tc][rally] Rally (Re: [rally][release] How rally release version)

[Andrey Kurilin]

On Mon, Feb 13, 2017 at 4:49 PM, Davanum Srinivas <dava...@gmail.com> wrote:

> Andrey,
>
> It's a question, not a proposal.
>

Sorry, but your message doesn't sound like a question. It sounds like a
polite proposal.


> If you don't do use releases repo, then rally information will be stale
> here:
> https://releases.openstack.org/
>
> Here's why we have a release team and things we do:
> https://governance.openstack.org/tc/reference/projects/relea
> se-management.html
> https://specs.openstack.org/openstack-infra/infra-specs/spec
> s/centralize-release-tagging.html
> http://docs.openstack.org/project-team-guide/release-management.html
>
> Since Rally is following the independent model, it has a whole lot of
> leeway:
> http://docs.openstack.org/project-team-guide/release-managem
> ent.html#independent-release-model
>
> However the absolute minimum requirement is that the releases repo
> should be kept in sync. If that is too cumbersome, i don't know...
>
>
Please re-read your first mail in the thread. It is not about synchronizing
release notes at all. You are
asking about throwing Rally project out from Big Tent due to ourdated info
posted at https://releases.openstack.org.
Seriusly?

To finish this topic:

- As a Rally PTL, I do not want to drop the project out of Big Tent. At
least for now. Who knows what will happen
  when you will extend bureaucracy someday...

- I'll update info at openstack/releases repo soon and will try to do it in
the right time while releasing new versions.

- Rally follows the rules described by:
  * http://docs.openstack.org/project-team-guide/release-managem
ent.html#independent-release-model
  *
http://docs.openstack.org/project-team-guide/release-management.html#release-process-for-other-projects

> OpenStack projects following a cycle-independent model can ... push
signed tags by themselves.

- There are no reasons to continue discussion dropping Rally. I can start a
ton of topics like "Drop Nova" with similar "real"
  reasons.

- I'm not against the work done by OpenStack Release team. I had a good
experience with that while working in not-Rally projects.


> Thanks,
> Dims
>
>
>
> On Mon, Feb 13, 2017 at 9:15 AM, Andrey Kurilin <akuri...@mirantis.com>
> wrote:
> > Hi Dims!
> >
> > I do not want to say except question "why you are proposing to do that?".
> >
> > I tried to find any rules about releasing at
> > https://governance.openstack.org, but I could not.
> > Please point me what rule I broke.
> >
> > On Mon, Feb 13, 2017 at 3:57 PM, Davanum Srinivas <dava...@gmail.com>
> wrote:
> >>
> >> Andrey, Rally team,
> >>
> >> Do you want Rally to be dropped from Governance and Releases repository?
> >>
> >> Thanks,
> >> Dims
> >>
> >> On Mon, Feb 13, 2017 at 8:17 AM, Jeffrey Zhang <zhang.lei@gmail.com
> >
> >> wrote:
> >> > @Andrey, thanks for the explanation.
> >> >
> >> > The issue is: how can i know which tag works with certain OpenStack
> >> > branch?
> >> > For example, which tag
> >> > works with OpenStack Ocata release? There is no place recording this.
> >> >
> >> > I also found there are some other project do not use
> "project/releases"
> >> > project. May they are using
> >> > the same solution as rally.
> >> >
> >> > On Mon, Feb 13, 2017 at 6:14 PM, Andrey Kurilin <
> akuri...@mirantis.com>
> >> > wrote:
> >> >>
> >> >> Hi Jeffrey,
> >> >>
> >> >> Rally team do not use "releases" repo at all, that is why information
> >> >> at
> >> >> [2] is outdated.
> >> >> Our release workflow is making a proper tag and pushing it via
> Gerrit.
> >> >> I
> >> >> find it more convenient.
> >> >>
> >> >>
> >> >>
> >> >> On Mon, Feb 13, 2017 at 9:13 AM, Jeffrey Zhang
> >> >> <zhang.lei@gmail.com>
> >> >> wrote:
> >> >>>
> >> >>> Hey guys,
> >> >>>
> >> >>> I found rally already releases its 0.8.1 tag from[0][1]. But
> >> >>> I found nothing in openstack/releases project[2]. How rally
> >> >>> create tag?
> >> >>>
> >> >>> [0] http://tarballs.openstack.org/rally/
> >> >>> [1] https://github.com/openstack/rally/releases
> >> >>> [2]
> >> >>>
> >> >&g

Re: [openstack-dev] [rally][release] How rally release version

[Andrey Kurilin]

Hi Jeffrey,

Rally team do not use "releases" repo at all, that is why information at
[2] is outdated.
Our release workflow is making a proper tag and pushing it via Gerrit. I
find it more convenient.



On Mon, Feb 13, 2017 at 9:13 AM, Jeffrey Zhang <zhang.lei@gmail.com>
wrote:

> Hey guys,
>
> I found rally already releases its 0.8.1 tag from[0][1]. But
> I found nothing in openstack/releases project[2]. How rally
> create tag?
>
> [0] http://tarballs.openstack.org/rally/
> [1] https://github.com/openstack/rally/releases
> [2] https://github.com/openstack/releases/blob/master/deliverables/_
> independent/rally.yaml#L45
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Do we need service types at all?! (Re: [octavia][sdk] service name for octavia)

[Andrey Kurilin]

On Thu, Feb 16, 2017 at 1:57 PM, Radomir Dopieralski <openst...@sheep.art.pl
> wrote:

> I think that you have to remember that OpenStack doesn't only work with
> officially approved OpenStack services, but with any services that have a
> conforming API.
>

Yes, I forgot about it. But it changes nothing.
Custom implementation of particular service should cover the same API as an
official one. For me, as for user, it doesn't metter if there is Keystone
or MyAwesomeKeystone, I want just an service which implements Keystone
functionality.


> OpenStack itself provides implementations of those services, and you are
> right that it's unlikely that there will be two competing implementations
> for the same service type officially endorsed by OpenStack. But you are
> ignoring 3rd-party services that are being used, and also the possibility
> that the services will change in the future. Since it doesn't really cost
> us to keep this flexibility, I think it's reasonable to keep doing it.
>
> On Thu, Feb 16, 2017 at 11:55 AM, Andrey Kurilin <akuri...@mirantis.com>
> wrote:
>
>> Hi everyone!
>>
>> When I started contribution to OpenStack long time ago, I asked about the
>> reason of having two entities - service type and name; at that time I got
>> an answer that service name is a name of the project that implements
>> particular service type, so it is possible to have several projects which
>> implement one service type. That answer satisfied me.
>>
>> The reality of OpenStack is that there is no and there will not be
>> several implementations of one "service type". Even when we had nova-net
>> and neutron, only the neutron registered his service in the catalog.
>>
>> An example of Octavia shows that everybody was ok about having service
>> name equal with type before inconsistency was found. That is why I want to
>> ask again: Do we need two separate entities and if yes - why? Maybe service
>> name and description fields should be enough?
>>
>> On Wed, Feb 15, 2017 at 3:08 AM, Qiming Teng <teng...@linux.vnet.ibm.com>
>> wrote:
>>
>>> When reviewing a recent patch that adds openstacksdk support to octavia,
>>> I found that octavia is using 'octavia' as its service name instead of
>>> 'loadbalancing' or 'loadbalancingv2' or something similar.
>>>
>>> The overall suggestion is to use a word/phrase that indicates what a
>>> service do instead of the name of the project providing that service.
>>>
>>> Below is the list of the service types currently supported by
>>> openstacksdk:
>>>
>>> 'alarming',# aodh
>>> 'baremetal',   # ironic
>>> 'clustering',  # senlin
>>> 'compute', # nova
>>> 'database',# trove
>>> 'identity',# keystone
>>> 'image',   # glance
>>> 'key-manager', # barbican
>>> 'messaging',   # zaqar
>>> 'metering',# ceilometer
>>> 'network', # neutron
>>> 'object-store',   # swift
>>> 'octavia',# <--- this is an exception
>>> 'orchestration',  # heat
>>> 'volume', # cinder
>>> 'workflowv2', # mistral
>>>
>>> While I believe this has been discussed about a year ago, I'm not sure
>>> if there are things we missed so I'm brining this issue to a broader
>>> audience for discussion.
>>>
>>> Reference:
>>>
>>> [1] Patch to python-openstacksdk:
>>> https://review.openstack.org/#/c/428414
>>> [2] Octavia service naming:
>>> http://git.openstack.org/cgit/openstack/octavia/tree/devstac
>>> k/plugin.sh#n52
>>>
>>> Regards,
>>>  Qiming
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> Best regards,
>> Andrey Kurilin.
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] Do we need service types at all?! (Re: [octavia][sdk] service name for octavia)

[Andrey Kurilin]

Hi everyone!

When I started contribution to OpenStack long time ago, I asked about the
reason of having two entities - service type and name; at that time I got
an answer that service name is a name of the project that implements
particular service type, so it is possible to have several projects which
implement one service type. That answer satisfied me.

The reality of OpenStack is that there is no and there will not be several
implementations of one "service type". Even when we had nova-net and
neutron, only the neutron registered his service in the catalog.

An example of Octavia shows that everybody was ok about having service name
equal with type before inconsistency was found. That is why I want to ask
again: Do we need two separate entities and if yes - why? Maybe service
name and description fields should be enough?

On Wed, Feb 15, 2017 at 3:08 AM, Qiming Teng <teng...@linux.vnet.ibm.com>
wrote:

> When reviewing a recent patch that adds openstacksdk support to octavia,
> I found that octavia is using 'octavia' as its service name instead of
> 'loadbalancing' or 'loadbalancingv2' or something similar.
>
> The overall suggestion is to use a word/phrase that indicates what a
> service do instead of the name of the project providing that service.
>
> Below is the list of the service types currently supported by
> openstacksdk:
>
> 'alarming',# aodh
> 'baremetal',   # ironic
> 'clustering',  # senlin
> 'compute', # nova
> 'database',# trove
> 'identity',# keystone
> 'image',   # glance
> 'key-manager', # barbican
> 'messaging',   # zaqar
> 'metering',# ceilometer
> 'network', # neutron
> 'object-store',   # swift
> 'octavia',# <--- this is an exception
> 'orchestration',  # heat
> 'volume', # cinder
> 'workflowv2', # mistral
>
> While I believe this has been discussed about a year ago, I'm not sure
> if there are things we missed so I'm brining this issue to a broader
> audience for discussion.
>
> Reference:
>
> [1] Patch to python-openstacksdk:
> https://review.openstack.org/#/c/428414
> [2] Octavia service naming:
> http://git.openstack.org/cgit/openstack/octavia/tree/
> devstack/plugin.sh#n52
>
> Regards,
>  Qiming
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Rally] PTL candidacy

[Andrey Kurilin]

Hi stackers,

I'm happy to announce my candidacy for Rally PTL for the Ocata release
cycle.

Quick introduction of myself:
 - My contribution to OpenStack started > 2.5 years ago
 - My first commit to Rally was merged ~ 2,5 years ago
 - I became Rally core ~2.3 years ago

My goals for the Ocata cycle:

 - simplify review process of Rally plugins(more democracy!)
 - do regular 3 weeks releases
 - provide up-to-dated release schedule
 - finish validation refactoring to be more flexible
 - port rally verification component to plugin base to support different
verifiers
 - provide subunit output for Rally Task
 - continue work on Rally as a Service
 - make rally certification even more user-friendly and cover more use-cases
 - update docs to cover all aspects of Rally
 - finish work on new entity - hooks, which allow to execute something on
   specified points of scenario execution
 - port all plugins to support Keystone V3 and make V3 as default version
 - provide a way to deliver rally plugins as python packages
 - split Rally Core and OpenStack related plugins into 2 repos
 - nested atomics
 - trends reports for rally verification


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [Rally] broken jobs

[Andrey Kurilin]

Finally, fixes are merged and our jobs work now.

On Tue, Nov 22, 2016 at 3:01 PM, Andrey Kurilin <akuri...@mirantis.com>
wrote:

> Hi Renat,
>
> As soon as one [1][2] changes will be merged, everything should be
> unblocked.
>
> [1] - https://review.openstack.org/#/c/399752
> [2] - https://review.openstack.org/#/c/400183
>
>
> On Tue, Nov 22, 2016 at 12:40 PM, Renat Akhmerov <renat.akhme...@gmail.com
> > wrote:
>
>> Andrey, thanks for reporting this. Any estimations on how long it will
>> take to fix it?
>>
>> Renat Akhmerov
>> @Nokia
>>
>> On 19 Nov 2016, at 02:23, Andrey Kurilin <akuri...@mirantis.com> wrote:
>>
>> yse, I think you are right.
>>
>> On Fri, Nov 18, 2016 at 4:04 PM, gordon chung <g...@live.ca> wrote:
>>
>>> this seems related to fact we use datetime type in mysql which requires
>>> 5.6.4? (i'm guessing on version). but yes, ubuntu-xenial should have the
>>> required mysql.
>>>
>>> On 18/11/16 07:50 AM, Andrey Kurilin wrote:
>>> > Hi stackers,
>>> >
>>> > I hate to report such things, but most of rally jobs are broken now due
>>> > to uncompatibility aodh service with ubuntu-trusty nodes.
>>> >
>>> > If you find failed rally jobs with
>>> > http://paste.openstack.org/show/589707/ in devstacklogs, recheck will
>>> > not help.
>>> >
>>> > I'm working on two changes now for Rally jobs which should unblock and
>>> > fix gates:
>>> > - Port Rally jobs to use ubuntu-xenial nodes. We had to do it long
>>> time ago.
>>> > - Disable telemetry services in those jobs which do not need them.
>>> >
>>> >
>>> > --
>>> > Best regards,
>>> > Andrey Kurilin.
>>> >
>>> >
>>> > 
>>> __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>> --
>>> gord
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> Best regards,
>> Andrey Kurilin.
>> ________
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best regards,
> Andrey Kurilin.
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

[Andrey Kurilin]

The same for Rally project...

On Thu, Oct 13, 2016 at 2:56 PM, Qiming Teng <teng...@linux.vnet.ibm.com>
wrote:

> project-navigator? http://www.openstack.org/software/
>
> It is often misinterpreted as: OpenStack has 6 core services which are
> all mandatory (because they are *core* services) plus 13 optional
> services that can be selectively installed.
>
> I tried hard to find out how the lists are generated, but I failed.
> There are at least the following projects which are neither *core* nor
> *optional* services:
>
> cloudkitty
> dragonflow
> freezer
> karbor
> kolla
> kuryr
> mistral
> monasca
> searchlight
> senlin
> solum
> tacker
> vitrage
> watcher
>
> Looks like this is something causing some confusions. Should/can we fix
> that?
>
> Regards,
>   Qiming
>
>
> On Wed, Oct 12, 2016 at 02:43:45PM -0700, Mike Perez wrote:
> > On 14:50 Oct 12, Flavio Percoco wrote:
> > > Greetings,
> > >
> > > One of the common complains about the existing project organization in
> the big
> > > tent is that it's difficult to wrap our heads around the many projects
> there
> > > are, their current state (in/out the big tent), their tags, etc.
> > >
> > > This information is available on the governance website[0]. Each
> official
> > > project team has a page there containing the information related to the
> > > deliverables managed by that team. Unfortunately, I don't think this
> page is
> > > checked often enough and I believe it's not known by everyone.
> >
> > Besides the governance site, there is also the project navigator [1]
> which is
> > a more friendly landing page on projects and their tags. Although it
> does not
> > today capture separate deliverables.
> >
> > Assuming the README files aren't being manually updated, I don't have a
> problem
> > with this idea.
> >
> > [1] - https://www.openstack.org/software/project-navigator/
> >
> > --
> > Mike Perez
>
>
> __________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [Rally] broken jobs

[Andrey Kurilin]

Hi Renat,

As soon as one [1][2] changes will be merged, everything should be
unblocked.

[1] - https://review.openstack.org/#/c/399752
[2] - https://review.openstack.org/#/c/400183


On Tue, Nov 22, 2016 at 12:40 PM, Renat Akhmerov <renat.akhme...@gmail.com>
wrote:

> Andrey, thanks for reporting this. Any estimations on how long it will
> take to fix it?
>
> Renat Akhmerov
> @Nokia
>
> On 19 Nov 2016, at 02:23, Andrey Kurilin <akuri...@mirantis.com> wrote:
>
> yse, I think you are right.
>
> On Fri, Nov 18, 2016 at 4:04 PM, gordon chung <g...@live.ca> wrote:
>
>> this seems related to fact we use datetime type in mysql which requires
>> 5.6.4? (i'm guessing on version). but yes, ubuntu-xenial should have the
>> required mysql.
>>
>> On 18/11/16 07:50 AM, Andrey Kurilin wrote:
>> > Hi stackers,
>> >
>> > I hate to report such things, but most of rally jobs are broken now due
>> > to uncompatibility aodh service with ubuntu-trusty nodes.
>> >
>> > If you find failed rally jobs with
>> > http://paste.openstack.org/show/589707/ in devstacklogs, recheck will
>> > not help.
>> >
>> > I'm working on two changes now for Rally jobs which should unblock and
>> > fix gates:
>> > - Port Rally jobs to use ubuntu-xenial nodes. We had to do it long time
>> ago.
>> > - Disable telemetry services in those jobs which do not need them.
>> >
>> >
>> > --
>> > Best regards,
>> > Andrey Kurilin.
>> >
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> --
>> gord
>>
>> ________
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Best regards,
> Andrey Kurilin.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Rally][all] Gitter as an alternative way for communication

[Andrey Kurilin]

Hi folks!

I'm happy to announce our new chats at gitter.im :

- https://gitter.im/rally-dev/Lobby  # main chat for regular
communication
- https://gitter.im/rally-dev/statuses  # chat for gerrit notifications

These chats are configured with a simple bot which syncs messages between
Gitter and IRC, so we do not plan to abandon our #openstack-rally Freenode
channel and you can choose the best messenger for yourself.

Long story:
I had a talk with several guys some time ago and they mentioned that IRC is
not convenient for them enough, even with modern clients like IRCCloud (it
is not an advertisement:) ). Also, this topic was raised at Rally work
session at Barcelona and we discussed it at our weekly meetings too.

Why Gitter?
Gitter is a free service from GitHub, so you can use you GitHub account for
authentication (everyone has GitHub account) or you can use your twitter
account. It provides convenient chats with avatars, quoting, markdown and
etc. You do not need an invitation for join us - just go to
https://gitter.im/rally-dev/Lobby and push "join room" button.
Also, if you want, you can use Gitter IRC tunnel (actually, you do not need
it, you can continue use #openstack-rally Freenode channel).

Why not slack?
Slack is good enough and it is used by another big community - Kubernetes,
but, imho, it has at least several limitations: you need to be invited for
joining "organization"; the way of switching between organizations are not
good enough.

-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Rally][all] Gitter as an alternative way for communication

[Andrey Kurilin]

Hi Thierry,

On Fri, Nov 25, 2016 at 12:51 PM, Thierry Carrez <thie...@openstack.org>
wrote:

> Andrey Kurilin wrote:
> > I'm happy to announce our new chats at gitter.im <http://gitter.im> :
> > [...]
>
> While I understand where you're coming from, I would like to remind you
> that the OpenStack community standardized on IRC for community
> communication. Maintaining alternate communication channels might make
> it slightly easier for your team members, but it makes it more difficult
> for others in the OpenStack community to follow what is happening, and
> participate to Rally development.


As I said before, we do not plan to abandon our regular IRC channel and we
have a bot for synchronisation messages between gitter and irc channels, so
users from Gitter can participate in IRC discussions, and vice versa users
from IRC
can ping guys from our Gitter channel. It is just an extension of rally
communication
workflow, not replacement of IRC at all.



> This is why as part of the official
> OpenStack project team requirements we have usage of IRC baked in.
>
> IRC is a standard protocol, implemented in a lot of open source clients.
> Alternatives like Slack or Gitter are closed-source services with terms
> of use (and future decisions on openness and pricing) that may or may
> not be acceptable by our community members -- using them creates
> fragmentation within the OpenStack community.
>
> That is not saying that IRC is perfect and that we will never move to
> something else. But when we do, it will be as a community (and after an
> open community discussion) and not project per project.


I can believe that OpenStack community will move from Freenode to another
IRC service (if Freenode dies) someday, but moving to another protocol is
unbelievable
thing for me. OpenStack community will never do it. :) We'd rather maintain
IRC protocol by ourself...

That is why Rally-community decided to use "not-irc tool" without
cross-project
discussion. BUT, as I said before, we did it without breaking compatibility
with
other OpenStack projects and we will not do it..


> It is also
> likely to be toward an open protocol supported by open source software,
> rather than one specific third-party proprietary web service.
>

Why? Why we can not use convenient free for opensource projects things?
Why not enjoy all the advantages of the modern world?:) It is out of
current topic, but
why we use inconvenient launchpad instead of bitbucket and so on?


> Regards,
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [Rally] broken jobs

[Andrey Kurilin]

yse, I think you are right.

On Fri, Nov 18, 2016 at 4:04 PM, gordon chung <g...@live.ca> wrote:

> this seems related to fact we use datetime type in mysql which requires
> 5.6.4? (i'm guessing on version). but yes, ubuntu-xenial should have the
> required mysql.
>
> On 18/11/16 07:50 AM, Andrey Kurilin wrote:
> > Hi stackers,
> >
> > I hate to report such things, but most of rally jobs are broken now due
> > to uncompatibility aodh service with ubuntu-trusty nodes.
> >
> > If you find failed rally jobs with
> > http://paste.openstack.org/show/589707/ in devstacklogs, recheck will
> > not help.
> >
> > I'm working on two changes now for Rally jobs which should unblock and
> > fix gates:
> > - Port Rally jobs to use ubuntu-xenial nodes. We had to do it long time
> ago.
> > - Disable telemetry services in those jobs which do not need them.
> >
> >
> > --
> > Best regards,
> > Andrey Kurilin.
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> --
> gord
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] rally failure in the gate

[Andrey Kurilin]

Hi stackers!

Imo, there is a better solution - just turn off telemetry services[*] :)
Neutron jobs do not runs any ceilometer scenarios, so enabling all
telemetry services looks redundant and takes some time while preparing
environment (installing devstack).


[*] - https://review.openstack.org/#/c/399212

On Fri, Nov 18, 2016 at 12:41 PM, Ihar Hrachyshka <ihrac...@redhat.com>
wrote:

>
> > On 17 Nov 2016, at 20:32, Armando M. <arma...@gmail.com> wrote:
> >
> > Hi folks,
> >
> > Please do not recheck rally failures.
> >
> > There was a breaking change introduced by aodh [0] that prevented rally
> to work on trusty. We are switching to xenial as we speak anyway [1], so
> the glitch should be short lived.
>
> To give an update, the switch to Xenial occurred, and I see jobs passing
> just fine again.
>
> Ihar
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] [Rally] broken jobs

[Andrey Kurilin]

Hi stackers,

I hate to report such things, but most of rally jobs are broken now due to
uncompatibility aodh service with ubuntu-trusty nodes.

If you find failed rally jobs with http://paste.openstack.org/show/589707/
in devstacklogs, recheck will not help.

I'm working on two changes now for Rally jobs which should unblock and fix
gates:
- Port Rally jobs to use ubuntu-xenial nodes. We had to do it long time ago.
- Disable telemetry services in those jobs which do not need them.


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] rally failure in the gate

[Andrey Kurilin]

hi folks!

Neutron gates are broken again. New failure relates to issue with
heatclient [*] .

[*] - https://bugs.launchpad.net/python-heatclient/+bug/1643507



On Fri, Nov 18, 2016 at 12:51 PM, Andrey Kurilin <akuri...@mirantis.com>
wrote:

> Hi stackers!
>
> Imo, there is a better solution - just turn off telemetry services[*] :)
> Neutron jobs do not runs any ceilometer scenarios, so enabling all
> telemetry services looks redundant and takes some time while preparing
> environment (installing devstack).
>
>
> [*] - https://review.openstack.org/#/c/399212
>
> On Fri, Nov 18, 2016 at 12:41 PM, Ihar Hrachyshka <ihrac...@redhat.com>
> wrote:
>
>>
>> > On 17 Nov 2016, at 20:32, Armando M. <arma...@gmail.com> wrote:
>> >
>> > Hi folks,
>> >
>> > Please do not recheck rally failures.
>> >
>> > There was a breaking change introduced by aodh [0] that prevented rally
>> to work on trusty. We are switching to xenial as we speak anyway [1], so
>> the glitch should be short lived.
>>
>> To give an update, the switch to Xenial occurred, and I see jobs passing
>> just fine again.
>>
>> Ihar
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Best regards,
> Andrey Kurilin.
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] rally failure in the gate

[Andrey Kurilin]

Dims, thanks!

On Mon, Nov 21, 2016 at 1:44 PM, Davanum Srinivas <dava...@gmail.com> wrote:

> Andrey, Folks,
>
> I've fast-tracked the black list:
> https://review.openstack.org/400183
>
> Thanks,
> Dims
>
>
>
> On Mon, Nov 21, 2016 at 6:00 AM, Andrey Kurilin <akuri...@mirantis.com>
> wrote:
> > hi folks!
> >
> > Neutron gates are broken again. New failure relates to issue with
> heatclient
> > [*] .
> >
> > [*] - https://bugs.launchpad.net/python-heatclient/+bug/1643507
> >
> >
> >
> > On Fri, Nov 18, 2016 at 12:51 PM, Andrey Kurilin <akuri...@mirantis.com>
> > wrote:
> >>
> >> Hi stackers!
> >>
> >> Imo, there is a better solution - just turn off telemetry services[*] :)
> >> Neutron jobs do not runs any ceilometer scenarios, so enabling all
> telemetry
> >> services looks redundant and takes some time while preparing environment
> >> (installing devstack).
> >>
> >>
> >> [*] - https://review.openstack.org/#/c/399212
> >>
> >> On Fri, Nov 18, 2016 at 12:41 PM, Ihar Hrachyshka <ihrac...@redhat.com>
> >> wrote:
> >>>
> >>>
> >>> > On 17 Nov 2016, at 20:32, Armando M. <arma...@gmail.com> wrote:
> >>> >
> >>> > Hi folks,
> >>> >
> >>> > Please do not recheck rally failures.
> >>> >
> >>> > There was a breaking change introduced by aodh [0] that prevented
> rally
> >>> > to work on trusty. We are switching to xenial as we speak anyway
> [1], so the
> >>> > glitch should be short lived.
> >>>
> >>> To give an update, the switch to Xenial occurred, and I see jobs
> passing
> >>> just fine again.
> >>>
> >>> Ihar
> >>>
> >>> 
> __
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> Andrey Kurilin.
> >
> >
> >
> >
> > --
> > Best regards,
> > Andrey Kurilin.
> >
> > ____
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] broken rally gate

[Andrey Kurilin]

Sorry folks!
We were broken by Keystone, Nova-net, Heat, oslo.db, setuptools(virtualenv)
at one moment and it looks like I made a mistake while trying to fix them
all.

On Fri, Dec 9, 2016 at 3:04 AM, Armando M. <arma...@gmail.com> wrote:

>
>
> On 8 December 2016 at 16:40, Armando M. <arma...@gmail.com> wrote:
>
>> Hi folks
>>
>> Chasing down why [1] accidentally broke rally. Please do not recheck, and
>> the failure is persistent.
>>
>> Thanks,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/408020
>>
>
> https://review.openstack.org/#/c/408870/ should bring sanity back into
> the world.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][devstack][rally][python-novaclient][magnum] switching to keystone v3 by default

[Andrey Kurilin]

On Thu, Dec 1, 2016 at 7:39 PM, Morgan Fainberg <morgan.fainb...@gmail.com>
wrote:

> On Dec 1, 2016 8:25 AM, "Andrey Kurilin" <akuri...@mirantis.com> wrote:
> >
> > As I replied at IRC, please do not mix two separate issues!
> > Yes, we have several scenarios which are not support keystone v3 yet. It
> is an issue, but it is unrelated issue to described in the first mail.
> > We have a job which is configured with proper IDENTITY_API_VERSION flag
> and should be launched against Keystone v2, but there is only keystone v3
> and it is a real issue.
> >
> > On Thu, 1 Dec 2016 at 17:48, Lance Bragstad <lbrags...@gmail.com> wrote:
> >>
> >> FWIW - i'm seeing a common error in several of the rally failures [0]
> [1] [2] [3]. Dims also pointed out a few bugs in rally for keystone v3
> support [4].
> >>
> >> I checked with the folks in #openstack-containers to see if they were
> experiencing anymore fallout, but it looks like the magnum gate is under
> control [5]. We're currently in #openstack-keystone talking through options
> for the rally situation in case anyone feels like joining.
> >>
> >>
> >> [0] http://logs.openstack.org/87/404887/4/check/gate-rally-
> dsvm-neutron-existing-users-rally/ff60a83/console.html#_
> 2016-12-01_08_05_55_268772
> >> [1] http://logs.openstack.org/43/405143/3/check/gate-rally-
> dsvm-neutron-existing-users-rally/3ee975b/console.html#_
> 2016-12-01_08_39_02_618302
> >> [2] http://logs.openstack.org/83/394583/26/check/gate-rally-
> dsvm-cli/af28c0f/console.html#_2016-12-01_14_09_19_584427
> >> [3] http://logs.openstack.org/83/394583/26/check/gate-rally-
> dsvm-neutron-existing-users-rally/26cd009/console.html#_
> 2016-12-01_14_15_17_147016
> >> [4] https://bugs.launchpad.net/rally?field.searchtext=keystone+v3
> >> [5] http://eavesdrop.openstack.org/irclogs/%23openstack-containers/%
> 23openstack-containers.2016-12-01.log.html#t2016-12-01T14:57:00
> >>
> >> On Thu, Dec 1, 2016 at 6:39 AM, Spyros Trigazis <strig...@gmail.com>
> wrote:
> >>>
> >>> I think for magnum we are OK.
> >>>
> >>> This job [1] finished using keystone v3 [2]
> >>>
> >>> Spyros
> >>>
> >>> [1] http://logs.openstack.org/93/400593/9/check/gate-
> functional-dsvm-magnum-api/93e8c14/
> >>> [2] http://logs.openstack.org/93/400593/9/check/gate-
> functional-dsvm-magnum-api/93e8c14/logs/devstacklog.txt.
> gz#_2016-12-01_11_32_58_033
> >>>
> >>> On 1 December 2016 at 12:26, Davanum Srinivas <dava...@gmail.com>
> wrote:
> >>>>
> >>>> It has taken years to get here with a lot of work from many folks.
> >>>>
> >>>> -1 for Any revert!
> >>>>
> >>>> https://etherpad.openstack.org/p/v3-only-devstack
> >>>> http://markmail.org/message/aqq7itdom36omnf6
> >>>> https://review.openstack.org/#/q/status:merged+project:
> openstack-dev/devstack+branch:master+topic:bp/keystonev3
> >>>>
> >>>> Thanks,
> >>>> Dims
> >>>>
> >>>> On Thu, Dec 1, 2016 at 5:38 AM, Andrey Kurilin <akuri...@mirantis.com>
> wrote:
> >>>> > Hi folks!
> >>>> >
> >>>> > Today devstack team decided to switch to keystone v3 by default[0].
> >>>> > Imo, it is important thing, but it was made in silent, so other
> project was
> >>>> > unable to prepare to that change. Also, proposed way to select
> Keystone API
> >>>> > version via devstack configuration doesn't work(IDENTITY_API_VERSION
> >>>> > variable doesn't work [1] ).
> >>>> >
> >>>> > Switching to keystone v3 broke at least Rally and Magnum(based on
> comment to
> >>>> > [0])  gates. Also, python-novaclient has two separate jobs for
> checking
> >>>> > compatibility with keystone V2 and V3. One of these jobs became
> redundant.
> >>>> >
> >>>> > That is why I submitted a revert [2] .
> >>>> >
> >>>> > PS: Please, do not make such changes in silent!
> >>>> >
> >>>> > [0] - https://review.openstack.org/#/c/386183
> >>>> > [1] -
> >>>> > https://github.com/openstack-infra/project-config/blob/
> master/jenkins/jobs/rally.yaml#L70-L74
> >>>> > [2] - https://review.openstack.org/405264
> >>>> >
> >>>> > --
&g

Re: [openstack-dev] [keystone][devstack][rally][python-novaclient][magnum] switching to keystone v3 by default

[Andrey Kurilin]

As I replied at IRC, please do not mix two separate issues!
Yes, we have several scenarios which are not support keystone v3 yet. It is
an issue, but it is unrelated issue to described in the first mail.
We have a job which is configured with proper IDENTITY_API_VERSION flag and
should be launched against Keystone v2, but there is only keystone v3 and
it is a real issue.

On Thu, 1 Dec 2016 at 17:48, Lance Bragstad <lbrags...@gmail.com> wrote:

> FWIW - i'm seeing a common error in several of the rally failures [0] [1]
> [2] [3]. Dims also pointed out a few bugs in rally for keystone v3 support
> [4].
>
> I checked with the folks in #openstack-containers to see if they were
> experiencing anymore fallout, but it looks like the magnum gate is under
> control [5]. We're currently in #openstack-keystone talking through options
> for the rally situation in case anyone feels like joining.
>
>
> [0]
> http://logs.openstack.org/87/404887/4/check/gate-rally-dsvm-neutron-existing-users-rally/ff60a83/console.html#_2016-12-01_08_05_55_268772
> [1]
> http://logs.openstack.org/43/405143/3/check/gate-rally-dsvm-neutron-existing-users-rally/3ee975b/console.html#_2016-12-01_08_39_02_618302
> [2]
> http://logs.openstack.org/83/394583/26/check/gate-rally-dsvm-cli/af28c0f/console.html#_2016-12-01_14_09_19_584427
> [3]
> http://logs.openstack.org/83/394583/26/check/gate-rally-dsvm-neutron-existing-users-rally/26cd009/console.html#_2016-12-01_14_15_17_147016
> [4] https://bugs.launchpad.net/rally?field.searchtext=keystone+v3
> [5]
> http://eavesdrop.openstack.org/irclogs/%23openstack-containers/%23openstack-containers.2016-12-01.log.html#t2016-12-01T14:57:00
>
> On Thu, Dec 1, 2016 at 6:39 AM, Spyros Trigazis <strig...@gmail.com>
> wrote:
>
> I think for magnum we are OK.
>
> This job [1] finished using keystone v3 [2]
>
> Spyros
>
> [1]
> http://logs.openstack.org/93/400593/9/check/gate-functional-dsvm-magnum-api/93e8c14/
> [2]
> http://logs.openstack.org/93/400593/9/check/gate-functional-dsvm-magnum-api/93e8c14/logs/devstacklog.txt.gz#_2016-12-01_11_32_58_033
>
> On 1 December 2016 at 12:26, Davanum Srinivas <dava...@gmail.com> wrote:
>
> It has taken years to get here with a lot of work from many folks.
>
> -1 for Any revert!
>
> https://etherpad.openstack.org/p/v3-only-devstack
> http://markmail.org/message/aqq7itdom36omnf6
>
> https://review.openstack.org/#/q/status:merged+project:openstack-dev/devstack+branch:master+topic:bp/keystonev3
>
> Thanks,
> Dims
>
> On Thu, Dec 1, 2016 at 5:38 AM, Andrey Kurilin <akuri...@mirantis.com>
> wrote:
> > Hi folks!
> >
> > Today devstack team decided to switch to keystone v3 by default[0].
> > Imo, it is important thing, but it was made in silent, so other project
> was
> > unable to prepare to that change. Also, proposed way to select Keystone
> API
> > version via devstack configuration doesn't work(IDENTITY_API_VERSION
> > variable doesn't work [1] ).
> >
> > Switching to keystone v3 broke at least Rally and Magnum(based on
> comment to
> > [0])  gates. Also, python-novaclient has two separate jobs for checking
> > compatibility with keystone V2 and V3. One of these jobs became
> redundant.
> >
> > That is why I submitted a revert [2] .
> >
> > PS: Please, do not make such changes in silent!
> >
> > [0] - https://review.openstack.org/#/c/386183
> > [1] -
> >
> https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/rally.yaml#L70-L74
> > [2] - https://review.openstack.org/405264
> >
> > --
> > Best regards,
> > Andrey Kurilin.
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___

[openstack-dev] [keystone][devstack][rally][python-novaclient][magnum] switching to keystone v3 by default

[Andrey Kurilin]

Hi folks!

Today devstack team decided to switch to keystone v3 by default[0].
Imo, it is important thing, but it was made in silent, so other project was
unable to prepare to that change. Also, proposed way to select Keystone API
version via devstack configuration doesn't work(IDENTITY_API_VERSION
variable doesn't work [1] ).

Switching to keystone v3 broke at least Rally and Magnum(based on comment
to [0])  gates. Also, python-novaclient has two separate jobs for checking
compatibility with keystone V2 and V3. One of these jobs became redundant.

That is why I submitted a revert [2] .

PS: Please, do not make such changes in silent!

[0] - https://review.openstack.org/#/c/386183
[1] -
https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/rally.yaml#L70-L74
[2] - https://review.openstack.org/405264

-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Performance] PTG?

[Andrey Kurilin]

Hi, Joe!

It is not a mistake. After a talk with Dina B., we decided to extend Rally
session for the wider
audience and I requested "Rally & Performance team" session.

On Wed, Jan 4, 2017 at 5:29 PM, Joe Talerico <jtale...@redhat.com> wrote:

> When I signed up to attend the PTG, Performance was not listed as a
> option, however on the website it clearly shows Performance is
> Monday-Tuesday.
>
> Is this just a mistake in the event website?
>
> Joe
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Performance] PTG?

[Andrey Kurilin]

Here[*] you can find an etherpad of Performance team. I think Rally team
will re-use it.

[*] - https://etherpad.openstack.org/p/ptg-performance-team

On Sat, Jan 7, 2017 at 9:35 PM, Joe Talerico <jtale...@redhat.com> wrote:

> Hey Andrey - Is there a shared etherpad for the Rally/Performance days?
>
> Thanks,
> Joe
>
> On Wed, Jan 4, 2017 at 11:01 AM, Andrey Kurilin <akuri...@mirantis.com>
> wrote:
> > Hi, Joe!
> >
> > It is not a mistake. After a talk with Dina B., we decided to extend
> Rally
> > session for the wider
> > audience and I requested "Rally & Performance team" session.
> >
> > On Wed, Jan 4, 2017 at 5:29 PM, Joe Talerico <jtale...@redhat.com>
> wrote:
> >>
> >> When I signed up to attend the PTG, Performance was not listed as a
> >> option, however on the website it clearly shows Performance is
> >> Monday-Tuesday.
> >>
> >> Is this just a mistake in the event website?
> >>
> >> Joe
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > --
> > Best regards,
> > Andrey Kurilin.
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

[Andrey Kurilin]

Hi, Flavio!

Does it possible to create badges per project release?

On Mon, Jan 9, 2017 at 3:23 PM, Flavio Percoco <fla...@redhat.com> wrote:

> Just a heads up!
>
> There are still unmerged patches on this effort. If you have a couple of
> spare
> brain cycles, it'd be awesome to get the patches relative to the projects
> you've
> +2 votes on in.
>
> I'll proceed to abandon remaining patches in 2 weeks from now assuming that
> projects are not interested in having them. As I mentioned in previous
> emails,
> you're free to update the patches to match your project needs.
>
> Here's the link to see the remaining patches:
> https://review.openstack.org/#/q/status:open+topic:project-badges
>
> Thanks a lot,
> Flavio
>
>
> On 12/10/16 14:50 +0200, Flavio Percoco wrote:
>
>> Greetings,
>>
>> One of the common complains about the existing project organization in
>> the big
>> tent is that it's difficult to wrap our heads around the many projects
>> there
>> are, their current state (in/out the big tent), their tags, etc.
>>
>> This information is available on the governance website[0]. Each official
>> project team has a page there containing the information related to the
>> deliverables managed by that team. Unfortunately, I don't think this page
>> is
>> checked often enough and I believe it's not known by everyone.
>>
>> In the hope that we can make this information clearer to people browsing
>> the
>> many repos (most likely on github), I'd like to propose that we include
>> the
>> information of each deliverable in the readme file. This information
>> would be
>> rendered along with the rest of the readme (at least on Github, which
>> might not
>> be our main repo but it's the place most humans go to to check our
>> projects).
>>
>> Rather than duplicating this information, I'd like to find a way to just
>> "include it" in the Readme file. As far as showing the "official" badge
>> goes, I
>> believe it'd be quite simple. We can do it the same way CI tags are
>> exposed when
>> using travis (just include an image). As for the rest of the tags, it
>> might
>> require some extra hacking.
>>
>> So, before I start digging more into this, I wanted to get other
>> opinions/ideas
>> on this topic and how we can make this information more evident to the
>> rest of
>> the community (and people not as familiar with our processes as some of
>> us are).
>>
>> Thanks in advance,
>> Flavio
>>
>> [0] http://governance.openstack.org/reference/projects/index.html
>>
>> --
>> @flaper87
>> Flavio Percoco
>>
>
>
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

[Andrey Kurilin]

On Mon, Jan 9, 2017 at 6:37 PM, Flavio Percoco <fla...@redhat.com> wrote:

> On 09/01/17 17:55 +0200, Andrey Kurilin wrote:
>
>> Hi, Flavio!
>>
>> Does it possible to create badges per project release?
>>
>
> mmh, it's currently not possible.
>
> Could you elaborate on why you need a specific tag per release? IS it to
> tag the
> releases that were done after the inclusion in the big tent?
>
>
OpenStack has a bunch of different tags. "the inclusion in the big tent" is
one of tags that should not match to all project releases once project did
it.
Another one is a "single-vendor" and so on. I think most of tags should be
applied per project release.

One more "feature request": creation of custom badges(I'm interested in
"tested on %(operation_system)s".


> Flavio
>
>
> On Mon, Jan 9, 2017 at 3:23 PM, Flavio Percoco <fla...@redhat.com> wrote:
>>
>> Just a heads up!
>>>
>>> There are still unmerged patches on this effort. If you have a couple of
>>> spare
>>> brain cycles, it'd be awesome to get the patches relative to the projects
>>> you've
>>> +2 votes on in.
>>>
>>> I'll proceed to abandon remaining patches in 2 weeks from now assuming
>>> that
>>> projects are not interested in having them. As I mentioned in previous
>>> emails,
>>> you're free to update the patches to match your project needs.
>>>
>>> Here's the link to see the remaining patches:
>>> https://review.openstack.org/#/q/status:open+topic:project-badges
>>>
>>> Thanks a lot,
>>> Flavio
>>>
>>>
>>> On 12/10/16 14:50 +0200, Flavio Percoco wrote:
>>>
>>> Greetings,
>>>>
>>>> One of the common complains about the existing project organization in
>>>> the big
>>>> tent is that it's difficult to wrap our heads around the many projects
>>>> there
>>>> are, their current state (in/out the big tent), their tags, etc.
>>>>
>>>> This information is available on the governance website[0]. Each
>>>> official
>>>> project team has a page there containing the information related to the
>>>> deliverables managed by that team. Unfortunately, I don't think this
>>>> page
>>>> is
>>>> checked often enough and I believe it's not known by everyone.
>>>>
>>>> In the hope that we can make this information clearer to people browsing
>>>> the
>>>> many repos (most likely on github), I'd like to propose that we include
>>>> the
>>>> information of each deliverable in the readme file. This information
>>>> would be
>>>> rendered along with the rest of the readme (at least on Github, which
>>>> might not
>>>> be our main repo but it's the place most humans go to to check our
>>>> projects).
>>>>
>>>> Rather than duplicating this information, I'd like to find a way to just
>>>> "include it" in the Readme file. As far as showing the "official" badge
>>>> goes, I
>>>> believe it'd be quite simple. We can do it the same way CI tags are
>>>> exposed when
>>>> using travis (just include an image). As for the rest of the tags, it
>>>> might
>>>> require some extra hacking.
>>>>
>>>> So, before I start digging more into this, I wanted to get other
>>>> opinions/ideas
>>>> on this topic and how we can make this information more evident to the
>>>> rest of
>>>> the community (and people not as familiar with our processes as some of
>>>> us are).
>>>>
>>>> Thanks in advance,
>>>> Flavio
>>>>
>>>> [0] http://governance.openstack.org/reference/projects/index.html
>>>>
>>>> --
>>>> @flaper87
>>>> Flavio Percoco
>>>>
>>>>
>>>
>>>
>>> --
>>> @flaper87
>>> Flavio Percoco
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>
>> --
>> Best regards,
>> Andrey Kurilin.
>>
>
> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Intermittent gate failures across multiple projects

[Andrey Kurilin]

Hi Steve,

It looks like latest OSC is not the root of issue - the failure appeared
several ours ago(5?!) and
upper-constrains for OSC was updated several days ago(lxml was blocked more
than 5 hours ago).

Possibly, update of openstacksdk(https://review.openstack.org/#/c/414366/ )
causes new issues.

On Fri, Dec 23, 2016 at 4:16 PM, Steve Martinelli <s.martine...@gmail.com>
wrote:

> Those look like they were introduced in the latest release, and related to
> the OpenStackSDK refactoring that hit openstackclient networking commands.
> We actually released the new version because folks were hitting similar
> errors, but for more often used commands (like listing security groups or
> IPs.)
>
> Is the latest OSC affecting a gate for you?
>
>
> On Dec 23, 2016 8:33 AM, "Andrey Kurilin" <akuri...@mirantis.com> wrote:
>
> Hi eveyone!
>
> I found two more failures related to openstackclient which had appeared
> recently:
>
> - "HttpException: Bad Request" while trying to set quotas via
> openstackclient
>   http://logs.openstack.org/43/414543/1/check/gate-rally-dsvm-
> neutron-existing-users-rally/36518f0/console.html#_2016-12-
> 23_11_31_55_070176
> - "'SecurityGroup' object has no attribute 'keys'" while creating new
> security group
>   http://logs.openstack.org/64/355264/5/check/gate-manila-temp
> est-dsvm-mysql-generic-ubuntu-xenial-nv/9ff7aec/logs/devstac
> klog.txt.gz#_2016-12-23_12_53_44_213
>
> State of latest openstackclient doesn't look good to me :(
>
>
> On Fri, Dec 23, 2016 at 5:24 AM, Tony Breeds <t...@bakeyournoodle.com>
> wrote:
>
>> On Thu, Dec 22, 2016 at 04:31:38PM -0800, John Villalovos wrote:
>> > We believe the error is caused by a bad wheel for lxml 3.7.0 that was
>> > pushed today to PyPi
>> >
>> > Thanks to everyone working together on this issue in #openstack-infra !
>> >
>> > A patch is proposed to blacklist that release and we are testing it now.
>>
>> The fix is now merged so if you're jobs failed with 'Illegal Instruction'
>> feel
>> free to recheck without swamping our CI.  I believe that eleastic-recheck
>> should
>> tell you if you match this case.
>>
>> Thanks to those that found the root cause and worked on the fix
>>
>> Yours Tony.
>>
>> ____
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best regards,
> Andrey Kurilin.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Intermittent gate failures across multiple projects

[Andrey Kurilin]

Hi eveyone!

I found two more failures related to openstackclient which had appeared
recently:

- "HttpException: Bad Request" while trying to set quotas via
openstackclient

http://logs.openstack.org/43/414543/1/check/gate-rally-dsvm-neutron-existing-users-rally/36518f0/console.html#_2016-12-23_11_31_55_070176
- "'SecurityGroup' object has no attribute 'keys'" while creating new
security group

http://logs.openstack.org/64/355264/5/check/gate-manila-tempest-dsvm-mysql-generic-ubuntu-xenial-nv/9ff7aec/logs/devstacklog.txt.gz#_2016-12-23_12_53_44_213

State of latest openstackclient doesn't look good to me :(


On Fri, Dec 23, 2016 at 5:24 AM, Tony Breeds <t...@bakeyournoodle.com>
wrote:

> On Thu, Dec 22, 2016 at 04:31:38PM -0800, John Villalovos wrote:
> > We believe the error is caused by a bad wheel for lxml 3.7.0 that was
> > pushed today to PyPi
> >
> > Thanks to everyone working together on this issue in #openstack-infra !
> >
> > A patch is proposed to blacklist that release and we are testing it now.
>
> The fix is now merged so if you're jobs failed with 'Illegal Instruction'
> feel
> free to recheck without swamping our CI.  I believe that eleastic-recheck
> should
> tell you if you match this case.
>
> Thanks to those that found the root cause and worked on the fix
>
> Yours Tony.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Storyboard Lives!

[Andrey Kurilin]

Hi!

It looks really promising. I like the idea of abandoning launchpad (it is
inconvenient at all) and I like "boards" for tasks.
But I have one feature request, before I can think seriously about
switching to it from my trello board - ability to change colors of UI.
Generally I like red and black colors, but it’s just too harsh and my eyes get
tired quickly while browsing pages at StoryBoard.

On Wed, Dec 21, 2016 at 11:59 PM, Kendall Nelson <kennelso...@gmail.com>
wrote:

> Hello All,
>
>As you may or may not have heard, we are still working on moving
> towards Storyboard as our task tracker. In an effort to spread awareness
> about Storyboard and its capabilities, we’ve decided to write some blog
> posts about how it works and how it will be different from Launchpad. The
> first post is a general overview of the decision to move to Storyboard from
> Launchpad [1]. Please take a few minutes to look it over!
>
> We will have more blog posts coming after the new year begins (with
> everyone taking things easy over the holidays and all there will be a bit
> of a gap). The next post’s focus will be a more in depth compare and
> contrast of Launchpad and Storyboard. After that, we have a few others
> planned, but if there are things you would be interested in hearing about
> in more detail that might be good for a blog post, let us know! Also, feel
> free to drop in the #storyboard channel if you have questions or attend our
> weekly meetings [2].
>
> If you are interested in playing around in the Storyboard sandbox [3],
> read some of the documentation [4], or just go check it out [5] please do
> so as well :)
>
> Thanks!
>
> Kendall Nelson (diablo_rojo) & the Storyboard team :)
>
> [1] https://storyboard-blog.sotk.co.uk/why-storyboard-for-openstack.html
>
> [2] https://wiki.openstack.org/wiki/StoryBoard
>
> [3] https://storyboard-dev.openstack.org/
>
> [4] http://docs.openstack.org/infra/storyboard/
>
> [5] https://storyboard.openstack.org/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Intermittent gate failures across multiple projects

[Andrey Kurilin]

Proposed revert: https://review.openstack.org/414621

On Fri, Dec 23, 2016 at 4:56 PM, Valeriy Ponomaryov <
vponomar...@mirantis.com> wrote:

> Bug report for problem Andrey and Goutham mentioned is here:
> https://bugs.launchpad.net/python-openstackclient/+bug/1652317
>
> Valeriy
>
> On Fri, Dec 23, 2016 at 4:30 PM, Ravi, Goutham <
> goutham.pachar...@netapp.com> wrote:
>
>> Yes. It’s affecting manila tests as well:
>>
>>
>>
>> Patch: https://review.openstack.org/#/c/414286/
>>
>> Failure: http://logs.openstack.org/86/414286/2/gate/gate-manila-tempe
>> st-minimal-dsvm-lvm-ubuntu-xenial/a79dc50/logs/devstacklo
>> g.txt.gz#_2016-12-23_13_26_11_470
>>
>>
>>
>> Version of OSC: http://logs.openstack.org/86/4
>> 14286/2/gate/gate-manila-tempest-minimal-dsvm-lvm-ubuntu-
>> xenial/a79dc50/logs/devstacklog.txt.gz#_2016-12-23_13_19_04_456 (1.2.0)
>>
>> Version of OpenStackSDK: http://logs.openstack.org/86/4
>> 14286/2/gate/gate-manila-tempest-minimal-dsvm-lvm-ubuntu-
>> xenial/a79dc50/logs/devstacklog.txt.gz#_2016-12-23_13_19_53_450 (0.9.11)
>>
>>
>>
>>
>>
>> *From: *Steve Martinelli <s.martine...@gmail.com>
>> *Reply-To: *"OpenStack Development Mailing List (not for usage
>> questions)" <openstack-dev@lists.openstack.org>
>> *Date: *Friday, December 23, 2016 at 9:16 AM
>> *To: *"OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> *Subject: *Re: [openstack-dev] [all] Intermittent gate failures across
>> multiple projects
>>
>>
>>
>> Those look like they were introduced in the latest release, and related
>> to the OpenStackSDK refactoring that hit openstackclient networking
>> commands. We actually released the new version because folks were hitting
>> similar errors, but for more often used commands (like listing security
>> groups or IPs.)
>>
>>
>>
>> Is the latest OSC affecting a gate for you?
>>
>>
>>
>>
>>
>> On Dec 23, 2016 8:33 AM, "Andrey Kurilin" <akuri...@mirantis.com> wrote:
>>
>> Hi eveyone!
>>
>> I found two more failures related to openstackclient which had appeared
>> recently:
>>
>> - "HttpException: Bad Request" while trying to set quotas via
>> openstackclient
>>   http://logs.openstack.org/43/414543/1/check/gate-rally-dsvm-
>> neutron-existing-users-rally/36518f0/console.html#_2016-12-
>> 23_11_31_55_070176
>> - "'SecurityGroup' object has no attribute 'keys'" while creating new
>> security group
>>   http://logs.openstack.org/64/355264/5/check/gate-manila-temp
>> est-dsvm-mysql-generic-ubuntu-xenial-nv/9ff7aec/logs/devstac
>> klog.txt.gz#_2016-12-23_12_53_44_213
>>
>> State of latest openstackclient doesn't look good to me :(
>>
>>
>>
>>
>>
>> On Fri, Dec 23, 2016 at 5:24 AM, Tony Breeds <t...@bakeyournoodle.com>
>> wrote:
>>
>> On Thu, Dec 22, 2016 at 04:31:38PM -0800, John Villalovos wrote:
>> > We believe the error is caused by a bad wheel for lxml 3.7.0 that was
>> > pushed today to PyPi
>> >
>> > Thanks to everyone working together on this issue in #openstack-infra !
>> >
>> > A patch is proposed to blacklist that release and we are testing it now.
>>
>> The fix is now merged so if you're jobs failed with 'Illegal Instruction'
>> feel
>> free to recheck without swamping our CI.  I believe that eleastic-recheck
>> should
>> tell you if you match this case.
>>
>> Thanks to those that found the root cause and worked on the fix
>>
>> Yours Tony.
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> --
>>
>> Best regards,
>> Andrey Kurilin.
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> 
>> __
>> OpenSta

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

[Andrey Kurilin]

true. Regularly, README.rst includes "how-to contribute" stuff, but
"ideal" README should describe a lot of things about projects and it can
become huge enough, so new contributors can miss "how-to contribute"
section
there (README often doesn't have content list at the top of file).

+1 on those files.
>
> > If you look at the gerrit query, some projects have already merged or
> > abandoned some of the patches. Let's see if we can come to an
> > agreement about how to improve the experience for people finding our
> > projects and wanting to collaborate with us.
> >
> > [1]: https://review.openstack.org/#/q/owner:zhouyunfeng%40inspur.
> com+topic:addCONTRIBUTING.rst
> > --
> > Ian Cordasco
> >
> > ________
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

[Andrey Kurilin]

On Wed, Dec 21, 2016 at 5:46 PM, Andreas Jaeger <a...@suse.com> wrote:

> On 2016-12-21 16:22, Ian Cordasco wrote:
> > [...]
> > That said, I think there are two better places for this information
> > that are already standards in OpenStack:
> >
> > * README.rst
> > * HACKING.rst
> >
> > Most projects include links to the contributing documentation in at
> > least one of these files. I think the effort here is to standardize,
> > albeit in a brand new file, and that's admirable.
>
> If that's the goal - to standardize - then I would expect that we move
> all the documentation out of those files in one place.
>
> Right now, the changes duplicate information that exists - and the new
> information is often wrong. It points to place that do not exist or
> where better places exist. ;(
>

Duplication can be reduced by using `.. include:: ` directive.

>
>
> I'm fine with the status quo - of using the two files that you mention.
> Having contribution information is important,
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][ptls][tc] help needed filling out project-navigator data

[Andrey Kurilin]

Hi folks!

Does it possible to store history of the project without alignment to
OpenStack releases?

2017-04-19 17:54 GMT+03:00 Jimmy McArthur <ji...@openstack.org>:

> Ideally, as far back as your project goes. That way we will have a
> complete API history, per release, on the project navigator.  This also
> helps us determine the project age.
>
> Thanks!
> Jimmy
>
> Telles Nobrega <tenob...@redhat.com>
> April 19, 2017 at 9:48 AM
> Hi Monty,
>
> quick question, how far into past releases should we go?
>
> Thanks,
>
> --
>
> TELLES NOBREGA
>
> SOFTWARE ENGINEER
>
> Red Hat I <https://www.redhat.com/>
>
> tenob...@redhat.com
> <https://red.ht/sig>
> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> Monty Taylor <mord...@inaugust.com>
> April 18, 2017 at 3:03 PM
> Hey everybody!
>
> The Foundation is rolling out a new version of the Project Navigator. One
> of the things it contains is a section that shows API versions available
> for each project for each release. They asked the TC's help in providing
> that data, so we spun up a new repository:
>
>   http://git.openstack.org/cgit/openstack/project-navigator-data
>
> that the Project Navigator will consume.
>
> We need your help!
>
> The repo contains a file for each project for each release with
> CURRENT/SUPPORTED/DEPRECATED major versions and also microversion ranges if
> they exist. The data is pretty much exactly what everyone already produces
> in their version discovery documents - although it's normalized into the
> format described by the API-WG:
>
>
> https://specs.openstack.org/openstack/api-wg/guidelines/
> microversion_specification.html#version-discovery
>
> What would be really helpful is if someone from each project could go make
> a patch to the repo adding the historical (and currently) info for your
> project. We'll come up with a process for maintaining it over time - but
> for now just crowdsourcing the data seems like the best way.
>
> The README file explains the format, and there is data from a few of the
> projects for Newton.
>
> It would be great to include an entry for every release - which for many
> projects will just be the same content copied a bunch of times back to the
> first release the project was part of OpenStack.
>
> This is only needed for service projects (something that registers in the
> keystone catalog) and is only needed for 'main' APIs (like, it is not
> needed, for now, to put in things like Placement)
>
> If y'all could help - it would be super great!
>
> Thanks!
> Monty
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ______
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev