Re: [openstack-dev] Congrats (I think) to the new TC

[Maish Saidel-Keesing]

On 04/30/15 16:40, Jay Pipes wrote:

On 04/30/2015 09:26 AM, David Medberry wrote:

Hey guys,

Congrats to the new TC leaders.

http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ef1379fee7b94688

Please reach out to me (and openstack-operat...@lists.openstack.org
) if you ever need
operator input (that you aren't already getting.)

And many thanks for volunteering so much of your time this go round


I *most* certainly will be reaching out to you, David. First up on the 
operator-related docket for me will be tags that represent 
production-level maturity. I have always maintained the the TC should 
help create the tag definition with the help of the operator community 
and rely on the operator community to determine which projects can get 
the tag applied to them. I hope you will be an instrument in achieving 
that collaboration.


All the best,
-jay

A huge congratulations from me as well.
I would also like to offer my help from an operator perspective and 
perhaps I can also help with the tasks that were discussed regarding 
finding a way to get the information out there to those who are not 
'OpenStack savvy' or 'strong with the OpenStack force' .


I have learned a lot from this election, the process, the candidates, 
the active members of the community, and also from the results. I 
definitely think we are on the right path. Rome was not built in a day, 
peace in the middle east will not come for another 1000 years and 
changes take time.


--
Best Regards,
Maish Saidel-Keesing

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Deadline for submitting Nova Design Summit Session Proposals

[John Garbutt]

Hi,

In case you were unable to make yesterday's Nova meeting...

If you have a suggestion for a Nova design summit session, please
ensure you add it to before the next Nova meeting (7th May):
https://etherpad.openstack.org/p/liberty-nova-summit-ideas

Shortly after that Nova meeting, the (mostly) final schedule will be
uploaded here:
http://libertydesignsummit.sched.org/type/design+summit/Nova

Priority will be given to issues where need to build a consensus on
the way forward with the whole community. We had a nova-drivers
meeting to agree on a provisional list of sessions, based on suggested
sessions at the time. You can see that list at the very end of the
summit ideas etherpad.

If you have a feature you want feedback on, please submit a nova-spec,
in the usual way. We have scheduled some 'unconference' time to
discuss stuck nova-spec reviews. We will fill up those slots during
the week of the summit.

In addition to the scheduled fishbowl sessions, and unconference
slots, just like in Paris, all day Friday will be a nova contributor
meetup. We are collecting topics for the meetup on this etherpad:
https://etherpad.openstack.org/p/liberty-nova-summit-meetup

Notice I have scheduled the first 40 mins after lunch on Friday for
individual sub team discussions, designed to replace the fishbowl virt
driver sessions we have done previously. We can decide how that will
work, and if its needed, on Friday morning.

Any questions, or ideas, please let me know, and I will do my best to help.

Thanks,
johnthetubaguy

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Blueprints and Specs for Liberty Deadline

[John Garbutt]

Hi,

Just a quick reminder that blueprints and nova-specs need to be
approved for liberty, even if they have already been approved for a
previous release.

I added deadline in the subject mostly just to get your attention. We
haven't agreed a deadline for spec and blueprint submissions yet, but
expect it to be near liberty-1:
https://wiki.openstack.org/wiki/Liberty_Release_Schedule


As with kilo, not all blueprints will need a spec, for details please see:
http://docs.openstack.org/developer/nova/devref/kilo.blueprints.html

If you think your blueprint doesn't need a spec, but you want to get
it approve for liberty, please add a link to your blueprint to the
agenda for the next nova-meeting:
https://wiki.openstack.org/wiki/Meetings/Nova

If you want to get your nova-spec reviewed for liberty, please submit
that ASAP. Ideally before the summit, so any problems that come up
during the review can be discussed at the summit.

We already have lots of approved blueprints that are up for review:
https://blueprints.launchpad.net/nova/liberty

Please note we are not attempting to predict what features will land
in each milestone during liberty. For more details please see:
https://wiki.openstack.org/wiki/Release_Cycle_Management/Liberty_Tracking


Any questions around process, please just ask, and I can help you move
forward. Asking sooner helps us fix the problem sooner.


Thanks,
johnthetubaguy

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Manila] Mount automation using Zeroconf

[Ben Swartzlander]

On 05/01/2015 12:54 AM, Deepak Shetty wrote:

Hi,
  Have we considered cloud-init and qemu guest agent, I remember there 
was some discussion around this

in the prev summit, but i couldn't find any etherpad/notes on that.

I had one more question in this regards. Is it possible to do some 
kind of VM hotplug add operation as part of manila
access allow which will cause the VM to see a new drive with a 
pre-specified label and a client inside the VM will

mount it as part of the udev/uevent ?


The only way to get hotplug working for shares (that I know of) would be 
to use virtfs. In that case the hypervisor would mount the share and 
present it to the guest through a p9fs/virtio tunnel. This would be 
pretty cool but also has a bunch of disadvantages:

* Doesn't work w/ Windows guests
* Doesn't work with hypervisors other than qemu/xen
* p9fs semantics are different than native nfs/cifs to the client
   * Some apps are coded to use NFS directly (not through the OS's 
built in nfs client)

   * Many apps are tested/qualified with NFS/CIFS but not virtfs
   * Locking and FS metadata work significantly differently
* VirtFS appears to be abandonware

If anyone knows of a way other than VirtFS to get cool hotplug 
semantics, I'd love to know. Also, if any of my above assertions are 
false, I'd also love to know about that too.


-Ben Swartzlander


On Tue, Apr 28, 2015 at 11:50 PM, Knight, Clinton 
mailto:clinton.kni...@netapp.com>> wrote:


Thanks, Luis, I agree with your assessment that one good way to
solve this
issue is a publisher-subscriber model.  The publisher would be Manila,
using zeroconf or AMQP or Zaqar (the one I¹m investigating now).  The
subscriber would be a lightweight agent running on the client that
listens
for share availability events and handles the mounts.  One open
question
is whether Manila needs to store a record of client mounts,
without which
it could not influence the mount paths on each client.

Clinton


On 4/27/15, 1:49 PM, "Luis Pabon" mailto:lpa...@redhat.com>> wrote:

>Hi Clinton,
>  I think there are two main parts that are needed to
automatically mount
>Manila shares.  One is the share discovery model, and the other is
>enabling the virtual machine to mount the share.  I think the only
>benefit to using zeroconf would be as a standard way to broadcast
>availability of a network share regardless of protocol.  Manila could
>broadcast the availability of a share by using a name like
_manila_nfs,
>_manila_cifs, _manila_gluster, etc.  Although, even with
zeroconf, the
>virtual machine still requires an agent to be able to attach the
share
>for use.  I think the real benefit of using zeroconf is its
simplicity.
>
>There could still be other methods we can investigate.  For example
>(don't kill me for this ;-)), have a Manila YP NIS service for
NFS shares?
>
>- Luis
>
>
>
>
>- Original Message -
>From: "Clinton Knight" mailto:clinton.kni...@netapp.com>>
>To: "OpenStack Development Mailing List (not for usage questions)"
>mailto:openstack-dev@lists.openstack.org>>
>Sent: Wednesday, April 22, 2015 3:29:50 PM
>Subject: [openstack-dev] [Manila] Mount automation using Zeroconf
>
>Hello, Manila-philes.
>
>Back in Paris we started talking about Manila mount automation,
whereby
>file shares could be automatically mounted on clients, and this will
>likely be a topic in Vancouver. So in order to have an informed
>discussion at the summit, I'd like to explore a few things
beforehand.
>
>Besides brute force approaches like SSH or PsExec, one of the
community
>suggestions was to use Zeroconf (aka Bonjour)[1]. Zeroconf sounds
>attractive on the surface, but it seems to have a number of
limitations:
>
>* No standard way to specify local mount point
>* Additional setup required to work beyond the 'local' domain
>* Custom software needed on clients to mount advertised shares
>* Same issues with network connectivity as any other mount automation
>solution
>
>Does anyone have a clearer idea how Zeroconf might satisfy the
need for
>Manila mount automation?
>
>Thanks,
>Clinton Knight
>Manila core team
>
>[1] http://en.wikipedia.org/wiki/Zero-configuration_networking
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>__
>OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [nova] Proposal to add Melanie Witt to nova-core

[Ken'ichi Ohmichi]

+1 :)

2015-04-30 20:30 GMT+09:00 John Garbutt :
> Hi,
>
> I propose we add Melanie to nova-core.
>
> She has been consistently doing great quality code reviews[1],
> alongside a wide array of other really valuable contributions to the
> Nova project.
>
> Please respond with comments, +1s, or objections within one week.
>
> Many thanks,
> John
>
> [1] https://review.openstack.org/#/dashboard/4690
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum] Proposal for Madhuri Kumari to join Core Team

[Madhuri Rai]

Hi All,

Thank you for adding me to this team.

It will be my pleasure to work with you all together.
Till now, everyone has helped me in many or some way.

Thank you for all the support and this honor.

Looking forward for contributing more.


Thanks & Regards
Madhuri Kumari

On Fri, May 1, 2015 at 10:25 AM, Adrian Otto 
wrote:

>  Team,
>
>  Madnuri has been added to the magnum-core group [1]. Thanks everyone for
> your votes.
>
>  Regards,
>
>  Adrian
>
>  [1] https://review.openstack.org/#/admin/groups/473,members
>
>  On Apr 30, 2015, at 8:48 PM, Hongbin Lu  wrote:
>
>  +1!
>
> On Apr 28, 2015, at 11:14 PM, "Steven Dake (stdake)" 
> wrote:
>
>  Hi folks,
>
>  I would like to nominate Madhuri Kumari  to the core team for Magnum.
> Please remember a +1 vote indicates your acceptance.  A –1 vote acts as a
> complete veto.
>
>  Why Madhuri for core?
>
>1. She participates on IRC heavily
>2. She has been heavily involved in a really difficult project  to
>remove Kubernetes kubectl and replace it with a native python language
>binding which is really close to be done (TM)
>3. She provides helpful reviews and her reviews are of good quality
>
> Some of Madhuri’s stats, where she performs in the pack with the rest of
> the core team:
>
>  reviews: http://stackalytics.com/?release=kilo&module=magnum-group
> commits:
> http://stackalytics.com/?release=kilo&module=magnum-group&metric=commits
>
>  Please feel free to vote if your a Magnum core contributor.
>
>  Regards
> -steve
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>  __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Manila] Mount automation using Zeroconf

