Re: [openstack-dev] [Glance] IRC logging

On 09/01/15 12:11 -0800, Joshua Harlow wrote: So the only comment I'll put in is one that I know not everyone agrees with but might as well throw it out there. http://freenode.net/channel_guidelines.shtml (this page has a bunch of useful advice IMHO). From that; something useful to look/thin

Re: [openstack-dev] Vancouver Design Summit format changes

On 09/01/15 15:50 +0100, Thierry Carrez wrote: [huge snip] What do you think ? Could that work ? If not, do you have alternate suggestions ? Love it! Thanks for the thoughtful and detailed email. Flavio -- @flaper87 Flavio Percoco pgp2LB9GMnSpn.pgp Description: PGP signature __

Re: [openstack-dev] 答复: [devstack] Opensatck installation issue.

Hi all, I am still getting the same error while installing the Openstack through devstack, If someone know the solution please reply. On Fri, Jan 9, 2015 at 1:53 PM, Abhishek Shrivastava wrote: > Hi Liuxinguo, > > Thanks for the suggestion, I'll try and make it work. > > On Fri, Jan 9, 2015 at

Re: [openstack-dev] 答复: Re: [neutron][AdvancedServices] Confusion about the solution of the service chaining!

Hi Alan, We are now in the process of doing It :) Thanks Vikram From: [email protected] [mailto:[email protected]] Sent: 12 January 2015 12:57 To: Vikram Choudhary Cc: Dongfeng (C); Dhruv Dhody; Kalyankumar Asangi; OpenStack Development Mailing List (not for usage questions); sumitnaiksa.

Re: [openstack-dev] [Fuel] update existing plugin and add new ones

There was a discussion on whether to put all the fuel plugins into the single repository or have them separate. The problems with all the fuel plugins in single repository are following: - it is impossible to make a branch on a single plugin, branch is applied to the whole repository and all the p

Re: [openstack-dev] [nova] serial-console *replaces* console-log file?

> On Fri, Jan 09, 2015 at 09:15:39AM +0800, Lingxian Kong wrote: > >There is an excellent post describing this, for your information: > http://blog.oddbit.com/2014/12/22/accessing-the-serial-console-of-your-nova-servers/ In the last section of that article he describes my issue as well: "It w

Re: [openstack-dev] openstack-dev topics now work correctly

On 01/09/2015 08:12 PM, Stefano Maffulli wrote: Dear all, if you've tried the topics on this mailing list and haven't received emails, well... we had a problem on our side: the topics were not setup correctly. Luigi Toscano helped isolate the problem and point at the solution[1]. He noticed tha

Re: [openstack-dev] [TripleO] Switching CI back to amd64

On 01/08/2015 10:22 AM, Derek Higgins wrote: On 07/01/15 23:41, Ben Nemec wrote: I don't feel like we've been all that capacity constrained lately anyway, so as I said in my other (largely unnecessary, as it turns out) email, I'm +1 on doing this. Correct we're not currently constrained on capa

Re: [openstack-dev] Vancouver Design Summit format changes

Tim Bell wrote: > > Let's ask the operators opinions too on openstack-operators mailing list. Sure, that's my next step. I first wanted to check that this change was fine for historic Design Summit participants. I'll follow up with operators and also discuss it at the Ops meetup. FWIW, the propo

Re: [openstack-dev] [nova][neutron]VIF_VHOSTUSER

Hi Ian, Spec for “Support vhost-user in libvirt vif driver” [1] has been approved for Kilo. We should have code available by EOW. We are also working on a mechanism driver for Neutron as well [2]. We started working on a 3rd party CI. Regards Przemek [1] https://review.openstack.org/#/c/138

Re: [openstack-dev] [Telco] [NFV] Service function chaining

Hi Yuriy, FYI there is a project proposal on opnfv wiki on this issue: https://wiki.opnfv.org/requirements_projects/openstack_based_vnf_forwarding_graph On Wed, Jan 7, 2015 at 12:22 AM, wrote: > Hi all, > > as discussed per last IRC meeting we prepared first thoughts on the > requirements on Se

Re: [openstack-dev] 答复: [devstack] Opensatck installation issue.

Since it seems a permission error, this may help: http://docs.openstack.org/developer/devstack/guides/single-machine.html#installation-shake-and-bake NB: in my environment I had to edit the file sudoers with a text editor (echoing the string didn't work). On 01/12/15 09:33, Abhishek Shrivastava

Re: [openstack-dev] 答复: [devstack] Opensatck installation issue.

