[openstack-dev] [Neutron] Port Forwarding API

[Gal Sagie]

Hello All,

I have sent a spec [1] to resume the work on port forwarding API and
reference implementation.

Its currently marked as "WIP", however i raised some "TBD" questions for
the community.
The way i see port forwarding is an API that is very similar to floating IP
API and implementation
with few changes:

1) Can only define port forwarding on the router external gateway IP (or
additional public IPs
   that are located on the router.  (Similar to the case of centralized
DNAT)

2) The same FIP address can be used for different mappings, for example FIP
with IP X
can be used with different ports to map to different VM's X:4001  ->
VM1 IP
X:4002 -> VM2 IP (This is the essence of port forwarding).
So we also need the port mapping configuration fields

All the rest should probably behave (in my opinion) very similar to FIP's
(for example
not being able to remove external gateway if port forwarding entries are
configured,
if the VM is deletd the port forwarding entry is deleted as well and so
on..)
All of these points are mentioned in the spec and i am waiting for the
community feedback
on them.

I am trying to figure out if implementation wise, it would be smart to try
and use the floating IP
implementation and extend it for this (given all the above mechanism
described above already
works for floating IP's)
Or, add another new implementation which behaves very similar to floating
IP's in most aspects
(But still differ in some)
Or something else...

Would love to hear the community feedback on the spec, even that its WIP

Thanks
Gal.

[1] https://review.openstack.org/#/c/224727/
__
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] [fuel] PTL & Component Leads elections

[Mike Scherbakov]

Let's move on.
I started work on MAINTAINERS files, proposed two patches:
https://review.openstack.org/#/c/225457/1
https://review.openstack.org/#/c/225458/1

These can be used as templates for other repos / folders.

Thanks,

On Fri, Sep 18, 2015 at 7:45 PM Davanum Srinivas  wrote:

