You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@libcloud.apache.org by Roman Bogorodskiy <bo...@gmail.com> on 2011/04/05 00:10:39 UTC
[libcloud] Load Balancers support
Hi,
I've started implementing load balancers support. Currently this code
lives in 'balancers' branch on my github fork of libcloud:
https://github.com/novel/libcloud/tree/balancers
I've added an example how to work with this:
https://github.com/novel/libcloud/blob/balancers/example_lb.py
All balancer-related code lives here:
https://github.com/novel/libcloud/tree/balancers/libcloud/lb
If you check the code you will see that I used Rackspace balancers as a
starting point.
My further plan for balancers:
* cover the new code with unit tests and refine documentation
* merge to svn
* implement GoGrid driver for balancers (probably will have to make
minor adjustments to interface)
Feedback is welcome!
Roman Bogorodskiy
Re: [libcloud] Load Balancers support
Posted by Roman Bogorodskiy <bo...@gmail.com>.
Grig Gheorghiu wrote:
> > +1, and although I have yet to grok the new module layout, perhaps we can throw it into something like libcloud.networking.lb?
> >
> > Yet, I am having a difficult time thinking of non-load balancer networking components currently available.
> >
>
> Well in EC2 you have Elastic IPs that could be managed inside a
> networking package.
I believe that IP stuff is relatively simple and at the same time is
quite tightly integrated with compute drivers, so it's probably make
sense to just leave it as ex_ prefixed stuff in compute drivers instead.
As for 'libcloud.networking.lb', it looks like a more granulated version
of 'libcloud.resource.lb', I don't think we need such level of granulation
currently and most likely will not need for quite some time yet.
Roman Bogorodskiy
Re: [libcloud] Load Balancers support
Posted by Joe Miller <jo...@joeym.net>.
Also, some clouds have the concept of multiple private networks/vlans, VPN
endpoints and users, etc.
+1 for the libcloud.network.* idea
On Wed, Apr 13, 2011 at 9:32 AM, Grig Gheorghiu <gr...@gmail.com>wrote:
> On Wed, Apr 13, 2011 at 9:29 AM, Jerry Chen <je...@apache.org> wrote:
> >
> > On Apr 13, 2011, at 11:25 AM, Grig Gheorghiu wrote:
> >
> >> On Wed, Apr 13, 2011 at 9:15 AM, Tom Davis <to...@dislocatedday.com>
> wrote:
> >>> On Apr 13, 2011, at 12:29 AM, Roman Bogorodskiy <bo...@gmail.com>
> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> Updates on load balancing support. What do I have now:
> >>>>
> >>>> * Functional GoGrid and Rackspace drivers
> >>>> * Unit-tests for basic features
> >>>>
> >>>> Code is on github (as I mentioned before):
> >>>>
> >>>> https://github.com/novel/libcloud/compare/balancers
> >>>>
> >>>> It needs some more love for sure, but generally it's ready to hit main
> >>>> repository, in my opinion.
> >>>>
> >>>> The only concern I have there is when we are going to ship 0.5.0? If
> >>>> we're going to ship it really soonish, I'd rather wait for it to ship
> >>>> and commit balancers stuff thereafter.
> >>>>
> >>>> I think I will need about 2 or maybe 3 weeks to polish and test the
> >>>> code.
> >>>>
> >>>> Also, Paul had some concerns about 'lb' not being top-level module
> >>>> (libcloud.resource.lb as opposed to libcloud.lb). Any more thoughts
> on
> >>>> that?
> >>>
> >>> I agree with Paul—something that only supports a couple providers
> probably shouldn't be a top-level module. Also, I don't understand why it's
> called "lb"; it's completely non-descriptive and not even a common acronym.
> >>
> >> LB is actually a very common acronym in systems administration.
> >
> > +1, and although I have yet to grok the new module layout, perhaps we can
> throw it into something like libcloud.networking.lb?
> >
> > Yet, I am having a difficult time thinking of non-load balancer
> networking components currently available.
> >
>
> Well in EC2 you have Elastic IPs that could be managed inside a
> networking package.
>
> Grig
>
Re: [libcloud] Load Balancers support
Posted by Roman Bogorodskiy <bo...@gmail.com>.
Hi,
I'm glad to announce that I have merged Load Balancers support to trunk
yesterday. Everybody is welcome to start using, testing and
contributing.
Please don't hesitate to post your questions here on the maillist or
catch me on IRC (#libcloud on freenode) if you need support.
Roman Bogorodskiy
Re: [libcloud] Load Balancers support
Posted by Roman Bogorodskiy <bo...@gmail.com>.
Aymeric Barantal wrote:
> * use of location object to create a load balancer
> - Amazon elastic LB use availability zone like nodes at creation time.
Yes, I'm going to extend things to support locations for load balancers.
> * a concept, near the list_sizes Node component one, to choose a provider dependent way to abstract the whole LB rule to configure:
> - protocol (tcp / udp / http / ftp / ....) (level 4 or level 7 ones can cohabit
> - persistence mode (sticky and which type : vip, http_cookie, ...)
> - type of load balancing (round-robin, vip-src, etc)
> - type of healthcheck to use (tcp / ping / http get / ...)
> - others attributes provider specific or not
> - network topology (NAT/DSR/half-nat)
> - healtchecks properties (interval, timeout, ...)
> - price (???)
>
> To create a LB, we must pick a location and a "rule" in the catalog (IP/port still needed), driver will assemble all components involved (for example listener / healtcheck in amazon vocabulary).
>
> More capabilities of each providers should be accessible using such configuration catalog, I hope.
That sounds interesting. Some of the things like type of load balancing
and type of health check could be exposed as load balancer object
attributes I guess as it seems to be quite common to provide such
properties.
> my 2 cents, and this time my mail should be complete :)
It is, thank you for interesting comments!
Roman Bogorodskiy
Re: [libcloud] Load Balancers support
Posted by Aymeric Barantal <mr...@gandi.net>.
Le 14 avr. 2011 à 21:58, Roman Bogorodskiy a écrit :
> Tomaz Muraus wrote:
>
>> I am not totally sure, but for example, maybe we should also allow users to
>> pass in a Node object instead of the IP address to the balancer_attach_node
>> and other functions and the function would read private / public IP address
>> from the Node object.
>
> How do we understand if we should peak public or private address from
> the Node object?
Yes, node can have multiples IP address (private / public, ipv4 / ipv6) and we must explicitly define which IP of a node to be used in the load balancer definition. Check of the node status, or IP correctly attached, should be part of driver logic, depending on the provider.
libcloud.networking.lb sound a more natural namespace, within my experiences.
I also have some questions / remarks around reuse of others libcloud objects or concepts in this LB component.
* use of location object to create a load balancer
- Amazon elastic LB use availability zone like nodes at creation time.
* a concept, near the list_sizes Node component one, to choose a provider dependent way to abstract the whole LB rule to configure:
- protocol (tcp / udp / http / ftp / ....) (level 4 or level 7 ones can cohabit
- persistence mode (sticky and which type : vip, http_cookie, ...)
- type of load balancing (round-robin, vip-src, etc)
- type of healthcheck to use (tcp / ping / http get / ...)
- others attributes provider specific or not
- network topology (NAT/DSR/half-nat)
- healtchecks properties (interval, timeout, ...)
- price (???)
To create a LB, we must pick a location and a "rule" in the catalog (IP/port still needed), driver will assemble all components involved (for example listener / healtcheck in amazon vocabulary).
More capabilities of each providers should be accessible using such configuration catalog, I hope.
my 2 cents, and this time my mail should be complete :)
Aymeric
--
Senior Database Architect -- www.gandi.net
Re: [libcloud] Load Balancers support
Posted by Roman Bogorodskiy <bo...@gmail.com>.
Tomaz Muraus wrote:
> I am not totally sure, but for example, maybe we should also allow users to
> pass in a Node object instead of the IP address to the balancer_attach_node
> and other functions and the function would read private / public IP address
> from the Node object.
How do we understand if we should peak public or private address from
the Node object?
Roman Bogorodskiy
Re: [libcloud] Load Balancers support
Posted by Tomaz Muraus <to...@cloudkick.com>.
Replies are in-line.
On Wed, Apr 13, 2011 at 6:32 PM, Grig Gheorghiu <gr...@gmail.com>wrote:
> >>> I agree with Paul—something that only supports a couple providers
> probably shouldn't be a top-level module. Also, I don't understand why it's
> called "lb"; it's completely non-descriptive and not even a common acronym.
> >>
> >> LB is actually a very common acronym in systems administration.
> >
> > +1, and although I have yet to grok the new module layout, perhaps we can
> throw it into something like libcloud.networking.lb?
> >
> > Yet, I am having a difficult time thinking of non-load balancer
> networking components currently available.
> >
>
> Well in EC2 you have Elastic IPs that could be managed inside a
> networking package.
>
Correct, but the Elastic IP functionality is a bit different than the load
balancer one. Elastic IPs are tied to a Node and some of the functionality
already lives in the EC2 driver.
In contrast, the load balancer functionality is currently totally decoupled
from the Nodes.
I am not totally sure, but for example, maybe we should also allow users to
pass in a Node object instead of the IP address to the balancer_attach_node
and other functions and the function would read private / public IP address
from the Node object.
But, yeah, in general I am for the libcloud.networking.* namespace.
Grig
>
Re: [libcloud] Load Balancers support
Posted by Grig Gheorghiu <gr...@gmail.com>.
On Wed, Apr 13, 2011 at 9:29 AM, Jerry Chen <je...@apache.org> wrote:
>
> On Apr 13, 2011, at 11:25 AM, Grig Gheorghiu wrote:
>
>> On Wed, Apr 13, 2011 at 9:15 AM, Tom Davis <to...@dislocatedday.com> wrote:
>>> On Apr 13, 2011, at 12:29 AM, Roman Bogorodskiy <bo...@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Updates on load balancing support. What do I have now:
>>>>
>>>> * Functional GoGrid and Rackspace drivers
>>>> * Unit-tests for basic features
>>>>
>>>> Code is on github (as I mentioned before):
>>>>
>>>> https://github.com/novel/libcloud/compare/balancers
>>>>
>>>> It needs some more love for sure, but generally it's ready to hit main
>>>> repository, in my opinion.
>>>>
>>>> The only concern I have there is when we are going to ship 0.5.0? If
>>>> we're going to ship it really soonish, I'd rather wait for it to ship
>>>> and commit balancers stuff thereafter.
>>>>
>>>> I think I will need about 2 or maybe 3 weeks to polish and test the
>>>> code.
>>>>
>>>> Also, Paul had some concerns about 'lb' not being top-level module
>>>> (libcloud.resource.lb as opposed to libcloud.lb). Any more thoughts on
>>>> that?
>>>
>>> I agree with Paul—something that only supports a couple providers probably shouldn't be a top-level module. Also, I don't understand why it's called "lb"; it's completely non-descriptive and not even a common acronym.
>>
>> LB is actually a very common acronym in systems administration.
>
> +1, and although I have yet to grok the new module layout, perhaps we can throw it into something like libcloud.networking.lb?
>
> Yet, I am having a difficult time thinking of non-load balancer networking components currently available.
>
Well in EC2 you have Elastic IPs that could be managed inside a
networking package.
Grig
Re: [libcloud] Load Balancers support
Posted by Jerry Chen <je...@apache.org>.
On Apr 13, 2011, at 11:25 AM, Grig Gheorghiu wrote:
> On Wed, Apr 13, 2011 at 9:15 AM, Tom Davis <to...@dislocatedday.com> wrote:
>> On Apr 13, 2011, at 12:29 AM, Roman Bogorodskiy <bo...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Updates on load balancing support. What do I have now:
>>>
>>> * Functional GoGrid and Rackspace drivers
>>> * Unit-tests for basic features
>>>
>>> Code is on github (as I mentioned before):
>>>
>>> https://github.com/novel/libcloud/compare/balancers
>>>
>>> It needs some more love for sure, but generally it's ready to hit main
>>> repository, in my opinion.
>>>
>>> The only concern I have there is when we are going to ship 0.5.0? If
>>> we're going to ship it really soonish, I'd rather wait for it to ship
>>> and commit balancers stuff thereafter.
>>>
>>> I think I will need about 2 or maybe 3 weeks to polish and test the
>>> code.
>>>
>>> Also, Paul had some concerns about 'lb' not being top-level module
>>> (libcloud.resource.lb as opposed to libcloud.lb). Any more thoughts on
>>> that?
>>
>> I agree with Paul—something that only supports a couple providers probably shouldn't be a top-level module. Also, I don't understand why it's called "lb"; it's completely non-descriptive and not even a common acronym.
>
> LB is actually a very common acronym in systems administration.
+1, and although I have yet to grok the new module layout, perhaps we can throw it into something like libcloud.networking.lb?
Yet, I am having a difficult time thinking of non-load balancer networking components currently available.
Cheers,
Jerry
Re: [libcloud] Load Balancers support
Posted by Grig Gheorghiu <gr...@gmail.com>.
On Wed, Apr 13, 2011 at 9:15 AM, Tom Davis <to...@dislocatedday.com> wrote:
> On Apr 13, 2011, at 12:29 AM, Roman Bogorodskiy <bo...@gmail.com> wrote:
>
>> Hi,
>>
>> Updates on load balancing support. What do I have now:
>>
>> * Functional GoGrid and Rackspace drivers
>> * Unit-tests for basic features
>>
>> Code is on github (as I mentioned before):
>>
>> https://github.com/novel/libcloud/compare/balancers
>>
>> It needs some more love for sure, but generally it's ready to hit main
>> repository, in my opinion.
>>
>> The only concern I have there is when we are going to ship 0.5.0? If
>> we're going to ship it really soonish, I'd rather wait for it to ship
>> and commit balancers stuff thereafter.
>>
>> I think I will need about 2 or maybe 3 weeks to polish and test the
>> code.
>>
>> Also, Paul had some concerns about 'lb' not being top-level module
>> (libcloud.resource.lb as opposed to libcloud.lb). Any more thoughts on
>> that?
>
> I agree with Paul—something that only supports a couple providers probably shouldn't be a top-level module. Also, I don't understand why it's called "lb"; it's completely non-descriptive and not even a common acronym.
LB is actually a very common acronym in systems administration.
Grig
Re: [libcloud] Load Balancers support
Posted by Paul Querna <pa...@querna.org>.
On Wed, Apr 13, 2011 at 9:15 AM, Tom Davis <to...@dislocatedday.com> wrote:
> On Apr 13, 2011, at 12:29 AM, Roman Bogorodskiy <bo...@gmail.com> wrote:
>
>> Hi,
>>
>> Updates on load balancing support. What do I have now:
>>
>> * Functional GoGrid and Rackspace drivers
>> * Unit-tests for basic features
>>
>> Code is on github (as I mentioned before):
>>
>> https://github.com/novel/libcloud/compare/balancers
>>
>> It needs some more love for sure, but generally it's ready to hit main
>> repository, in my opinion.
>>
>> The only concern I have there is when we are going to ship 0.5.0? If
>> we're going to ship it really soonish, I'd rather wait for it to ship
>> and commit balancers stuff thereafter.
>>
>> I think I will need about 2 or maybe 3 weeks to polish and test the
>> code.
>>
>> Also, Paul had some concerns about 'lb' not being top-level module
>> (libcloud.resource.lb as opposed to libcloud.lb). Any more thoughts on
>> that?
>
> I agree with Paul—something that only supports a couple providers probably shouldn't be a top-level module. Also, I don't understand why it's called "lb"; it's completely non-descriptive and not even a common acronym.
Actually I thought it should be a top level module, and not under the
resources concept. It already has AWS, GoGrid and Rackspace.
I think naming it something more descriptive is better either way though.
loadbalancers is a mouthful, but shorter terms like 'balancers' don't
seem quite right either.
Re: [libcloud] Load Balancers support
Posted by Roman Bogorodskiy <bo...@gmail.com>.
Tom Davis wrote:
> I agree with Paul—something that only supports a couple providers probably shouldn't be a top-level module.
I think Paul had the opposite opinion.
Anyways, currently it's under 'resource.lb'. I don't think that it's
_that_ important to spend a lot of time discussing this (as it sounds
like a bikeshed color issue[1]). So I'd prefer to leave things as is
unless somebody has a strong reason against that.
> Also, I don't understand why it's called "lb"; it's completely non-descriptive and not even a common acronym.
What's the common acronym? http://en.wikipedia.org/wiki/Lb points to
'Load Balancing' in 'Science and Computing' section which makes me
think that it's more or less common.
I've though about other options. 'loadbalancers' is too long and too
much to type. 'balance' (the verb, like 'compute') and 'balancing'
(noun, like 'storage') doesn't give enough context to what we're
balancing.
Do you have an idea of a better name?
1: http://bikeshed.com/
Roman Bogorodskiy
Re: [libcloud] Load Balancers support
Posted by Tom Davis <to...@dislocatedday.com>.
On Apr 13, 2011, at 12:29 AM, Roman Bogorodskiy <bo...@gmail.com> wrote:
> Hi,
>
> Updates on load balancing support. What do I have now:
>
> * Functional GoGrid and Rackspace drivers
> * Unit-tests for basic features
>
> Code is on github (as I mentioned before):
>
> https://github.com/novel/libcloud/compare/balancers
>
> It needs some more love for sure, but generally it's ready to hit main
> repository, in my opinion.
>
> The only concern I have there is when we are going to ship 0.5.0? If
> we're going to ship it really soonish, I'd rather wait for it to ship
> and commit balancers stuff thereafter.
>
> I think I will need about 2 or maybe 3 weeks to polish and test the
> code.
>
> Also, Paul had some concerns about 'lb' not being top-level module
> (libcloud.resource.lb as opposed to libcloud.lb). Any more thoughts on
> that?
I agree with Paul—something that only supports a couple providers probably shouldn't be a top-level module. Also, I don't understand why it's called "lb"; it's completely non-descriptive and not even a common acronym.
>
> Roman Bogorodskiy
Re: [libcloud] Load Balancers support
Posted by Roman Bogorodskiy <bo...@gmail.com>.
Hi,
Updates on load balancing support. What do I have now:
* Functional GoGrid and Rackspace drivers
* Unit-tests for basic features
Code is on github (as I mentioned before):
https://github.com/novel/libcloud/compare/balancers
It needs some more love for sure, but generally it's ready to hit main
repository, in my opinion.
The only concern I have there is when we are going to ship 0.5.0? If
we're going to ship it really soonish, I'd rather wait for it to ship
and commit balancers stuff thereafter.
I think I will need about 2 or maybe 3 weeks to polish and test the
code.
Also, Paul had some concerns about 'lb' not being top-level module
(libcloud.resource.lb as opposed to libcloud.lb). Any more thoughts on
that?
Roman Bogorodskiy
Re: [libcloud] Load Balancers support
Posted by Aymeric Barantal <mr...@gandi.net>.
Hi all,
>
> I've closely looked at GoGrid balancers before starting an
> implementation. Actually, I was going to start with GoGrid driver first,
> but it happened that I need Rackspace balancers more currently. I think
> the abstraction used for balancers is more or less OK and wouldn't
> require major modifications for the new drivers.
I may help on some points for this loadbalancer API analysis. I'd designed
a LB service and I'd got a look of others providers API to be sure to not
reinvent a wheel.
From my point of view a main difference could occur in API usage switch we
consider a level 3/4 LB service or either a level 7 one (HTTP reverse proxy).
This could make this design difficult.
>
> I had a brief look at balancing service at Amazon and the object model
> they use is almost the same, but they expose this as WSDL, not REST.
They also have an HTTP interface with GET and POST verb, not strictly REST
but close enough to make such driver painless, I thinks (SOAP and
python is not always really an easy thing)
http://docs.amazonwebservices.com/ElasticLoadBalancing/latest/DeveloperGuide/index.html?Using_Query_API.html
I'll get a closer look of code proposal, and will report which points I can't
adapt easily to others API I know so far (mine included ;))
May we can provide another driver for l
Sincerly,
Aymeric Barantal (chamal)
--
Senior Database Architect -- www.gandi.net
Re: [libcloud] Load Balancers support
Posted by Roman Bogorodskiy <bo...@gmail.com>.
Tomaz Muraus wrote:
> Glad to see some new code and ideas flying in :)
>
> Here are some of my comments and concerns:
>
> - I have already posted this in my previous email, but imo we need a
> special place to put all those extra resources such as load balancers in.
> I don't think having a separate top-level module is acceptable, because
> there are many more resources we can implement, but most of them
> are relatively small compared to the compute and the storage API.
> We should probably move those resources to *
> libcloud.resources.{loadbalancer,ip,foobar}* or something like this?
Makes sense.
> - We should also limit which resources we will support and implement
> based on the number of providers which support them - e.g. if there are less
> than 3 providers, we shouldn't support it.
Load Balancers service is quite a common offering now.
> - I would vote to also research Amazon and GoGrid load balancer
> implementations before deciding how the final interface should look like,
> because there is a huge chance that your interface is currently biased
> towards the Rackspace API.
I've closely looked at GoGrid balancers before starting an
implementation. Actually, I was going to start with GoGrid driver first,
but it happened that I need Rackspace balancers more currently. I think
the abstraction used for balancers is more or less OK and wouldn't
require major modifications for the new drivers.
I had a brief look at balancing service at Amazon and the object model
they use is almost the same, but they expose this as WSDL, not REST.
Unfortunately, I don't have neither need to use Amazon balancers nor
possibility to have an account there (they don't accept my credit card
for my reason).
> - I will post some code comments in-line on github later on. In general
> it looks OK, but there are some minor styling issues, missing __ALL__
> statements and a few places with a repeated code.
Ok.
> - Tests - yeah, for the new things we should aim for a test coverage of
> 95% and above.
Coverage of 95% is too strict in my opinion, esp. considering that most
features are very easy to test at runtime. I think a rule of thumb that
all major components should be covered with test without going with
exact numbers etc.
Thanks for feedback,
Roman Bogorodskiy
Re: [libcloud] Load Balancers support
Posted by Tomaz Muraus <to...@cloudkick.com>.
Glad to see some new code and ideas flying in :)
Here are some of my comments and concerns:
- I have already posted this in my previous email, but imo we need a
special place to put all those extra resources such as load balancers in.
I don't think having a separate top-level module is acceptable, because
there are many more resources we can implement, but most of them
are relatively small compared to the compute and the storage API.
We should probably move those resources to *
libcloud.resources.{loadbalancer,ip,foobar}* or something like this?
- We should also limit which resources we will support and implement
based on the number of providers which support them - e.g. if there are less
than 3 providers, we shouldn't support it.
- I would vote to also research Amazon and GoGrid load balancer
implementations before deciding how the final interface should look like,
because there is a huge chance that your interface is currently biased
towards the Rackspace API.
- I will post some code comments in-line on github later on. In general
it looks OK, but there are some minor styling issues, missing __ALL__
statements and a few places with a repeated code.
- Tests - yeah, for the new things we should aim for a test coverage of
95% and above.
On Tue, Apr 5, 2011 at 12:10 AM, Roman Bogorodskiy <bo...@gmail.com>wrote:
> Hi,
>
> I've started implementing load balancers support. Currently this code
> lives in 'balancers' branch on my github fork of libcloud:
>
> https://github.com/novel/libcloud/tree/balancers
>
> I've added an example how to work with this:
>
> https://github.com/novel/libcloud/blob/balancers/example_lb.py
>
> All balancer-related code lives here:
>
> https://github.com/novel/libcloud/tree/balancers/libcloud/lb
>
> If you check the code you will see that I used Rackspace balancers as a
> starting point.
>
> My further plan for balancers:
>
> * cover the new code with unit tests and refine documentation
> * merge to svn
> * implement GoGrid driver for balancers (probably will have to make
> minor adjustments to interface)
>
> Feedback is welcome!
>
> Roman Bogorodskiy
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQEcBAEBAgAGBQJNmkHXAAoJEMltX/4IwiJqdWYH/3aF6Yv5HefV0GYJgOf+SPSu
> VKE34q95APb0Buk+Xe6IOfDl5XbMvrvMisMw6JniX3ppfZxD0Arl3QuUt4e+xwGl
> NW26TRw0maaPkYMpfgiS04Y9HNDdO3jDAZCS+FJHoSjfqPKq2mR7hmr75gBkZnYr
> jmd4fFWarU/5BTDtweiPIMe0DKe4QDSL6vN8I8YuYkzheJIbkoVE/KAi7SLUZt6o
> 69VgoOTQzthHflU1CbTFl5AZHYbPF8sNPgFxT9lKaWRndWX2k5dOJnf25Nozrlbd
> jqu0eQ7nlwwvgJHLiTzLUd8eMsO9m37GxyQNCd3nulL/X02/4WTxmqGOAL/XpFo=
> =+09i
> -----END PGP SIGNATURE-----
>
>