[Fox, Kevin M]

Hmm The cinder volumes dont automount either. /dev/vdx shows up, but you 
have to format/mount it yourself.

Maybe both teams could share a common solution? Im guessing it will have to be 
an agent...

Thanks,
Kevin


From: Deepak Shetty
Sent: Thursday, April 30, 2015 9:54:31 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Manila] Mount automation using Zeroconf

Hi,
  Have we considered cloud-init and qemu guest agent, I remember there was some 
discussion around this
in the prev summit, but i couldn't find any etherpad/notes on that.

I had one more question in this regards. Is it possible to do some kind of VM 
hotplug add operation as part of manila
access allow which will cause the VM to see a new drive with a pre-specified 
label and a client inside the VM will
mount it as part of the udev/uevent ?

On Tue, Apr 28, 2015 at 11:50 PM, Knight, Clinton 
mailto:clinton.kni...@netapp.com>> wrote:
Thanks, Luis, I agree with your assessment that one good way to solve this
issue is a publisher-subscriber model.  The publisher would be Manila,
using zeroconf or AMQP or Zaqar (the one I¹m investigating now).  The
subscriber would be a lightweight agent running on the client that listens
for share availability events and handles the mounts.  One open question
is whether Manila needs to store a record of client mounts, without which
it could not influence the mount paths on each client.

Clinton


On 4/27/15, 1:49 PM, "Luis Pabon" mailto:lpa...@redhat.com>> 
wrote:

>Hi Clinton,
>  I think there are two main parts that are needed to automatically mount
>Manila shares.  One is the share discovery model, and the other is
>enabling the virtual machine to mount the share.  I think the only
>benefit to using zeroconf would be as a standard way to broadcast
>availability of a network share regardless of protocol.  Manila could
>broadcast the availability of a share by using a name like _manila_nfs,
>_manila_cifs, _manila_gluster, etc.  Although, even with zeroconf, the
>virtual machine still requires an agent to be able to attach the share
>for use.  I think the real benefit of using zeroconf is its simplicity.
>
>There could still be other methods we can investigate.  For example
>(don't kill me for this ;-)), have a Manila YP NIS service for NFS shares?
>
>- Luis
>
>
>
>
>- Original Message -
>From: "Clinton Knight" 
>mailto:clinton.kni...@netapp.com>>
>To: "OpenStack Development Mailing List (not for usage questions)"
>mailto:openstack-dev@lists.openstack.org>>
>Sent: Wednesday, April 22, 2015 3:29:50 PM
>Subject: [openstack-dev] [Manila] Mount automation using Zeroconf
>
>Hello, Manila-philes.
>
>Back in Paris we started talking about Manila mount automation, whereby
>file shares could be automatically mounted on clients, and this will
>likely be a topic in Vancouver. So in order to have an informed
>discussion at the summit, I'd like to explore a few things beforehand.
>
>Besides brute force approaches like SSH or PsExec, one of the community
>suggestions was to use Zeroconf (aka Bonjour)[1]. Zeroconf sounds
>attractive on the surface, but it seems to have a number of limitations:
>
>* No standard way to specify local mount point
>* Additional setup required to work beyond the 'local' domain
>* Custom software needed on clients to mount advertised shares
>* Same issues with network connectivity as any other mount automation
>solution
>
>Does anyone have a clearer idea how Zeroconf might satisfy the need for
>Manila mount automation?
>
>Thanks,
>Clinton Knight
>Manila core team
>
>[1] http://en.wikipedia.org/wiki/Zero-configuration_networking
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: 
>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: 
>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-

Re: [openstack-dev] [octavia] Joining Neutron under the big tent

[Kyle Mestery]

On Thu, Apr 30, 2015 at 5:17 PM, Eichberger, German <
german.eichber...@hp.com> wrote:

> Hi,
>
> I am proposing that Octavia is joining the Networking program as a project
> under the Services area.
>
> Octavia is the open scalable reference implementation for Neutron LBaaS V2
> and has always seen itself as part of the networking program. We have
> adopted most governance rules from the Networking program, sharing the
> same build structure, and are organized like an OpenDStack project.
>
>
This sounds fine to me German. To proceed here, propose something similar
to what Russell has proposed for OVN here [1], and ping me on IRC with the
review so I can ack it. The TC can then approve it at a future meeting.

Thanks!
Kyle

[1] https://review.openstack.org/#/c/175954/

Thanks,
> German
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] Change for automatic translation import

[Andreas Jaeger]

Our PO files contain information about location (filename and line
numbers) as well as untranslated strings. Dolph suggested to me recently 
to import into projects only the *translated* strings and I did some 
investigation and implementation after discussion with the translation 
team [1] - with the goal to decrease the size of these changes.


We will continue to push the full location information to transifex (our 
translation tool) and leave it in the POT files that are stored in each 
repository.


During the import from transifex into the OpenStack git repositories,
our scripts remove the location information from the PO files as well as 
any untranslated strings thus reducing the files to import 
significantly. This also reduces the change of an import significantly 
since a line number change will not cause many location information to 
be updated.


The gettext tools we use can cope fine with this smaller PO file since
it contains everything that is needed - just nothing more ;)

This has been tested successfully on the Documentation repositories and 
now [2] has merged for the python projects that are translated. A 
separate patch for horizon is under review [3].


The next import for translation will be larger than normal - it removes 
lots of untranslated lines and the location information. Further patches 
will then be smaller. So, don't be surprised by the next import [4] 
(tomorrow),


Andreas

[1] 
http://lists.openstack.org/pipermail/openstack-i18n/2015-April/001061.html

[2] https://review.openstack.org/176947
[3] https://review.openstack.org/176943
[4] 
https://review.openstack.org/#/q/status:open++branch:master+topic:transifex/translations,n,z


--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
   Graham Norton, HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Are routed TAP interfaces (and DHCP for them) in scope for Neutron?

[Neil Jerram]

Thanks for your reply, Kevin, and sorry for the delay in following up.

On 21/04/15 09:40, Kevin Benton wrote:

Is it compatible with overlapping IPs? i.e. Will it give two different
VMs the same IP address if the reservations are setup that way?


No, not as I've described it below, and as we've implemented Calico so 
far.  Calico's first target is a shared address space without 
overlapping IPs, so that we can handle everything within the default 
namespace.


But we do also anticipate a future Calico release to support private 
address spaces with overlapping IPs, while still routing all VM data 
rather than bridging.  That will need the private address TAP interfaces 
to go into a separate namespace (per address space), and have their data 
routed there; and we'd run a Dnsmasq in that namespace to provide that 
space's IP addresses.


Within each namespace - whether the default one or private ones - we'd 
still use the other changes I've described below for how the DHCP agent 
creates the ns-XXX interface and launches Dnsmasq.


Does that make sense?  Do you think that this kind of approach could be 
in scope under the Neutron umbrella, as an alternative to bridging the 
TAP interfaces?


Thanks,
Neil



On 16/04/15 15:12, Neil Jerram wrote:

I have a Neutron DHCP agent patch whose purpose is to launch dnsmasq
with options such that it works (=> provides DHCP service) for TAP
interfaces that are _not_ bridged to the DHCP interface (ns-XXX).  For
the sake of being concrete, this involves:

- creating the ns-XXX interface as a dummy, instead of as a veth pair

- launching dnsmasq with --bind-dynamic --listen=ns-XXX --listen=tap*
--bridge-interface=ns-XXX,tap*

- not running in a separate namespace

- running the DHCP agent on every compute host, instead of only on the
network node

- using the relevant subnet's gateway IP on the ns-XXX interface (on
every host), instead of allocating a different IP for each ns-XXX
interface.

I proposed a spec for this in the Kilo cycle [1], but it didn't get
enough traction, and I'm now wondering what to do with this
work/function.  Specifically, whether to look again at integrating it
into Neutron during the Liberty cycle, or whether to maintain an
independent DHCP agent for my project outside the upstream Neutron tree.
   I would very much appreciate any comments or advice on this.

For answering that last question, I suspect the biggest factor is
whether routed TAP interfaces - i.e. forms of networking implementation
that rely on routing data between VMs instead of bridging it - is in
scope for Neutron, at all.  If it is, I understand that there could be a
lot more detail to work on, such as how it meshes with other Neutron
features such as DVR and the IPAM work, and that it might end up being
quite different from the blueprint linked below.  But it would be good
to know whether this would ultimately be in scope and of interest for
Neutron at all.

Please do let me now what you think.

Many thanks,
  Neil

[1] https://blueprints.launchpad.net/neutron/+spec/dhcp-for-routed-ifs


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Deadline for submitting Nova Design Summit Session Proposals

[Neil Jerram]

On 01/05/15 11:44, John Garbutt wrote:

Hi,

In case you were unable to make yesterday's Nova meeting...


I was there, but still a bit shy and retiring... :-)


If you have a suggestion for a Nova design summit session, please
ensure you add it to before the next Nova meeting (7th May):
https://etherpad.openstack.org/p/liberty-nova-summit-ideas


I've just added something, about "getting Nova out of the networking 
business" by providing a basic set of VIF types and a mechanism like 
vif-plugin-script.


It's my first time editing an etherpad, and also my first suggestion for 
an OpenStack summit - so I may have done it all wrong, but would 
appreciate any feedback on how to correct that if so.  Please be gentle!


Regards,
Neil

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] [docs] Scheduler filters documentation

[Anne Gentle]

On Wed, Apr 29, 2015 at 8:00 PM, Jay Pipes  wrote:

> On 04/29/2015 03:41 PM, Ed Leafe wrote:
>
>> On Apr 29, 2015, at 2:30 PM, Matt Riedemann
>>  wrote:
>>
>>  I'd prefer to see the scheduler filter docs be maintained in the
>>> nova devref where they are close to the source, versioned, and
>>> reviewed by the nova team when there are scheduler filter changes
>>> or new filters added.
>>>
>>
>> For now, I think this is best. When and if the scheduler is a
>> separate entity, it will need its own docs; nova will still need to
>> document *its* filters, but not *how to* filter.
>>
>
> So, the config-ref docs are auto-generated continually via automation
> scripts from the help text of options. And, IMO, this is A Good Thing.
>
> In this case, the end user of this information is the cloud admin -- the
> person who creates flavors and tags compute nodes with capability extra
> specs. The target audience for this information is not really the Nova
> developer.
>
> Now, if there are sections of the devref that need to inform the
> *developer* about some weird intricacies of the scheduler filters (and
> frankly, this is kind of one of them), then I think it's OK to have
> slightly duplicate information. It depends on the target audience. In this
> particular case, I think it's fine to duplicate a little.
>
>
Right, to me this is the right approach, thanks Jay. I say this because
here are the stats for each page, showing where your audience is.