I tried that also but still the error is same. On Mon, Jan 12, 2015 at 3:32 PM, Pasquale Porreca < [email protected]> wrote: > Since it seems a permission error, this may help: > http://docs.openstack.org/developer/devstack/guides/single-machine.html#installation-shake-and-bake > >

Re: [openstack-dev] 答复: [devstack] Opensatck installation issue.

Is this related to the version of Ubuntu being used ? Its 12.04 as per the email. Regards, Amit *CloudByte Inc.* On Mon, Jan 12, 2015 at 3:55 PM, Abhishek Shrivastava < [email protected]> wrote: > I tried that also but still the error is same. > > On Mon, Jan 12

Re: [openstack-dev] 答复: [devstack] Opensatck installation issue.

Its showing the same error on Ubuntu 13.10, so I think its not a Ubuntu Version issue. On Mon, Jan 12, 2015 at 4:02 PM, Amit Das wrote: > Is this related to the version of Ubuntu being used ? > > Its 12.04 as per the email. > > Regards, > Amit > *CloudByte Inc.* > > O

Re: [openstack-dev] [devstack]Openstack installation issue.

Hey abhishek, As a quick fix to this problem, edit this file devstack/lib/keystone +170 in this function function configure_keystone { edit this line with adding sudo sudo cp -p $KEYSTONE_DIR/etc/keystone.conf.sample $KEYSTONE_CONF Regards Samta On Mon, Jan 12, 2015 at 4:01 PM, Abhishek Shriv

Re: [openstack-dev] [Cinder] Cutoff deadlines for cinder drivers

Hi guys, Thanks for answering my questions. I have 2 points: 1 - This (remove drivers without CI) is a way impacting change to be implemented without exhausting notification and discussion on the mailing list. I myself was in the meeting but this decision wasn't crystal clear. There must be other

Re: [openstack-dev] [devstack]Openstack installation issue.

Hi Samta, Thanks for the suggestion but still problem remains the same. On Mon, Jan 12, 2015 at 4:29 PM, Samta Rangare wrote: > Hey abhishek, > > As a quick fix to this problem, edit this file devstack/lib/keystone +170 > in this function > function configure_keystone { > edit this line with ad

[openstack-dev] Future-based api for openstack clients calls, that starts background tasks

Hi all. There a set of openstack api functions which starts background actions and return preliminary results - like 'novaclient.create'. Those functions requires periodically check results and handle timeouts/errors (and often cleanup + restart help to fix an error). Check/retry/cleanup code dup

Re: [openstack-dev] [devstack]Openstack installation issue.

Whats the log now? On Mon, Jan 12, 2015 at 4:53 PM, Abhishek Shrivastava < [email protected]> wrote: > Hi Samta, > > Thanks for the suggestion but still problem remains the same. > > On Mon, Jan 12, 2015 at 4:29 PM, Samta Rangare > wrote: > >> Hey abhishek, >> >> As a quick fix to this prob

Re: [openstack-dev] Future-based api for openstack clients calls, that starts background tasks

Konstantin, I believe it's better to work on server side, and use some modern approach like web sockets for async operations. So we won't need to retrieve 100500 times information about object. And then use this feature in clients. create_future = novaclient.servers.create_async() > ...

Re: [openstack-dev] [Fuel][client][IMPORTANT] Making Fuel Client a separate project

Hi folks! This is a status update. Right now the patch for creating a new project on Stackforge is blocked by a bug in Zuul [1] which is actually a bug in python-daemon, the patch for this is already published [2] and waiting for being approved. After the patch is merged and all projects and gro

Re: [openstack-dev] [devstack]Openstack installation issue.

Same as before. On Mon, Jan 12, 2015 at 5:04 PM, Samta Rangare wrote: > Whats the log now? > > On Mon, Jan 12, 2015 at 4:53 PM, Abhishek Shrivastava < > [email protected]> wrote: > >> Hi Samta, >> >> Thanks for the suggestion but still problem remains the same. >> >> On Mon, Jan 12, 2015 at

Re: [openstack-dev] [Policy][Group-based-policy] ODL Policy Driver Specs

Hi, Can anyone explain the difference between gbp group-create and gbp policy-target-group-create?? I think both these are working same. Thanks & Regards Sachi Gupta From: Sumit Naiksatam To: "OpenStack Development Mailing List (not for usage questions)" Date: 11/26/2014 01:35 PM

Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI

Hi, Back with another error during image creation with nodepool: 2015-01-12 13:05:17,775 INFO nodepool.image.build.local_01.d-p-c: Downloading python-daemon-2.0.1.tar.gz (62kB) 2015-01-12 13:05:18,022 INFO nodepool.image.build.local_01.d-p-c: Traceback (most recent call last): 2015-01-12 13:05:18,0

Re: [openstack-dev] Future-based api for openstack clients calls, that starts background tasks

Boris, Move from sync http to something like websocket requires a lot of work and not directly connected with API issue. When openstack api servers begin to support websockets - it would be easy to change implementation of monitoring thread without breaking compatibility. At the moment periodical

Re: [openstack-dev] [oslo] dropping namespace packages

You rock, man. Thanks, I'll steal those. :) /Ihar On 01/11/2015 09:39 PM, Davanum Srinivas wrote: Jay, I have a hacking rule in nova already [1] and am updating the rule in the 3 reviews i have for oslo_utils, oslo_middleware and oslo_config [2] in Nova thanks, dims [1] https://github.com/ope

Re: [openstack-dev] [devstack]Openstack installation issue.

Is your root filesystem full? The log clearly shows the chown stack /etc/keystone passing right before the copy is attempted. -Sean On 01/12/2015 06:59 AM, Abhishek Shrivastava wrote: > Same as before. > > On Mon, Jan 12, 2015 at 5:04 PM, Samta Rangare > w

Re: [openstack-dev] [Fuel] Image based provisioning

Hello, Andrew, thank you for pointing out all the issues. I left more detailed comments inlined On Tue, Jan 6, 2015 at 3:51 AM, Andrew Woodward wrote: > Here is a list of the issues I ran into using IBP before the 23rd. 5 > appears to not be merged yet and must be resolved prior to making IBP >

[openstack-dev] [mistral] Cancelling today's team meeting

Hi, We decided to cancel today’s team meeting because some key members of the team won’t be present. The next on will be held on Jan 19. Renat Akhmerov @ Mirantis Inc. __ OpenStack Development Mailing List (not for usag

Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI

Hi, Regarding the last issue, i fixed it by logging in and manually "pip install docutils". Image was created successfully. Now the problem is that nodepool is not able to login into instances created from that image. I have NODEPOOL_SSH_KEY exported in the screen where nodepool is running, and al

Re: [openstack-dev] Future-based api for openstack clients calls, that starts background tasks

On Mon, Jan 12, 2015 at 10:17 PM, Konstantin Danilov wrote: > Boris, > > Move from sync http to something like websocket requires a lot of work and > not directly connected > with API issue. When openstack api servers begin to support > websockets - it would be easy to change implementation of mo

[openstack-dev] [nova] Requesting exception for resource-object-models blueprint spec

https://review.openstack.org/#/c/127609/ This is a fundamental building block for the #3 priority (Scheduler) work in Kilo. It's been through 11 revisions so far and has support from at least one nova-driver and 4 non-drivers. This work is a building block for the scheduler because it changes

Re: [openstack-dev] [nova][NFV][qa][Telco] Testing NUMA, CPU pinning and large pages

Hi Vladik, I added the [Telco] tag. see below.. Am 12.01.2015 um 03:02 schrieb Vladik Romanovsky : > Hi everyone, > > Following Steve Gordon's email [1], regarding CI for NUMA, SR-IOV, and other > features, I'd like to start a discussion about the NUMA testing in particular. > > Recently we

[openstack-dev] [Fuel] [Puppet] Manifests for granular deploy steps and testing results against the host OS

Hello. We are working on the modularization of Openstack deployment by puppet manifests in Fuel library [0]. Each deploy step should be post-verified with some testing framework as well. I believe the framework should: * be shipped as a part of Fuel library for puppet manifests instead of orches

[openstack-dev] [nova] Request Spec Freeze Exception (DRBD for Nova)

Hello all, in Paris (and later on, on IRC and the mailing list) I began to ask around about providing a DRBD storage driver for Nova. This is an alternative to using iSCSI for block storage access, and would be especially helpful for backends already using DRBD for replicated storage. The spe

Re: [openstack-dev] [nova][NFV][qa][Telco] Testing NUMA, CPU pinning and large pages

On Mon, Jan 12, 2015 at 02:47:19PM +0100, Marc Koderer wrote: > Hi Vladik, > > I added the [Telco] tag. > see below.. > > Am 12.01.2015 um 03:02 schrieb Vladik Romanovsky > : > > > Hi everyone, > > > > Following Steve Gordon's email [1], regarding CI for NUMA, SR-IOV, and other > > features,

Re: [openstack-dev] [Fuel] [Puppet] Manifests for granular deploy steps and testing results against the host OS

Hi, Puppet OpenStack community uses Beaker for acceptance testing. I would consider it as option [2] [2] https://github.com/puppetlabs/beaker -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Mon, Jan 12, 2015 at 2:53 PM, Bogdan Dobrelya wrote: > Hello. > > We are working on

Re: [openstack-dev] Vancouver Design Summit format changes

On Fri, Jan 9, 2015 at 8:50 AM, Thierry Carrez wrote: > Hi everyone, > > The OpenStack Foundation staff is considering a number of changes to the > Design Summit format for Vancouver, changes on which we'd very much like > to hear your feedback. > > The problems we are trying to solve are the fol

[openstack-dev] [neutron] Meeting tomorrow: Going over Critical and High priority Kilo-2 specs

Folks: During tomorrow's Neutron meeting, I'd like to spend a little time going over the approved specs marked as Critical and High priority [1]. We're about 3 weeks out from Kilo-2, so I'd like to get a feel for how these are coming along. If you are assigned one of these specs and can't make the

Re: [openstack-dev] Future-based api for openstack clients calls, that starts background tasks

On Mon, Jan 12, 2015 at 3:33 PM, Angus Salkeld wrote: > > On Mon, Jan 12, 2015 at 10:17 PM, Konstantin Danilov < > [email protected]> wrote: > >> Boris, >> >> Move from sync http to something like websocket requires a lot of work >> and not directly connected >> with API issue. When openstack

Re: [openstack-dev] [Fuel][plugins] Fuel 6.0 plugin for Pacemaker STONITH (HA fencing)

> > -- > > Message: 16 > Date: Wed, 31 Dec 2014 17:41:10 -0800 > From: Andrew Woodward > To: "OpenStack Development Mailing List (not for usage questions)" > > Subject: Re: [openstack-dev] [Fuel][plugins] Fuel 6.0 plugin for > Pacemaker STONITH (HA fencin

[openstack-dev] [Fuel] Dropping Python-2.6 support

Folks, as it was planned and then announced at the OpenStack summit OpenStack services deprecated Python-2.6 support. At the moment several services and libraries are already only compatible with Python>=2.7. And there is no common sense in trying to get back compatibility with Py2.6 because Op

Re: [openstack-dev] [Glance] IRC logging

+1 to Flavio's proposal. Thanks, -Nikhil From: Flavio Percoco [[email protected]] Sent: Monday, January 12, 2015 3:16 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] IRC logging On 09/01/15 12:11 -

Re: [openstack-dev] [Nova]Why nova mounts FS for LXC container instead of libvirt?

On 01/05/2015 02:30 PM, Daniel P. Berrange wrote: On Tue, Dec 30, 2014 at 05:18:19PM +0300, Dmitry Guryanov wrote: Hello, Libvirt can create loop or nbd device for LXC container and mount it by itself, for instance, you can add something like this to xml config: But nova mounts

[openstack-dev] [Heat] Where to keep data about stack breakpoints?

Hey folks, I did a quick proof of concept for a part of the Stack Breakpoint spec[1] and I put the "does this resource have a breakpoint" flag into the metadata of the resource: https://review.openstack.org/#/c/146123/ I'm not sure where this info really belongs, though. It does sound like

Re: [openstack-dev] [Policy][Group-based-policy] ODL Policy Driver Specs

Hello, Sachi, They both works. "End point group" has been renamed to "policy target group". It is recommended to use "gbp policy-target-group-create". Yapeng From: Sachi Gupta [mailto:[email protected]] Sent: Monday, January 12, 2015 7:03 AM To: OpenStack Development Mailing List (not for us

Re: [openstack-dev] [Nova]Why nova mounts FS for LXC container instead of libvirt?

On Mon, Jan 12, 2015 at 06:28:53PM +0300, Dmitry Guryanov wrote: > On 01/05/2015 02:30 PM, Daniel P. Berrange wrote: > >On Tue, Dec 30, 2014 at 05:18:19PM +0300, Dmitry Guryanov wrote: > >>Hello, > >> > >>Libvirt can create loop or nbd device for LXC container and mount it by > >>itself, for instan

Re: [openstack-dev] [Heat] Where to keep data about stack breakpoints?

On 01/12/2015 10:29 AM, Tomas Sedovic wrote: > Hey folks, > > I did a quick proof of concept for a part of the Stack Breakpoint > spec[1] and I put the "does this resource have a breakpoint" flag into > the metadata of the resource: > > https://review.openstack.org/#/c/146123/ > > I'm not sure w

Re: [openstack-dev] [Fuel] Image based provisioning

On Tue, Dec 16, 2014 at 11:09 PM, Andrey Danin wrote: > Adding Mellanox team explicitly. > > Gil, Nurit, Aviram, can you confirm that you tested that feature? It can be > enabled on every fresh ISO. You just need to enable the Experimental mode > (please, see the documentation for instructions).

Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI

You are correct to run nodepoold as nodepool user. I didn’t see any issues… Could you double check the public keys listed in .ssh/authorized_keys in the template for Ubuntu and Jenkins users match $NODEPOOL_SSH_KEY? Ramy From: Eduard Matei [mailto:[email protected]] Sent: Monday, Jan

Re: [openstack-dev] [Fuel] Dropping Python-2.6 support

Hi, Roman, Indeed, we have to go forward and drop python 2.6 support. That's how it supposed to be, but, unfortunately, it may not be as easy as it seems at first glance. Fuel Master is flying on top of Cent OS 6.5 which doesn't have python 2.7 at all. So we must either run master node on Cent OS

Re: [openstack-dev] [Glance] IRC logging

There's really no way to _force_ official logging on all project-related channels. People who are opposed to the idea simply move their conversations to new channels. They'll straddle the line between "somewhat official looking" and "official enough to require logging." -- Jeremy Stanley

Re: [openstack-dev] [Fuel] Dropping Python-2.6 support

You can get Python 2.7 via SCL: https://www.softwarecollections.org/en/scls/rhscl/python27/ On 01/12/2015 05:32 PM, Igor Kalnitsky wrote: Hi, Roman, Indeed, we have to go forward and drop python 2.6 support. That's how it supposed to be, but, unfortunately, it may not be as easy as it seems at

[openstack-dev] Kilo devstack issue

Hi, We deployed a kilo devstack on ubuntu 14.04 server. We successfully launched a instance from dashboard, but we are unable to open console from dashboard for instance.Also instacne is unable to get ip Below is link for local.conf http://paste.openstack.org/show/156497/ Regards Nikesh ___

Re: [openstack-dev] [Fuel] Dropping Python-2.6 support

Hi, Agree with Igor, I think we cannot just drop compatibility for fuel client with 2.6 python, the reason is we have old master nodes which have 2.6 python, and the newer fuel client should work fine on these environments. Or we can try to install python 2.7 on the master during the upgrade. As

Re: [openstack-dev] [Fuel] Dropping Python-2.6 support

On Mon, Jan 12, 2015 at 9:10 AM, Evgeniy L wrote: > Agree with Igor, I think we cannot just drop compatibility for fuel client > with 2.6 python, Hm, didn't Igor say in his email that "we have to drop python 2.6 support"? > the reason is we have old master nodes which have > 2.6 python, and the

[openstack-dev] [Ironic] Weekly subteam status report

Hi all, Following is the subteam report for Ironic. As usual, this is pulled directly from the Ironic whiteboard[0] and formatted. Bugs (dtantsur) (As of Mon, 12 Jan, 12:00 UTC) Open: 133 (+15). 14 new (+5), 32 in progress (+3), 1 critical (+1), 13 high (+2) and 5 incom

Re: [openstack-dev] [Fuel] Dropping Python-2.6 support

Hi Dmitry, >> Client uses REST API to interact with Fuel, how is Python version a factor? Fuel client is written in python it means it won't work on the master node with 2.6 python if you drop compatibility with it. >> What exactly is the use cases that requires a new client deployed on an old F

[openstack-dev] [all] Group Based Policy - Announcing Release

The first release of Group Based Policy (GBP) [1] is now available! It is designed to work with OpenStack stable Juno, and comprises of four components: Service, Client, Heat Automation, and Horizon UI This release includes GBP network policy drivers for connectivity rendering using Neutron, confi

Re: [openstack-dev] [Policy][Group-based-policy] ODL Policy Driver Specs

Hi, The 'group' CLI commands are an alias to the 'policy-target-group' commands and are provided for convenience of use. Per your observation, both are equally functional and supported. Thanks, ~Sumit. On Mon, Jan 12, 2015 at 4:02 AM, Sachi Gupta wrote: > Hi, > > Can anyone explain the differenc

Re: [openstack-dev] [devstack] noVNC disabled by default?

On 01/09/2015 05:24 PM, Sean Dague wrote: > On 01/09/2015 06:12 PM, Solly Ross wrote: >> Hi, >> >> I just noticed that noVNC was disabled by default in devstack (the relevant >> >> change was

Re: [openstack-dev] [Heat] Where to keep data about stack breakpoints?

On Mon, Jan 12, 2015 at 04:29:15PM +0100, Tomas Sedovic wrote: > Hey folks, > > I did a quick proof of concept for a part of the Stack Breakpoint spec[1] > and I put the "does this resource have a breakpoint" flag into the metadata > of the resource: > > https://review.openstack.org/#/c/146123/ >

[openstack-dev] oslo.db 1.4.0 released

The Oslo team is pleased to announce the release of oslo.db 1.4.0: oslo.db library The primary reason for this release is to move the code out of the oslo namespace package as part of https://blueprints.launchpad.net/oslo-incubator/+spec/drop-namespace-packages For more details, please see the gi

Re: [openstack-dev] [Fuel] Dropping Python-2.6 support

The python27 packages Ihar has linked do not conflict with the system python 2.6, so I don't see any problems with the rollback here. Is rollback the only concern for the master node upgrade use case? On Mon, Jan 12, 2015 at 9:51 AM, Evgeniy L wrote: > Hi Dmitry, > >>> Client uses REST API to in

[openstack-dev] [Ironic] Bug team meeting tomorrow 1700 UTC

Following up from our IRC meeting to let folks know that we'll be having a "bug day" tomorrow (Tuesday) to clean up our bug list. Folks who want to join Dmitry and I are welcome - we'll start at the same time as today's meeting (1700 UTC // 9am PST), but in our usual channel (#openstack-ironic) rat

Re: [openstack-dev] [nova][ThirdPartyCI][PCI] Intel Third party Hardware based CI for PCI

The public link for your test logs should really be a host name instead of an IP address. That way if you have to change it again in the future, you won't have dead links in old comments. You may already know, but all of the requirements and recommendations are here: http://git.openstack.org/cgit/o

[openstack-dev] [all] [api] gabbi: A tool for declarative testing of APIs

After some discussion with Sean Dague and a few others it became clear that it would be a good idea to introduce a new tool I've been working on to the list to get a sense of its usefulness generally, work towards getting it into global requirements, and get the documentation fleshed out so that

Re: [openstack-dev] Kilo devstack issue

On Mon, Jan 12, 2015 at 10:03 AM, Nikesh Kumar Mahalka wrote: > Hi, > We deployed a kilo devstack on ubuntu 14.04 server. > We successfully launched a instance from dashboard, but we are unable to > open console from dashboard for instance.Also instacne is unable to get ip > > Below is link for lo

[openstack-dev] [Keystone] Spec proposal deadline Feb 5

This is a reminder that the Keystone spec proposal deadline is Feb 5. Please work to have your specs submitted and approved by that date. The keystone team will be spending time at the midcycle next week (Jan 19, 20, 21) to discuss specs; specs proposed before the midcycle will get priority whe

Re: [openstack-dev] [all] [api] gabbi: A tool for declarative testing of APIs

> After some discussion with Sean Dague and a few others it became > clear that it would be a good idea to introduce a new tool I've been > working on to the list to get a sense of its usefulness generally, > work towards getting it into global requirements, and get the > documentation fleshed ou

Re: [openstack-dev] [Fuel] Dropping Python-2.6 support

> On Jan 12, 2015, at 9:55 AM, Roman Prykhodchenko wrote: > > Folks, > > as it was planned and then announced at the OpenStack summit OpenStack > services deprecated Python-2.6 support. At the moment several services and > libraries are already only compatible with Python>=2.7. And there is n

[openstack-dev] [nova] request spec freeze exception for virtio-net multiqueue

Hello, I'd like to request an exception for virtio-net multiqueue feature. [1] This is an important feature that aims to increase the total network throughput in guests and not too hard to implement. Thanks, Vladik [1] https://review.openstack.org/#/c/128825

Re: [openstack-dev] [all] [api] gabbi: A tool for declarative testing of APIs

Thanks for this Chris, I'm hoping to get my fingers dirty with it Real Soon Now. On Mon, Jan 12, 2015 at 1:54 PM, Eoghan Glynn wrote: > > I'd be interested in hearing the api-wg viewpoint, specifically whether > that working group intends to recommend any best practices around the > approach to A

Re: [openstack-dev] [heat][tripleo] Making diskimage-builder install from forked repo?

On 09/01/15 07:06, Gregory Haynes wrote: Excerpts from Steven Hardy's message of 2015-01-08 17:37:55 +: Hi all, I'm trying to test a fedora-software-config image with some updated components. I need: - Install latest master os-apply-config (the commit I want isn't released) - Install os-r

Re: [openstack-dev] [all] [api] gabbi: A tool for declarative testing of APIs

Chris, The Idea is brilliant. I may steal it! =) But there are some issues that will be faced: 1) Using as a base unittest: > python -m subunit.run discover -f gabbi | subunit2pyunit So rally team won't be able to reuse it for load testing (if we directly integrate it) because we will have hu

Re: [openstack-dev] [all] [api] gabbi: A tool for declarative testing of APIs

On 01/12/2015 03:11 PM, Dean Troyer wrote: > Thanks for this Chris, I'm hoping to get my fingers dirty with it Real > Soon Now. > > On Mon, Jan 12, 2015 at 1:54 PM, Eoghan Glynn > wrote: > > I'd be interested in hearing the api-wg viewpoint, specifically whether >

Re: [openstack-dev] [all] [api] gabbi: A tool for declarative testing of APIs

On 01/12/2015 03:18 PM, Boris Pavlovic wrote: > Chris, > > The Idea is brilliant. I may steal it! =) > > But there are some issues that will be faced: > > 1) Using as a base unittest: > > python -m subunit.run discover -f gabbi | subunit2pyunit > > > So rally team won't be able to reus

Re: [openstack-dev] [all] [api] gabbi: A tool for declarative testing of APIs

Sean, I definitely like the direction that gabbi seems to be headed. It feels > like a much cleaner version of what nova tried to do with API samples. > As long as multiple projects think this is an interesting direction, I > think it's probably fine to add it to global-requirements and let them

[openstack-dev] [Keystone] LDAP Identity Use Survey

The Keystone development team is looking for deployment feedback regarding the use of the LDAP Identity backend. The Identity backend only covers Users and Groups. We are looking to get an idea of types (read-only, read-write, etc) and reasons for use of the LDAP backend. The answers to this su

Re: [openstack-dev] [all] [api] gabbi: A tool for declarative testing of APIs

Excerpts from Chris Dent's message of 2015-01-12 19:20:18 +: > > After some discussion with Sean Dague and a few others it became > clear that it would be a good idea to introduce a new tool I've been > working on to the list to get a sense of its usefulness generally, > work towards getting i

Re: [openstack-dev] [horizon] static files handling, bower/

On 12/18/14 6:58 AM, Radomir Dopieralski wrote: > Hello, > > revisiting the package management for the Horizon's static files again, > I would like to propose a particular solution. Hopefully it will allow > us to both simplify the whole setup, and use the popular tools for the > job, without lo

Re: [openstack-dev] [all] [api] gabbi: A tool for declarative testing of APIs

On Mon, 12 Jan 2015, Gregory Haynes wrote: Awesome! I was discussing trying to add extensions to RAML[1] so we could do something like this the other day. Is there any reason you didnt use an existing modeling language like this? Glad you like it. I chose to go with my own model in the YAML f

Re: [openstack-dev] [all] Hacking 0.10 released

Just a heads up for anyone else making these changes: Even though the g-r entry is >=0.10, you need to do >=0.10.0 in the project for it to pass the requirements check. On 01/10/2015 07:15 PM, Joe Gordon wrote: > Hi all, > > I am happy to announce the release of hacking 0.10. Below is a list of >

[openstack-dev] [tc][python-clients] More freedom for all python clients

Hello TC, I would like to propose to allow adding all python-clients from stackforge (that are regarding global-requirements) to global requirements. It doesn't cost anything and simplifies life for everybody on stackforge. P.S. We already have billions libs in global requirements that aren't ev

[openstack-dev] [Fuel] Lack of additional setup on 10Gbit interfaces.

Hi. I'm testing OpenStack setup set on our hardware with Fuel 6.0 and I found the problem with 10Gbit network interfaces configuration. Our setup uses Centos on deployed nodes - I didn't look how this situation looks from Ubuntu perspective, but looking on the fuel-library - there is probably t

Re: [openstack-dev] [Heat] Where to keep data about stack breakpoints?

On 12/01/15 10:49, Ryan Brown wrote: On 01/12/2015 10:29 AM, Tomas Sedovic wrote: Hey folks, I did a quick proof of concept for a part of the Stack Breakpoint spec[1] and I put the "does this resource have a breakpoint" flag into the metadata of the resource: https://review.openstack.org/#/c/1

Re: [openstack-dev] [all] [api] gabbi: A tool for declarative testing of APIs

On Tue, 13 Jan 2015, Boris Pavlovic wrote: The Idea is brilliant. I may steal it! =) Feel free. But there are some issues that will be faced: 1) Using as a base unittest: python -m subunit.run discover -f gabbi | subunit2pyunit So rally team won't be able to reuse it for load testing (i

Re: [openstack-dev] [all] [api] gabbi: A tool for declarative testing of APIs

Hi Chris, If there's sufficient motivation and time it might make sense to > separate the part of gabbi that builds TestCases from the part that > runs (and evaluates) HTTP requests and responses. If that happens then > integration with tools like Rally and runners is probably possible. Having

Re: [openstack-dev] [Heat] Where to keep data about stack breakpoints?

On 12/01/15 13:05, Steven Hardy wrote: >I also had a chat with Steve Hardy and he suggested adding a STOPPED state >to the stack (this isn't in the spec). While not strictly necessary to >implement the spec, this would help people figure out that the stack has >reached a breakpoint instead of jus

Re: [openstack-dev] [all] [api] gabbi: A tool for declarative testing of APIs

On 01/12/2015 05:00 PM, Boris Pavlovic wrote: > Hi Chris, > > If there's sufficient motivation and time it might make sense to > separate the part of gabbi that builds TestCases from the part that > runs (and evaluates) HTTP requests and responses. If that happens then > integrati

Re: [openstack-dev] [Cinder] Cutoff deadlines for cinder drivers

On 09:03 Mon 12 Jan , Erlon Cruz wrote: > Hi guys, > > Thanks for answering my questions. I have 2 points: > > 1 - This (remove drivers without CI) is a way impacting change to be > implemented without exhausting notification and discussion on the mailing > list. I myself was in the meeting b

Re: [openstack-dev] [Fuel] Lack of additional setup on 10Gbit interfaces.

Hi Piotr, Thanks for writing up a detailed summary of the problem! At the moment, we have a way to set MTU using Fuel CLI [0] and a blueprint to add this functionality to Fuel Web UI [1] [0] http://docs.mirantis.com/openstack/fuel/fuel-6.0/reference-architecture.html#adjust-the-network-configura

Re: [openstack-dev] [api] API Definition Formats

On 1/9/15, 15:17, "Everett Toews" wrote: >One thing that has come up in the past couple of API WG meetings [1] is >just how useful a proper API definition would be for the OpenStack >projects. > >By API definition I mean a format like Swagger, RAML, API Blueprint, etc. >These formats are a machin

Re: [openstack-dev] [all] [api] gabbi: A tool for declarative testing of APIs

On Mon, Jan 12, 2015 at 1:20 PM, Chris Dent wrote: > > After some discussion with Sean Dague and a few others it became > clear that it would be a good idea to introduce a new tool I've been > working on to the list to get a sense of its usefulness generally, > work towards getting it into global

Re: [openstack-dev] [Heat] Where to keep data about stack breakpoints?

On Mon, Jan 12, 2015 at 05:10:47PM -0500, Zane Bitter wrote: > On 12/01/15 13:05, Steven Hardy wrote: > >>>I also had a chat with Steve Hardy and he suggested adding a STOPPED state > >>>to the stack (this isn't in the spec). While not strictly necessary to > >>>implement the spec, this would help

Re: [openstack-dev] [all] [api] gabbi: A tool for declarative testing of APIs

On Mon, 12 Jan 2015, Anne Gentle wrote: I'm interested, sure. What did you use to write the HTTP tests, as in, what was the source of truth for what the requests and responses should be? That is an _extremely_ good question and one I really struggled with as I started integrating gabbi with ce

Re: [openstack-dev] [all] [api] gabbi: A tool for declarative testing of APIs

Sean, So I'd say let's focus on that problem right now, and get some traction > on this as part of functional test suites in OpenStack. Genericizing it > too much just turns this back into a version of every other full stack > testing tool, which we know isn't sufficient for having quality > comp

Re: [openstack-dev] [all] [api] gabbi: A tool for declarative testing of APIs

On Tue, 13 Jan 2015, Boris Pavlovic wrote: Having separated engine seems like a good idea. It will really simplify stuff I'm not certain that's the case, but it may be worth exploration. This seems like a huge duplication of efforts. I mean operators will write own tools developers own... Wh

Re: [openstack-dev] [api] API Definition Formats

On Mon, 12 Jan 2015, Ian Cordasco wrote: This worked extremely well in my experience and helped improve development time for new endpoints and new endpoint versions. The documentation was also heavily used for the multiple internal clients for that API. This idea of definition formats seems li

  1   2   >