Modified items

All recently modified items, latest first.

gerrit-2.12.1-1.lbn19.noarch: Gerrit is a web based code review system, facilitating online code reviews for projects using the Git version control system. Gerrit makes reviews easier by showing changes in a side-by-side display, and allowing inline comments to be added by any reviewer. Gerrit simplifies Git based project maintainership by permitting any authorized user to submit changes to the master Git repository, rather than requiring all approved changes to be merged in by hand by the project maintainer. This functionality enables a more centralized usage of Git.

python-requestbuilder-0.3.0_pre2-1.lbn19.noarch: Command line-driven HTTP request builder

python-refstack-client-0.1.0.dev89-1.lbn19.noarch: refstack-client is a command line utility that allows you to execute Tempest test runs based on configurations you specify. When finished running Tempest it can send the passed test data to a RefStack API server. Environment setup We've created an "easy button" for Ubuntu, Centos, RHEL and openSuSe. Make sure you have git installed Get the refstack client: git clone https://github.com/openstack/refstack-client Go into the refstack-client directory: cd refstack-client Run the "easy button" setup: ./setup_env Options: a. -c option allows to specify SHA of commit or branch in Tempest repository which will be installed. b. -t option allows to specify tag in Tempest repository which will be installed. For example: execute ./setup_env -t tags/3 to install Tempest tag-3. c. By default, Tempest will be installed from commit 551e1a9701e7e2b3edf6d49a2eaa62b7ab2435ad (11 September 2015). Usage Prepare a tempest configuration file that is customized to your cloud environment. Go into the refstack-client directory. cd ~/refstack-client Source to use the correct Python environment. source .venv/bin/activate Validate your setup by running a short test. ./refstack-client test -c <Path of the tempest configuration file to use> -v -- tempest.api.identity.admin.v2.test_roles or ./refstack-client test -c <Path of the tempest configuration file to use> -v -- tempest.api.identity.v2.test_token Run tests. To run the entire API test set: ./refstack-client test -c <Path of the tempest configuration file to use> -v To run only those tests specified in a DefCore defined test file: ./refstack-client test -c <Path of the tempest configuration file to use> -v --test-list <Path or URL of test list> For example: ./refstack-client test -c ~/tempest.conf -v --test-list https://raw.githubusercontent.com/openstack/defcore/master/2015.05/2015.05.required.txt This will run only the test cases listed in 2015.05.required.txt. Note: Adding the -v option will show the Tempest test result output. Adding the --upload option will have your test results be uploaded to the default RefStack API server or the server specified by --url. Adding the --test-list option will allow you to specify the file path or URL of a test list text file. This test list should contain specific test cases that should be tested. Tests lists passed in using this argument will be normalized with the current Tempest evironment to eliminate any attribute mismatches. Adding the --url option will allow you to change where test results should be uploaded. Adding the -r option with a string will prefix the JSON result file with the given string (e.g. '-r my-test' will yield a result file like 'my-test-0.json'). Adding -- enables you to pass arbitary arguments to the Tempest runner. After the first --, all other subsequent arguments will be passed to the Tempest runner as is. This is mainly used for quick verification of the target test cases. (e.g. -- tempest.api.identity.v2.test_token) Use ./refstack-client test --help for the full list of arguments. Upload your results. If you previously ran a test with refstack-client without the --upload option, you can upload your results to a RefStack API server by using the following command: ./refstack-client upload <Path of results file> The results file is a JSON file generated by refstack-client when a test has completed. This is saved in .tempest/.testrepository. When you use the upload command, you can also override the RefStack API server uploaded to with the --url option. Alternatively, you can use the 'upload-subunit' command to upload results using an existing subunit file. This requires that you pass in the Keystone endpoint URL for the cloud that was tested to generate the subunit data: ./refstack-client upload-subunit --keystone-endpoint http://some.url:5000/v3 <Path of subunit file> Note: Adding -i <path-to-private-key> option will upload test results with a digital signature. For signing, refstack-client uses private RSA keys. The OpenSSH format of RSA keys is supported, so you can just use your SSH key '~/.ssh/id-rsa' or generate a new one with ssh-keygen -b 4096. For now, signed test results can be considered private. List uploaded test set. You can list previously uploaded data from a RefStack API server by using the following command: ./refstack-client list --url <URL of the RefStack API server> Tempest Hacking By default, refstack-client installs Tempest into the .tempest directory. If you're interested in working with Tempest directly for debugging or configuration, you can activate a working Tempest environment by switching to that directory and using the installed dependencies. cd .tempest run tempest with ./run_tempest.sh -V ` or `source ./.venv/bin/activate and run tests manually with testr. This will make the entire Tempest environment available for you to run, including the run_tempest script and testr.