> +1 Dmitry
>
> -- Dims
>
> On Fri, Sep 18, 2015 at 9:07 PM, Dmitry Borodaenko <
> dborodae...@mirantis.com> wrote:
>
>> Dims,
>>
>> Thanks for the reminder!
>>
>> I've summarized the uncontroversial parts of that thread in a policy
>> proposal as per you suggestion [0], please review and comment. I've
>> renamed SMEs to maintainers since Mike has agreed with that part, and I
>> omitted code review SLAs from the policy since that's the part that has
>> generated the most discussion.
>>
>> [0] https://review.openstack.org/225376
>>
>> I don't think we should postpone the election: the PTL election follows
>> the same rules as OpenStack so we don't need a Fuel-specific policy for
>> that, and the component leads election doesn't start until October 9,
>> which gives us 3 weeks to confirm consensus on that aspect of the
>> policy.
>>
>> --
>> Dmitry Borodaenko
>>
>>
>> On Fri, Sep 18, 2015 at 07:30:39AM -0400, Davanum Srinivas wrote:
>> > Sergey,
>> >
>> > Please see [1]. Did we codify some of these roles and responsibilities
>> as a
>> > community in a spec? There was also a request to use terminology like
>> say
>> > MAINTAINERS in that email as well.
>> >
>> > Are we pulling the trigger a bit early for an actual election?
>> >
>> > Thanks,
>> > Dims
>> >
>> > [1] http://markmail.org/message/2ls5obgac6tvcfss
>> >
>> > On Fri, Sep 18, 2015 at 6:56 AM, Vladimir Kuklin 
>> > wrote:
>> >
>> > > Sergey, Fuelers
>> > >
>> > > This is awesome news!
>> > >
>> > > By the way, I have a question on who is eligible to vote and to
>> nominate
>> > > him/her-self for both PTL and Component Leads. Could you elaborate on
>> that?
>> > >
>> > > And there is no such entity as Component Lead in OpenStack - so we are
>> > > actually creating one. What are the new rights and responsibilities
>> of CL?
>> > >
>> > > On Fri, Sep 18, 2015 at 5:39 AM, Sergey Lukjanov <
>> slukja...@mirantis.com>
>> > > wrote:
>> > >
>> > >> Hi folks,
>> > >>
>> > >> I'd like to announce that we're running the PTL and Component Leads
>> > >> elections. Detailed information available on wiki. [0]
>> > >>
>> > >> Project Team Lead: Manages day-to-day operations, drives the project
>> > >> team goals, resolves technical disputes within the project team. [1]
>> > >>
>> > >> Component Lead: Defines architecture of a module or component in
>> Fuel,
>> > >> reviews design specs, merges majority of commits and resolves
>> conflicts
>> > >> between Maintainers or contributors in the area of responsibility.
>> [2]
>> > >>
>> > >> Fuel has two large sub-teams, with roughly comparable codebases, that
>> > >> need dedicated component leads: fuel-library and fuel-python. [2]
>> > >>
>> > >> Nominees propose their candidacy by sending an email to the
>> > >> openstack-dev@lists.openstack.org mailing-list, which the subject:
>> > >> "[fuel] PTL candidacy" or "[fuel]  lead candidacy"
>> > >> (for example, "[fuel] fuel-library lead candidacy").
>> > >>
>> > >> Time line:
>> > >>
>> > >> PTL elections
>> > >> * September 18 - September 28, 21:59 UTC: Open candidacy for PTL
>> position
>> > >> * September 29 - October 8: PTL elections
>> > >>
>> > >> Component leads elections (fuel-library and fuel-python)
>> > >> * October 9 - October 15: Open candidacy for Component leads
>> positions
>> > >> * October 16 - October 22: Component leads elections
>> > >>
>> > >> [0] https://wiki.openstack.org/wiki/Fuel/Elections_Fall_2015
>> > >> [1] https://wiki.openstack.org/wiki/Governance
>> > >> [2]
>> > >>
>> http://lists.openstack.org/pipermail/openstack-dev/2015-August/072406.html
>> > >> [3] https://lwn.net/Articles/648610/
>> > >>
>> > >> --
>> > >> Sincerely yours,
>> > >> Sergey Lukjanov
>> > >> Sahara Technical Lead
>> > >> (OpenStack Data Processing)
>> > >> Principal Software Engineer
>> > >> Mirantis Inc.
>> > >>
>> > >>
>> __
>> > >> 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
>> > >>
>> > >>
>> > >
>> > >
>> > > --
>> > > Yours Faithfully,
>> > > Vladimir Kuklin,
>> > > Fuel Library Tech Lead,
>> > > Mirantis, Inc.
>> > > +7 (495) 640-49-04
>> > > +7 (926) 702-39-68
>> > > Skype kuklinvv
>> > > 35bk3, Vorontsovskaya Str.
>> > > Moscow, Russia,
>> > > www.mirantis.com 
>> > > www.mirantis.ru
>> > > vkuk...@mirantis.com
>> > >
>> > >
>> __
>> > > OpenStack Development Mailing List (not for usage questions)
>> > > Unsubscribe:
>> openstack-dev-req

Re: [openstack-dev] [neutron] What semantics are expected when booting a VM on an external network?

[Neil Jerram]

On 17/09/15 19:38, Kevin Benton wrote:
> router:external only affects the behavior of Neutron routers. It
> allows them to attach to it with an external gateway interface which
> implies NAT and floating IPs. 

I presume you're talking about the reference implementation here.  OK,
but my concern first is about what it _means_, in particular for
instances attached to such a network.  Which your next paragraph addresses:

>
> From an instance's perspective, an external network would be no
> different than any other provider network scenario that uses a
> non-Neutron router. Nothing different happens with the routing of
> traffic.

Right, thanks.  It seems to me that you're saying the same thing here as
my (b) below.  In case not, please do say more precisely what isn't
correct about my (b) statement.

>
> >Also I believe that (c) is already true for Neutron external networks
> - i.e. it doesn't make sense to assign a floating IP to an instance
> that is directly on an external network.  Is that correct?
>
> Well not floating IPs from the same external network, but you could
> conceivably have layers where one external network has an internal
> Neutron router interface that leads to another external network via a
> Neutron router.

Agreed.

Many thanks for your input in this thread!

Regards,
Neil

>
>
> On Thu, Sep 17, 2015 at 10:17 AM, Neil Jerram
> mailto:neil.jer...@metaswitch.com>> wrote:
>
> Thanks so much for your continuing answers; they are really
> helping me.
>
> I see your points now about the special casing, and about the semantic
> expectations and internal wiring of a Neutron network being just the
> same for an external network as for non-external.  Hence, the
> model for
> an L3-only external network should be the same as it would be for an
> L3-only tenant network, except for the router:external flag (and might
> be along the lines that you've suggested, of a subnet with a null
> network).
>
> It still seems that 'router:external true' might be a good match for
> some of the other 'routed' semantics in [1], though, so I'd like to
> drill down more on exactly what 'router:external true' means.
>
> A summary of the semantics at [1] is:
> (a) L3-only connectivity between instances attached to the network.
> (b) Data can be routed between between this network and the
> outside, and
> between multiple networks of this type, without needing Neutron
> routers
> (c) Floating IPs are not supported for instances on this network.
> Instead, wherever an instance needs to be routable from, attach it
> to a
> network with a subnet of IP addresses that are routable from that
> place.
>
> [1] https://review.openstack.org/#/c/198439/
> 
>
> According to [2], router:external "Indicates whether this network is
> externally accessible."  Which I think is an exact match for (b) -
> would
> you agree?  (Note: it can't mean that every instance on that network
> actually _is_ contactable from outside, because that depends on IP
> addressing, and router:external is a network property, not
> subnet.  But
> it can mean that every instance is _potentially_ contactable, without
> the mediation of a Neutron router.)
>
> [2] http://developer.openstack.org/api-ref-networking-v2-ext.html
>
> Also I believe that (c) is already true for Neutron external
> networks -
> i.e. it doesn't make sense to assign a floating IP to an instance that
> is directly on an external network.  Is that correct?
>
> In summary, for the semantics that I'm wanting to model, it sounds
> like
> router:external true already gives me 2 of the 3 main pieces.  There's
> still serious work needed for (a), but that's really nice news, if I'm
> seeing things correctly (since discovering that instances can be
> attached to an external network).
>
> Regards,
> Neil
>
>
>
>
> On 17/09/15 17:29, Kevin Benton wrote:
> >
> > Yes, the L2 semantics apply to the external network as well (at
> least
> > with ML2).
> >
> > One example of the special casing is the external_network_bridge
> > option in the L3 agent. That would cause the agent to plug directly
> > into a bridge so none of the normal L2 agent wiring would occur.
> With
> > the L2 bridge_mappings option there is no reason for this to exist
> > anymore because it ignoring network attributes makes debugging a
> > nightmare.
> >
> > >Yes, that makes sense.  Clearly the core semantic there is IP. 
> I can
> > imagine reasonable variation on less core details, e.g. L2
> broadcast vs.
> > NBMA.  Perhaps it would be acceptable, if use cases need it, for
> such
> > details to be described by flags on the external network object.
> >
> > An external network object is just a regular netw

Re: [openstack-dev] [openstack-ansible] To NTP, or not to NTP, that is the question

[Jim Meyer]

> On Sep 18, 2015, at 9:38 AM, Jay Pipes  wrote:
> 
>> On 09/18/2015 11:04 AM, Ian Cordasco wrote:
>>> On 9/18/15, 08:03, "Major Hayden"  wrote:
>>> 
>>> Hey there,
>>> 
>>> I start working on a bug[1] last night about adding a managed NTP
>>> configuration to openstack-ansible hosts.  My patch[2] gets chrony up and
>>> running with configurable NTP servers, but I'm still struggling to meet
>>> the "Proposal" section of the bug where the author has asked for
>>> non-infra physical nodes to get their time from the infra nodes.  I can't
>>> figure out how to make it work for AIO builds when one physical host is
>>> part of all of the groups. ;)
>>> 
>>> I'd argue that time synchronization is critical for a few areas:
>>> 
>>>  1) Security/auditing when comparing logs
>>>  2) Troubleshooting when comparing logs
>>>  3) I've been told swift is time-sensitive
>>>  4) MySQL/Galera don't like time drift
>>> 
>>> However, there's a strong argument that this should be done by deployers,
>>> and not via openstack-ansible.  I'm still *very* new to the project and
>>> I'd like to hear some feedback from other folks.
>> 
>> Personally, I fall into the camp of "this is a deployer concern".
>> Specifically, there is already an ansible-galaxy role to enable NTP on
>> your deployment hosts (https://galaxy.ansible.com/list#/roles/464) which
>> *could* be expanded to do this very work that you're talking about. Using
>> specialized roles to achieve this (and contributing back to the larger
>> ansible community) seems like a bigger win than trying to reimplement some
>> of this in OSA instead of reusing other roles that already exist.
>> 
>> Compare it to a hypothetical situation where Keystone wrote its own
>> backing libraries to implement Fernet instead of using the cryptography
>> library. In that case there would be absolutely no argument that Keystone
>> should use cryptography (even if it uses cffi and has bindings to OpenSSL
>> which our infra team doesn't like and some deployers find difficult to
>> manage when using pure-python deployment tooling). Why should OSA be any
>> different from another OpenStack project?
> 
> Have to agree with Ian here. NTP, as Major wrote, is a critical piece of the 
> deployment puzzle, but I don't think it's necessary to put anything in OSA 
> specifically to configure NTP. As Ian wrote, better to contribute to upstream 
> ansible-galaxy playbooks/roles that do this well.

I have a nuanced agreement with this which borders on disagreement. 

An agreed-upon time tick is as crucial to a distributed system as oxygen is to 
a human. It's not only those components that care, it's the humans who have to 
understand and operate it. As such, an OpenStack cloud should come with a time 
source that all services listen to; even if it's wildly off from the real 
world, the value of all services sharing the same tick is immeasurable. For me, 
it's part of "batteries included."

I'd argue that we should pick a tool and configuration for this by default and 
allow others to change it. And, while I love Major*, I don't think the 
deployment tools are the right place for this.

--j

* and I do. Been too long, Major. We should fix that. =]
__
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-dahboard directory is not created

[Monty Taylor]

On 09/18/2015 02:03 PM, OpenStack Mailing List Archive wrote:

Link: https://openstack.nimeyo.com/59453/?show=59453#q59453
From: vidya 

I am trying to create openstack -dashboard on my VM and
/usr/share/openstack-dashboard in not create. Please help me what i am
missing here.

here is what i tried
1 yum install openstack-selinux
2 yum install yum-plugin-priorities
3 yum install
http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm
4 yum install openstack-dashboard httpd mod_wsgi memcached python-memcached
5 yum install python-pip


I HIGHLY recommend not doing this. python-pip packages in distros are 
broken and old and it is unlikely this will change, due to the nature of 
the problem. for pip, I recommend:


wget https://bootstrap.pypa.io/get-pip.py
sudo python get-pip.py


6 yum groupinstall 'Development Tools'
7 yum install python-devel
8 yum install libffi-devel
9 yum install openssl-devel
10 pip install dep/horizon-2014.1.1.tar.gz
11 yum install openstack-dashboard
12 yum upgrade
13 reboot
14 history
15 yum install openstack-dashboard
16 pip install horizon-2014.1.1.tar.gz


Great. So - try again with more modern pip and let's see how it works.

