[openstack-dev] nova-compute
Hi all
I'm trying to run VM on a compute node having ubuntu 13.10 with powerpc
arch.When I launch a VM from the controller node,it is stucking at
spawning state and below are the logs of nova-compute ...
/common/processutils.py:147^M
#Result is passed#^M
2014-05-17 04:54:26.662 DEBUG nova.openstack.common.processutils
[req-8d485ab7-4879-42fe-9c6b-d6ffb8dde644 None None] Result was 0 execute
/opt/stack/nova/nova/openstack/common/processutils.py:174^M
result is :('image:
/opt/stack/data/nova/instances/f7d43412-3c5f-46cf-978b-670a29506d89/disk\nfile
format: qcow2\nvirtual size: 1.0G (1073741824 bytes)\ndisk size:
204K\ncluster_size: 65536\nbacking file:
/opt/stack/data/nova/instances/_base/b54371f89f94085a638ff098ed31e0027555eedc\n',
'')^M
#finally condition met^M
2014-05-17 04:54:26.705 DEBUG nova.compute.resource_tracker
[req-8d485ab7-4879-42fe-9c6b-d6ffb8dde644 None None] Hypervisor: free ram
(MB): 5449 _report_hypervisor_resource_view
/opt/stack/nova/nova/compute/resource_tracker.py:388^M
2014-05-17 04:54:26.706 DEBUG nova.compute.resource_tracker
[req-8d485ab7-4879-42fe-9c6b-d6ffb8dde644 None None] Hypervisor: free disk
(GB): 95 _report_hypervisor_resource_view
/opt/stack/nova/nova/compute/resource_tracker.py:389^M
2014-05-17 04:54:26.706 DEBUG nova.compute.resource_tracker
[req-8d485ab7-4879-42fe-9c6b-d6ffb8dde644 None None] Hypervisor: free
VCPUs: 24 _report_hypervisor_resource_view
/opt/stack/nova/nova/compute/resource_tracker.py:394^M
2014-05-17 04:54:26.707 DEBUG nova.compute.resource_tracker
[req-8d485ab7-4879-42fe-9c6b-d6ffb8dde644 None None] Hypervisor: assignable
PCI devices: [] _report_hypervisor_resource_view
/opt/stack/nova/nova/compute/resource_tracker.py:401^M
2014-05-17 04:54:26.708 DEBUG nova.openstack.common.rpc.amqp
[req-8d485ab7-4879-42fe-9c6b-d6ffb8dde644 None None] Making synchronous
call on conductor ... multicall
/opt/stack/nova/nova/openstack/common/rpc/amqp.py:553^M
I'm using mini.iso for ppc64 as a VM for booting onto the compute node from
the below link...
https://help.ubuntu.com/community/Installation/MinimalCD
However when I'm trying to launch a VM onto x86 compute node with mini.iso
as VM from the above link for x86 machine,the status of VM is ACTIVE and
below are the nova-compute logs..
t/stack/nova/nova/openstack/common/processutils.py:188^M
#Result is passed#^M
result is :('', '')^M
#finally condition met^M
2014-05-17 14:07:13.701 DEBUG nova.network.linux_net
[req-d0effb91-f036-45d5-b212-18dea1bd1e19 admin admin] Net device removed:
'qvod42ac663-a4' delete_net_dev
/opt/stack/nova/nova/network/linux_net.py:1358^M
2014-05-17 14:07:13.744 DEBUG nova.objects.instance
[req-d0effb91-f036-45d5-b212-18dea1bd1e19 admin admin] Lazy-loading
`system_metadata' on Instance uuid b2257f51-56c1-4464-ba1e-b24e44cbaba9
obj_load_attr /opt/stack/nova/nova/objects/instance.py:519^M
2014-05-17 14:07:13.801 INFO nova.virt.libvirt.driver
[req-d0effb91-f036-45d5-b212-18dea1bd1e19 admin admin] [instance:
b2257f51-56c1-4464-ba1e-b24e44cbaba9] Deleting instance files
/opt/stack/data/nova/instances/b2257f51-56c1-4464-ba1e-b24e44cbaba9^M
2014-05-17 14:07:13.805 INFO nova.virt.libvirt.driver
[req-d0effb91-f036-45d5-b212-18dea1bd1e19 admin admin] [instance:
b2257f51-56c1-4464-ba1e-b24e44cbaba9] Deletion of
/opt/stack/data/nova/instances/b2257f51-56c1-4464-ba1e-b24e44cbaba9
complete^M
2014-05-17 14:07:13.937 DEBUG nova.compute.manager
[req-d0effb91-f036-45d5-b212-18dea1bd1e19 admin admin] [instance:
b2257f51-56c1-4464-ba1e-b24e44cbaba9] Deallocating network for instance
_deallocate_network /
While comparing the logs from the two different compute logs,the value of
result comes out as the only difference.
I'm also attaching the file from where the above logs are coming i.e
/opt/stack/nova/nova/openstack/common/processutils.py.
Please help regarding this.
Thanks
Abhishek Jain
# vim: tabstop=4 shiftwidth=4 softtabstop=4
# Copyright 2011 OpenStack Foundation.
# All Rights Reserved.
#
#Licensed under the Apache License, Version 2.0 (the License); you may
#not use this file except in compliance with the License. You may obtain
#a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
#Unless required by applicable law or agreed to in writing, software
#distributed under the License is distributed on an AS IS BASIS, WITHOUT
#WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
#License for the specific language governing permissions and limitations
#under the License.
System-level utilities and helper functions.
import logging as stdlib_logging
import os
import random
import shlex
import signal
from eventlet.green import subprocess
from eventlet import greenthread
from nova.openstack.common.gettextutils import _ # noqa
from
Re: [openstack-dev] [Ironic] no team meeting this monday
Hi Devananda Can you please help regarding my openstack issue? On Sat, May 17, 2014 at 6:44 PM, Devananda van der Veen devananda@gmail.com wrote: Since many folks are flying home this weekend, and will probably need a few days to recover from the conference, we're going to skip this Monday's meeting. We all got a lot of design and planning done during the week, so stay tuned to the mailing list for some discussions/announcements! Regards, Devananda ___ 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
Re: [openstack-dev] Openstack access with Java SDKs
On 05/13/2014 11:46 AM, Matthew Farina wrote: Vikas, That's a great question. I was on vacation so it took me a little time to respond. If you use the OpenStack provider in jclouds you should be able to work against OpenStack clouds from different providers. You won't have access to any proprietary extensions. The package that seems to be getting the most development and support is jclouds. See http://developer.openstack.org/ for more details. If you're curious about other languages I can speak to some of those as well. oVirt happens to use/contribute to openstack-java-sdk. unlike jclouds its not an abstraction library (i think the right architecture would have been for jclouds to use openstack-java-sdk...) - Matt On Mon, May 5, 2014 at 10:50 PM, Vikas Kokare vikaskok...@gmail.com mailto:vikaskok...@gmail.com wrote: I am looking for a standard, seamless way to access OpenStack APIs , most likely using the Java SDKs that are summarized at https://wiki.openstack.org/wiki/SDKs#Software_Development_Kits There are various distributions of Openstack available today. Is this possible using these SDK's to write an application that works seamlessly across distributions? If the answer to the above is yes, then how does one evaluate the pros/cons of these SDK's? -Vikas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto: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
[openstack-dev] BluePrint Lifecycle info
Hey Everybody, I had some questions from some folks about BluePrints in Launchpad and the process of getting them approved. As a refresher I thought I'd point out that there's a WIKI page on this very topic here [1]. In addition, Cinder is lagging but we are in the process of moving to using Specs (just submitted the repo creation to gerrit here [2]) but that doesn't apply to folks that already have submissions. I'll get some docs on the wiki around this when it's in place. Thanks, John [1] https://wiki.openstack.org/wiki/Blueprints [2] https://review.openstack.org/#/c/94035/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Approval process for Cinder Blueprints
On Wed, May 14, 2014 at 1:35 PM, Steven Sonnenberg steven.sonnenb...@hds.com wrote: Hi John, Can you please explain to me how the approval process for blueprints works. I have seen blueprints waiting for 6 or more months for approval, and others get approved rapidly (especially if they are from SolidFire). Please explain how this is supposed to work. Thanks, -steve Hi Steve, Some BluePrints come with communication, in other words the folks that are interested in working on them tend to communicate with the rest of the team and the Community which helps quite a bit. To be clear, I'm not sure what the comment regarding especially SolidFire was meant to be taken as, but I can assure you that an individual's affiliation has nothing to do with BluePrint approval (and frankly I'm not aware that there was significant BluePrint activity from SolidFire so that seems odd as well). If on the other hand they communicate with the Cinder team they have a much higher chance of something being approved rather than rotting away and being missed. I would also like to point out that we are in the process of changing the approval system to try and address exactly this sort of situation. We're moving towards using a specs submission via Gerrit to try and get better organization and visibility of the BluePrints. I did approve a couple of HDS BluePrints last night, however I must be missing some, as I only found 2. One other thing to keep in mind, there's an awful lot of activity around BluePrints, Submissions and reviews. It's not uncommon for myself and other Cinder core team members to miss something. You can actually help with this, you can help with reviews, bug triage and Blue Print reviews, and work with the rest of the team to prioritize and get things moving along faster. Finally, I'd also like to point out that waiting for approval on a BluePrint should not necessarily preclude you from working on something. I've added openstack-dev to the CC list here, you'll have much better luck getting help from folks (including this list) by posting via this list. Let me know which BluePrints have been missed, and of course if there's been any work done on them in the six months since they were submitted. Be patient if you could and communicate via the ML or IRC. I'm only one person and there are is an extremely high volume of BluePrints that get dropped in LaunchPad with zero communication. As a result things get missed, but if you communicate and give me a heads up we have a better chance at being successful. Thanks, John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] A VM with multiple images that boot off a non-first image
Hi all, I have the need to support a VM which (a) comprises multiple disk images, and (b) boots off a disk which is not the first disk. I've read the docs, played with: nova boot --image (and also --ephemeral) nova boot --block-device-mapping nova boot --block-device and its boot_index and I think that what I need is something like this: nova boot --block-device=diskimage0,type=?? \ --block-device=diskimage1,type=?? \ --block-device=diskimage2,type=??,boot-index=0 On Havana h1 at least, all that seems to do is to rename the boot device from vda to vdc. I see several launchpad entries in this vague area, but am left wondering if this is beyond what is actually possible even in Icehouse (which I have not yet tried). Any clues welcomed. Thanks, Shaheed P.S. AFAIK, I am not interested in anything which is volume-centric in the first instance, as I need the same images to be loaded by multiple instances. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Haproxy configuration options
We are considering the following connection chain: - HAProxy - stunnel -OS services bound to 127.0.0.1 Virtual IP server IP localhost 127.0.0.1 secure SSL terminate unsecure In this chain none of the ports need to changed. One of the major issues I have come across is the hard coding of the Keystone ports in the OpenStack service's configuration files. With the above connection scheme none of the ports need to change. Mark -Original Message- From: Gregory Haynes [mailto:g...@greghaynes.net] Sent: Friday, May 16, 2014 9:25 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [TripleO] Haproxy configuration options On Fri, May 16, 2014, at 02:52 AM, Jan Provazník wrote: On 05/12/2014 10:35 AM, Dmitriy Shulyak wrote: Adding haproxy (or keepalived with lvs for load balancing) will require binding haproxy and openstack services on different sockets. Afaik there is 3 approaches that tripleo could go with. Consider configuration with 2 controllers: haproxy: nodes: - name: controller0 ip: 192.0.2.20 - name: controller1 ip: 192.0.2.21 1. Binding haproxy on virtual ip and standard ports haproxy: services: - name: horizon proxy_ip: 192.0.2.22 (virtual ip) port: 80 proxy_port: 80 - name: neutron proxy_ip: 192.0.2.22 (virtual ip) proxy_port: 9696 port: 9696 Pros: - No additional modifications in elements is required Actually openstack services elements have to be updated to bind to local address only. Another big issue with this set up is dealing with changes to interfaces on the box. We would have to detect when a new interface is added, and have the app-specific logic to make the application aware of the new interface (typically just editing the app's config file isn't enough for this). Note that this is not an issue when an app binds to 0.0.0.0. HA-Proxy version 1.4.24 2013/06/17 What was the reason this approach was dropped? IIRC the major reason was that having 2 services on same port (but different interface) would be too confusing for anyone who is not aware of this fact. 2. Haproxy listening on standard ports, services on non-standard haproxy: services: - name: horizon proxy_ip: 192.0.2.22 (virtual ip) port: 8080 proxy_port: 80 - name: neutron proxy_ip: 192.0.2.22 (virtual ip) proxy_port: 9696 port: 9797 Pros: - No changes will be required to init-keystone part of workflow - Proxied services will be accessible on accustomed ports Bear in mind that we already use not-standard SSL ports for public endpoints. Also extra work will be required for setting up stunnels (element openstack-ssl). - No changes to configs where services ports need to be hardcoded, for example in nova.conf https://review.openstack.org/#/c/92550/ Cons: - Config files should be changed to add possibility of ports configuration Another cons is also updating selinux and firewall rules for each node. Also Iptables rules. On the plus side, these ports should *really* be configurable anyway. 3. haproxy on non-standard ports, with services on standard haproxy: services: - name: horizon proxy_ip: 192.0.2.22 (virtual ip) port: 8080 proxy_port: 80 - name: neutron proxy_ip: 192.0.2.22 (virtual ip) proxy_port: 9797 port: 9696 Notice that i changed only port for neutron, main endpoint for horizon should listen on default http or https ports. Agree that having 2 service ports switched in other way than other is sub-optimal. +1 on this solution being the least preferred - we shouldn't be pushing the extra configuration work onto our clients. Basicly it is opposite to 2 approach. I would prefer to go with 2, cause it requires only minor refactoring. Thoughts? Options 2 and 3 seem quite equal based on pros vs cons. Maybe we should reconsider option 1? Jan ___ 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
Re: [openstack-dev] [cinder], [cinder-driver] Request for new cinder driver
On 11:50 Tue 13 May , Mardan Raghuwanshi wrote: Hello Team, We develop cinder driver and supporting minimum features, but our driver are not the part of openstack release. We also created blueprint for it. I would like to understand the process to push the cinder driver with the official release of openstack. What are the pre-requisites one needs to fulfill to be part of the openstack release? so I'm looking at a clear procedure required to be qualified to be a part of the openstack release? Please let me know. Thanks, Mardan Hi Mardan, Welcome to the community! Cinder has a doc on minimum features [1] that are required to be in the Cinder tree. These are features that are available from the VolumeDriver class in cinder.volume.driver that should be implemented by your driver class. There are docs on submitting code to gerrit [2], how to form your commit messages [3] It has just been discussed at the design summit this week that we will be requiring new drivers to provide a CI hooked up to their real backend solution to run once a day to provide results of working on the current state of tree. [4]. We should have polished up documentation sometime next week, and will reply to this thread once that's done. For now, you can read about how the OpenStack CI works and how you would setup your own external system. [5][6][7] [1] - http://docs.openstack.org/developer/cinder/devref/drivers.html [2] - https://wiki.openstack.org/wiki/Gerrit_Workflow [3] - https://wiki.openstack.org/wiki/GitCommitMessages [4] - https://etherpad.openstack.org/p/juno-cinder-3rd-party-cert-and-verification [5] - http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/ [6] - http://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system-part-2/ [7] - http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/ -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Question about response code of API
On 00:08 Wed 14 May , Trump.Zhang wrote: Hi, all: I find a lot of methods in cinder.api.contrib.* return 202 code instead of 200, even when these methods only involve database operation, which are not async process. For example, cinder.api.contrib.types_extra_specs.\ VolumeTypeExtraSpecsController:delete, cinder.api.contrib.volume_actions.\ VolumeActionsController:_reserve, etc. From the HTTP/1.1 Status Code Definitions [1], 202 means Accepted, i.e. the request has been accepted for processing, but the processing has not been completed. Are these response codes are returned by mistake? If it's just a db operation, that sounds like a mistake. Unfortunately, we have not spent time on dealing with versioned extensions to easily deal with this. https://wiki.openstack.org/wiki/APIChangeGuidelines -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Logging exceptions and Python 3
On Fri, May 16, 2014, Victor Stinner victor.stin...@enovance.com wrote: See my documentation: https://wiki.openstack.org/wiki/Python3#logging_module_and_format_exceptions six.text_type(exc): always use Unicode. It may raise unicode error depending on the exception, be careful. Example of such error in python 2: unicode(Exception(nonascii:\xe9)). unicode(exc) works with such exception classes: --- class MyException1(Exception): pass exc = MyException1() exc.message = u\u20ac unicode(exc) #ok class MyException2(Exception): def __unicode__(self): return u\20ac exc = MyException2() unicode(exc) #ok --- If we want to format an exception as Unicode, we need a function trying unicode(), or use str() and then guess the encoding. It means adding a new safe function to Olso to format an exception. This is unnecessarily complicated. Strings should be decoded to unicode as soon as possible. When a request is read from a user, it should be decoded to a unicode type. When it's read from a file, it should be decoded to a unicode type. Nothing should be stored internally as an encoded string. If a third party library raises exceptions with strings in an encoding other than ASCII, they should be shot :) JE ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Logging exceptions and Python 3
On Fri, May 16, 2014, Igor Kalnitsky ikalnit...@mirantis.com wrote: unicode(exc) (or six.text_type(exc)) works for all exceptions, built-in or custom. That's too much of a statement. Sometimes exceptions implement their own __str__ / __unitcode__ methods, that return too many rubbish information or not enough. What do you do in that case? I don't understand the problem. What are you expecting from unicode(exc)? What exceptions don't meet that expectation? Using str(exc) or unicode(exc) is the standard Python convention to get a useful string out of an exception. This is what the traceback module does (at least in Python 2.7) for the last line in the traceback output. It tries str first, then unicode if str fails. If it uses unicode, then it backslash escapes it back to ASCII. The behavior to try str first and then unicode second appears to be because of legacy reasons. I'm not entirely sure why it backslash escapes unicode back to ASCII. Maybe to avoid a possible second exception when printing it? JE ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [barbican] Juno roadmap items
Hello folks, An etherpad capturing potential CRs for the Juno release is available here: https://etherpad.openstack.org/p/barbican-juno-roadmap Suggestions/corrections are welcome! Thanks, John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Keystone] Specs repo
While we are waiting to see if the Nova specs process works out, I have started a personal copy of the repo and tailored it to Keystone: https://github.com/admiyo/keystone-specs/ I've made use of it for a Blueprint https://blueprints.launchpad.net/keystone/+spec/crls Which is only partially completed: https://github.com/admiyo/keystone-specs/blob/CRL/specs/juno/OS-SIMPLECERT-CRL.rst ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] Specs repo
An idea. Instead of everyone (cinder, nova, keystone, ...) copying 'tests/test_titles.py' Why not instead use something like https://pypi.python.org/pypi/doc8 which I just published that can do most these *.rst style checks in a way that is more useable and actually reports line numbers and such... The current checks it does: https://github.com/harlowja/doc8/blob/master/scripts/doc8#L23 Seems nicer to use the above (and improve it) instead of duplicating more code across repos. -Original Message- From: Adam Young ayo...@redhat.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Saturday, May 17, 2014 at 7:46 PM To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Subject: [openstack-dev] [Keystone] Specs repo While we are waiting to see if the Nova specs process works out, I have started a personal copy of the repo and tailored it to Keystone: https://github.com/admiyo/keystone-specs/ I've made use of it for a Blueprint https://blueprints.launchpad.net/keystone/+spec/crls Which is only partially completed: https://github.com/admiyo/keystone-specs/blob/CRL/specs/juno/OS-SIMPLECERT -CRL.rst ___ 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
Re: [openstack-dev] [Openstack-dev][Neutron] Port Mirroring Extension in Neutron
Hi, Unfortunately I could not participate in this discussion. As
requested in this thread earlier, it would be good to get a summary of
the discussion.
We, in the advanced services team in Neutron, have long discussed[1]
the possibility of accommodating a tap service. So I would like to
understand if/how this discussion is aligning with that goal.
Thanks,
~Sumit.
[1]
https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering
On Thu, May 15, 2014 at 6:52 PM, Anil Rao anil@gigamon.com wrote:
See you all there tomorrow.
Regards,
Anil
From: Vinay Yadhav [mailto:vinayyad...@gmail.com]
Sent: Thursday, May 15, 2014 12:51 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Openstack-dev][Neutron] Port Mirroring
Extension in Neutron
Hi,
Booked a slot tomorrow at 9:20 AM at the neutron pod.
Cheers,
main(i){putchar((5852758((i-1)/2)*8)-!(1i)*'\r')^89main(++i);}
On Thu, May 15, 2014 at 2:50 PM, Stephen Wong s3w...@midokura.com wrote:
Hi Vinay,
I am interested. Please sign up a slot on Neutron pod for tomorrow
(Friday) and announce the timeslot to the ML.
Thanks,
- Stephen
On Thu, May 15, 2014 at 7:13 AM, Vinay Yadhav vinayyad...@gmail.com wrote:
Hi,
I am Vinay, working with Ericsson.
I am interested in the following blueprint regarding port mirroring
extension in neutron:
https://blueprints.launchpad.net/neutron/+spec/port-mirroring
I am close to finishing an implementation for this extension in OVS plugin
and would be submitting a neutron spec related to the blueprint soon.
I would like to know other who are also interested in introducing Port
Mirroring extension in neutron.
It would be great if we can discuss and collaborate in development and
testing this extension
I am currently attending the OpenStack Summit in Atlanta, so if any of you
are interested in the blueprint, we can meet here in the summit and discuss
how to proceed with the blueprint.
Cheers,
main(i){putchar((5852758((i-1)/2)*8)-!(1i)*'\r')^89main(++i);}
___
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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
