[openstack-dev] [Nova] Hyper-V CI broken?

I apologise if there's already been an email about this, I can't see one. Is the Hyper-V CI broken at the moment? It looks like there are a number of tests failing for every change, including trivial typo fixes. An example: http://64.119.130.115/168500/4/results.html.gz http://stackalytics.com/r

Re: [openstack-dev] [cinder] Attaching extra-spec to vol-type using Cinder py-client

cinder.volume_types.create returns an instance of VolumeType. https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/volume_types.py#L118 Thanks, Vipin From: Pradip Mukhopadhyay [mailto:pradip.inte...@gmail.com] Sent: Tuesday, March 31, 2015 10:07 AM To: OpenStack Developmen

Re: [openstack-dev] [Neutron] Core API vs extension: the subnet pool feature

Hi, I am also fine with the shim extension. Thanks Gary On 3/31/15, 1:44 AM, "Carl Baldwin" wrote: >Thanks for your support, Akihiro. We will get this up for review very >soon. > >Carl > >On Mon, Mar 30, 2015 at 2:59 PM, Akihiro Motoki wrote: >> Hi Carl, >> >> I am now reading the detail from

Re: [openstack-dev] [OpenStack-Dev] [third-party-ci] Clarifications on the goal and skipping tests

On 31 March 2015 at 01:35, John Griffith wrote: > On Mon, Mar 30, 2015 at 4:06 PM, Doug Wiegley < > doug...@parksidesoftware.com> wrote: > >> ​ >> >> > - Test relies on some “optional” feature, like overlapping IP subnets that >> the backend doesn’t support. I’d argue it’s another case of broken