Also - are you sure you want to install horizon 2014.1.1? That's already 
end of life - if I were you, I'd not work on installing it now.


If you DO want to install it now, I HIGHLY recommend installing it from 
a linux distro - since you seem to be using CentOS 7 - perhaps you can use:


yum install 
http://repos.fedorapeople.org/repos/openstack/openstack-havana/rdo-release-havana-7.noarch.rpm


Also - I  just noticed that you are yum instlaling openstack-dashboard 
and then pip installing horizon. This is a very bad idea. either install 
the software from yum or from pip - do not mix the two. Literally nobody 
supports this (neither openstack nor python pip maintainers nor redhat)


So - please try again either all from a distro, or with a more modern 
openstack with a more modern pip and let's see where you are.



16 execution gave me this

Processing ./dep/horizon-2014.1.1.tar.gz
Requirement already satisfied (use --upgrade to upgrade):
horizon==2014.1.1 from file:///home/centos/dep/horizon-2014.1.1.tar.gz
in /usr/lib/python2.7/site-packages
Requirement already satisfied (use --upgrade to upgrade):
Django<1.7,>=1.4 in /usr/lib/python2.7/site-packages (from
horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade):
django-compressor>=1.3 in /usr/lib/python2.7/site-packages (from
horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade):
django-openstack-auth>=1.1.4 in /usr/lib/python2.7/site-packages (from
horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade):
eventlet>=0.13.0 in /usr/lib/python2.7/site-packages (from
horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.9
in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): kombu>=2.4.8
in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): lesscpy>=0.9j
in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): lockfile>=0.8
in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): netaddr>=0.7.6
in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): pbr<1.0,>=0.6
in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade):
python-ceilometerclient>=1.0.6 in /usr/lib/python2.7/site-packages (from
horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade):
python-cinderclient>=1.0.6 in /usr/lib/python2.7/site-packages (from
horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade):
python-glanceclient>=0.9.0 in /usr/lib/python2.7/site-packages (from
horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade):
python-heatclient>=0.2.3 in /usr/lib/python2.7/site-packages (from
horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade):
python-keystoneclient>=0.7.0 in /usr/lib/python2.7/site-packages (from
horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade):
python-neutronclient<3,>=2.3.4 in /usr/lib/python2.7/site-packages (from
horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade):
python-novaclient>=2.17.0 in /usr/lib/python2.7/site-packages (from
horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade):
python-swiftclient>=1.6 in /usr/lib/python2.7/site-packages (from
horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade):
python-troveclient>=1.0.3 in /usr/lib/python2.7/site-packages (from
horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): p

[openstack-dev] [Rally][Meeting][Agenda]

[Roman Vasilets]

Hi, its a friendly reminder that if you what to discuss some topics at
Rally meetings, please add you topic to our Meeting agenda
https://wiki.openstack.org/wiki/Meetings/Rally#Agenda. Don't forget to
specify by whom led this topic. Add some information about topic(links,
etc.) Thank you for your attention.

- Best regards, Vasilets Roman.
__
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][ptl][release] final liberty cycle client library releases needed

[Doug Hellmann]

Excerpts from Renat Akhmerov's message of 2015-09-19 00:35:49 +0300:
> Doug,
> 
> python-mistralclient-1.1.0 (also on pypi) is the final release for Liberty. 
> Here’s the patch updating global-requirements.txt: 
> https://review.openstack.org/#/c/225330/ 
>  (upper-constraints.txt should be 
> soon updated automatically, in my understanding)

Because we're in requirements freeze, we're trying not to update any of
the global-requirements.txt entries unless absolutely necessary. At this
point, no projects can be depending on the previously unreleased
features in 1.1.0, so as long as python-mistralclient doesn't have a cap
on the major version allowed the requirements list, it should only be
necessary to update the constraints.

