Re: [openstack-dev] [Openstack-dev][Neutron] Port Mirroring Extension in Neutron

2014-05-17 Thread Stephen Wong 
Hi Sumit,

Srinivasa has agreed to join the advanced service meeting to kick off
the discussion on this topic at our regular meeting[1]. Looking forward to
working with him and others that are interested in getting this "tap"
service effort started in Neutron.

Thanks,
- Stephen


[1]
https://wiki.openstack.org/wiki/Meetings#Neutron_Advanced_Services.27_Common_requirements_team_meeting


On Sat, May 17, 2014 at 9:05 PM, Sumit Naiksatam
wrote:

> 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  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)-!(1&i)*'\r')^89&&main(++i);}
> >
> >
> >
> > On Thu, May 15, 2014 at 2:50 PM, Stephen Wong 
> 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 
> 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)-!(1&i)*'\r')^89&&main(++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
>
___
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

2014-05-17 Thread Sumit Naiksatam 
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  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)-!(1&i)*'\r')^89&&main(++i);}
>
>
>
> On Thu, May 15, 2014 at 2:50 PM, Stephen Wong  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  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)-!(1&i)*'\r')^89&&main(++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

Re: [openstack-dev] [Keystone] Specs repo

2014-05-17 Thread Joshua Harlow 
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 
Reply-To: "OpenStack Development Mailing List (not for usage questions)"

Date: Saturday, May 17, 2014 at 7:46 PM
To: OpenStack Development Mailing List 
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

[openstack-dev] [Keystone] Specs repo

2014-05-17 Thread Adam Young 
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] [barbican] Juno roadmap items

2014-05-17 Thread John Wood 
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

Re: [openstack-dev] [oslo] Logging exceptions and Python 3

2014-05-17 Thread Johannes Erdfelt 
On Fri, May 16, 2014, Igor Kalnitsky  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

Re: [openstack-dev] [oslo] Logging exceptions and Python 3

2014-05-17 Thread Johannes Erdfelt 
On Fri, May 16, 2014, Victor Stinner  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] [Cinder] Question about response code of API

2014-05-17 Thread Mike Perez 
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] [cinder], [cinder-driver] Request for new cinder driver

2014-05-17 Thread Mike Perez 
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] [TripleO] Haproxy configuration options

2014-05-17 Thread Miller, Mark M (EB SW Cloud - R&D - Corvallis) 
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

[openstack-dev] A VM with multiple images that boot off a non-first image

2014-05-17 Thread Shaheed Haque 
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] Approval process for Cinder Blueprints

2014-05-17 Thread John Griffith 
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] BluePrint Lifecycle info

2014-05-17 Thread John Griffith 
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] Openstack access with Java SDKs

2014-05-17 Thread Itamar Heim 

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 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

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] [Ironic] no team meeting this monday

2014-05-17 Thread sonia verma 
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

[openstack-dev] [Ironic] no team meeting this monday

2014-05-17 Thread Devananda van der Veen 
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] nova-compute

2014-05-17 Thread abhishek jain 
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 nova.open