python-quantumclient-2.2.1-3.fc19.noarch: Client library and command line utility for interacting with Openstack Quantum's API.

python-qpid-common-0.24-1.fc19.noarch: Shared code for Qpid Python language bindings.

python-qpid-0.24-1.fc19.noarch: The Apache Qpid Python client library for AMQP.

python-pysaml2-3.0.2-2.lbn19.noarch: PySAML2 implementation of SAML Version 2 to be used in a WSGI environment.

python-pyrsistent-0.11.13-1.lbn19.x86_64: Pyrsistent is a number of persistent collections (by some referred to as functional data structures). Persistent in the sense that they are immutable. All methods on a data structure that would normally mutate it instead return a new copy of the structure containing the requested updates. The original structure is left untouched. This will simplify the reasoning about what a program does since no hidden side effects ever can take place to these data structures. You can rest assured that the object you hold a reference to will remain the same throughout its lifetime and need not worry that somewhere five stack levels below you in the darkest corner of your application someone has decided to remove that element that you expected to be there. Pyrsistent is influenced by persistent data structures such as those found in the standard library of Clojure. The data structures are designed to share common elements through path copying. It aims at taking these concepts and make them as pythonic as possible so that they can be easily integrated into any python program without hassle. If you want to go all in on persistent data structures and use literal syntax to define them in your code rather than function calls check out Pyrthon. Examples The collection types and key features currently implemented are: PVector, similar to a python list PMap, similar to dict PSet, similar to set PRecord, a PMap on steroids with fixed fields, optional type and invariant checking and much more PClass, a Python class fixed fields, optional type and invariant checking and much more Checked collections, PVector, PMap and PSet with optional type and invariance checks and more PBag, similar to collections.Counter PList, a classic singly linked list PDeque, similar to collections.deque Immutable object type (immutable) built on the named tuple freeze and thaw functions to convert between pythons standard collections and pyrsistent collections. Flexible transformations of arbitrarily complex structures built from PMaps and PVectors.

python-pymongo-gridfs-2.5.2-1.fc19.x86_64: GridFS is a storage specification for large objects in MongoDB.

python-pymongo-2.5.2-1.fc19.x86_64: The Python driver for MongoDB.

python-pymongo-2.5.2-1.fc19.armv6hl: The Python driver for MongoDB.

python-pymongo-2.5.2-1.fc19.x86_64: The Python driver for MongoDB.

python-pymongo-2.5.2-1.fc19.armv6hl: The Python driver for MongoDB.

python-pyghmi-0.5.9-2.lbn19.noarch: This is a pure python implementation of the IPMI protocol.

python-pyeclib-1.2.0-2.lbn19.x86_64: This library provides a simple Python interface for implementing erasure codes. A number of back-end implementations is supported either directly or through the C interface liberasurecode.

python-pycadf-1.1.0-2.lbn19.noarch: DMTF Cloud Audit (CADF) data model

python-pyasn1-modules-0.1.7-1.fc19.noarch: ASN.1 types modules for python-pyasn1.

python-pyasn1-0.1.7-1.fc19.noarch: This is an implementation of ASN.1 types and codecs in the Python programming language.

python-py-1.4.18-1.lbn19.noarch: The py lib is a Python development support library featuring the following tools and modules: * py.path: uniform local and svn path objects * py.apipkg: explicit API control and lazy-importing * py.iniconfig: easy parsing of .ini files * py.code: dynamic code generation and introspection * py.path: uniform local and svn path objects

python-pulp-win-common-2.4.0-8.lbn19.noarch: A collection of modules shared among all Win components.

« Previous 20 items Next 20 items » 1 ... 1722 1723 1724 1725 1726 1727 1728 ... 2425


	Copyright © 2000-2025 Corporation of Balclutha Inc. All rights reserved.

Sections

Modified items