10,473 page views in six months:[1]
http://docs.openstack.org/juno/config-reference/content/section_compute-
scheduler.html#aggregate-instanceextraspecsfilter
5,143 page views in same six months:
[2] http://docs.openstack.org/developer/nova
/devref/filter_scheduler.html#filtering


> Best,
> -jay
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Anne Gentle
annegen...@justwriteclick.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova-docker] Status update

[Davanum Srinivas]

Anyone still interested in this work? :)

* there's a stable/kilo branch now (see
http://git.openstack.org/cgit/stackforge/nova-docker/).
* CI jobs are running fine against both nova trunk and nova's
stable/kilo branch.
* there's an updated nova-spec to get code back into nova tree (see
https://review.openstack.org/#/c/128753/)

Thanks,
dims

-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Manila] Mount automation using Zeroconf

[Ben Swartzlander]

On 05/01/2015 09:32 AM, Fox, Kevin M wrote:
Hmm The cinder volumes dont automount either. /dev/vdx shows up, 
but you have to format/mount it yourself.


Maybe both teams could share a common solution? Im guessing it will 
have to be an agent...


That not really true. If the volume is already formatted with a 
filesystem, and the filesystem is listed in the fstab, linux will mount 
it automatically. Same with Windows. Even unlabelled volumes could be 
automatically formatted and mounted with some script inside the guest 
that was watching for the right events.