Please update the constraints file by hand, only changing
python-mistralclient. That will allow us to land the update without
changing any other libraries in the test infrastructure (the automated
update submits all of the changes together, and we have several
outstanding right now).

> 
> I really apologize because I should have probably followed ML better and 
> attended corresponding meetings in order to know all of this release 
> management stuff.  But I still have a number questions on release management 
> like:

Yes, clearly we're going to have to do a better job of communicating
with project teams next cycle. I welcome suggestions for that.

> So far I have been doing release management for Mistral myself (~2 years), 
> and the last year I’ve been trying to be aligned with OpenStack schedule. In 
> may 2015 Mistral was accepted into Big Tent so does that mean I’m not longer 
> responsible for doing that? Or I can still do it on my own? Even with final 
> Mistral client for Liberty I’ve done it just myself (didn’t create a stable 
> branch though yet), maybe I shouldn’t have. Clarifications would be helpful.

It means you can now ask the release management team to take over for
the library, but that is not an automatic change.

> Same question about stable branches.

Same, for the stable maintenance team.

> Does this all apply to all Big Tent projects?

Yes, and to all horizontal teams. Every project team is expected
to provide liaisons to all horizontal teams now. The degree to which
a horizontal team does the work for you is up to each pair of teams
to negotiate.

> What exactly is upper-constraints.txt for? I’m still not sure why 
> global-requirements.txt is not enough.

global-requirements.txt tells what versions of libraries we are
compatible with. upper-constraints.txt tells the most recent version of
libraries actually being used in tests running in our CI system.
Currently that only applies to integration tests, but the work to apply
it to unit tests is coming along.

> What’s the best source of info about release management? Is it complete?

Documentation is one of the weak points right now, and we'll be
addressing that with clearer documentation for milestone dates and
expectations and probably some centralization so there is only one
place folks need to go. Right now we have a section in the project
team guide [1], descriptions of the tools in the release-tools
REAMDE [2], and for managed teams we have instructions in the
releases repository [3].  Deadlines are listed in the wiki [4].

[1] http://docs.openstack.org/project-team-guide/release-management.html
[2] http://git.openstack.org/cgit/openstack-infra/release-tools/tree/README.rst
[3] http://git.openstack.org/cgit/openstack/releases/tree/README.rst
[4] https://wiki.openstack.org/wiki/Liberty_Release_Schedule

> 
> Sorry for asking this probably basic stuff.
> 
> Let me know if some of what I’ve done is wrong. It’s a late night here but 
> I’ll check ML the first thing in the morning just in case.
> 
> Thanks
> 
> Renat Akhmerov
> @ Mirantis Inc.
> 
> > On 15 Sep 2015, at 22:24, Nikhil Komawar  wrote:
> > 
> > Hi Doug,
> > 
> > And it would be good to lock in on glance_store (if it applies to this
> > email) 0.9.1 too. (that's on pypi)
> > 
> > On 9/14/15 9:26 AM, Kuvaja, Erno wrote:
> >> Hi Doug,
> >> 
> >> Please find python-glanceclient 1.0.1 release request 
> >> https://review.openstack.org/#/c/222716/
> >> 
> >> - Erno
> >> 
> >>> -Original Message-
> >>> From: Doug Hellmann [mailto:d...@doughellmann.com]
> >>> Sent: Monday, September 14, 2015 1:46 PM
> >>> To: openstack-dev
> >>> Subject: [openstack-dev] [all][ptl][release] final liberty cycle client 
> >>> library
> >>> releases needed
> >>> 
> >>> PTLs and release liaisons,
> >>> 
> >>> In order to keep the rest of our schedule for the end-of-cycle release 
> >>> tasks,
> >>> we need to have final releases for all client libraries in the next day 
> >>> or two.
> >>> 
> >>> If you have not already submitted your final release request for this 
> >>> cycle,
> >>> please do that as soon as possible.
> >>> 
> >>> If you *have* already submitted your final release request for this cycle,
> >>> please repl