Re: [openstack-dev] [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

On Tuesday, 31 de March de 2015 at 7:14, George Shuklin wrote: > > > On 03/30/2015 11:18 AM, Kevin Benton wrote: > > What does fog do? Is it just a client to the Neutron HTTP API? If so, > > it should not have broken like that because the API has remained > > pretty stable. If it's a deploy

Re: [openstack-dev] [nova] how to handle vendor-specific API microversions?

2015-03-28 4:03 GMT+09:00 Chris Friesen : > On 03/27/2015 12:44 PM, Dan Smith wrote: >>> >>> To quote John from an earlier email in this thread: >>> >>> Its worth noting, we do have the "experimental" flag: >>> " >>> The first header specifies the version number of the API which was >>> executed. E

[openstack-dev] EC2 API Sub team weekly meeting

We'll have the weekly EC2 API sub team meeting [1] at 1400UTC in #openstack-meeting-3 today. We'll likely spend the majority of the time going over current status along with critical bugs, as well as covering BPs. Please feel free to add other items in the agenda [2] section. Thanks! Swami [1]

[openstack-dev] [neutron]

Hi, all. Recently, I have requirement to establish ipsec connection with virtual tunnel interface(VTI). But I found the existing vpnaas in neutron does not support ipsec with virtual tunnel interface. Do we have plan to let vpnaas support ipsec with vti or gre over ipsec ? With this feature, we

Re: [openstack-dev] Barbican : Use of consumer resource

As John said, the URI is unrestricted (intentionally so) -- this could be 'mailto:s...@person.com' just as easily as a reference to another OpenStack or external service. Originally, the idea was that Loadbalancers would need to use a Container for TLS purposes, so we'd put the LB's URI in there

Re: [openstack-dev] [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

On 03/30/2015 11:18 AM, Kevin Benton wrote: What does fog do? Is it just a client to the Neutron HTTP API? If so, it should not have broken like that because the API has remained pretty stable. If it's a deployment tool, then I could see that because the configuration options to tend to suffe

Re: [openstack-dev] Barbican : Use of consumer resource

(Including Adam, who implemented this feature last year to make sure I'm not misspeaking here :) Hello Asha, The consumers feature allows clients/services to register 'interest' in a given secret or container. The URL provided is unrestricted. Clients that wish to delete a secret or consumer m

[openstack-dev] [cinder] Attaching extra-spec to vol-type using Cinder py-client

Hello, I am trying to create and type-set some parameters to a volume-type as follows: cinder type-create nfs cinder type-key nfs set volume_backend_name=myNFSBackend The same thing I want to achieve through python client. I can create the type as follows: from cinderclient import client cinde

Re: [openstack-dev] [nova] how to handle vendor-specific API microversions?

On 03/27/2015 03:03 PM, Chris Friesen wrote: On 03/27/2015 12:44 PM, Dan Smith wrote: To quote John from an earlier email in this thread: Its worth noting, we do have the "experimental" flag: " The first header specifies the version number of the API which was executed. Experimental is only ret

Re: [openstack-dev] [libvirt] [nova] The risk of hanging when shutdown instance.

On 2015/3/31 4:36, Eric Blake wrote: > On 03/30/2015 06:08 AM, Michal Privoznik wrote: >> On 30.03.2015 11:28, zhang bo wrote: >>> On 2015/3/28 18:06, Rui Chen wrote: >>> >>> >>> The API virDomainShutdown's description is out of date, it's not correct. >>> In fact, virDomainShutdown woul

[openstack-dev] [neutron] [devstack] neutron router ID is not set

Hi, All, When Q_USE_NAMESPACE=False, router id is set by create_neutron_initial_network _neutron_configure_router_v4 _neutron_set_router_id function _neutron_set_router_id { if [[ "$Q_USE_NAMESPACE" == "False" ]]; then iniset $Q_L3_CONF_FILE DEFAULT router_id $ROUTER_ID fi }

Re: [openstack-dev] [Mistral] Proposal for the Resume Feature

Thanks Winson for the summary. @Lingxian Kong > The context for a task is used > internally, I know the aim for this feature is to make it very easy > and convinient for users to see the details for the workflow exection, > but what users can do next with the context? Do you have a plan to > cha

Re: [openstack-dev] [Neutron] initial OVN testing

On 03/26/2015 07:54 PM, Russell Bryant wrote: > Gary and Kyle, I saw in my IRC backlog that you guys were briefly > talking about testing the Neutron ovn ml2 driver. I suppose it's time > to add some more code to the devstack integration to install the current > ovn branch and set up ovsdb-server

Re: [openstack-dev] [OpenStack-Dev] [third-party-ci] Clarifications on the goal and skipping tests

On Mon, Mar 30, 2015 at 7:26 PM, wrote: > Another scenario. > > The default LVM driver is local to cinder service. Thus, it may work fine > as soon as you go outside controller node it does not. > > We had a discussion on choosing different default driver and expect that > discussion to continue

Re: [openstack-dev] [OpenStack-Dev] [third-party-ci] Clarifications on the goal and skipping tests

Another scenario. The default LVM driver is local to cinder service. Thus, it may work fine as soon as you go outside controller node it does not. We had a discussion on choosing different default driver and expect that discussion to continue. Not all drivers support all features. We have a tab

Re: [openstack-dev] [OpenStack-Dev] [third-party-ci] Clarifications on the goal and skipping tests

On Mon, Mar 30, 2015 at 6:21 PM, Rochelle Grober wrote: > Top posting… I believe the main issue was a problem with snapshots that > caused false negatives for most cinder drivers. But, that got fixed. > Unfortunately, we haven’t yet established a good process to notify third > parties when skip

Re: [openstack-dev] [nova] [scheduler] [gantt] Please stop using "Gantt" for discussing about Nova scheduler

I actually prefer to use the term Gantt, it neatly encapsulates the discussions and it doesn't take much effort to realize that Gantt refers to the scheduler and, if you feel there is confusion, we can clarify things in the wiki page to emphasize the process: clean up the current scheduler inter

Re: [openstack-dev] [nova] meaning of 'Triaged' in bug tracker

On Mon, Mar 30, 2015 at 10:00:44AM -0400, Sean Dague wrote: > I've been attempting to clean up the bug tracker, one of the continued > inconsistencies that are in the Nova tracker is the use of 'Triaged'. > > > https://wiki.openstack.org/wiki/BugTriage > > "If the bug contains the solution, or a

Re: [openstack-dev] [OpenStack-Dev] [third-party-ci] Clarifications on the goal and skipping tests

Top posting… I believe the main issue was a problem with snapshots that caused false negatives for most cinder drivers. But, that got fixed. Unfortunately, we haven’t yet established a good process to notify third parties when skipped tests are fixed and should be “unskipped”. Maybe tagging t

[openstack-dev] [barbican] python-barbicanclient 3.0.3 released

The Barbican Project Team would like to announce the release of python-barbicanclient 3.0.3. The release is available via PyPI * https://pypi.python.org/pypi/python-barbicanclient For detailed release notes, please visit the milestone page i

Re: [openstack-dev] [Neutron] Core API vs extension: the subnet pool feature

Thanks for your support, Akihiro. We will get this up for review very soon. Carl On Mon, Mar 30, 2015 at 2:59 PM, Akihiro Motoki wrote: > Hi Carl, > > I am now reading the detail from Salvatore, but would like to response > this first. > > I don't want to kill this useful feature too and move t

Re: [openstack-dev] [Neutron] Core API vs extension: the subnet pool feature

I will quickly spin another patch set with the shim extension. Hopefully this will be all it takes to get subnet allocation merged. -Ryan -Original Message- From: Akihiro Motoki [mailto:amot...@gmail.com] Sent: Monday, March 30, 2015 2:00 PM To: OpenStack Development Mailing List (not

Re: [openstack-dev] [OpenStack-Dev] [third-party-ci] Clarifications on the goal and skipping tests

On Mon, Mar 30, 2015 at 4:06 PM, Doug Wiegley wrote: > A few reasons, I’m sure there are others: > > - Broken tests that hardcode something about the ref implementation. The > test needs to be fixed, of course, but in the meantime, a constantly > failing CI is worthless (hello, lbaas scenario tes

Re: [openstack-dev] [heat] Network name as a Server properties

On 30/03/15 03:51, BORTMAN, Limor (Limor) wrote: Hi, I noticed the we can't use network name under OS::Neutron::Port (only "network_id") as a valid neutron property, and I was wondering why? IIRC it was something weird about how python-neutronclient worked at the time. I expected it to be

[openstack-dev] [stable] Preparing for 2014.2.3 -- branches freeze April 2nd

Hi All- We'll be freezing the stable/juno branches for integrated Juno projects this Thursday April 2nd in preparation for the 2014.2.3 stable release on Thursday April 9th. You can view the current queue of proposed patches on gerrit [1]. I'd like to request all interested parties review curren

Re: [openstack-dev] [heat] heat delete woes in Juno

On 26/03/15 15:30, Georgy Okrokvertskhov wrote: I attached an example of the template which is hanging right now in my Juno environment. I believe it hangs because of floating ip stuff and the way how it is attached to a VM. It is autogenerated, so please don't be disturbed by strange resource na

Re: [openstack-dev] [OpenStack-Dev] [third-party-ci] Clarifications on the goal and skipping tests

A few reasons, I’m sure there are others: - Broken tests that hardcode something about the ref implementation. The test needs to be fixed, of course, but in the meantime, a constantly failing CI is worthless (hello, lbaas scenario test.) - Test relies on some “optional” feature, like overlapping

Re: [openstack-dev] Barbican : Use of consumer resource

Including Alee and Paul in the loop Refining the above question : The consumer resource allows the clients to register with container resources. Please find the command and response below POST v1/containers/888b29a4-c7cf-49d0-bfdf-bd9e6f26d718/consumers Header: content-type=application/json

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

> Quick update about OVS vs LB: > Sean M. Collins pushed up a patch that runs CI on Tempest with LB: > https://review.openstack.org/#/c/168423/ > > So far it's failing pretty badly. I haven't had a chance to debug the failures - it is my hope that perhaps there are just more changes I need to ma

[openstack-dev] Barbican : Unable to reterieve asymmetric order request for rsa algorithm type

Hi All , I would like to know whether Barbican supports asymmetric order request . Please find the curl command and response for creating the order and retrieving the order root@barbican:~# curl -X POST -H 'content-type:application/json' -H 'X-Project-Id: 12345' -d '{"type" : "asymmetric", "meta

Re: [openstack-dev] [Neutron] Core API vs extension: the subnet pool feature

Hi Carl, I am now reading the detail from Salvatore, but would like to response this first. I don't want to kill this useful feature too and move the thing forward. I am fine with the empty/shim extension approach. The subnet pool is regarded as a part of Core API, so I think this extension can b

[openstack-dev] [Fuel] Core groups split

Hi, everyone, as a follow-up for discussion [1] we've added per project core groups for all main fuel-* repositories (see [2]): fuel-astute-core fuel-devops-core fuel-docs-core fuel-library-core fuel-main-core fuel-ostf-core fuel-plugins-core fuel-qa-core fuel-stats-core fuel-web-core The origin

[openstack-dev] [OpenStack-Dev] [third-party-ci] Clarifications on the goal and skipping tests

This may have already been raised/discussed, but I'm kinda confused so thought I'd ask on the ML here. The whole point of third party CI as I recall was to run the same tests that we run in the official Gate against third party drivers. To me that would imply that a CI system/device that marks it

Re: [openstack-dev] [libvirt] [nova] The risk of hanging when shutdown instance.

On 03/30/2015 06:08 AM, Michal Privoznik wrote: > On 30.03.2015 11:28, zhang bo wrote: >> On 2015/3/28 18:06, Rui Chen wrote: >> >>> >> >> The API virDomainShutdown's description is out of date, it's not correct. >> In fact, virDomainShutdown would block or not, depending on its mode. If >> i

Re: [openstack-dev] [Neutron] Core API vs extension: the subnet pool feature

Akihiro, If we go with the empty extension you proposed in the patch will that be acceptable? We've got to stop killing new functionality on the very last day like this . It just kills progress. This proposal isn't new. Carl On Mar 30, 2015 11:37 AM, "Akihiro Motoki" wrote: > Hi Neutron folks

Re: [openstack-dev] [Neutron] [ML2] using binding:tun_ip instead of agent_ip for l2pop to support agentless backend

hi henry, thanks for this interesting idea. It would be interesting to think about how external gateway could leverage the l2pop framework. Currently l2pop sends its fdb messages once the status of the port is modified. AFAIK, this status is only modified by agents which send update_devce_up/down

Re: [openstack-dev] [Neutron] Core API vs extension: the subnet pool feature

Akihiro, thanks for sharing this on the mailing list. I have some answers inline, but from a community process perspective I have a feeling that a majority of contributors feel like well established guidelines have been violated. This has been exacerbated by the fact that these changes are landing

Re: [openstack-dev] [Openstack-operators] [Openstack-dev][all] how to apply security/back-ported release to Icehouse production

On Mon, Mar 30, 2015 at 3:19 PM, Daniel Comnea wrote: > No thoughts? You don't need to do sequential upgrades, you *should* be able to cherry pick which components to upgrade because there *shouldn't* be and RPC format changes in back ports. That said I once had issues becasue of an RPC change wh

Re: [openstack-dev] [Openstack-operators][Openstack-dev][all] how to apply security/back-ported release to Icehouse production

No thoughts? On Sat, Mar 28, 2015 at 10:35 PM, Daniel Comnea wrote: > Hi all, > > Can anyone shed some light as to how you upgrade/ applies the > security/back-ported patches? > > E.g - let's say i already have a production environment running Icehouse > 2014.1 as per the link [1] and i'd lik

Re: [openstack-dev] [puppet] Coordinator(s)/PTL tasks description

On 03/26/2015 01:08 PM, Sebastien Badia wrote: > Hi, > > Following our Tuesday meeting, we decided to create a sort of PTL / > Coordinators tasks list with the essence of > https://wiki.openstack.org/wiki/PTL_Guide > > I list some point here, but feel free to add discuss about them, it's > not

[openstack-dev] [ceilometer] upgrades from juno to kilo

I tracked down the cause of the check-grenade-dsvm failure on https://review.openstack.org/#/c/167370 . As I understand it, grenade is taking the previous stable release, deploying it, then upgrading to the current master (plus the proposed changeset) without changing any of the config from the s

Re: [openstack-dev] Barbican : Usage of mode attribute in storing and order the secret

Thanks a lot Douglas for your response. It helped me . What are the possible values of algorithm attribute? Is AES only supported algorithm type for Barbican or does it support any other algorithm type? Thanks and Regards, Asha Seshagiri On Mon, Mar 30, 2015 at 1:04 PM, Douglas Mendizabal < dou

Re: [openstack-dev] [Fuel] Nominate Irina Povolotskaya for fuel-docs core

I think it's safe to conclude that we have a strong consensus in favor. Congratulations Irina! All that's left is to merge https://review.openstack.org/168182 so that we can actually assign core reviewers separately for fuel-docs. On Sun, Mar 29, 2015 at 11:13 PM, Nikolay Markov wrote: > +1 > >

Re: [openstack-dev] Barbican : Usage of mode attribute in storing and order the secret

Hi Asha, Barbican Orders of type “key” are intended to generate keys suitable for encryption. The metadata associated with the key order defines the encryption scheme in which the key will be used. In the example you provided, the order is requesting a key that is suitable for use in a block

[openstack-dev] [Fuel] Re: 6.1 Soft Code Freeze moved to April 7th

Note: Modifying the subject line to add the tag "Fuel" as this message has gone out to the OpenStack Dev mailing list. On Mon, Mar 30, 2015 at 10:50 AM, Eugene Bogdanov wrote: > Hello everyone, > > We currently have 500+ medium priority bugs assigned to 6.1 release. > Obviously we won't be able t

[openstack-dev] 6.1 Soft Code Freeze moved to April 7th

Hello everyone, We currently have 500+ medium priority bugs assigned to 6.1 release. Obviously we won't be able to make a big difference with

Re: [openstack-dev] Barbican : Usage of mode attribute in storing and order the secret

Any help would be appreciated ? Thanks in advance ! Thanks and Regards, Asha Seshagiri On Mon, Mar 30, 2015 at 12:45 PM, Asha Seshagiri wrote: > Hi All , > > What is the use of the mode attribute ? what does the value of this > attribute signify and what are the possible values of this attribut

[openstack-dev] Barbican : Usage of mode attribute in storing and order the secret

Hi All , What is the use of the mode attribute ? what does the value of this attribute signify and what are the possible values of this attribute? For ex :Consider the order request to create the secret : POST v1/orders Header: content-type=application/json X-Project-Id: {project_id} {

Re: [openstack-dev] [Manila] FFE Request: "glusterfs_native: negotiate volumes with glusterd"

On 03/30/2015 12:21 PM, Csaba Henk wrote: Hi, I'm applying for an FFE for change https://review.openstack.org/162542 , "glusterfs_native: negotiate volumes with glusterd". The change in question is in the grey zone between a bugfix and a feature. So, having it discussed with the Manila communi

[openstack-dev] [Neutron] Core API vs extension: the subnet pool feature

Hi Neutron folks (API folks may be interested on this) We have another discussion on Core vs extension in the subnet pool feature reivew https://review.openstack.org/#/c/157597/. We did the similar discussion on VLAN transparency and MTU for a network model last week. I would like to share my conc

[openstack-dev] [Telco][NFV] Update to weekly meeting time commencing this week.

Hi all, Since the Paris summit the Telco Working Group has been meeting on an alternating basis at 1400 UTC and 2200 UTC. As discussed in the last two meetings due to low attendance in the 2200 UTC slot, particularly as DST has now kicked in for many participants, we are going to trial a slight

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

On Sun, Mar 29, 2015 at 6:45 AM, Kevin Benton wrote: > Does the decision about the floating IP have to be based on the use of the > private IP in the original destination, or could you get by with rules on > the L3 agent to avoid NAT just based on the destination being in a > configured set of CI

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

On 03/30/2015 12:35 PM, Russell Bryant wrote: > On 03/30/2015 10:34 AM, Anita Kuno wrote: >> On 03/26/2015 08:58 PM, Russell Bryant wrote: >>> To me it comes down to the reasons people don't want to move. I'd like >>> to dig into exactly why people don't want to use Neutron. If there are >>> legi

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

On Mon, Mar 30, 2015 at 4:49 AM, Jesse Pretorius wrote: > On 28 March 2015 at 00:41, Steve Wormley wrote: > >> 2. Floating IPs managed at each compute node(multi-host) and via the >> standard nova API calls. >> > > 2 meant we can't use pure provider VLAN networks so we had to wait for DVR >> VL

[openstack-dev] [mistral] Team meeting minutes - 03/30/2015

Thanks for joining today’s team meeting! Meeting minutes: http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-03-30-16.23.html Meeting log: http://eavesdrop.openstack.org/meetings/mistral/2015/mi

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

On 03/30/2015 10:34 AM, Anita Kuno wrote: > On 03/26/2015 08:58 PM, Russell Bryant wrote: >> To me it comes down to the reasons people don't want to move. I'd like >> to dig into exactly why people don't want to use Neutron. If there are >> legitimate reasons why nova-network will work better, th

[openstack-dev] Find your discount code for Vancouver and register *now*

Folks, If you have received your discount code to OpenStack summit Vancouver, stop whatever you're doing and register *now* Admission prices go up to $900 tomorrow and you'll have to pay the difference. *There will be absolutely no exceptions*. If you're in doubt if you s

[openstack-dev] [Manila] FFE Request: "glusterfs_native: negotiate volumes with glusterd"

Hi, I'm applying for an FFE for change https://review.openstack.org/162542 , "glusterfs_native: negotiate volumes with glusterd". The change in question is in the grey zone between a bugfix and a feature. So, having it discussed with the Manila community and our PTL, Ben Swartzlander, we decided

Re: [openstack-dev] [Sahara] Question about Sahara API v2

Agree with Mike, thx for the link. On Mon, Mar 30, 2015 at 4:55 PM, michael mccune wrote: > On 03/30/2015 07:02 AM, Sergey Lukjanov wrote: > >> My personal opinion for API 2.0 - we should discuss design of all object >> and endpoint, review how they are used from Horizon or >> python-saharaclien

Re: [openstack-dev] [os-ansible-deployment] Nominating Nolan Brubaker for core team

Thanks Kevin, and thanks to the other cores for their votes of confidence. On Mar 30, 2015, at 11:50 AM, Kevin Carter wrote: > Please join me in welcoming Nolan Brubaker (palendae) to the > os-ansible-deployment core team. > > — > > Kevin Carter > > >> On Mar 30, 2015, at 06:54, Jesse Preto

Re: [openstack-dev] [os-ansible-deployment] Nominating Nolan Brubaker for core team

Please join me in welcoming Nolan Brubaker (palendae) to the os-ansible-deployment core team. — Kevin Carter > On Mar 30, 2015, at 06:54, Jesse Pretorius wrote: > > On 25 March 2015 at 15:24, Kevin Carter wrote: > I would like to nominate Nolan Brubaker (palendae on IRC) for the > os-ansib

[openstack-dev] [kolla] Kolla milestone 3 was busted for Ubuntu 14.04 - fixed in master

Hey folks, We got a lot of complaints for folks trying to run Kolla on Ubuntu 14.04 with 3.13 kernel. Most of the problems were related to kernel bugs or docker bugs. We have worked around them, and now Kolla launches like a champ for me on 14.04. Regards -steve __

Re: [openstack-dev] [kolla] Re: Questions about kolla

From: Chmouel Boudjnah mailto:chmo...@chmouel.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Monday, March 30, 2015 at 6:52 AM To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

- Original Message - > On 03/30/2015 09:25 AM, Assaf Muller wrote: > > > > > > - Original Message - > >> On 03/27/2015 11:48 AM, Assaf Muller wrote: > >>> > >>> > >>> - Original Message - > On 03/27/2015 05:22 AM, Thierry Carrez wrote: > > > Part of it is

Re: [openstack-dev] [nova] meaning of 'Triaged' in bug tracker

+1 Sean! On Mon, Mar 30, 2015 at 10:00 AM, Sean Dague wrote: > I've been attempting to clean up the bug tracker, one of the continued > inconsistencies that are in the Nova tracker is the use of 'Triaged'. > > > https://wiki.openstack.org/wiki/BugTriage > > "If the bug contains the solution, or a

Re: [openstack-dev] [QA] How will Tempest discover/run tests migrated to specific projects?

On Mon, Mar 30, 2015 at 12:21:18PM +0530, Rohan Kanade wrote: > Since tests can now be removed from Tempest < > https://wiki.openstack.org/wiki/QA/Tempest-test-removal> and migrated to > their specific projects. > > Does Tempest plan to discover/run these tests in tempest gates? If yes, how > is t

[openstack-dev] [neutron] Liberty Specs are now open!

Hi all! The patch to open up Liberty specs in neutron-specs has now merged [1], so we're now accepting specs for Neutron targeting the Liberty release. Please note the process has changed slightly, as indicated in this patch [2]. If a patch was submitted for Kilo and didn't make it, I've got a rev

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

On 03/26/2015 08:58 PM, Russell Bryant wrote: > On 03/26/2015 06:31 PM, Michael Still wrote: >> Hi, >> >> I thought it would be a good idea to send out a status update for the >> migration from nova-network to Neutron, as there hasn't been as much >> progress as we'd hoped for in Kilo. There are a

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

On 03/26/2015 06:31 PM, Michael Still wrote: > Hi, > > I thought it would be a good idea to send out a status update for the > migration from nova-network to Neutron, as there hasn't been as much > progress as we'd hoped for in Kilo. There are a few issues which have > been slowing progress down.

Re: [openstack-dev] [ceilometer][FFE] Floating IP traffic statistics meters

if we can get the related driver implementation(s) for these meters ASAP, i'm ok with supporitng this feature. cheers, gord > From: me...@juniper.net > To: openstack-dev@lists.openstack.org > Date: Sat, 28 Mar 2015 00:56:27 + > Subject: [openstack-de

[openstack-dev] [nova] [scheduler] [gantt] Please stop using "Gantt" for discussing about Nova scheduler

Hi, tl;dr: I used the [gantt] tag for this e-mail, but I would prefer if we could do this for the last time until we spin-off the project. As it is confusing for many people to understand the difference in between the future Gantt project and the Nova scheduler effort we're doing, I'm propo

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

On 03/30/2015 09:25 AM, Assaf Muller wrote: > > > - Original Message - >> On 03/27/2015 11:48 AM, Assaf Muller wrote: >>> >>> >>> - Original Message - On 03/27/2015 05:22 AM, Thierry Carrez wrote: > Part of it is corner (or simplified) use cases not being optimally

[openstack-dev] [nova] meaning of 'Triaged' in bug tracker

I've been attempting to clean up the bug tracker, one of the continued inconsistencies that are in the Nova tracker is the use of 'Triaged'. https://wiki.openstack.org/wiki/BugTriage "If the bug contains the solution, or a patch, set the bug status to Triaged" In OpenStack the Triaged state me

Re: [openstack-dev] [Sahara] Question about Sahara API v2

On 03/30/2015 07:02 AM, Sergey Lukjanov wrote: My personal opinion for API 2.0 - we should discuss design of all object and endpoint, review how they are used from Horizon or python-saharaclient and improve them as much as possible. For example, it includes: * get rid of tons of extra optional f

Re: [openstack-dev] [kolla] Re: Questions about kolla

On Mon, Mar 30, 2015 at 3:42 PM, Steven Dake (stdake) wrote: > We plan to dockerize any service needed to deploy OpenStack. We haven’t > decided if that includes ceph, since ceph may already be dockerized by > someone else. But it does include the HA services we need as well as the > rest of th

Re: [openstack-dev] [TripleO] CI outage

Tl;dr tripleo ci is back up and running, see below for more On 21/03/15 01:41, Dan Prince wrote: Short version: The RH1 CI region has been down since yesterday afternoon. We have a misbehaving switch and have file a support ticket with the vendor to troubleshoot things further. We hope to kno

Re: [openstack-dev] [QA] How will Tempest discover/run tests migrated to specific projects?

Rohan, In Rally we are going to automate this work extending rally verify command. You can read here in more details: http://boris-42.me/rally-verfiy-as-the-control-plane-for-gabbi-tempest-in-tree-functional-tests/ As well, you are welcome to take a part in spec discussion here: https://review.op

[openstack-dev] [kolla] Re: Questions about kolla

Michal, All great questions. I have copied the OpenStack mailing list since these technical questions can benefit everyone. From: , Michal mailto:michal.stachow...@intel.com>> Date: Monday, March 30, 2015 at 6:21 AM To: Steven Dake mailto:std...@cisco.com>> Cc: "Chylinski, Arek" mailto:arek.c

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

- Original Message - > On 03/27/2015 11:48 AM, Assaf Muller wrote: > > > > > > - Original Message - > >> On 03/27/2015 05:22 AM, Thierry Carrez wrote: > >> > >>> Part of it is corner (or simplified) use cases not being optimally > >>> served by Neutron, and I think Neutron coul

[openstack-dev] [sahara] Last client release in Kilo

Hi Sahara folks, please, share your thoughts about about which changes should be included into the last sahara client release in Kilo to add this version to global requirements and use it in Heat, Horizon, etc. Here is an etherpad: https://etherpad.openstack.org/p/sahara-kilo-client Thanks. --

[openstack-dev] [Fuel][MySQL][Galera] Improvements for the DB configuration

Hello. There are several bugs and patches on review related to the MySQL with Galera and HAproxy cluster-check script configuration. Please don't hesitate to discuss them in this mail thread and in the review. * MySQL O_DIRECT mode [0] - merged. Do we need some additional performance test cases fo

Re: [openstack-dev] [nova] Host maintenance notification

Hi, Balázs I have the same scenario with you. AFAIK, notifications in Nova does not support some thing like service enable/disable action. These APIs do nothing more than saving new value to database. But I believe supporting these kind of notifications will not be very complicated. To the second

Re: [openstack-dev] [os-ansible-deployment] Nominating Nolan Brubaker for core team

On 25 March 2015 at 15:24, Kevin Carter wrote: > I would like to nominate Nolan Brubaker (palendae on IRC) for the > os-ansible-deployment-core team. Nolan has been involved with the project > for the last few months and has been an active reviewer with solid reviews. > IMHO, I think he is ready

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

On 28 March 2015 at 00:41, Steve Wormley wrote: > So, I figured I'd weigh in on this as an employee of a nova-network using > company. > > Nova-network allowed us to do a couple things simply. > > 1. Attach openstack networks to our existing VLANs using our existing > firewall/gateway and allow e

Re: [openstack-dev] [Sahara] Question about Sahara API v2

Hi, in a few words - we're finding out some places that were designed not very well (or our vision changed) and so we'd like to update the API to have a much better interface to work with Sahara. The blueprint you've listed was created in Atlanta summit timeframe and so it's not actual now. My pe

[openstack-dev] [nova] Host maintenance notification

Hi, I have the following scenario. I have an application consisting of multiple VMs on different compute hosts. The admin puts one of the hosts into maintenance mode (nova-manage service disable ...) because there will be some maintenance activity on that host in the near future. Is there a w

[openstack-dev] Added gating jobs on merge actions for chosen repositories.

Hello, I would like to inform you, that few gating jobs were added to https://fuel-jenkins.mirantis.com/ Jenkins: gate-fuel-web gate-fuel-astute gate-fuel-library-python gate-fuel-ostf gate-fuel-tasks-validator gate-python-fuelclient As suggested by Sebastian, those jobs run CI tests on merge

[openstack-dev] FWaaS iptables implementation

Hi, I want to ask about FWaaS iptables rule implementation. firewall rule are deployed as iptables rules in network node , and ACCEPT target is set at second rule(*). Chain neutron-l3-agent-iv431d7bfbc (1 references) pkts bytes target prot opt in out source destina

Re: [openstack-dev] [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

What does fog do? Is it just a client to the Neutron HTTP API? If so, it should not have broken like that because the API has remained pretty stable. If it's a deployment tool, then I could see that because the configuration options to tend to suffer quite a bit of churn as tools used by the refere

Re: [openstack-dev] [oslo.messaging][zeromq] introduce Request-Reply pattern to improve the stability

Hi, Sorry for not replying on [1] comments too long. I'm almost ready to return to the spec with updates. The main lack of current zmq-driver implementation is that it manually implements REQ/REP on top of PUSH/PULL. It results in: 1. PUSH/PULL is one way directed socket (reply needs another c

[openstack-dev] [heat] Network name as a Server properties

Hi, I noticed the we can't use network name under OS::Neutron::Port (only "network_id") as a valid neutron property, and I was wondering why? I expected it to be like image under OS::Nova::Server: The property name should be network, and it should accept both id and name Thanks Stotland Limor