With shares, even the basic notification is not there, nor is there a 
standard way for a guest to determine what mounts are available out 
there (the equivalent of the existence of the /dev/* files).


We'd like to solve these 2 basic problems in a way that's standard 
across all Manila instances. Of course what consumes that information 
and what happens afterwards would ideally be up the the tenant, and we 
would like to provide a set of samples for popular use cases.


-Ben



Thanks,
Kevin *
*

*From:* Deepak Shetty
*Sent:* Thursday, April 30, 2015 9:54:31 PM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [Manila] Mount automation using Zeroconf

Hi,
  Have we considered cloud-init and qemu guest agent, I remember there 
was some discussion around this

in the prev summit, but i couldn't find any etherpad/notes on that.

I had one more question in this regards. Is it possible to do some 
kind of VM hotplug add operation as part of manila
access allow which will cause the VM to see a new drive with a 
pre-specified label and a client inside the VM will

mount it as part of the udev/uevent ?

On Tue, Apr 28, 2015 at 11:50 PM, Knight, Clinton 
mailto:clinton.kni...@netapp.com>> wrote:


Thanks, Luis, I agree with your assessment that one good way to
solve this
issue is a publisher-subscriber model.  The publisher would be Manila,
using zeroconf or AMQP or Zaqar (the one I¹m investigating now).  The
subscriber would be a lightweight agent running on the client that
listens
for share availability events and handles the mounts.  One open
question
is whether Manila needs to store a record of client mounts,
without which
it could not influence the mount paths on each client.

Clinton


On 4/27/15, 1:49 PM, "Luis Pabon" mailto:lpa...@redhat.com>> wrote:

>Hi Clinton,
>  I think there are two main parts that are needed to
automatically mount
>Manila shares.  One is the share discovery model, and the other is
>enabling the virtual machine to mount the share. I think the only
>benefit to using zeroconf would be as a standard way to broadcast
>availability of a network share regardless of protocol.  Manila could
>broadcast the availability of a share by using a name like
_manila_nfs,
>_manila_cifs, _manila_gluster, etc.  Although, even with
zeroconf, the
>virtual machine still requires an agent to be able to attach the
share
>for use.  I think the real benefit of using zeroconf is its
simplicity.
>
>There could still be other methods we can investigate.  For example
>(don't kill me for this ;-)), have a Manila YP NIS service for
NFS shares?
>
>- Luis
>
>
>
>
>- Original Message -
>From: "Clinton Knight" mailto:clinton.kni...@netapp.com>>
>To: "OpenStack Development Mailing List (not for usage questions)"
>mailto:openstack-dev@lists.openstack.org>>
>Sent: Wednesday, April 22, 2015 3:29:50 PM
>Subject: [openstack-dev] [Manila] Mount automation using Zeroconf
>
>Hello, Manila-philes.
>
>Back in Paris we started talking about Manila mount automation,
whereby
>file shares could be automatically mounted on clients, and this will
>likely be a topic in Vancouver. So in order to have an informed
>discussion at the summit, I'd like to explore a few things
beforehand.
>
>Besides brute force approaches like SSH or PsExec, one of the
community
>suggestions was to use Zeroconf (aka Bonjour)[1]. Zeroconf sounds
>attractive on the surface, but it seems to have a number of
limitations:
>
>* No standard way to specify local mount point
>* Additional setup required to work beyond the 'local' domain
>* Custom software needed on clients to mount advertised shares
>* Same issues with network connectivity as any other mount automation
>solution
>
>Does anyone have a clearer idea how Zeroconf might satisfy the
need for
>Manila mount automation?
>
>Thanks,
>Clinton Knight
>Manila core team
>
>[1] http://en.wikipedia.org/wiki/Zero-configuration_networking
>
>
>__
>Op

Re: [openstack-dev] [octavia] Joining Neutron under the big tent

[Brandon Logan]

?+1 from me


From: Kyle Mestery 
Sent: Friday, May 1, 2015 8:53 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [octavia] Joining Neutron under the big tent

On Thu, Apr 30, 2015 at 5:17 PM, Eichberger, German 
mailto:german.eichber...@hp.com>> wrote:
Hi,

I am proposing that Octavia is joining the Networking program as a project
under the Services area.

Octavia is the open scalable reference implementation for Neutron LBaaS V2
and has always seen itself as part of the networking program. We have
adopted most governance rules from the Networking program, sharing the
same build structure, and are organized like an OpenDStack project.


This sounds fine to me German. To proceed here, propose something similar to 
what Russell has proposed for OVN here [1], and ping me on IRC with the review 
so I can ack it. The TC can then approve it at a future meeting.

Thanks!
Kyle

[1] https://review.openstack.org/#/c/175954/

Thanks,
German



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates

[Joshua Harlow]

Davanum Srinivas wrote:

One concrete suggestion based on my experience working with Kris
Lindgren on Heartbeat patch:
http://markmail.org/message/gifrt5f3mslco24j

I could have added a "Co-Tested-By" (or "Co-Operator" - get it? :) in
my commit message which would have signaled a concrete
contribution/feedback with specific folks in the operator community.
This could be done not just for code, could be for reviews or
documentation etc as well. WDYT?


+1 Kris is a great example, and I can think of other operators that 
should be some sort of ATC (but may not contribute code to get this). 
IMHO any operator running openstack (let's say at least at 50+ compute 
nodes) and operating it should get full access to the summit, because 
their words of advice/experience are just as useful as technical 
contributors...




thanks,
dims

On Thu, Apr 30, 2015 at 9:06 PM, Adam Lawson  wrote:

I think it's easy to quantify a code contributor since we have systems that
monitor activity - who contributed, what they contributed and when. But we
don't have a system that monitors operator activity and honestly, that's the
question mark for which I really don't have any answers. That might be our
first hurdle - how define the difference between a causal user making
remarks on the mailing lists and someone who works with the technology and
engages. We'd have to quantify them differently somehow.

Maybe attending an operators meeting would qualify someone to vote?

On Apr 30, 2015 5:35 PM, "Stefano Maffulli"  wrote:

On Thu, 2015-04-30 at 12:26 +0200, Flavio Percoco wrote:

I've seen the number of threads to discuss Ops topics increase in
openstack-dev and the influence of Ops - even just points of views
inherited from the feedback we've got - on reviews has gotten better
as well.

Fantastic, that has always been the intention.


If it's a matter of having more Ops voting for the TC, we do have a
process in place that we could likely improve. Other than that, I
believe Thierry and Doug have explained perfectly the issues related
to having these 2 groups merged from a *governance* perspective.

I noticed that this round of elections we had TC *candidates* that at
least I consider more operators than strictly 'dev'. That, to me, is a
huge sign of the progress we've made to integrate the two categories.

To me the real big question is: how are candidates from the operators
side going to get a better chance of being elected next time?

And what's the role of the User Committee in all this?

/stef


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [octavia] Joining Neutron under the big tent

[Jorge Miramontes]

Good stuff. Thanks everyone for your hard work on getting Octavia to this point!

Cheers,
--Jorge

From: Brandon Logan 
mailto:brandon.lo...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, May 1, 2015 at 10:20 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [octavia] Joining Neutron under the big tent


​+1 from me


From: Kyle Mestery mailto:mest...@mestery.com>>
Sent: Friday, May 1, 2015 8:53 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [octavia] Joining Neutron under the big tent

On Thu, Apr 30, 2015 at 5:17 PM, Eichberger, German 
mailto:german.eichber...@hp.com>> wrote:
Hi,

I am proposing that Octavia is joining the Networking program as a project
under the Services area.

Octavia is the open scalable reference implementation for Neutron LBaaS V2
and has always seen itself as part of the networking program. We have
adopted most governance rules from the Networking program, sharing the
same build structure, and are organized like an OpenDStack project.


This sounds fine to me German. To proceed here, propose something similar to 
what Russell has proposed for OVN here [1], and ping me on IRC with the review 
so I can ack it. The TC can then approve it at a future meeting.

Thanks!
Kyle

[1] https://review.openstack.org/#/c/175954/

Thanks,
German



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] service chaining feature development

[Cathy Zhang]

Hello everyone,

Some of you have reached out to me asking questions about when we will start 
meeting discussion on the service chaining feature BPs in OpenStack.

I have set up a"goto meeting" for an audio meeting discussion so that we can 
sync up thought and bring everyone on the same page in a more efficient way. 
The meeting will be 10am~11am May 5th pacific time. Anyone who has interest in 
this feature development is welcome to join the meeting and contribute together 
to the service chain feature in OpenStack. Hope the time is good for most 
people.


OpenStack BP discussion for service chaining
Please join the meeting from your computer, tablet or smartphone.
https://global.gotomeeting.com/join/199553557, meeting password: 199-553-557
You can also dial in using your phone.
United States +1 (224) 501-3212
Access Code: 199-553-557

-
Following are the links to the Neutron related service chain specs and the bug 
IDs. Feel free to sign up and add you comments/input to the BPs.
https://review.openstack.org/#/c/177946
https://bugs.launchpad.net/neutron/+bug/1450617
https://bugs.launchpad.net/neutron/+bug/1450625



Just FYI. There is an approved service chain project in OPNFV. Here is the link 
to the project page. It will be good to sync up the service chain work between 
the two communities. 
https://wiki.opnfv.org/requirements_projects/openstack_based_vnf_forwarding_graph



Thanks,

Cathy



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] service chaining feature development

[Vasudevan, Swaminathan (PNB Roseville)]

Hi Cathy,
Thanks for the information.
Waiting for the invite.
Thanks
Swami


From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com]
Sent: Thursday, April 30, 2015 6:17 PM
To: adolfo.duar...@hp.com; Vikram Choudhary; Isaku Yamahata; Yamahata, Isaku; 
Vasudevan, Swaminathan (PNB Roseville); Anand, Ritesh; 
vishswanan...@hotmail.com; Gal Sagie; Subrahmanyam Ongole; Manish Godara; 
ybaben...@gmail.com; vishwana...@hotmail.com; Palanisamy, Ila (HP Networking); 
Li, Lynn; Vasudevan, Swaminathan (PNB Roseville); adrian.ho...@intel.com; 
Carlos; jdand...@research.att.com; Dirk; ronen.a...@intel.com; 
sram...@brocade.com; A, Keshava; Wu, Hong-Guang 
(ES-Best-Shore-Services-China-BJ); yuriy.babe...@telekom.de; 
ralf.trezec...@telekom.de; ybaben...@gmail.com; Jay-s-b; 
mathieu.rohon@orange.coSum; Migliaccio, Armando; mest...@mestery.com; 
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] service chaining feature development

Hello everyone,

Some of you have reached out to me asking questions about when we will start 
meeting discussion on the service chaining feature BPs in OpenStack.

I have set up a"goto meeting" for an audio meeting discussion so that we can 
sync up thought and bring everyone on the same page in a more efficient way. 
The meeting will be 10am~11am May 5th pacific time. Anyone who has interest in 
this feature development is welcome to join the meeting and contribute together 
to the service chain feature in OpenStack. Hope the time is good for most 
people.


OpenStack BP discussion for service chaining
Please join the meeting from your computer, tablet or smartphone.
https://global.gotomeeting.com/join/199553557, meeting password: 199-553-557
You can also dial in using your phone.
United States +1 (224) 501-3212
Access Code: 199-553-557

-
Following are the links to the Neutron related service chain specs and the bug 
IDs. Feel free to sign up and add you comments/input to the BPs.
https://review.openstack.org/#/c/177946
https://bugs.launchpad.net/neutron/+bug/1450617
https://bugs.launchpad.net/neutron/+bug/1450625



Just FYI. There is an approved service chain project in OPNFV. Here is the link 
to the project page. It will be good to sync up the service chain work between 
the two communities. 
https://wiki.opnfv.org/requirements_projects/openstack_based_vnf_forwarding_graph



Thanks,

Cathy



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates

[Adam Lawson]

So this is an interesting idea. Would we require operators co-author/review
all patches that land? if not (and that actually strikes me as making
uploading patches more difficult unnecessarily), My question is how
Operators can easily get involved with that process.

If Operators want to get recognized for contributing and participate with
TC elections, an easy way to start an engagement with some means of
tracking would be immensely helpful I think.

Does the current system allow this kind of co-authoring/operator review
sort of thing?


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Fri, May 1, 2015 at 8:44 AM, Joshua Harlow  wrote:

> Davanum Srinivas wrote:
>
>> One concrete suggestion based on my experience working with Kris
>> Lindgren on Heartbeat patch:
>> http://markmail.org/message/gifrt5f3mslco24j
>>
>> I could have added a "Co-Tested-By" (or "Co-Operator" - get it? :) in
>> my commit message which would have signaled a concrete
>> contribution/feedback with specific folks in the operator community.
>> This could be done not just for code, could be for reviews or
>> documentation etc as well. WDYT?
>>
>
> +1 Kris is a great example, and I can think of other operators that should
> be some sort of ATC (but may not contribute code to get this). IMHO any
> operator running openstack (let's say at least at 50+ compute nodes) and
> operating it should get full access to the summit, because their words of
> advice/experience are just as useful as technical contributors...
>
>
>
>> thanks,
>> dims
>>
>> On Thu, Apr 30, 2015 at 9:06 PM, Adam Lawson  wrote:
>>
>>> I think it's easy to quantify a code contributor since we have systems
>>> that
>>> monitor activity - who contributed, what they contributed and when. But
>>> we
>>> don't have a system that monitors operator activity and honestly, that's
>>> the
>>> question mark for which I really don't have any answers. That might be
>>> our
>>> first hurdle - how define the difference between a causal user making
>>> remarks on the mailing lists and someone who works with the technology
>>> and
>>> engages. We'd have to quantify them differently somehow.
>>>
>>> Maybe attending an operators meeting would qualify someone to vote?
>>>
>>> On Apr 30, 2015 5:35 PM, "Stefano Maffulli"
>>> wrote:
>>>
 On Thu, 2015-04-30 at 12:26 +0200, Flavio Percoco wrote:

> I've seen the number of threads to discuss Ops topics increase in
> openstack-dev and the influence of Ops - even just points of views
> inherited from the feedback we've got - on reviews has gotten better
> as well.
>
 Fantastic, that has always been the intention.

  If it's a matter of having more Ops voting for the TC, we do have a
> process in place that we could likely improve. Other than that, I
> believe Thierry and Doug have explained perfectly the issues related
> to having these 2 groups merged from a *governance* perspective.
>
 I noticed that this round of elections we had TC *candidates* that at
 least I consider more operators than strictly 'dev'. That, to me, is a
 huge sign of the progress we've made to integrate the two categories.

 To me the real big question is: how are candidates from the operators
 side going to get a better chance of being elected next time?

 And what's the role of the User Committee in all this?

 /stef



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] pbr 0.11 released. Must read if you encounter pbr.version.SemanticVersion(XXXX), but target version ... errors

[Doug Hellmann]

Excerpts from Robert Collins's message of 2015-05-01 10:59:49 +1200:
> pbr 0.11 is finally released (now that Kilo is out :).
> 
> This brings in more support to ensure that our version numbers are
> monotonically increasing.
> 
> Mostly this should be unintrusive (but please do read the docs -
> http://docs.openstack.org/developer/pbr/#version).
> 
> The key things you need to know are:
>  - setup.cfg's with a version line in it are 'preversioned'
>  - preversioning requires an *immediate* commit to a branch right
> after a final release is done, to update the setup.cfg - without this,
> no future changes can be landed. Details below.
>  - most projects - particularly non-server projects - should be able
> to remove remove the version entry from setup.cfg and let pbr manage
> everything. This is 'postversioning', and pbr will calculate the next
> appropriate version number based on the git history.
> 
> Details:
>  say your project is tempest, and you have 'version = 4' in setup.cfg.
> This tells pbr that you want your next final release to be 4.0.0[the
> .0.0 is implied].
>  Then you tag a release: 'git tag -s 4' (or 4.0.0 - same difference to
> pbr). This tells pbr that you *have released* 4.0.0.
>  Then you do a new commit to the tree. What version should pbr choose?
>  By having a version= line in setup.cfg, you've turned off pbr's
> automatic selection of a good version, but it will cross-check to
> prevent your versions rolling backwards - and since 4 has been
> released there are *no* versions that are lower than the release, for
> it to choose from.
> 
> So - the next commit needs to be the one where you choose a new
> version (be that 4.0.1 or 5 or whatever) as a target.
> 
> Alternatively, you can choose to let pbr's version calculation logic
> automatically determine the version - just remove the version =  line
> from setup.cfg entirely, and pbr will generate numbers for you, with
> you choosing the actual one when you make a new tag.
> 
> We're dealing with the most visible projects that have bad metadata
> now in -infra, but projects using pbr elsewhere will probably be
> puzzled - thus this email :)

It would be good to make sure this is in the pbr documentation, too.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [octavia] Joining Neutron under the big tent

[Doug Wiegley]

+1

Governance patch filed: 
https://review.openstack.org/179417

Thanks,
doug


> On May 1, 2015, at 9:58 AM, Jorge Miramontes  
> wrote:
> 
> Good stuff. Thanks everyone for your hard work on getting Octavia to this 
> point!
> 
> Cheers,
> --Jorge
> 
> From: Brandon Logan  >
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> mailto:openstack-dev@lists.openstack.org>>
> Date: Friday, May 1, 2015 at 10:20 AM
> To: "OpenStack Development Mailing List (not for usage questions)" 
> mailto:openstack-dev@lists.openstack.org>>
> Subject: Re: [openstack-dev] [octavia] Joining Neutron under the big tent
> 
>> ​+1 from me
>> From: Kyle Mestery mailto:mest...@mestery.com>>
>> Sent: Friday, May 1, 2015 8:53 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [octavia] Joining Neutron under the big tent
>>  
>> On Thu, Apr 30, 2015 at 5:17 PM, Eichberger, German 
>> mailto:german.eichber...@hp.com>> wrote:
>>> Hi,
>>> 
>>> I am proposing that Octavia is joining the Networking program as a project
>>> under the Services area.
>>> 
>>> Octavia is the open scalable reference implementation for Neutron LBaaS V2
>>> and has always seen itself as part of the networking program. We have
>>> adopted most governance rules from the Networking program, sharing the
>>> same build structure, and are organized like an OpenDStack project.
>>> 
>> 
>> This sounds fine to me German. To proceed here, propose something similar to 
>> what Russell has proposed for OVN here [1], and ping me on IRC with the 
>> review so I can ack it. The TC can then approve it at a future meeting.
>> 
>> Thanks!
>> Kyle
>> 
>> [1] https://review.openstack.org/#/c/175954/ 
>> 
>> 
>>> Thanks,
>>> German
>>> 
>>> 
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
>>> 
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>>> 
>> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [octavia] Joining Neutron under the big tent

[Adam Harwell]

+1

--Adam

https://keybase.io/rm_you


From: Doug Wiegley 
mailto:doug...@parksidesoftware.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, May 1, 2015 at 11:19 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [octavia] Joining Neutron under the big tent

+1

Governance patch filed:
https://review.openstack.org/179417

Thanks,
doug


On May 1, 2015, at 9:58 AM, Jorge Miramontes 
mailto:jorge.miramon...@rackspace.com>> wrote:

Good stuff. Thanks everyone for your hard work on getting Octavia to this point!

Cheers,
--Jorge

From: Brandon Logan 
mailto:brandon.lo...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, May 1, 2015 at 10:20 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [octavia] Joining Neutron under the big tent

​+1 from me

From: Kyle Mestery mailto:mest...@mestery.com>>
Sent: Friday, May 1, 2015 8:53 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [octavia] Joining Neutron under the big tent

On Thu, Apr 30, 2015 at 5:17 PM, Eichberger, German 
mailto:german.eichber...@hp.com>> wrote:
Hi,

I am proposing that Octavia is joining the Networking program as a project
under the Services area.

Octavia is the open scalable reference implementation for Neutron LBaaS V2
and has always seen itself as part of the networking program. We have
adopted most governance rules from the Networking program, sharing the
same build structure, and are organized like an OpenDStack project.


This sounds fine to me German. To proceed here, propose something similar to 
what Russell has proposed for OVN here [1], and ping me on IRC with the review 
so I can ack it. The TC can then approve it at a future meeting.

Thanks!
Kyle

[1] https://review.openstack.org/#/c/175954/

Thanks,
German



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet when creating a pool?

[Adam Harwell]

The subnet_id on the pool specifies what networks to plug when everything is 
first configured.Iif you add a member to the pool that is outside this subnet, 
there may not be a route to it, since it is probably on a different network 
that is not correctly plugged on the LB host. (I hope this is correct, it is 
from memory from a bit ago.)

--Adam

https://keybase.io/rm_you


From: Wanjing Xu mailto:wanjing...@hotmail.com>>
Reply-To: OpenStack Development Mailing List not for usage questions 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, April 30, 2015 at 5:15 PM
To: OpenStack Development Mailing List not for usage questions 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet 
when creating a pool?

Thanks Bharath for replying.  But when I add members , I can successfully 
specify a member ip address from a different pool than the subnet when creating 
pool, hence the confusion.  And theoretically, why would members for a pool 
have to belong to the same subnet?


Date: Tue, 28 Apr 2015 17:50:16 -0700
From: bharath.stac...@gmail.com
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet 
when creating a pool?

Hi Wanjing,

As it's Juno, I assume you are using LBaaSv1. If that's the case, as Brandon 
pointed, there's no subnet-id switch in the "neutron lb-member-create" command.

Having said that you still use the subnet-id in both the following commands:
neutron lb-pool-create
neutron lb-vip-create

You should note that the subnet id in each of the above commands serve 
different purpose. In the case of "lb-pool-create", the subnet-id is provided 
to make sure that only members belonging to the specified subnet-id could be 
added to the pool.

However, the subnet id in the "lb-vip-create" command specifies the network 
range from which an ip is chosen to be assigned as a vip.

Thus, you could use different subnets for both the above commands and as long 
as you have route between those two, the load balancing works.

Thanks,
Bharath.


On Tue, Apr 28, 2015 at 9:19 AM, Brandon Logan 
mailto:brandon.lo...@rackspace.com>> wrote:
​So someone pointed out that you were using lbaas for Juno, which would mean 
you aren't using LBaaS V2.  So you're using V1.  V1 member's do not take 
subnet_id as an attribute.  Let me know how you are making your requests.



Thanks,

Brandon


From: Brandon Logan 
mailto:brandon.lo...@rackspace.com>>
Sent: Monday, April 27, 2015 8:40 PM
To: OpenStack Development Mailing List not for usage questions
Subject: Re: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet 
when creating a pool?

I'm assuming you are using LBaaS V2.  With that assumption, I'm not sure how 
you are having to select subnet on the pool.  It's not supposed to be a field 
at all on the pool object.  subnet_id is required on the member object right 
now, but that's something I and others think should just be optional, and if 
not specified then it's assumed that member can be reached with whatever has 
already been setup.​  Another option is pool could get a subnet_id field in the 
future and all members that are created without subnet_id are assumed to be on 
the pool's subnet_id, but I'm getting ahead of myself and this has no bearing 
on your current issue.



Could you tell me how you are making your requests? CLI? REST directly?


From: Wanjing Xu mailto:wanjing...@hotmail.com>>
Sent: Monday, April 27, 2015 12:57 PM
To: OpenStack Development Mailing List not for usage questions
Subject: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet when 
creating a pool?

So when I use Haproxy for LBaaS for Juno, there is a subnet mandatary field 
that I need to fill in when creating a pool, and later on when I add members, I 
can use a different subnet(or simply just enter the ip of the member), when 
adding vip, I can still select a third subnet.  So what is the usage of the 
first subnet that I used to create pool?  There is no port created for this 
pool subnet.  I can see that a port is created for the vip subnet that the 
loadbalancer instance is binding to.

Regards!

Wanjing Xu

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__ 
OpenStack Development Mailing List (not for usage questions) Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.ope

Re: [openstack-dev] [Manila] Mount automation using Zeroconf

[Fox, Kevin M]

Same is true of network shares. If its already listed in fstab, it will just 
work. But an admin's got to manually add it there. My point is "automation" is 
not supported in cinder either?

Thanks,
Kevin

From: Ben Swartzlander [b...@swartzlander.org]
Sent: Friday, May 01, 2015 8:19 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Manila] Mount automation using Zeroconf

On 05/01/2015 09:32 AM, Fox, Kevin M wrote:
Hmm The cinder volumes dont automount either. /dev/vdx shows up, but you 
have to format/mount it yourself.

Maybe both teams could share a common solution? Im guessing it will have to be 
an agent...

That not really true. If the volume is already formatted with a filesystem, and 
the filesystem is listed in the fstab, linux will mount it automatically. Same 
with Windows. Even unlabelled volumes could be automatically formatted and 
mounted with some script inside the guest that was watching for the right 
events.

With shares, even the basic notification is not there, nor is there a standard 
way for a guest to determine what mounts are available out there (the 
equivalent of the existence of the /dev/* files).

We'd like to solve these 2 basic problems in a way that's standard across all 
Manila instances. Of course what consumes that information and what happens 
afterwards would ideally be up the the tenant, and we would like to provide a 
set of samples for popular use cases.

-Ben


Thanks,
Kevin


From: Deepak Shetty
Sent: Thursday, April 30, 2015 9:54:31 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Manila] Mount automation using Zeroconf

Hi,
  Have we considered cloud-init and qemu guest agent, I remember there was some 
discussion around this
in the prev summit, but i couldn't find any etherpad/notes on that.

I had one more question in this regards. Is it possible to do some kind of VM 
hotplug add operation as part of manila
access allow which will cause the VM to see a new drive with a pre-specified 
label and a client inside the VM will
mount it as part of the udev/uevent ?

On Tue, Apr 28, 2015 at 11:50 PM, Knight, Clinton 
mailto:clinton.kni...@netapp.com>> wrote:
Thanks, Luis, I agree with your assessment that one good way to solve this
issue is a publisher-subscriber model.  The publisher would be Manila,
using zeroconf or AMQP or Zaqar (the one I¹m investigating now).  The
subscriber would be a lightweight agent running on the client that listens
for share availability events and handles the mounts.  One open question
is whether Manila needs to store a record of client mounts, without which
it could not influence the mount paths on each client.

Clinton


On 4/27/15, 1:49 PM, "Luis Pabon" mailto:lpa...@redhat.com>> 
wrote:

>Hi Clinton,
>  I think there are two main parts that are needed to automatically mount
>Manila shares.  One is the share discovery model, and the other is
>enabling the virtual machine to mount the share.  I think the only
>benefit to using zeroconf would be as a standard way to broadcast
>availability of a network share regardless of protocol.  Manila could
>broadcast the availability of a share by using a name like _manila_nfs,
>_manila_cifs, _manila_gluster, etc.  Although, even with zeroconf, the
>virtual machine still requires an agent to be able to attach the share
>for use.  I think the real benefit of using zeroconf is its simplicity.
>
>There could still be other methods we can investigate.  For example
>(don't kill me for this ;-)), have a Manila YP NIS service for NFS shares?
>
>- Luis
>
>
>
>
>- Original Message -
>From: "Clinton Knight" 
>mailto:clinton.kni...@netapp.com>>
>To: "OpenStack Development Mailing List (not for usage questions)"
>mailto:openstack-dev@lists.openstack.org>>
>Sent: Wednesday, April 22, 2015 3:29:50 PM
>Subject: [openstack-dev] [Manila] Mount automation using Zeroconf
>
>Hello, Manila-philes.
>
>Back in Paris we started talking about Manila mount automation, whereby
>file shares could be automatically mounted on clients, and this will
>likely be a topic in Vancouver. So in order to have an informed
>discussion at the summit, I'd like to explore a few things beforehand.
>
>Besides brute force approaches like SSH or PsExec, one of the community
>suggestions was to use Zeroconf (aka Bonjour)[1]. Zeroconf sounds
>attractive on the surface, but it seems to have a number of limitations:
>
>* No standard way to specify local mount point
>* Additional setup required to work beyond the 'local' domain
>* Custom software needed on clients to mount advertised shares
>* Same issues with network connectivity as any other mount automation
>solution
>
>Does anyone have a clearer idea how Zeroconf might satisfy the need for
>Manila mount automation?
>
>Thanks,
>Clinton Knight
>Manila core team
>
>[1] http://en.wikipedia.org/wiki/Zero-configuration_networking
>

Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates

[Doug Hellmann]

Excerpts from Adam Lawson's message of 2015-05-01 09:06:20 -0700:
> So this is an interesting idea. Would we require operators co-author/review
> all patches that land? if not (and that actually strikes me as making
> uploading patches more difficult unnecessarily), My question is how
> Operators can easily get involved with that process.

*Requiring* reviews would be onerous, but we definitely *encourage*
them.

> If Operators want to get recognized for contributing and participate with
> TC elections, an easy way to start an engagement with some means of
> tracking would be immensely helpful I think.

I think folks who are truly engaged with the existing contributor
team will be recognized, and if they feel they are engaged but are
not being recognized they should talk to the PTL of the project to
understand why.  It's likely that not all PTLs are thinking about
adding ATCs to their project, and some may just need to be nudged.

On the other hand, if you want to have a real, immediate, impact
on the future direction of OpenStack start with the folks making
the plans for upcoming work by reviewing their proposals.  One
benefit of the specs review process is that it is open for everyone
to participate, and we especially want to hear from operators.  I
have several times pointed my local meetup group or some individual
operators to specifications where I thought their input would be
valuable.

I don't know how much feedback we're seeing overall from anyone not
already designated a contributor (if someone familiar enough with
the tools to generate those stats could do it I think it would be
useful information).

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates

[Tim Bell]

The spec review process has made it much easier for operators to see what is 
being proposed and give input.

Recognition is a different topic. It also comes into who would be the 
operator/user electorate ? ATC is simple to define where the equivalent 
operator/user definition is less clear.

I’m trying to capture the various comments from this discussion as time permits 
in the ether pad for the user committee design session at 
https://etherpad.openstack.org/p/YVR-ops-user-committee but feel free to add 
further items you’d like to discuss. The user committee or operators mailing 
list is, IMHO, a better place for these discussions since they are generally 
paid to run their clouds.

Tim (trying to keep up while running a 140K core cloud and doing lots outreach )


From: Adam Lawson mailto:alaw...@aqorn.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, May 1, 2015 at 6:06 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates

So this is an interesting idea. Would we require operators co-author/review all 
patches that land? if not (and that actually strikes me as making uploading 
patches more difficult unnecessarily), My question is how Operators can easily 
get involved with that process.

If Operators want to get recognized for contributing and participate with TC 
elections, an easy way to start an engagement with some means of tracking would 
be immensely helpful I think.

Does the current system allow this kind of co-authoring/operator review sort of 
thing?


Adam Lawson

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
[http://www.aqorn.com/images/logo.png]

On Fri, May 1, 2015 at 8:44 AM, Joshua Harlow 
mailto:harlo...@outlook.com>> wrote:
Davanum Srinivas wrote:
One concrete suggestion based on my experience working with Kris
Lindgren on Heartbeat patch:
http://markmail.org/message/gifrt5f3mslco24j

I could have added a "Co-Tested-By" (or "Co-Operator" - get it? :) in
my commit message which would have signaled a concrete
contribution/feedback with specific folks in the operator community.
This could be done not just for code, could be for reviews or
documentation etc as well. WDYT?

+1 Kris is a great example, and I can think of other operators that should be 
some sort of ATC (but may not contribute code to get this). IMHO any operator 
running openstack (let's say at least at 50+ compute nodes) and operating it 
should get full access to the summit, because their words of advice/experience 
are just as useful as technical contributors...



thanks,
dims

On Thu, Apr 30, 2015 at 9:06 PM, Adam 
Lawsonmailto:alaw...@aqorn.com>>  wrote:
I think it's easy to quantify a code contributor since we have systems that
monitor activity - who contributed, what they contributed and when. But we
don't have a system that monitors operator activity and honestly, that's the
question mark for which I really don't have any answers. That might be our
first hurdle - how define the difference between a causal user making
remarks on the mailing lists and someone who works with the technology and
engages. We'd have to quantify them differently somehow.

Maybe attending an operators meeting would qualify someone to vote?

On Apr 30, 2015 5:35 PM, "Stefano 
Maffulli"mailto:stef...@openstack.org>>  wrote:
On Thu, 2015-04-30 at 12:26 +0200, Flavio Percoco wrote:
I've seen the number of threads to discuss Ops topics increase in
openstack-dev and the influence of Ops - even just points of views
inherited from the feedback we've got - on reviews has gotten better
as well.
Fantastic, that has always been the intention.

If it's a matter of having more Ops voting for the TC, we do have a
process in place that we could likely improve. Other than that, I
believe Thierry and Doug have explained perfectly the issues related
to having these 2 groups merged from a *governance* perspective.
I noticed that this round of elections we had TC *candidates* that at
least I consider more operators than strictly 'dev'. That, to me, is a
huge sign of the progress we've made to integrate the two categories.

To me the real big question is: how are candidates from the operators
side going to get a better chance of being elected next time?

And what's the role of the User Committee in all this?

/stef


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_

[openstack-dev] [keystone] Liberty MidCycle Meetup

[Morgan Fainberg]

Hi everyone! 

I'm happy to announce that (due to overwhelming demand from the development 
team) Keystone will be holding a MidCycle meetup for Liberty. 

In an effort to get ahead of the curve and ensure everyone has time to put in 
for travel arrangements, I am sending out the preliminary details today. Expect 
that more details will come as we get to the summit and beyond (such as hotels, 
topics, etc). 

Keystone Liberty MidCycle Meetup
Location:
   Boston University (Main Campus)
   Boston, MA
Dates: July 15, 16, and 17th

I want to thank the Massachusetts Open Cloud [1] for offering to host us at BU! 
It will be a great meetup in a great city. 

I'll send out more details as they become available. 

Cheers,
Morgan  

[1] http://www.bu.edu/hic/research/massachusetts-open-cloud/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][heat] pbr 0.11 released. Must read if you encounter pbr.version.SemanticVersion(XXXX), but target version ... errors

[Robert Collins]

On 2 May 2015 at 04:17, Doug Hellmann  wrote:
> Excerpts from Robert Collins's message of 2015-05-01 10:59:49 +1200:
>> pbr 0.11 is finally released (now that Kilo is out :).
>>
>> This brings in more support to ensure that our version numbers are
>> monotonically increasing.
>>
>> Mostly this should be unintrusive (but please do read the docs -
>> http://docs.openstack.org/developer/pbr/#version).
...

> It would be good to make sure this is in the pbr documentation, too.

It is, at the link I gave. If its not clear enough, please do help me
understand how, since having clear docs is kindof important :)

I'd also like to do a little postmortem - here's the fallout I've
heard of from pbr's 0.11 release (which is > 1yr of inventory, so
kindof a big deal).

Two number of projects had backslid since the audit I did last year on
their setup.cfg's: tempest and rally. These have all been trivially
fixed by removal. tempest's caused issues in many different projects
test runs though, which let to some confused reports - generally any
patch hitting that issue should be fine on a recheck.
http://logs.openstack.org/85/179285/1/check/check-tempest-dsvm-full/1c5fec4/logs/devstacklog.txt.gz#_2015-04-30_23_47_08_277
and the following error show this.

Nova had a unit test that mocked out only part of the API it was
using, and when the internals of pbr changed, the mocking stopped
being effective. It was using VersionInfo.version_string, but mocking
VersionInfo.version. https://review.openstack.org/179307 and the
associated backports fix this. I think we should move the vendor
functionality into pbr itself (you'd give pbr a callback to get the
vendor info) rather than having multiple copies of it one per server,
all potentially different.

Lastly, and still unresolved, heat's contrib plugin versions
(introduced in March) are deliberately different to the git history,
and thats a use case that pbr hasn't ever supported (multiple version
timelines in one git tree). https://review.openstack.org/#/c/162311/
introduced the versions. https://bugs.launchpad.net/heat/+bug/1450733
is the bug for this.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates

[Russell Bryant]

On 05/01/2015 02:22 PM, Tim Bell wrote:
> 
> The spec review process has made it much easier for operators to see
> what is being proposed and give input.
> 
> Recognition is a different topic. It also comes into who would be the
> operator/user electorate ? ATC is simple to define where the equivalent
> operator/user definition is less clear.

I think spec review participation is a great example of where it would
make sense to grant extra ATC status.  If someone provides valuable spec
input, but hasn't made any commits that get ATC status, I'd vote to
approve their ATC status if proposed.

-- 
Russell Bryant

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates

[Morgan Fainberg]

On Friday, May 1, 2015, Russell Bryant  wrote:

> On 05/01/2015 02:22 PM, Tim Bell wrote:
> >
> > The spec review process has made it much easier for operators to see
> > what is being proposed and give input.
> >
> > Recognition is a different topic. It also comes into who would be the
> > operator/user electorate ? ATC is simple to define where the equivalent
> > operator/user definition is less clear.
>
> I think spec review participation is a great example of where it would
> make sense to grant extra ATC status.  If someone provides valuable spec
> input, but hasn't made any commits that get ATC status, I'd vote to
> approve their ATC status if proposed.


This is exactly the case for David Chadwick (U of Kent) if anyone is
looking for prior examples of someone who has contributed to the spec
process but has not landed code and has received ATC for the contributions.

This is a great way to confer ATC for spec participation.

--Morgan


> --
> Russell Bryant
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][api] 3 API Guidelines up for final review

[Everett Toews]

All 3 API guidelines have merged. Thanks everyone!

Everett


On Apr 22, 2015, at 2:08 PM, Everett Toews  wrote:

> Hi All,
> 
> We have 3 API Guidelines that are ready for a final review.
> 
> 1. Metadata guidelines document
> https://review.openstack.org/#/c/141229/
> 
> 2. Tagging guidelines
> https://review.openstack.org/#/c/155620/
> 
> 3. Guidelines on using date and time format
> https://review.openstack.org/#/c/159892/
> 
> If the API Working Group hasn’t received any further feedback, we’ll merge 
> them on April 29.
> 
> Thanks,
> Everett
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][api] API working group liaisons and responsibilities

[Everett Toews]

On Apr 30, 2015, at 9:54 AM, Jay Pipes  wrote:

> Hi Stackers,
> 
> OK, so Matthew Gilliard and Alex Xu have volunteered to be the Nova team's 
> liaisons to the API working group. Big thank you to Matthew and Alex for 
> volunteering for this important role.
> 
> I've created a wiki page [1] that details the responsibilities of these 
> liaisons. If these duties work out for Nova, we'll recommend other projects 
> pick them up.
> 
> Here are the responsibilities that the Nova/API working group liaisons have:
> 
> 1. Monitor the active patch queue in nova (and nova-specs) and look out for 
> any patch that adds or changes the REST API
> 
> 2. For each patch collected in #1, determine if the constructs used in the 
> patch (or proposed spec) match the guidance currently laid out in the API 
> working group repo's guidance documents.
> 
> 3. If the patch does NOT match the guidance from the API working group, do a 
> code review on the patch pointing to the guidance from the API working group, 
> and ask the author to align with that guidance. Include in your research 
> patches to the API working group that may actually be in review and not 
> merged. (An example of this recently occurred with Sergey Nikitin's 
> re-proposed instance tagging spec: https://review.openstack.org/#/c/177112/. 
> See Ryan Brown's reference to an in-progress API working group guidance on 
> tagging)
> 
> 4. If there is NO guidance in the API working group repo for a particular 
> proposed API change or addition, the liaison should **either** create a 
> proposed patch to the API working group with guidance that clarifies the 
> missing functionality that is introduced in the new Nova patch or spec patch, 
> and bring the proposed guidance to the attention of the API working group. 
> **or** the liaison should working with a member of the API working group to 
> draft such a guideline. The liaison should mark the corresponding Nova patch 
> with a -1 Code Review vote with a link to the proposed guideline, noting that 
> the patch should be put on hold (Work In Progress) until the guideline is 
> merged.
> 
> Best,
> -jay
> 
> [1] https://wiki.openstack.org/wiki/Nova/APIWGLiaisons

This is great. I’ve added a link to that page from the Cross-Project Liaisons 
page [2]. I also added Matthew and Alex as liaisons there. 

giiard and alex_xu: feel free to join us in #openstack-api on freenode too!

Everett

[2] https://wiki.openstack.org/wiki/CrossProjectLiaisons#API_Working_Group
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates

[Adam Lawson]

I purposely didn't email the general mailing list since I didn't want to
cross-post, hard to have these discussions across verticals and choosing
one list = hearing one community - those subscribed to the developer
mailing list.

So I'm not assuming anything, it seems some are suggesting that Operators
get into code review to quantify their role as an engaged Operator. Is that
a correct statement? Just want to make sure I'm hearing correctly. I try to
avoid absolutes but personally speaking for the record, I don't believe the
answer lies with asking Operators to become code reviewers on top of
everthing else they're doing in order for them to have a voice in the TC
elections. If code reviews are being suggested (again, assuming the
assumption is correct for the sake of making my point), technical
contribution extends far beyond uploading and reviewing code. This
alternate means to gain ATC status seems like a potential candidate for
those who want to review code but not for those who are day-to-day
operators engaging with the community.

Is there any meetings planned in Vancouver where users/operators are
meeting where we can add an agenda items to gather input?

Given this conversation involves the Operator community as well, I went
ahead and CC'd them to hopefully capture their specific thoughts/ideas on
the subject.

Mahalo,
Adam


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Fri, May 1, 2015 at 12:22 PM, Morgan Fainberg 
wrote:

>
>
> On Friday, May 1, 2015, Russell Bryant  wrote:
>
>> On 05/01/2015 02:22 PM, Tim Bell wrote:
>> >
>> > The spec review process has made it much easier for operators to see
>> > what is being proposed and give input.
>> >
>> > Recognition is a different topic. It also comes into who would be the
>> > operator/user electorate ? ATC is simple to define where the equivalent
>> > operator/user definition is less clear.
>>
>> I think spec review participation is a great example of where it would
>> make sense to grant extra ATC status.  If someone provides valuable spec
>> input, but hasn't made any commits that get ATC status, I'd vote to
>> approve their ATC status if proposed.
>
>
> This is exactly the case for David Chadwick (U of Kent) if anyone is
> looking for prior examples of someone who has contributed to the spec
> process but has not landed code and has received ATC for the contributions.
>
> This is a great way to confer ATC for spec participation.
>
> --Morgan
>
>
>> --
>> Russell Bryant
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [tc] Who is allowed to vote for TC candidates

[Morgan Fainberg]

On Fri, May 1, 2015 at 2:50 PM, Adam Lawson  wrote:

> I purposely didn't email the general mailing list since I didn't want to
> cross-post, hard to have these discussions across verticals and choosing
> one list = hearing one community - those subscribed to the developer
> mailing list.
>
> So I'm not assuming anything, it seems some are suggesting that Operators
> get into code review to quantify their role as an engaged Operator. Is that
> a correct statement? Just want to make sure I'm hearing correctly. I try to
> avoid absolutes but personally speaking for the record, I don't believe the
> answer lies with asking Operators to become code reviewers on top of
> everthing else they're doing in order for them to have a voice in the TC
> elections. If code reviews are being suggested (again, assuming the
> assumption is correct for the sake of making my point), technical
> contribution extends far beyond uploading and reviewing code. This
> alternate means to gain ATC status seems like a potential candidate for
> those who want to review code but not for those who are day-to-day
> operators engaging with the community.
>
>
Specification review is a far cry from code review. Specification review is
really about direction / impact. Operator imput on specifications can be
extremely valuable (e.g. "This doesn't meet any of our needs, but it's
close. Here are some suggestions to make it meet more needs/closer to
real-world").

It is one of the ways operators can be involved and get ATC status. It may
not be the only way that operators should be involved.

--Morgan


> Is there any meetings planned in Vancouver where users/operators are
> meeting where we can add an agenda items to gather input?
>
> Given this conversation involves the Operator community as well, I went
> ahead and CC'd them to hopefully capture their specific thoughts/ideas on
> the subject.
>
> Mahalo,
> Adam
>
>
> *Adam Lawson*
>
> AQORN, Inc.
> 427 North Tatnall Street
> Ste. 58461
> Wilmington, Delaware 19801-2230
> Toll-free: (844) 4-AQORN-NOW ext. 101
> International: +1 302-387-4660
> Direct: +1 916-246-2072
>
>
> On Fri, May 1, 2015 at 12:22 PM, Morgan Fainberg <
> morgan.fainb...@gmail.com> wrote:
>
>>
>>
>> On Friday, May 1, 2015, Russell Bryant  wrote:
>>
>>> On 05/01/2015 02:22 PM, Tim Bell wrote:
>>> >
>>> > The spec review process has made it much easier for operators to see
>>> > what is being proposed and give input.
>>> >
>>> > Recognition is a different topic. It also comes into who would be the
>>> > operator/user electorate ? ATC is simple to define where the equivalent
>>> > operator/user definition is less clear.
>>>
>>> I think spec review participation is a great example of where it would
>>> make sense to grant extra ATC status.  If someone provides valuable spec
>>> input, but hasn't made any commits that get ATC status, I'd vote to
>>> approve their ATC status if proposed.
>>
>>
>> This is exactly the case for David Chadwick (U of Kent) if anyone is
>> looking for prior examples of someone who has contributed to the spec
>> process but has not landed code and has received ATC for the contributions.
>>
>> This is a great way to confer ATC for spec participation.
>>
>> --Morgan
>>
>>
>>> --
>>> Russell Bryant
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [tc] Who is allowed to vote for TC candidates

[Doug Hellmann]

Excerpts from Adam Lawson's message of 2015-05-01 14:50:33 -0700:
> I purposely didn't email the general mailing list since I didn't want to
> cross-post, hard to have these discussions across verticals and choosing
> one list = hearing one community - those subscribed to the developer
> mailing list.

I didn't notice that you had cross-posted this time, so my reply only
went to the operators list:

http://lists.openstack.org/pipermail/openstack-operators/2015-May/006860.html

Let's pick a list before continuing the discussion. Maybe it's
sufficient to link to this discussion on the operator's list, since most
of the discussion is already in the archives here?

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet when creating a pool?

[Wanjing Xu]

Thanks Adam!
That makes sense to me!Wanjing Xu

From: adam.harw...@rackspace.com
To: openstack-dev@lists.openstack.org
Date: Fri, 1 May 2015 16:33:09 +
Subject: Re: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet 
when creating a pool?








The subnet_id on the pool specifies what networks to plug when everything is 
first configured.Iif you add a member to the pool that is outside this subnet, 
there may not be a route to it, since it is probably on a different network 
that is not correctly
 plugged on the LB host. (I hope this is correct, it is from memory from a bit 
ago.)





--Adam




https://keybase.io/rm_you











From: Wanjing Xu 

Reply-To: OpenStack Development Mailing List not for usage questions 


Date: Thursday, April 30, 2015 at 5:15 PM

To: OpenStack Development Mailing List not for usage questions 


Subject: Re: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet 
when creating a pool?








Thanks Bharath for replying.  But when I add members , I can successfully 
specify a member ip address from a different pool than the subnet when creating 
pool, hence the confusion.  And theoretically, why would members for a pool 
have to belong
 to the same subnet?  





Date: Tue, 28 Apr 2015 17:50:16 -0700

From: bharath.stac...@gmail.com

To: openstack-dev@lists.openstack.org

Subject: Re: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet 
when creating a pool?



Hi Wanjing,



As it's Juno, I assume you are using LBaaSv1. If that's the case, as Brandon 
pointed, there's no subnet-id switch in the "neutron lb-member-create" command. 



Having said that you still use the subnet-id in both the following commands:
neutron lb-pool-create
neutron lb-vip-create



You should note that the subnet id in each of the above commands serve 
different purpose. In the case of "lb-pool-create", the subnet-id is provided 
to make sure that only members belonging to the specified subnet-id could be 
added to the pool. 



However, the subnet id in the "lb-vip-create" command specifies the network 
range from which an ip is chosen to be assigned as a vip. 



Thus, you could use different subnets for both the above commands and as long 
as you have route between those two, the load balancing works.



Thanks,
Bharath.






On Tue, Apr 28, 2015 at 9:19 AM, Brandon Logan 
 wrote:



​So someone pointed out that you were using lbaas for Juno, which would mean 
you aren't using LBaaS V2.  So you're using V1.  V1 member's do not take 
subnet_id as an attribute.  Let me know how you are making your requests.







Thanks,



Brandon





From: Brandon Logan 

Sent: Monday, April 27, 2015 8:40 PM

To: OpenStack Development Mailing List not for usage questions

Subject: Re: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet 
when creating a pool?
 



I'm assuming you are using LBaaS V2.  With that assumption, I'm not sure how 
you are having to select subnet on the pool.  It's not supposed to be a field 
at all on the pool object.  subnet_id is required on the member object right 
now, but that's something
 I and others think should just be optional, and if not specified then it's 
assumed that member can be reached with whatever has already been setup.​  
Another option is pool could get a subnet_id field in the future and all 
members that are created without
 subnet_id are assumed to be on the pool's subnet_id, but I'm getting ahead of 
myself and this has no bearing on your current issue.







Could you tell me how you are making your requests? CLI? REST directly?





From: Wanjing Xu 

Sent: Monday, April 27, 2015 12:57 PM

To: OpenStack Development Mailing List not for usage questions

Subject: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet when 
creating a pool?
 


So when I use Haproxy for LBaaS for Juno, there is a subnet mandatary field 
that I need to fill in when creating a pool, and later on when I add members, I 
can use a different subnet(or simply just enter the ip of the member), when 
adding vip,
 I can still select a third subnet.  So what is the usage of the first subnet 
that I used to create pool?  There is no port created for this pool subnet.  I 
can see that a port is created for the vip subnet that the loadbalancer 
instance is binding to.



Regards!



Wanjing Xu










__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev












__ 
OpenStack Development Mailing List (not for usage questions) Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev








___

[openstack-dev] [puppet] Status of Beaker jobs

[Emilien Macchi]

Hi,

TL;DR: Please review:
https://review.openstack.org/#/q/status:open++topic:bug-1444736,n,z


I would like to share some progress/feedback about integrating Beaker in
our modules.
First, everything is updated in the Google Doc [1]

My main blockers were related to packaging in UCA, I had sometimes to do
ugly Puppet patches (as dependencies) to fix some bugs.

Packaging is missing
===
Some projects don't have packages (Gnocchi & Tuskar), so I can't tests
it in OpenStack CI for now.

Bugs in packaging
===
Ensure python-mysqldb is installed  before MySQL db_sync (ceilometer)
https://review.openstack.org/#/c/177593/

Allow to deploy Sahara on Ubuntu
https://review.openstack.org/#/c/179136/

FWaaS: update packaging for Debian & Ubuntu
https://review.openstack.org/#/c/179210/

chmod /etc/neutron to 755 instead of 750
https://review.openstack.org/#/c/179235/

Fix Sahara installation for Ubuntu (workaround)
https://bugs.launchpad.net/puppet-sahara/+bug/1450659
https://bugs.launchpad.net/cloud-archive/+bug/1450945
https://review.openstack.org/#/c/179276/

Ensure /var/log/ironic ownership
https://review.openstack.org/#/c/179531/
https://bugs.launchpad.net/cloud-archive/+bug/1450942

python-openstackclient

For Keystone v3 API, we *need* 1.0.3 at least if we want to have our new
providers working[2], it should be in UCA soon. Fedora will have the
right package too.
I'm helping Rich to test the feature with
https://review.openstack.org/#/c/178828/ (Beaker will be very useful to
actually test the whole thing with patch dependencies).


TripleO
===
I did not start beaker tests for now, because I first want to see unit
testing. (If someone is volunteer? or I'll make it next week).


Have a great week-end,

[1]
https://docs.google.com/spreadsheets/d/1i2z5QyvukHCWU_JjkWrTpn-PexPBnt3bWPlQfiDGsj8/edit#gid=0
[2]
https://review.openstack.org/#/q/status:open+project:stackforge/puppet-keystone+branch:master+topic:bp/api-v3-support,n,z
-- 
Emilien Macchi





signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] service chaining feature development

[Cathy Zhang]

Hello everyone,

Some of you have reached out to me asking questions about when we will start 
meeting discussion on the service chaining feature BPs in OpenStack.

I have set up a"goto meeting" for an audio meeting discussion so that we can 
sync up thought and bring everyone on the same page in a more efficient way. 
The meeting will be 10am~11am May 5th pacific time. Anyone who has interest in 
this feature development is welcome to join the meeting and contribute together 
to the service chain feature in OpenStack. Hope the time is good for most 
people.


OpenStack BP discussion for service chaining
Please join the meeting from your computer, tablet or smartphone.
https://global.gotomeeting.com/join/199553557, meeting password: 199-553-557
You can also dial in using your phone.
United States +1 (224) 501-3212
Access Code: 199-553-557

-
Following are the links to the Neutron related service chain specs and the bug 
IDs. Feel free to sign up and add you comments/input to the BPs.
https://review.openstack.org/#/c/177946
https://bugs.launchpad.net/neutron/+bug/1450617
https://bugs.launchpad.net/neutron/+bug/1450625



Just FYI. There is an approved service chain project in OPNFV. Here is the link 
to the project page. It will be good to sync up the service chain work between 
the two communities. 
https://wiki.opnfv.org/requirements_projects/openstack_based_vnf_forwarding_graph



Thanks,

Cathy



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon] Karma Tests in Horizon

[Michael Krotscheck]

Paging David Lyle!

We're trying to nail down exactly what work needs to be done on the Karma
patch to get your approval and avoid further frustrating patch churn. Could
you take a moment to respond to Matt's question, and/or discuss here what
you're looking for? We tried pinging you on IRC, but it appears you missed
the notification in backscroll.

For reference, here's the patch under consideration:
https://review.openstack.org/#/c/168152/

Michael Krotscheck
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TC][Keystone] Rehashing the Pecan/Falcon/other WSGI debate

[Jamie Lennox]

Hi all, 

At around the time Barbican was applying for incubation there was a
discussion about "supported" WSGI frameworks. From memory the decision
at the time was that Pecan was to be the only supported framework and
that for incubation Barbican had to convert to Pecan (from Falcon).

Keystone is looking to ditch our crusty old, home-grown wsgi layer for
an external framework and both Pecan and Falcon are in global
requirements. 

In the experimenting I've done Pecan provides a lot of stuff we don't
need and some that just gets in the way. To call out a few:
 * the rendering engine really doesn't make sense for us, for APIs, and
where we are often returning different data (not just different views or
data) based on Content-Type. 
 * The security enforcement within Pecan does not really mesh with how
we enforce policy, nor does the way we build controller objects per
resource. It seems we will have to build this for ourselves on top of
pecan

and there are just various other niggles. 

THIS IS NOT SUPPOSED TO START A DEBATE ON THE VIRTUES OF EACH FRAMEWORK.

Everything I've found can be dealt with and pecan will be a vast
improvement over what we use now. I have also not written a POC with
Falcon to know that it will suit any better.

My question is: Does the ruling that Pecan is the only WSGI framework
for OpenStack stand? I don't want to have 100s of frameworks in the
global requirements, but given falcon is already there iff a POC
determines that Falcon is a better fit for keystone can we use it? 


Thanks, 

Jamie 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] Status of Beaker jobs

[Rich Megginson]

On 05/01/2015 05:35 PM, Emilien Macchi wrote:

Hi,

TL;DR: Please review:
https://review.openstack.org/#/q/status:open++topic:bug-1444736,n,z


I would like to share some progress/feedback about integrating Beaker in
our modules.
First, everything is updated in the Google Doc [1]

My main blockers were related to packaging in UCA, I had sometimes to do
ugly Puppet patches (as dependencies) to fix some bugs.

Packaging is missing
===
Some projects don't have packages (Gnocchi & Tuskar), so I can't tests
it in OpenStack CI for now.

Bugs in packaging
===
Ensure python-mysqldb is installed  before MySQL db_sync (ceilometer)
https://review.openstack.org/#/c/177593/

Allow to deploy Sahara on Ubuntu
https://review.openstack.org/#/c/179136/

FWaaS: update packaging for Debian & Ubuntu
https://review.openstack.org/#/c/179210/

chmod /etc/neutron to 755 instead of 750
https://review.openstack.org/#/c/179235/

Fix Sahara installation for Ubuntu (workaround)
https://bugs.launchpad.net/puppet-sahara/+bug/1450659
https://bugs.launchpad.net/cloud-archive/+bug/1450945
https://review.openstack.org/#/c/179276/

Ensure /var/log/ironic ownership
https://review.openstack.org/#/c/179531/
https://bugs.launchpad.net/cloud-archive/+bug/1450942

python-openstackclient

For Keystone v3 API, we *need* 1.0.3 at least if we want to have our new
providers working[2], it should be in UCA soon. Fedora will have the
right package too.


Looks like RDO kilo now has python-openstackclient 1.0.3.  I've been 
using that since last night and it has been working fine.



I'm helping Rich to test the feature with
https://review.openstack.org/#/c/178828/ (Beaker will be very useful to
actually test the whole thing with patch dependencies).


Thanks Emilien!




TripleO
===
I did not start beaker tests for now, because I first want to see unit
testing. (If someone is volunteer? or I'll make it next week).


Have a great week-end,

[1]
https://docs.google.com/spreadsheets/d/1i2z5QyvukHCWU_JjkWrTpn-PexPBnt3bWPlQfiDGsj8/edit#gid=0
[2]
https://review.openstack.org/#/q/status:open+project:stackforge/puppet-keystone+branch:master+topic:bp/api-v3-support,n,z


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][LBaaS] Clarification required

[Madhusudhan Kandadai]

Hello,

I am playing around with Neutron LBaaS API calls as per Neutron/LBaaS/API
2.0 docs. I have noticed below behavior against working devstack. I would
like to clarify on it:

1. I create a loadbalancer using RESTAPI with the attributes -
'vip_subnet_id' and 'admin_state_up' as 'False'. It is getting created
successfully

when I do a GET on loadbalancer, I could see the relevant their information.

2. I create a listener with the loadbalancer_id from step 1 and
'admin_state_up' as 'False' and able to create listener.

when I do a GET on loadbalancer again, I could see listener details
associated with the loadbalancer as expected

Now the question comes in:-

3. I create a pool with listener _id and 'admin_state_up' as 'False' and
able to create pool accordingly

But, when I do a GET on loadbalancer, I could not see pool details under
listener associated with the loadbalancer.

Just curious, why I could not see like this when I do a GET on loadbalancer:

{
loadbalancer {
 listener {
   pools
}
   }
}


4. I could see all the details including pool correctly when I do GET on
loadbalancers//statuses

Thanks,
Madhusudhan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Proposal to add Melanie Witt to nova-core

[Gary Kotton]

+1

From: Alex Xu mailto:sou...@gmail.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, May 1, 2015 at 6:30 AM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [nova] Proposal to add Melanie Witt to nova-core

I'm not core, but I want to +1 :)

2015-04-30 19:30 GMT+08:00 John Garbutt 
mailto:j...@johngarbutt.com>>:
Hi,

I propose we add Melanie to nova-core.

She has been consistently doing great quality code reviews[1],
alongside a wide array of other really valuable contributions to the
Nova project.

Please respond with comments, +1s, or objections within one week.

Many thanks,
John

[1] https://review.openstack.org/#/dashboard/4690

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev