Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo

[Adam Harwell]

Octavia relies heavily on Taskflow and Futurist as well. Personally I agree
with basically everything Monty said earlier. The problem here really isn't
anything besides relaxing the social review policy, which is as simple as
just deciding it as a team and saying "well, ok then". :)

I also use a number of openstack libs outside of openstack to great effect
and have had no problems to speak of, so I don't really think this should
be a concern. I know it can be daunting to first enter the dev/review
process because it is so different from the workflow most people are used
to, but this is a problem that can be solved by having good docs (I think
the existing developer quickstart docs are very effective) and maintaining
an open and welcoming community.

--Adam

On Thu, Oct 18, 2018, 16:32 Dmitry Tantsur  wrote:

> On 10/17/18 5:59 PM, Joshua Harlow wrote:
> > Dmitry Tantsur wrote:
> >> On 10/10/18 7:41 PM, Greg Hill wrote:
> >>> I've been out of the openstack loop for a few years, so I hope this
> >>> reaches the right folks.
> >>>
> >>> Josh Harlow (original author of taskflow and related libraries) and I
> >>> have been discussing the option of moving taskflow out of the
> >>> openstack umbrella recently. This move would likely also include the
> >>> futurist and automaton libraries that are primarily used by taskflow.
> >>
> >> Just for completeness: futurist and automaton are also heavily relied on
> >> by ironic without using taskflow.
> >
> > When did futurist get used??? nice :)
> >
> > (I knew automaton was, but maybe I knew futurist was to and I forgot,
> lol).
>
> I'm pretty sure you did, it happened back in Mitaka :)
>
> >
> >>
> >>> The idea would be to just host them on github and use the regular
> >>> Github features for Issues, PRs, wiki, etc, in the hopes that this
> >>> would spur more development. Taskflow hasn't had any substantial
> >>> contributions in several years and it doesn't really seem that the
> >>> current openstack devs have a vested interest in moving it forward. I
> >>> would like to move it forward, but I don't have an interest in being
> >>> bound by the openstack workflow (this is why the project stagnated as
> >>> core reviewers were pulled on to other projects and couldn't keep up
> >>> with the review backlog, so contributions ground to a halt).
> >>>
> >>> I guess I'm putting it forward to the larger community. Does anyone
> >>> have any objections to us doing this? Are there any non-obvious
> >>> technicalities that might make such a transition difficult? Who would
> >>> need to be made aware so they could adjust their own workflows?
> >>>
> >>> Or would it be preferable to just fork and rename the project so
> >>> openstack can continue to use the current taskflow version without
> >>> worry of us breaking features?
> >>>
> >>> Greg
> >>>
> >>>
> >>>
> __
> >>>
> >>> 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
>
__
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] [kolla][octavia] Containerize the amphora-agent

[Adam Harwell]

I was coming to the same conclusion for a completely different goal --
baking lighter weight VMs (and eliminating a number of compatibility
issues) by putting exactly what we need in containers and making the base
OS irrelevant. So, I am interested in helping to do this in a way that will
work well for both goals.
My thought is that containerizing the agent AND using (existing?)
containerized haproxy distributions, we can better standardize things
between different amphora base OSes at the same time as setting up for full
containerization.
We should discuss further on IRC next week maybe, if we can find a good
time.

   --Adam

On Sun, Sep 30, 2018, 11:56 Hongbin Lu  wrote:

> Hi all,
>
> I am working on the Zun integration for Octavia. I did a preliminary
> research and it seems what we need to do is to containerize the amphora
> agent that was packaged and shipped by a VM image. I wonder if anyone
> already has a containerized docker image that I can leverage. If not, I
> will create one.
>
> Best regards,
> Hongbin
> __
> 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] Optimize the query of the octavia database

[Adam Harwell]

It's high priority for me as well, so we should be able to get something
done very soon, I think. Look for something early next week maybe?

Thanks,
--Adam

On Thu, Sep 13, 2018, 21:18 Jeff Yang  wrote:

> Thanks:
> I found the correlative patch in neutron-lbaas:
> https://review.openstack.org/#/c/568361/
>
> The bug was marked high level by our QA team. I need to fix it as soon
> as possible.
>  Does Michael Johnson have any good suggestion? I am willing to
> complete the
>  repair work of this bug. If your patch still takes a while to prepare.
>
> Michael Johnson  于2018年9月14日周五 上午7:56写道：
>
>> This is a known regression in the Octavia API performance. It has an
>> existing story[0] that is under development. You are correct, that
>> star join is the root of the problem.
>> Look for a patch soon.
>>
>> [0] https://storyboard.openstack.org/#!/story/2002933
>>
>> Michael
>> On Thu, Sep 13, 2018 at 10:32 AM Erik Olof Gunnar Andersson
>>  wrote:
>> >
>> > This was solved in neutron-lbaas recently, maybe we could adopt the
>> same method for Octavia?
>> >
>> > Sent from my iPhone
>> >
>> > On Sep 13, 2018, at 4:54 AM, Jeff Yang  wrote:
>> >
>> > Hi, All
>> >
>> > As octavia resources increase, I found that running the "openstack
>> loadbalancer list" command takes longer and longer. Sometimes a 504 error
>> is reported.
>> >
>> > By reading the code, I found that octavia will performs complex left
>> outer join queries when acquiring resources such as loadbalancer, listener,
>> pool, etc. in order to only make one trip to the database.
>> > Reference code: http://paste.openstack.org/show/730022 Line 133
>> > Generated SQL statements: http://paste.openstack.org/show/730021
>> >
>> > So, I suggest that adjust the query strategy to provide different join
>> queries for different resources.
>> >
>> > https://storyboard.openstack.org/#!/story/2003751
>> >
>> >
>> __
>> > 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
>
__
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] Proposing Carlos Goncalves (cgoncalves) as an Octavia core reviewer

[Adam Harwell]

+1 for sure!

On Sat, Sep 1, 2018, 01:41 Carlos Goncalves  wrote:

> Ha! Gracias for the kind words, Miguel! :-)
>
> On Fri, Aug 31, 2018 at 5:55 PM, Miguel Lavalle 
> wrote:
>
>> Well, I don't vote here but I stiil want to express my +1. I knew this
>> was going to happen sooner rather than later
>>
>> On Thu, Aug 30, 2018 at 10:24 PM, Michael Johnson 
>> wrote:
>>
>>> Hello Octavia community,
>>>
>>> I would like to propose Carlos Goncalves as a core reviewer on the
>>> Octavia project.
>>>
>>> Carlos has provided numerous enhancements to the Octavia project,
>>> including setting up the grenade gate for Octavia upgrade testing.
>>>
>>> Over the last few releases he has also been providing quality reviews,
>>> in line with the other core reviewers [1]. I feel that Carlos would
>>> make an excellent addition to the Octavia core reviewer team.
>>>
>>> Existing Octavia core reviewers, please reply to this email with your
>>> support or concerns with adding Jacky to the core team.
>>>
>>> Michael
>>>
>>> [1] http://stackalytics.com/report/contribution/octavia-group/90
>>>
>>>
>>> __
>>> 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] [kolla][ptg] Denver PTG on-site or virtual

[Adam Harwell]

Yeah, definitely! Worst case, we spend some time huddled around a table by
the bar, and that isn't too bad in my book. ;)

   --Adam

On Fri, Aug 17, 2018, 20:59 Mark Goddard  wrote:

> Whether there is a physical PTG session or not, I'd certainly like to meet
> up with other folks who are using and/or contributing to Kolla, let's be
> sure to make time for that.
> Mark
>
> On 17 August 2018 at 12:54, Adam Harwell  wrote:
>
>> As one of the other two in the etherpad, I will say that I was looking
>> forward to getting together face to face with other contributors for the
>> first time (as I am new to the project), but I guess the majority won't
>> actually be there, and I understand that we need to do what is best for the
>> majority as well.
>> I know that at least one or maybe two other people from my team were also
>> planning to attend some Kolla sessions, so I'll see if I can get them to
>> sign up.
>> The other projects I'll be focused on are Octavia and Barbican, and I
>> know both have been successful with a hybrid approach in the past
>> (providing video of the room and allowing folks to dial in and contribute,
>> while also having a number of people present physically).
>> Since the room is already reserved, I don't see a huge point in avoiding
>> its use either.
>>
>>--Adam
>>
>>
>> On Fri, Aug 17, 2018, 20:27 Mark Goddard  wrote:
>>
>>> As one of the lucky three kolleagues able to make the PTG, here's my
>>> position (inline).
>>>
>>> On 17 August 2018 at 11:52, Eduardo Gonzalez  wrote:
>>>
>>>> Fellow kolleages.
>>>>
>>>> In september is Denver PTG, as per the etherpad [0] only 3 contributors
>>>> confirmed their presence in the PTG, we expected more people to be there as
>>>> previous PTGs were full of contributors and operators.
>>>>
>>>> In the last kolla meeting [1] with discussed if we should make a
>>>> virtual PTG rather than a on-site one as we will probably reach a bigger
>>>> number of attendance.
>>>>
>>>> This set us in a bad possition as per:
>>>>
>>>> If we do an on-site PTG
>>>>
>>>> - Small representation for a whole cycle design, being this one larger
>>>> than usual.
>>>> - Many people whiling to attend is not able to be there.
>>>>
>>>
>>> I agree that three is too small a number to justify an on-site PTG. I
>>> was planning to split my time between kolla and ironic, so being able to
>>> focus on one project would be beneficial to me, assuming the virtual PTG
>>> takes place at a different time. I could still split my time if the virtual
>>> PTG occurs at the same time.
>>>
>>>
>>>>
>>>> If we do a virtual PTG
>>>>
>>>> - Some people already spend money to travel for kolla PTG
>>>>
>>>
>>> I would be going anyway.
>>>
>>>
>>>> - PTG rooms are already reserved for kolla session
>>>>
>>>
>>> If the virtual PTG occurs at the same time, we could use the
>>> (oversized) reserved room to dial into calls.
>>>
>>> - No cross project discussion
>>>>
>>>
>>> Happy to attend on behalf of kolla and feed back to the team.
>>>
>>>>
>>>> If there are more people who is going to Denver and haven't signed up
>>>> at the etherpad, please confirm your presence as it will probably influence
>>>> on this topic.
>>>>
>>>> Here is the though question...
>>>>
>>>> What kind of PTG do you prefer for this one, virtual or on-site in
>>>> Denver?
>>>>
>>>
>>> Virtual makes sense to me.
>>>
>>>>
>>>> CC to Kendall Nelson from the foundation if she could help us on this
>>>> though decission, given the small time we have until the PTG both ways have
>>>> some kind of bad consecuencies for both the project and the contributors.
>>>>
>>>> [0] https://etherpad.openstack.org/p/kolla-stein-ptg-planning
>>>> [1]
>>>> http://eavesdrop.openstack.org/meetings/kolla/2018/kolla.2018-08-15-15.00.log.html#l-13
>>>>
>>>> Regards
>>>>
>>>>
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> op

Re: [openstack-dev] [kolla][ptg] Denver PTG on-site or virtual

[Adam Harwell]

As one of the other two in the etherpad, I will say that I was looking
forward to getting together face to face with other contributors for the
first time (as I am new to the project), but I guess the majority won't
actually be there, and I understand that we need to do what is best for the
majority as well.
I know that at least one or maybe two other people from my team were also
planning to attend some Kolla sessions, so I'll see if I can get them to
sign up.
The other projects I'll be focused on are Octavia and Barbican, and I know
both have been successful with a hybrid approach in the past (providing
video of the room and allowing folks to dial in and contribute, while also
having a number of people present physically).
Since the room is already reserved, I don't see a huge point in avoiding
its use either.

   --Adam

On Fri, Aug 17, 2018, 20:27 Mark Goddard  wrote:

> As one of the lucky three kolleagues able to make the PTG, here's my
> position (inline).
>
> On 17 August 2018 at 11:52, Eduardo Gonzalez  wrote:
>
>> Fellow kolleages.
>>
>> In september is Denver PTG, as per the etherpad [0] only 3 contributors
>> confirmed their presence in the PTG, we expected more people to be there as
>> previous PTGs were full of contributors and operators.
>>
>> In the last kolla meeting [1] with discussed if we should make a virtual
>> PTG rather than a on-site one as we will probably reach a bigger number of
>> attendance.
>>
>> This set us in a bad possition as per:
>>
>> If we do an on-site PTG
>>
>> - Small representation for a whole cycle design, being this one larger
>> than usual.
>> - Many people whiling to attend is not able to be there.
>>
>
> I agree that three is too small a number to justify an on-site PTG. I was
> planning to split my time between kolla and ironic, so being able to focus
> on one project would be beneficial to me, assuming the virtual PTG takes
> place at a different time. I could still split my time if the virtual PTG
> occurs at the same time.
>
>
>>
>> If we do a virtual PTG
>>
>> - Some people already spend money to travel for kolla PTG
>>
>
> I would be going anyway.
>
>
>> - PTG rooms are already reserved for kolla session
>>
>
> If the virtual PTG occurs at the same time, we could use the (oversized)
> reserved room to dial into calls.
>
> - No cross project discussion
>>
>
> Happy to attend on behalf of kolla and feed back to the team.
>
>>
>> If there are more people who is going to Denver and haven't signed up at
>> the etherpad, please confirm your presence as it will probably influence on
>> this topic.
>>
>> Here is the though question...
>>
>> What kind of PTG do you prefer for this one, virtual or on-site in Denver?
>>
>
> Virtual makes sense to me.
>
>>
>> CC to Kendall Nelson from the foundation if she could help us on this
>> though decission, given the small time we have until the PTG both ways have
>> some kind of bad consecuencies for both the project and the contributors.
>>
>> [0] https://etherpad.openstack.org/p/kolla-stein-ptg-planning
>> [1]
>> http://eavesdrop.openstack.org/meetings/kolla/2018/kolla.2018-08-15-15.00.log.html#l-13
>>
>> Regards
>>
>> __
>> 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] [tripleo] [barbican] [tc] key store in base services

[Adam Harwell]

Looks like I missed this so I'm late to the party, but:

Ade is technically correct, Octavia doesn't explicitly depend on Barbican,
as we do support castellan generically.

*HOWEVER*: we don't just store and retrieve our own secrets -- we rely on
loading up user created secrets. This means that for Octavia to work, even
if we use castellan, we still need some way for users to interact with the
secret store via an API, and what that means in openstack in still
Barbican. So I would still say that Barbican is a dependency for us
logistically, if not technically.

For example, internally at GoDaddy we were investigating deploying Vault
with a custom user-facing API/UI for allowing users to store secrets that
could be consumed by Octavia with castellan (don't get me started on how
dumb that is, but it's what we were investigating).
The correct way to do this in an openstack environment is the openstack
secret store API, which is Barbican. So, while I am personally dealing with
an example of very painfully avoiding Barbican (which may have been a
non-issue if Barbican were a base service), I have a tough time reconciling
not including Barbican itself as a requirement.

   --Adam (rm_work)

On Wed, Jun 20, 2018, 11:37 Jeremy Stanley  wrote:

> On 2018-06-06 01:29:49 + (+), Jeremy Stanley wrote:
> [...]
> > Seeing no further objections, I give you
> > https://review.openstack.org/572656 for the next step.
>
> That change merged just a few minutes ago, and
>
> https://governance.openstack.org/tc/reference/base-services.html#current-list-of-base-services
> now includes:
>
> A Castellan-compatible key store
>
> OpenStack components may keep secrets in a key store, using
> Oslo’s Castellan library as an indirection layer. While
> OpenStack provides a Castellan-compatible key store service,
> Barbican, other key store backends are also available for
> Castellan. Note that in the context of the base services set
> Castellan is intended only to provide an interface for services
> to interact with a key store, and it should not be treated as a
> means to proxy API calls from users to that key store. In order
> to reduce unnecessary exposure risks, any user interaction with
> secret material should be left to a dedicated API instead
> (preferably as provided by Barbican).
>
> Thanks to everyone who helped brainstorming/polishing, and here's
> looking forward to a ubiquity of default security features and
> functionality in future OpenStack releases!
> --
> Jeremy Stanley
> __
> 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] Multiple availability zone and network region support

[Adam Harwell]

I have a patch up here for multi AZ: https://review.openstack.org/558962

But, it doesn't really handle other networks... It works for me because I
use my own L3 network driver: https://review.openstack.org/435612

It might be possible to use it with an AZ aware networking driver as well?
If you wanted to contribute something like that, please do! It's probably
not going to be possible with anything L2 though...

Good luck,
--Adam (rm_work)

On Fri, May 25, 2018, 04:19  wrote:

> Hello,
>
>
>
> Is there any way to set up Octavia so that we are able to launch amphora
> in different AZs and connected to different network per each AZ?
>
>
>
> Than you,
>
> Mihaela Balas
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
> __
> 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] Proposing Jacky Hu (dayou) as an Octavia core reviewer

[Adam Harwell]

+1, definitely a good contributor! Thanks especially for your work on the
dashboard!

On Tue, Mar 27, 2018 at 2:09 PM German Eichberger <
german.eichber...@rackspace.com> wrote:

> +1
>
> Really excited to work with Jacky --
>
> German
>
> On 3/26/18, 8:33 PM, "Michael Johnson"  wrote:
>
> Hello Octavia community,
>
> I would like to propose Jacky Hu (dayou) as a core reviewer on the
> Octavia project.
>
> Jacky has done amazing work on Octavia dashboard, specifically
> updating the look and feel of our details pages to be more user
> friendly.  Recently he has contributed support for L7 policies in the
> dashboard and caught us up with the wider Horizon framework advances.
>
> Jacky has also contributed thoughtful reviews on the main Octavia
> project as well as contributed to the L3 Active/Active work in
> progress.
>
> Jacky's review statistics are in line with the other core reviewers
> [1] and I feel Jacky would make a great addition to the Octavia core
> reviewer team.
>
> Existing Octavia core reviewers, please reply to this email with your
> support or concerns with adding Jacky to the core team.
>
> Michael
>
> [1] http://stackalytics.com/report/contribution/octavia-group/90
>
>
> __
> 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] Proposing Nir Magnezi as Octavia core reviewer

[Adam Harwell]

+1

On Thu, Oct 5, 2017, 05:48 Daniel Mellado 
wrote:

> +1
>
> Go, Nir, Go!
>
> congrats!
>
> On 10/05/2017 03:51 AM, German Eichberger wrote:
> > +1
> >
> > Welcome Nir, well earned.
> >
> > German
> >
> > On 10/4/17, 4:28 PM, "Michael Johnson"  wrote:
> >
> > Hello OpenStack folks,
> >
> > I would like to propose Nir Magnezi as a core reviewer on the
> Octavia project.
> >
> > He has been an active contributor to the Octavia projects for a few
> > releases and has been providing solid patch review comments. His
> > review stats are also in line with other core reviewers.
> >
> > Octavia cores, please reply to this e-mail with your
> > agreement/disagreement to this proposal.
> >
> > Michael
> >
> >
>  __
> > 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] [octavia] haproxy fails to receive datagram

[Adam Harwell]

When was the old image built and when was the new one built? I noticed my
images had stopped working on our older (Liberty) production cloud, and
discovered that recently Ubuntu and Centos have both upgraded cloud-init to
0.7.9 in their base images (from something like 0.7.5), which finished the
deprecation of the old cloud-init config format that our older cloud
injects. If they're booting in Nova but not allowing connections, see if
you can console in or inspect the logs. Cloud-init was not bringing up the
networking properly on the old version for me.

On Sun, Oct 8, 2017, 02:59 Yipei Niu  wrote:

> Hi, Michael,
>
> I once installed a successful environment, so I move the amphora image of
> the environment to my latest environment which doesn’t work. I create a
> load balancer in the latest environment using the old amphora image, and it
> works.
>
> So I think there is some problem with the amphora image of my latest
> environment. The detailed info of my amphora image is as follows.
>
> stack@VM-IP10:~$ glance image-show 3bc4a09e-86b5-4e54-b468-b3d9c7ac8607
> +--+--+
> | Property | Value|
> +--+--+
> | checksum | 4bd41781226068fe91bf181efd2df8c3 |
> | container_format | bare |
> | created_at   | 2017-09-28T02:50:48Z |
> | disk_format  | qcow2|
> | id   | 3bc4a09e-86b5-4e54-b468-b3d9c7ac8607 |
> | min_disk | 0|
> | min_ram  | 0|
> | name | amphora-x64-haproxy  |
> | owner| 01fd6fdee6ba436abe1a4bfe5defeea2 |
> | protected| False|
> | size | 678293504|
> | status   | active   |
> | tags | ["amphora"]  |
> | updated_at   | 2017-09-28T02:51:13Z |
> | virtual_size | None |
> | visibility   | public   |
> +--+———+
>
> Is the checksum the same to yours?
>
> Best regards,
> Yipei
> __
> 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] [forum] Future of Stackalytics

[Adam Harwell]

I wish I'd made it to that Forum session, but here's my two cents now:

As a core reviewer for LBaaS I actually find Stackalytics quite helpful for
giving me a quick snapshot of contributions, and it lines up almost
perfectly in my experience with what I see when I'm actually reviewing and
working with people (if you know which statistics to look at -- just
sorting by sheer number of reviews or commits and ignoring everything else
is of course not useful, and as you say possibly misleading). In all though
I actually find that it is a very accurate representation of people's work.

For example, in looking at reviewer contributions, I make a mental score
based on both the number of reviews, but also the +% (this shouldn't be too
high) and the disagreement score (low is generally good, but 0% with a high
review count might be questionable). So, I know to discount someone who
just spams +1 at everything that has a +2 already and doesn't contribute
anything else, which can go unnoticed while reading reviews but sticks out
like a sore thumb in Stackalytics. The other side of the coin is someone
who posts a ton of useless comments and -1's everything, which then is
super obvious to anyone who actually reads reviews.

Maybe the experience with the projects I work on is a little different than
some of the more populous "base" services like Nova or Neutron? Regardless,
I'd be really sad to see it go, as I use it multiple times a week for
various reasons. So, I definitely agree with keeping it around and possibly
focusing on improving the way the data is displayed. It is definitely best
used as one tool in a toolkit, not taken alone as a single source of truth.
Is that the main problem people are trying to solve?

   --Adam

On Wed, Jun 7, 2017, 16:38 Ken'ichi Ohmichi  wrote:

> 2017-05-17 11:55 GMT-07:00 Jeremy Stanley :
> > On 2017-05-17 16:16:30 +0200 (+0200), Thierry Carrez wrote:
> > [...]
> >> we need help with completing the migration to infra. If interested
> >> you can reach out to fungi (Infra team PTL) nor mrmartin (who
> >> currently helps with the transition work).
> > [...]
> >
> > The main blocker for us right now is addressed by an Infra spec
> > (Stackalytics is an unofficial project and it's unclear to us where
> > design discussions for it happen):
> >
> > https://review.openstack.org/434951
>
> I also want to find a good design discussion space for stackalytics future.
> For example, one of config files is 30KL due to much user information
> and that makes the maintenance hard now.
> I am trying to separate user part from the existing file but I cannot
> find the way to make a consensus for such thing.
> In addition, we have two ways for managing bug reports: launchpad and
> storyboard if considering it as infra project.
> It would be necessary to transport them from launchpad, I guess.
>
> > In particular, getting the current Stackalytics developers on-board
> > with things like this is where we've been failing to make progress
> > mainly (I think) because we don't have a clear venue for discussions
> > and they're stretched pretty thin with other work. If we can get
> > some additional core reviewers for that project (and maybe even talk
> > about turning it into an official team or joining them up as a
> > deliverable for an existing team) that might help.
>
> Yeah, diversity will be great for our future.
>
> Thanks
>
> __
> 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] [oslo][barbican][castellan] Proposal to rename Castellan to oslo.keymanager

[Adam Harwell]

I have been a fan of this from the very beginning of the project as well. I
think oslo is the obvious correct place for a library that should define
core interfaces for use by many openstack projects.

Also, whether you have seen it or not, I have *definitely* seen real
instances where people shied away from using castellan or contributing to
it because it seemed "no different than just barbican, created and owned by
the same people". That was never the goal, and though it's difficult to
point to specific instances, there were many times during discussions that
I thought explaining it was part of oslo would have totally changed the
tone and direction of the conversation.

The naming of things is no joke -- there is significant psychological
emphasis given to the "name of a thing" that can be seen in many cultures
all through literature and tradition. Some of you may think of this as a
meaningless gesture, but I am personally very sure it is not.

+1 from me as an interested user/contributor. Personally I'd go in for the
complete rename to oslo.keymanager, but just oslo is a good start.

--Adam Harwell

On Wed, Mar 22, 2017, 00:34 Flavio Percoco <fla...@redhat.com> wrote:

> On 16/03/17 12:43 -0400, Davanum Srinivas wrote:
> >+1 from me to bring castellan under Oslo governance with folks from
> >both oslo and Barbican as reviewers without a project rename. Let's
> >see if that helps get more adoption of castellan
>
> This sounds like a great path forward! +1
>
> Flavio
>
> >Thanks,
> >Dims
> >
> >On Thu, Mar 16, 2017 at 12:25 PM, Farr, Kaitlin M.
> ><kaitlin.f...@jhuapl.edu> wrote:
> >> This thread has generated quite the discussion, so I will try to
> >> address a few points in this email, echoing a lot of what Dave said.
> >>
> >> Clint originally explained what we are trying to solve very well. The
> hope was
> >> that the rename would emphasize that Castellan is just a basic
> >> interface that supports operations common between key managers
> >> (the existing Barbican back end and other back ends that may exist
> >> in the future), much like oslo.db supports the common operations
> >> between PostgreSQL and MySQL. The thought was that renaming to have
> >> oslo part of the name would help reinforce that it's just an interface,
> >> rather than a standalone key manager. Right now, the only Castellan
> >> back end that would work in DevStack is Barbican. There has been talk
> >> in the past for creating other Castellan back ends (Vault or Tang), but
> >> no one has committed to writing the code for those yet.
> >>
> >> The intended proposal was to rename the project, maintain the current
> >> review team (which is only a handful of Barbican people), and bring on
> >> a few Oslo folks, if any were available and interested, to give advice
> >> about (and +2s for) OpenStack library best practices. However, perhaps
> >> pulling it under oslo's umbrella without a rename is blessing it enough.
> >>
> >> In response to Julien's proposal to make Castellan "the way you can do
> >> key management in Python" -- it would be great if Castellan were that
> >> abstract, but in practice it is pretty OpenStack-specific. Currently,
> >> the Barbican team is great at working on key management projects
> >> (including both Barbican and Castellan), but a lot of our focus now is
> >> how we can maintain and grow integration with the rest of the OpenStack
> >> projects, for which having the name and expertise of oslo would be a
> >> great help.
> >>
> >> Thanks,
> >>
> >> Kaitlin
> >>
> __
> >> 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
> >
> >
> >
> >--
> >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
>
> --
> @flaper87
> Flavio Percoco
> __
> 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][barbican][octavia]certs don't get deregistered in barbican after lbaas listener delete

[Adam Harwell]

Yeah, I believe it was because we intended to leave it up to the specific
certificate manager to determine what needs to be done -- we are treating
it as a delete, and if the cert manager wants to do a true delete, they
can. I'll agree the verb is not perfectly clear, but the driver author
should make sure the correct action is taken regardless of the function
name.

It's possible we should just rename the function to something like
"unget_cert", which sounds a bit nonsensical but is possibly still clearer.
I remember at the time I wrote this being frustrated with trying to name
the function and wanting to just move on. T_T

   --Adam (rm_work)

PS: Did we remove the local cert manager yet? Now I need to check... I hope
so, because it's not actually usable, nor can it be without API
modifications (which we discussed but never actually implemented or even
fully agreed on).

On Wed, Jan 25, 2017, 17:50 Jiahao Liang (Frankie) <gzliangjia...@gmail.com>
wrote:

> Thanks rm_work.
>
> I also notice something need to be handled properly.
>
> For barbican, the delete_cert() only deregisters the cert without actually
> delete it. That's safe for us to call during
> delete_listener()/delete_loadbalancer().
>
> But if the user uses other cert_manager by any chance, say the
> local_cert_manager, the same delete_cert() method will do a real delete of
> the cert.
>
> Probably we need to implement register_consumer()/remove_consumer() method
> for cert_manager and call them in neutron_lbaas as well.
>
>
> On Wed, Jan 25, 2017 at 10:48 Adam Harwell <flux.a...@gmail.com> wrote:
>
> I've got this on my list of things to look at -- I don't know if it was
> you I was talking with on IRC the other day about this issue, but I'm
> definitely aware of it. As soon as we are past the Ocata feature freeze
> crunch, I'll take a closer look.
>
> My gut says that we should be calling the delete (which is not a real
> delete) when the LB is deleted, and not doing so is a bug, but I'll need to
> double check the logic as it has been a while since I touched this.
>
> --Adam (rm_work)
>
> On Mon, Jan 23, 2017, 18:38 Jiahao Liang (Frankie) <
> gzliangjia...@gmail.com> wrote:
>
> Hi community,
>
> I created a loadbalancer with a listener with protocol as
> "TERMINATED_HTTPS" and specify --default-tls-container-ref with a ref of
> secret container from Barbican.
> However, after I deleted the listener, the lbaas wasn't removed from
> barbican container consumer list.
>
> $openstack secret container get
> http://192.168.20.24:9311/v1/containers/453e8905-d42b-43bd-9947-50e3acf499f4
>
> ++-+
> | Field  | Value
> |
>
> ++-+
> | Container href |
> http://192.168.20.24:9311/v1/containers/453e8905-d42b-43bd-9947-50e3acf499f4
>|
> | Name   | tls_container2
>  |
> | Created| 2017-01-19 12:44:07+00:00
> |
> | Status | ACTIVE
>  |
> | Type   | certificate
> |
> | Certificate|
> http://192.168.20.24:9311/v1/secrets/bfc2bf01-0f23-4105-bf09-c75839b6b4cb
>   |
> | Intermediates  | None
>  |
> | Private Key|
> http://192.168.20.24:9311/v1/secrets/c85d150e-ec84-42e0-a65f-9c9ec19767e1
>   |
> | PK Passphrase  | None
>  |
> | *Consumers  | {u'URL':
> u'lbaas://RegionOne/loadbalancer/5e7768b9-7aa9-4146-8a71-6291353b447e',
> u'name': u'lbaas'}*
>
>
> I went through the neutron-lbaas code base. We did register consumer
> during the creation of "TERMINATED_HTTPS" listener in [1]. But we somehow
> doesn't deregister it during the deletion in [1]:
> https://github.com/openstack/neutron-lbaas/blob/stable/mitaka/neutron_lbaas/services/loadbalancer/plugin.py#L642
> get_cert() register lbaas as a consumer for barbican cert_manager.  (
> https://github.com/openstack/neutron-lbaas/blob/stable/mitaka/neutron_lbaas/common/cert_manager/barbican_cert_manager.py#L177
> )
> [2]:
> https://github.com/openstack/neutron-lbaas/blob/stable/mitaka/neutron_lbaas/services/loadbalancer/plugin.py#L805
> we probably need to call delete_cert from barbican cert_manager to remove
> the consumer. (
> https://github.com/openstack/neutron-l

Re: [openstack-dev] [neutron-lbaas][barbican][octavia]certs don't get deregistered in barbican after lbaas listener delete

[Adam Harwell]

I've got this on my list of things to look at -- I don't know if it was you
I was talking with on IRC the other day about this issue, but I'm
definitely aware of it. As soon as we are past the Ocata feature freeze
crunch, I'll take a closer look.

My gut says that we should be calling the delete (which is not a real
delete) when the LB is deleted, and not doing so is a bug, but I'll need to
double check the logic as it has been a while since I touched this.

--Adam (rm_work)

On Mon, Jan 23, 2017, 18:38 Jiahao Liang (Frankie) 
wrote:

> Hi community,
>
> I created a loadbalancer with a listener with protocol as
> "TERMINATED_HTTPS" and specify --default-tls-container-ref with a ref of
> secret container from Barbican.
> However, after I deleted the listener, the lbaas wasn't removed from
> barbican container consumer list.
>
> $openstack secret container get
> http://192.168.20.24:9311/v1/containers/453e8905-d42b-43bd-9947-50e3acf499f4
>
> ++-+
> | Field  | Value
> |
>
> ++-+
> | Container href |
> http://192.168.20.24:9311/v1/containers/453e8905-d42b-43bd-9947-50e3acf499f4
>|
> | Name   | tls_container2
>  |
> | Created| 2017-01-19 12:44:07+00:00
> |
> | Status | ACTIVE
>  |
> | Type   | certificate
> |
> | Certificate|
> http://192.168.20.24:9311/v1/secrets/bfc2bf01-0f23-4105-bf09-c75839b6b4cb
>   |
> | Intermediates  | None
>  |
> | Private Key|
> http://192.168.20.24:9311/v1/secrets/c85d150e-ec84-42e0-a65f-9c9ec19767e1
>   |
> | PK Passphrase  | None
>  |
> | *Consumers  | {u'URL':
> u'lbaas://RegionOne/loadbalancer/5e7768b9-7aa9-4146-8a71-6291353b447e',
> u'name': u'lbaas'}*
>
>
> I went through the neutron-lbaas code base. We did register consumer
> during the creation of "TERMINATED_HTTPS" listener in [1]. But we somehow
> doesn't deregister it during the deletion in [1]:
> https://github.com/openstack/neutron-lbaas/blob/stable/mitaka/neutron_lbaas/services/loadbalancer/plugin.py#L642
> get_cert() register lbaas as a consumer for barbican cert_manager.  (
> https://github.com/openstack/neutron-lbaas/blob/stable/mitaka/neutron_lbaas/common/cert_manager/barbican_cert_manager.py#L177
> )
> [2]:
> https://github.com/openstack/neutron-lbaas/blob/stable/mitaka/neutron_lbaas/services/loadbalancer/plugin.py#L805
> we probably need to call delete_cert from barbican cert_manager to remove
> the consumer. (
> https://github.com/openstack/neutron-lbaas/blob/stable/mitaka/neutron_lbaas/common/cert_manager/barbican_cert_manager.py#L187
> )
>
>
> My questions are:
> 1. is that a bug?
> 2. or is it a intentional design letting the vendor driver to handle it?
>
> It looks more like a bug to me.
>
> Any thoughts?
>
>
> Best,
> Jiahao
> --
>
> *梁嘉豪/Jiahao LIANG (Frankie) *
> Email: gzliangjia...@gmail.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 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] Nominating German Eichberger for Octavia core reviewer

[Adam Harwell]

+1

Welcome back German!

On Fri, Jan 20, 2017, 11:43 Michael Johnson  wrote:

>
> Hello Octavia Cores,
>
> I would like to nominate German Eichberger (xgerman) for reinstatement as
> an
> Octavia core reviewer.
>
> German was previously a core reviewer for Octavia and neutron-lbaas as well
> as a former co-PTL for Octavia.  Work dynamics required him to step away
> from the project for a period of time, but now he has moved back into a
> position that allows him to contribute to Octavia.  His review numbers are
> back in line with other core reviewers [1] and I feel he would be a solid
> asset to the core reviewing team.
>
> Current Octavia cores, please respond with your +1 vote or an objections.
>
> Michael
>
> [1] http://stackalytics.com/report/contribution/octavia-group/90
>
>
> __
> 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] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Adam Harwell]

The "single master token" issue is something I think a lot of services may
suffer from, and it's definitely something the Barbican folks are aware of
(I've made it a point to personally bring this up many times, including
hijacking parts of the keystone and barbican sessions at the Tokyo, Austin,
and Barcelona summits). When ACLs work, they should do this job,  but there
should also be better ways to do this. I know there have been proposals
around using more tightly scoped Trusts (I participated in proposing some)
but I don't know how much traction they actually got.

Yes, currently Barbican does both secret storage and certificate
provisioning, though I'm certain that basic secret storage was fully
implemented before any of the certificate stuff ever happened… I believe
you are correct though that it should be more tightly focused, and I think
the Barbican team agrees as well -- to my (admittedly fuzzy) recollection
there was agreement to split the certificate provisioning system into
another project as of version two of the API. Maybe Dave or Doug can
confirm this?

And for the record, Neutron-LBaaS and Octavia have at least a soft
requirement for Barbican, which is to say we only support our TLS
Termination features if Barbican is deployed. We do have our own
Castellan-like interface, but it only has a Barbican driver, and we'd love
to have that interface merged with Castellan if possible (I'm still salty
that this didn't happen years ago, but that's a much longer story).

    --Adam Harwell

On Mon, Jan 16, 2017, 14:36 Duncan Thomas <duncan.tho...@gmail.com> wrote:

> To give a totally different prospective on why somebody might dislike
> Barbican (I'm one of those people). Note that I'm working from pretty hazy
> memories so I don't guarantee I've got everything spot on, and I am without
> a doubt giving a very one sided view. But hey, that's the side I happen to
> sit on. I certainly don't mean to cause great offence to the people
> concerned, but rather to give  ahistory from a PoV that hasn't appeared yet.
>
> Cinder needed somewhere to store volume encryption keys. Long, long ago,
> Barbican gave a great presentation about secrets as a service, ACLs on
> secrets, setups where one service could ask for keep material to be created
> and only accessible to some other service. Having one service give another
> service permission to get at a secret (but never be able to access that
> secret itself). All the clever things that cinder could possibly leverage.
> It would also handle hardware security modules and all of the other
> craziness that no sane person wants to understand the fine details of. Key
> revocation, rekeying and some other stuff was mentioned as being possible
> future work.
>
> So I waited, and I waited, and I asked some security people about what
> Barbican was doing, and I got told it had gone off and done some unrelated
> to anything we wanted certificate cleverness stuff for some other service,
> but secrets-as-a-service would be along at some point. Eventually, a long
> time after all my enthusiasm had waned, the basic feature
>
> It doesn't do what it says on the tin. It isn't very good at keeping
> secrets. If I've got a token then I can get the keys for all my volumes.
> That kind of sucks. For several threat models, I'd have done better to just
> stick the keys in the cinder db.
>
> I really wish I'd got a video of that first presentation, because it would
> be an interesting project to implement. Barbican though, from a really
> narrow focused since usecase view point really isn't very good though.
>
> (If I've missed something and Barbican can do the clever ACL type stuff
> that was talked about, please let me know - I'd be very interested in
> trying to fit it to cinder, and I'm not even working on cinder
> professionally currently.)
> __
> 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] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Adam Harwell]

Someone mentioned Castellan, and was exactly correct -- Castellan is
supposed to allow for flexibility, so developers can code for the Castellan
interface and simply configure it to use Barbican or whatever else they
want.

The only drawback of Castellan at the moment is that it doesn't directly
support certificate storage (that is, if you are using groupings of
cert/intermediates/PK, they have to be stored individually). Otherwise,
using that interface would make it very easy to allow use of Barbican for
any clouds that deploy it, and something else (maybe even a *common*
something simple) otherwise (though I am fully behind just using Barbican).

   --Adam Harwell (LBaaS/Octavia)

On Mon, Jan 16, 2017, 11:57 Adrian Otto <adrian.o...@rackspace.com> wrote:

>
> > On Jan 16, 2017, at 11:02 AM, Dave McCowan (dmccowan) <
> dmcco...@cisco.com> wrote:
> >
> > On 1/16/17, 11:52 AM, "Ian Cordasco" <sigmaviru...@gmail.com> wrote:
> >
> >> -Original Message-
> >> From: Rob C <hyaku...@gmail.com>
> >> Reply: OpenStack Development Mailing List (not for usage questions)
> >> <openstack-dev@lists.openstack.org>
> >> Date: January 16, 2017 at 10:33:20
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> <openstack-dev@lists.openstack.org>
> >> Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are
> >> projects trying to avoid Barbican, still?
> >>
> >>> Thanks for raising this on the mailing list Ian, I too share some of
> >>> your consternation regarding this issue.
> >>>
> >>> I think the main point has already been hit on, developers don't want
> to
> >>> require that Barbican be deployed in order for their service to be
> >>> used.
> >>>
> >>> The resulting spread of badly audited secret management code is pretty
> >>> ugly and makes certifying OpenStack for some types of operation very
> >>> difficult, simply listing where key management "happens" and what
> >>> protocols are in use quickly becomes a non-trivial operation with some
> >>> teams using hard coded values while others use configurable algorithms
> >>> and no connection between any of them.
> >>>
> >>> In some ways I think that the castellan project was supposed to help
> >>> address the issue. The castellan documentation[1] is a little sparse
> but
> >>> my understanding is that it exists as an abstraction layer for
> >>> key management, such that a service can just be set to use castellan,
> >>> which in turn can be told to use either a local key-manager, provided
> by
> >>> the project or Barbican when it is available.
> >>>
> >>> Perhaps a miss-step previously was that Barbican made no efforts to
> >>> really provide a robust non-HSM mode of operation. An obvious contrast
> >>> here is with Hashicorp Vault[2] which has garnered significant market
> >>> share in key management because it's software-only* mode of operation
> is
> >>> well documented, robust and cryptographically sound. I think that the
> >>> lack of a sane non-HSM mode, has resulted in developers trying to
> create
> >>> their own and contributed to the situation.
>
> Bingo!
>
> >>> I'd be interested to know if development teams would be less concerned
> >>> about requiring Barbican deployments, if it had a robust non-HSM
> >>> (i.e software only) mode of operation. Lowering the cost of deployment
> >>> for organisations that want sensible key management without the expense
> >>> of deploying multi-site HSMs.
> >>>
> >>> * Vault supports HSM deployments also
> >>>
> >>> [1] http://docs.openstack.org/developer/castellan/
> >>> [2] https://www.vaultproject.io/
> >>
> >> The last I checked, Rob, they also support DogTag IPA which is purely
> >> a Software based HSM. Hopefully the Barbican team can confirm this.
> >> --
> >> Ian Cordasco
> >
> > Yep.  Barbican supports four backend secret stores. [1]
> >
> > The first (Simple Crypto) is easy to deploy, but not extraordinarily
> > secure, since the secrets are encrypted using a static key defined in the
> > barbican.conf file.
> >
> > The second and third (PKCS#11 and KMIP) are secure, but require an HSM as
> > a hardware base to encrypt and/or store the secrets.
> > The fourth (Dogtag) is secure, but requires a deployment of Dogtag to
> &

Re: [openstack-dev] [trove][octavia][tacker][designate][manila][sahara][magnum][infra] servicevm working group meetup

[Adam Harwell]

I'll be there.

On Mon, Oct 24, 2016, 20:29 Doug Wiegley 
wrote:

>
> On Oct 24, 2016, at 8:23 PM, Doug Wiegley 
> wrote:
>
> As part of a requirements mailing list thread [1], the idea of a servicevm
> working group, or a common framework for reference openstack service VMs,
> came up. It's too late to get onto the official schedule, but unofficially,
> let's meet here:
>
> When: Tuesday, 1:30pm-2:10pm
> Where: CCIB P1 Room 128
>
> If this is too short notice, then we can retry on Friday.
>
> Thanks,
> doug
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-October/105861.html
>
>
> And an etherpad:
>
> https://etherpad.openstack.org/p/ocata-summit-servicevm
>
>
> __
> 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] [requirements][lbaas] gunicorn to g-r

[Adam Harwell]

Dims: that wasn't meant as hostile to you, though re-reading it kind of
sounds that way.
You were not the first in this thread to suggest bindep, and while your
links are useful, I don't think it makes a lot of sense for our use case. I
legitimately can't understand why this *one* dependency (not anything a
deployer will need to install on their control-plane instances) is
suggested as a binary dependency, when it is a python module that we
include in our code just like *everything else* in our requirements file.

On Wed, Oct 19, 2016 at 11:02 PM Adam Harwell <flux.a...@gmail.com> wrote:

> We literally install every other dependency from pypi with
> requirements.txt, so I'm struggling understand why all the sudden we need
> to install this one as a binary, for our devstack specific script, when we
> are planning a move to a distro that doesn't even support binary packages?
> Should we switch our entire requirements file to bindep? If not, what makes
> this different?
>
> On Wed, Oct 19, 2016, 22:56 Davanum Srinivas <dava...@gmail.com> wrote:
>
> Adam,
>
> Have you see this yet?
>
>
> http://docs.openstack.org/infra/bindep/readme.html#writing-requirements-files
> http://codesearch.openstack.org/?q=platform=nope=bindep.txt=
>
> Thanks,
> Dims
>
> On Wed, Oct 19, 2016 at 9:40 AM, Adam Harwell <flux.a...@gmail.com> wrote:
> > Yes, but we need to use SOMETHING for our own devstack gate tests --
> maybe
> > it is easier to think of our devstack code as a "third party setup", and
> > that it uses gunicorn for its DIB images (but not every deployer needs
> to).
> > In this case, how do we include it? Devstack needs it to run our gate
> jobs,
> > which means it has to be in our main codebase, but deployers don't
> > necessarily need it for their deployments (though it is the default
> option).
> > Do we include it in global-requirements or not? How do we use it in
> devstack
> > if it is not in global-requirements? We don't install it as a binary
> because
> > the plan is to stay completely distro-independant (or target a distro
> that
> > doesn't even HAVE binary packages like cirros). Originally I just put the
> > line "pip install gunicorn>=19.0" directly in our DIB script, but was
> told
> > that was a dirty hack, and that it should be in requirements.txt like
> > everything else. I'm not sure I agree, and it seems like maybe others are
> > suggesting I go back to that method?
> >
> >  --Adam
> >
> > On Wed, Oct 19, 2016 at 10:19 PM Hayes, Graham <graham.ha...@hpe.com>
> wrote:
> >>
> >> On 18/10/2016 19:57, Doug Wiegley wrote:
> >> >
> >> >> On Oct 18, 2016, at 12:42 PM, Doug Hellmann <d...@doughellmann.com>
> >> >> wrote:
> >> >>
> >> >> Excerpts from Doug Wiegley's message of 2016-10-18 12:21:20 -0600:
> >> >>>
> >> >>>> On Oct 18, 2016, at 12:10 PM, Doug Hellmann <d...@doughellmann.com
> >
> >> >>>> wrote:
> >> >>>>
> >> >>>> Excerpts from Doug Wiegley's message of 2016-10-18 12:00:35 -0600:
> >> >>>>>
> >> >>>>>> On Oct 18, 2016, at 11:30 AM, Doug Hellmann <
> d...@doughellmann.com
> >> >>>>>> <mailto:d...@doughellmann.com>> wrote:
> >> >>>>>>
> >> >>>>>> Excerpts from Doug Wiegley's message of 2016-10-18 09:59:54
> -0600:
> >> >>>>>>>
> >> >>>>>>>> On Oct 18, 2016, at 5:14 AM, Ian Cordasco <
> sigmaviru...@gmail.com
> >> >>>>>>>> <mailto:sigmaviru...@gmail.com> <mailto:sigmaviru...@gmail.com
> >> >>>>>>>> <mailto:sigmaviru...@gmail.com>>> wrote:
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>> -Original Message-
> >> >>>>>>>> From: Thierry Carrez <thie...@openstack.org
> >> >>>>>>>> <mailto:thie...@openstack.org> <mailto:thie...@openstack.org
> >> >>>>>>>> <mailto:thie...@openstack.org>> <mailto:thie...@openstack.org
> >> >>>>>>>> <mailto:thie...@openstack.org> <mailto:thie...@openstack.org
> >> >>>>>>>> <mailto:thie...@openstack.org>>>>
> >> >>>>>>>> Reply: OpenStack Dev

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Adam Harwell]

We literally install every other dependency from pypi with
requirements.txt, so I'm struggling understand why all the sudden we need
to install this one as a binary, for our devstack specific script, when we
are planning a move to a distro that doesn't even support binary packages?
Should we switch our entire requirements file to bindep? If not, what makes
this different?

On Wed, Oct 19, 2016, 22:56 Davanum Srinivas <dava...@gmail.com> wrote:

> Adam,
>
> Have you see this yet?
>
>
> http://docs.openstack.org/infra/bindep/readme.html#writing-requirements-files
> http://codesearch.openstack.org/?q=platform=nope=bindep.txt=
>
> Thanks,
> Dims
>
> On Wed, Oct 19, 2016 at 9:40 AM, Adam Harwell <flux.a...@gmail.com> wrote:
> > Yes, but we need to use SOMETHING for our own devstack gate tests --
> maybe
> > it is easier to think of our devstack code as a "third party setup", and
> > that it uses gunicorn for its DIB images (but not every deployer needs
> to).
> > In this case, how do we include it? Devstack needs it to run our gate
> jobs,
> > which means it has to be in our main codebase, but deployers don't
> > necessarily need it for their deployments (though it is the default
> option).
> > Do we include it in global-requirements or not? How do we use it in
> devstack
> > if it is not in global-requirements? We don't install it as a binary
> because
> > the plan is to stay completely distro-independant (or target a distro
> that
> > doesn't even HAVE binary packages like cirros). Originally I just put the
> > line "pip install gunicorn>=19.0" directly in our DIB script, but was
> told
> > that was a dirty hack, and that it should be in requirements.txt like
> > everything else. I'm not sure I agree, and it seems like maybe others are
> > suggesting I go back to that method?
> >
> >  --Adam
> >
> > On Wed, Oct 19, 2016 at 10:19 PM Hayes, Graham <graham.ha...@hpe.com>
> wrote:
> >>
> >> On 18/10/2016 19:57, Doug Wiegley wrote:
> >> >
> >> >> On Oct 18, 2016, at 12:42 PM, Doug Hellmann <d...@doughellmann.com>
> >> >> wrote:
> >> >>
> >> >> Excerpts from Doug Wiegley's message of 2016-10-18 12:21:20 -0600:
> >> >>>
> >> >>>> On Oct 18, 2016, at 12:10 PM, Doug Hellmann <d...@doughellmann.com
> >
> >> >>>> wrote:
> >> >>>>
> >> >>>> Excerpts from Doug Wiegley's message of 2016-10-18 12:00:35 -0600:
> >> >>>>>
> >> >>>>>> On Oct 18, 2016, at 11:30 AM, Doug Hellmann <
> d...@doughellmann.com
> >> >>>>>> <mailto:d...@doughellmann.com>> wrote:
> >> >>>>>>
> >> >>>>>> Excerpts from Doug Wiegley's message of 2016-10-18 09:59:54
> -0600:
> >> >>>>>>>
> >> >>>>>>>> On Oct 18, 2016, at 5:14 AM, Ian Cordasco <
> sigmaviru...@gmail.com
> >> >>>>>>>> <mailto:sigmaviru...@gmail.com> <mailto:sigmaviru...@gmail.com
> >> >>>>>>>> <mailto:sigmaviru...@gmail.com>>> wrote:
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>> -Original Message-
> >> >>>>>>>> From: Thierry Carrez <thie...@openstack.org
> >> >>>>>>>> <mailto:thie...@openstack.org> <mailto:thie...@openstack.org
> >> >>>>>>>> <mailto:thie...@openstack.org>> <mailto:thie...@openstack.org
> >> >>>>>>>> <mailto:thie...@openstack.org> <mailto:thie...@openstack.org
> >> >>>>>>>> <mailto:thie...@openstack.org>>>>
> >> >>>>>>>> Reply: OpenStack Development Mailing List (not for usage
> >> >>>>>>>> questions) <openstack-dev@lists.openstack.org
> >> >>>>>>>> <mailto:openstack-dev@lists.openstack.org>
> >> >>>>>>>> <mailto:openstack-dev@lists.openstack.org
> >> >>>>>>>> <mailto:openstack-dev@lists.openstack.org>>
> >> >>>>>>>> <mailto:openstack-dev@lists.openstack.org
> >> >>>>>>>> <mailto:openstack-dev@lists.openstack.org>
> >> >>>>>&

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Adam Harwell]

To reply more directly and clearly:

On Wed, Oct 19, 2016 at 9:30 PM Tony Breeds <t...@bakeyournoodle.com> wrote:

> On Wed, Oct 19, 2016 at 08:41:16AM +0000, Adam Harwell wrote:
> > I wonder if maybe it is not clear -- for us, gunicorn is a runtime
> > dependency for our gate jobs to work, not a deploy dependency.
>
> Okay then frankly I'm deeply confused.
>
> Can we see the code that uses it? to understand why the deployer can't
> build a
> custom service VM using an alternative to gunicorn?
>
A deployer is perfectly free to use an alternative to gunicorn. Gunicorn is
built into our devstack plugin code, not the main agent application
(agent.py is just the runner we created for devstack -- you could run
octavia.amphorae.backends.agent.api_server with any WSGI runner you want in
a real deployment). We just have to use SOMETHING in devstack for our gate
scenario tests to run...

>
> Yours Tony.
> __
> 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] [requirements][lbaas] gunicorn to g-r

[Adam Harwell]

Yes, but we need to use SOMETHING for our own devstack gate tests -- maybe
it is easier to think of our devstack code as a "third party setup", and
that it uses gunicorn for its DIB images (but not every deployer needs to).
In this case, how do we include it? Devstack needs it to run our gate jobs,
which means it has to be in our main codebase, but deployers don't
necessarily need it for their deployments (though it is the default option).
Do we include it in global-requirements or not? How do we use it in
devstack if it is not in global-requirements? We don't install it as a
binary because the plan is to stay completely distro-independant (or target
a distro that doesn't even HAVE binary packages like cirros). Originally I
just put the line "pip install gunicorn>=19.0" directly in our DIB script,
but was told that was a dirty hack, and that it should be in
requirements.txt like everything else. I'm not sure I agree, and it seems
like maybe others are suggesting I go back to that method?

 --Adam

On Wed, Oct 19, 2016 at 10:19 PM Hayes, Graham  wrote:

> On 18/10/2016 19:57, Doug Wiegley wrote:
> >
> >> On Oct 18, 2016, at 12:42 PM, Doug Hellmann 
> wrote:
> >>
> >> Excerpts from Doug Wiegley's message of 2016-10-18 12:21:20 -0600:
> >>>
>  On Oct 18, 2016, at 12:10 PM, Doug Hellmann 
> wrote:
> 
>  Excerpts from Doug Wiegley's message of 2016-10-18 12:00:35 -0600:
> >
> >> On Oct 18, 2016, at 11:30 AM, Doug Hellmann  > wrote:
> >>
> >> Excerpts from Doug Wiegley's message of 2016-10-18 09:59:54 -0600:
> >>>
>  On Oct 18, 2016, at 5:14 AM, Ian Cordasco   >> wrote:
> 
> 
> 
>  -Original Message-
>  From: Thierry Carrez  >    Reply: OpenStack Development Mailing List (not for usage
> questions)   openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org>>  openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org>  openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org
>  Date: October 18, 2016 at 03:55:41
>  To: openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org>  openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org>>  openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org>  openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org>>>   openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org>>  openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org>  openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org
>  Subject:  Re: [openstack-dev] [requirements][lbaas] gunicorn to
> g-r
> 
> > Doug Wiegley wrote:
> >> [...] Paths forward:
> >>
> >> 1. Add gunicorn to global requirements.
> >>
> >> 2. Create a project specific “amphora-requirements.txt” file
> for the
> >> service VM packages (this is actually my preference.) It has
> been
> >> pointed out that this wouldn’t be kept up-to-date by the bot.
> We could
> >> modify the bot to include it in some way, or do it manually, or
> with a
> >> project specific job.
> >>
> >> 3. Split our service VM builds into another repo, to keep a
> clean
> >> separation between API services and the backend. But, even this
> new
> >> repo’s standlone requirements.txt file will have the g-r issue
> from #1.
> >>
> >> 4. Boot the backend out of OpenStack entirely.
> >
> > All those options sound valid to me, so the requirements team
> should
> > pick what they are the most comfortable with.
> >
> > My 2c: yes g-r is mostly about runtime dependencies and ensuring
> > co-installability. However it also includes test/build-time
> deps, and
> > generally converging dependencies overall sounds like a valid
> goal. Is
> > there any drawback in adding gunicorn to g-r (option 1) ?
> 
>  The drawback (in my mind) is that new projects might start using
> it giving operators yet another thing to learn about when deploying a new
> component (eventlet, gevent, gunicorn, ...).
> 
>  On the flip, what's the benefit of adding it to g-r?
> >>>
> >>> The positive benefit is the same as Octavia’s use case: it
> provides an 

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Adam Harwell]

I wonder if maybe it is not clear -- for us, gunicorn is a runtime
dependency for our gate jobs to work, not a deploy dependency.

On Wed, Oct 19, 2016, 11:16 Tony Breeds  wrote:

> On Mon, Oct 17, 2016 at 08:12:45PM -0600, Doug Wiegley wrote:
>
> > Right, so, we’re dancing around the common problem in openstack lately:
> what
> > the heck is openstack?
>
> Sorry to get here so late.
>
> > This came up because service VMs/data plane implementations, which this
> is,
> > have different requirements than API services. Paths forward:
> >
> > 1. Add gunicorn to global requirements.
>
> I'd rather avoid this.  Other have done a great job explaining the runtime
> vs
> deploy dependencies.
>
> > 2. Create a project specific “amphora-requirements.txt” file for the
> service
> > VM packages (this is actually my preference.) It has been pointed out
> that
> > this wouldn’t be kept up-to-date by the bot. We could modify the bot to
> > include it in some way, or do it manually, or with a project specific
> job.
> >
> > 3. Split our service VM builds into another repo, to keep a clean
> separation
> > between API services and the backend.  But, even this new repo’s
> standlone
> > requirements.txt file will have the g-r issue from #1.
>
> Actually Options 2 and 3 are functionally the same (from my POV).  We'd
> need a
> specific job to update your *requirements.txt files.  I feel like a
> separate
> repo is slightly neater but it has the most impact on the Octavia team.
>
> So I'd suggest you go with one of 2 or 3 and we can work together to make
> the
> tools work with you.
>
> > 4. Boot the backend out of OpenStack entirely.
>
> :(  I really hope this was a joke suggestion.  If it isn't then we have
> some
> problems in our community / tools :(
>
> Yours Tony.
> __
> 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] [requirements][lbaas] gunicorn to g-r

[Adam Harwell]

Yep, I believe we did this in the past when we first started down this path
with Octavia, but we may have been too early -- maybe now is a better time
to do it. I will be at the summit and more than happy to attend a related
meeting.
But, I agree with Doug that we shouldn't stall this because of that -- can
we go ahead and vote the official OpenStack way: comments and +1/-1 on
https://review.openstack.org/#/c/386790/ ? I also feel like commenting
there is a better way to keep track of this discussion for posterity, as
the ML feels much more ephemeral to me. I can always go look up a CR as
it's directly linked to the commit. :)

--Adam

On Wed, Oct 19, 2016 at 3:24 AM Doug Wiegley 
wrote:

> On Oct 18, 2016, at 12:10 PM, Doug Hellmann  wrote:
>
> Excerpts from Doug Wiegley's message of 2016-10-18 12:00:35 -0600:
>
>
> On Oct 18, 2016, at 11:30 AM, Doug Hellmann  wrote:
>
> Excerpts from Doug Wiegley's message of 2016-10-18 09:59:54 -0600:
>
>
> On Oct 18, 2016, at 5:14 AM, Ian Cordasco  mailto:sigmaviru...@gmail.com >> wrote:
>
>
>
> -Original Message-
> From: Thierry Carrez  >     Reply: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org <
> mailto:openstack-dev@lists.openstack.org
> > <
> mailto:openstack-dev@lists.openstack.org
>  <
> mailto:openstack-dev@lists.openstack.org
>  Date: October 18, 2016 at 03:55:41
> To: openstack-dev@lists.openstack.org <
> mailto:openstack-dev@lists.openstack.org
> > <
> mailto:openstack-dev@lists.openstack.org
>  <
> mailto:openstack-dev@lists.openstack.org
> >>  mailto:openstack-dev@lists.openstack.org
> > <
> mailto:openstack-dev@lists.openstack.org
>  <
> mailto:openstack-dev@lists.openstack.org
>  Subject:  Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r
>
> Doug Wiegley wrote:
>
> [...] Paths forward:
>
> 1. Add gunicorn to global requirements.
>
> 2. Create a project specific “amphora-requirements.txt” file for the
> service VM packages (this is actually my preference.) It has been
> pointed out that this wouldn’t be kept up-to-date by the bot. We could
> modify the bot to include it in some way, or do it manually, or with a
> project specific job.
>
> 3. Split our service VM builds into another repo, to keep a clean
> separation between API services and the backend. But, even this new
> repo’s standlone requirements.txt file will have the g-r issue from #1.
>
> 4. Boot the backend out of OpenStack entirely.
>
>
> All those options sound valid to me, so the requirements team should
> pick what they are the most comfortable with.
>
> My 2c: yes g-r is mostly about runtime dependencies and ensuring
> co-installability. However it also includes test/build-time deps, and
> generally converging dependencies overall sounds like a valid goal. Is
> there any drawback in adding gunicorn to g-r (option 1) ?
>
>
> The drawback (in my mind) is that new projects might start using it giving
> operators yet another thing to learn about when deploying a new component
> (eventlet, gevent, gunicorn, ...).
>
> On the flip, what's the benefit of adding it to g-r?
>
>
> The positive benefit is the same as Octavia’s use case: it provides an
> alternative for any non-frontline-api service to run a lightweight
> http/wsgi service as needed (service VMs, health monitor agents, etc). And
> something better than the built-in debug servers in most of the frameworks.
>
> On the proliferation point, it is certainly a risk, though I’ve personally
> heard pretty strong guidance that all main API services in our community
> should be trending towards pecan.
>
>
> Pecan is a way to build WSGI applications. Gunicorn is a way to deploy
> them. So they're not mutually exclusive.
>
>
> Right, agreed.
>
> What we’re trying to convey here is:
>
> - The normal way of making a REST endpoint in OpenStack is to use pecan
> (or flask or falcon), and let the deployer or packager worry about the
> runtime wsgi and/or reverse proxy.
>
> - This isn't a “normal” OpenStack endpoint, because it’s a microservice
> inside a service VM, and thus has different needs, and is much less likely
> to be customized by a non-dev, to boot. And it needs to be “deploy ready”
> as a simple matter of it being a service VM black box. It’s part of the
> data plane, not the control plane.
>
> Thanks,
> 

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Adam Harwell]

For the record, it might help if people actually look at how we're
proposing to use the gunicorn python module (remember, this code is
executing inside a *service VM*, not on the main control plane):
https://review.openstack.org/#/c/386758/12/octavia/cmd/agent.py


On Wed, Oct 19, 2016 at 2:05 AM Adam Harwell <flux.a...@gmail.com> wrote:

> Inline comments.
>
> On Wed, Oct 19, 2016 at 1:38 AM Thomas Goirand <z...@debian.org> wrote:
>
> On 10/18/2016 02:37 AM, Ian Cordasco wrote:
> > On Oct 17, 2016 7:27 PM, "Thomas Goirand" <z...@debian.org
> > <mailto:z...@debian.org>> wrote:
> >>
> >> On 10/17/2016 08:43 PM, Adam Harwell wrote:
> >> > Jim, that is exactly my thought -- the main focus of g-r as far as I
> was
> >> > aware is to maintain interoperability between project dependencies for
> >> > openstack deploys, and since our amphora image is totally separate, it
> >> > should not be restricted to g-r requirements.
> >>
> >> The fact that we have a unified version number of a given lib in all of
> >> OpenStack is also because that's a requirement of downstream distros.
> >>
> >> Imagine that someone would like to build the Octavia image using
> >> exclusively packages from ...
> >>
> >> > I brought this up, but
> >> > others thought it would be prudent to go the g-r route anyway.
> >>
> >> It is, and IMO you should go this route.
> >
> > I'm not convinced by your arguments here, Thomas. If the distributor
> > were packaging Octavia for X but the image is using some other operating
> > system, say Y, why are X's packages relevant?
>
> What if operating systems would be the same?
>
> We still want to install from pypi, because we still want deployers to
> build images for their cloud using our DIB elements. There is absolutely no
> situation in which I can imagine we'd want to install a binary packaged
> version of this. There's a VERY high chance we will soon be using a distro
> that isn't even a supported OpenStack deploy target...
>
>
> As a Debian package maintainer, I really prefer if the underlying images
> can also be Debian (and preferably Debian stable everywhere).
>
> Sure, I love Debian too, but we're investigating things like Alpine and
> Cirros as our base image, and there's pretty much zero chance anyone will
> package ANY of our deps for those distros. Cirros doesn't even have a
> package manager AFAIK.
>
>
> > I would think that if this
> > is something inside an image going to be launched by Octavia that
> > co-installibilty wouldn't really be an issue.
>
> The issue isn't co-instability, but the fact that downstream
> distribution vendors will only package *ONE* version of a given python
> module. If we have Octavia with version X, and another component of
> OpenStack with version Y, then we're stuck with Octavia not being
> packageable in downstream distros.
>
> Octavia will not use gunicorn for its main OpenStack API layer. It will
> continue to be packagable regardless of whether gunicorn is available.
> Gunicorn is used for our *amphora image*, which is not part of the main
> deployment layer. It is part of our *dataplane*. It is unrelated to any
> part of Octavia that is deployed as part of the main service layer of
> Openstack. In fact, in production, deployers may completely ignore gunicorn
> altogether and use a different solution, that is up to the way they build
> their amphora image (which, again, is not part of the main deployment). We
> just use gunicorn in the image we use for our gate tests.
>
>
> > I don't lean either way right now, so I'd really like to understand your
> > point of view, especially since right now it isn't making much sense to
> me.
>
> Do you understand now? :)
>
> I see what you are saying, but I assert it does not apply to our case at
> all. Do you see how our case is different?
>
>
> Cheers,
>
> Thomas
>
>
> __
> 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] [requirements][lbaas] gunicorn to g-r

[Adam Harwell]

Inline comments.

On Wed, Oct 19, 2016 at 1:38 AM Thomas Goirand <z...@debian.org> wrote:

> On 10/18/2016 02:37 AM, Ian Cordasco wrote:
> > On Oct 17, 2016 7:27 PM, "Thomas Goirand" <z...@debian.org
> > <mailto:z...@debian.org>> wrote:
> >>
> >> On 10/17/2016 08:43 PM, Adam Harwell wrote:
> >> > Jim, that is exactly my thought -- the main focus of g-r as far as I
> was
> >> > aware is to maintain interoperability between project dependencies for
> >> > openstack deploys, and since our amphora image is totally separate, it
> >> > should not be restricted to g-r requirements.
> >>
> >> The fact that we have a unified version number of a given lib in all of
> >> OpenStack is also because that's a requirement of downstream distros.
> >>
> >> Imagine that someone would like to build the Octavia image using
> >> exclusively packages from ...
> >>
> >> > I brought this up, but
> >> > others thought it would be prudent to go the g-r route anyway.
> >>
> >> It is, and IMO you should go this route.
> >
> > I'm not convinced by your arguments here, Thomas. If the distributor
> > were packaging Octavia for X but the image is using some other operating
> > system, say Y, why are X's packages relevant?
>
> What if operating systems would be the same?
>
We still want to install from pypi, because we still want deployers to
build images for their cloud using our DIB elements. There is absolutely no
situation in which I can imagine we'd want to install a binary packaged
version of this. There's a VERY high chance we will soon be using a distro
that isn't even a supported OpenStack deploy target...

>
> As a Debian package maintainer, I really prefer if the underlying images
> can also be Debian (and preferably Debian stable everywhere).
>
Sure, I love Debian too, but we're investigating things like Alpine and
Cirros as our base image, and there's pretty much zero chance anyone will
package ANY of our deps for those distros. Cirros doesn't even have a
package manager AFAIK.

>
> > I would think that if this
> > is something inside an image going to be launched by Octavia that
> > co-installibilty wouldn't really be an issue.
>
> The issue isn't co-instability, but the fact that downstream
> distribution vendors will only package *ONE* version of a given python
> module. If we have Octavia with version X, and another component of
> OpenStack with version Y, then we're stuck with Octavia not being
> packageable in downstream distros.
>
Octavia will not use gunicorn for its main OpenStack API layer. It will
continue to be packagable regardless of whether gunicorn is available.
Gunicorn is used for our *amphora image*, which is not part of the main
deployment layer. It is part of our *dataplane*. It is unrelated to any
part of Octavia that is deployed as part of the main service layer of
Openstack. In fact, in production, deployers may completely ignore gunicorn
altogether and use a different solution, that is up to the way they build
their amphora image (which, again, is not part of the main deployment). We
just use gunicorn in the image we use for our gate tests.

>
> > I don't lean either way right now, so I'd really like to understand your
> > point of view, especially since right now it isn't making much sense to
> me.
>
> Do you understand now? :)
>
I see what you are saying, but I assert it does not apply to our case at
all. Do you see how our case is different?

>
> Cheers,
>
> Thomas
>
>
> __
> 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] [requirements][lbaas] gunicorn to g-r

[Adam Harwell]

We really don't want bindep IMO -- it's much safer to use the non-packaged
version from pypi for our purposes, since we may not be running on a system
that packages things like this. Again, our use case may be strange though,
as we're really using the python module and not the binaries.

--Adam

On Wed, Oct 19, 2016 at 1:07 AM Doug Wiegley 
wrote:

> On Oct 18, 2016, at 5:14 AM, Ian Cordasco  wrote:
>
>
>
> -Original Message-
> From: Thierry Carrez 
> Reply: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Date: October 18, 2016 at 03:55:41
> To: openstack-dev@lists.openstack.org 
> Subject:  Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r
>
> Doug Wiegley wrote:
>
> [...] Paths forward:
>
> 1. Add gunicorn to global requirements.
>
> 2. Create a project specific “amphora-requirements.txt” file for the
> service VM packages (this is actually my preference.) It has been
> pointed out that this wouldn’t be kept up-to-date by the bot. We could
> modify the bot to include it in some way, or do it manually, or with a
> project specific job.
>
> 3. Split our service VM builds into another repo, to keep a clean
> separation between API services and the backend. But, even this new
> repo’s standlone requirements.txt file will have the g-r issue from #1.
>
> 4. Boot the backend out of OpenStack entirely.
>
>
> All those options sound valid to me, so the requirements team should
> pick what they are the most comfortable with.
>
> My 2c: yes g-r is mostly about runtime dependencies and ensuring
> co-installability. However it also includes test/build-time deps, and
> generally converging dependencies overall sounds like a valid goal. Is
> there any drawback in adding gunicorn to g-r (option 1) ?
>
>
> The drawback (in my mind) is that new projects might start using it giving
> operators yet another thing to learn about when deploying a new component
> (eventlet, gevent, gunicorn, ...).
>
> On the flip, what's the benefit of adding it to g-r?
>
>
> The positive benefit is the same as Octavia’s use case: it provides an
> alternative for any non-frontline-api service to run a lightweight
> http/wsgi service as needed (service VMs, health monitor agents, etc). And
> something better than the built-in debug servers in most of the frameworks.
>
> On the proliferation point, it is certainly a risk, though I’ve personally
> heard pretty strong guidance that all main API services in our community
> should be trending towards pecan.
>
> Thanks,
> doug
>
>
> --
> Ian Cordasco
>
>
> __
> 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] [requirements][lbaas] gunicorn to g-r

[Adam Harwell]

If there's no objection to us using gunicorn without it being present in
g-r, then I don't know if I want to argue strongly for adding it -- the
only benefit I see to tracking g-r at all is that it lets us continue to
get free version tracking for our amphora dependencies as they are updated
in g-r without having to manually tweak them. Once we go away from using
g-r for our amphora-requirements, our project team has to track these
dependencies manually. Tweaking the requirements bot to look at
amphora-requirements.txt as Doug mentioned won't actually do much, since
the whole point here is that we're including things that aren't in g-r so
there's no source to update them from.

So, does everyone at least agree that it's ok for us to *use* gunicorn
internally on our service-vm image? If so, I'm happy to move forward with
option #2 if it looks like that'll be the path of least resistance. As I
said, options 3 and 4 are not really good solutions to this particular
problem, so in my view we should do whichever is most likely to be accepted
of options 1 or 2.

--Adam

On Tue, Oct 18, 2016 at 8:18 PM Ian Cordasco  wrote:

>
>
> -Original Message-
> From: Thierry Carrez 
> Reply: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Date: October 18, 2016 at 03:55:41
> To: openstack-dev@lists.openstack.org 
> Subject:  Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r
>
> > Doug Wiegley wrote:
> > > [...] Paths forward:
> > >
> > > 1. Add gunicorn to global requirements.
> > >
> > > 2. Create a project specific “amphora-requirements.txt” file for the
> > > service VM packages (this is actually my preference.) It has been
> > > pointed out that this wouldn’t be kept up-to-date by the bot. We could
> > > modify the bot to include it in some way, or do it manually, or with a
> > > project specific job.
> > >
> > > 3. Split our service VM builds into another repo, to keep a clean
> > > separation between API services and the backend. But, even this new
> > > repo’s standlone requirements.txt file will have the g-r issue from #1.
> > >
> > > 4. Boot the backend out of OpenStack entirely.
> >
> > All those options sound valid to me, so the requirements team should
> > pick what they are the most comfortable with.
> >
> > My 2c: yes g-r is mostly about runtime dependencies and ensuring
> > co-installability. However it also includes test/build-time deps, and
> > generally converging dependencies overall sounds like a valid goal. Is
> > there any drawback in adding gunicorn to g-r (option 1) ?
>
> The drawback (in my mind) is that new projects might start using it giving
> operators yet another thing to learn about when deploying a new component
> (eventlet, gevent, gunicorn, ...).
>
> On the flip, what's the benefit of adding it to g-r?
>
> --
> Ian Cordasco
>
>
> __
> 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] [requirements][lbaas] gunicorn to g-r

[Adam Harwell]

Right, and this is totally possible (using a different distro). In fact, it
is *likely* that in the future the amphora image will be based on a minimal
distro and not anything like the distro the rest of OpenStack is deployed
to. Also, given that the amphora image build process uses DIB and installs
gunicorn via pypi, I'm not clear on how distro packages are relevant. Pypi
installs are distro agnostic, and each operator really does *need* to build
their own amphora image for their own cloud for various reasons...

Also also, normally people think of gunicorn as a binary runner, but we are
actually using it as a Python module:
http://docs.gunicorn.org/en/stable/custom.html

As for Doug's options, I'm more in favor of option 1 or 2 (since they
actually solve the problem). Option 3 is something we'd like to do, but
doesn't do anything for this particular dilemma. Option 4 is a bit extreme,
and I think the amphora image should still retain ties to OpenStack. :/

   --Adam

On Tue, Oct 18, 2016, 09:42 Ian Cordasco <sigmaviru...@gmail.com> wrote:

> On Oct 17, 2016 7:27 PM, "Thomas Goirand" <z...@debian.org> wrote:
> >
> > On 10/17/2016 08:43 PM, Adam Harwell wrote:
> > > Jim, that is exactly my thought -- the main focus of g-r as far as I
> was
> > > aware is to maintain interoperability between project dependencies for
> > > openstack deploys, and since our amphora image is totally separate, it
> > > should not be restricted to g-r requirements.
> >
> > The fact that we have a unified version number of a given lib in all of
> > OpenStack is also because that's a requirement of downstream distros.
> >
> > Imagine that someone would like to build the Octavia image using
> > exclusively packages from ...
> >
> > > I brought this up, but
> > > others thought it would be prudent to go the g-r route anyway.
> >
> > It is, and IMO you should go this route.
>
> I'm not convinced by your arguments here, Thomas. If the distributor were
> packaging Octavia for X but the image is using some other operating system,
> say Y, why are X's packages relevant? I would think that if this is
> something inside an image going to be launched by Octavia that
> co-installibilty wouldn't really be an issue.
>
> I don't lean either way right now, so I'd really like to understand your
> point of view, especially since right now it isn't making much sense to me.
> __
> 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] [requirements][lbaas] gunicorn to g-r

[Adam Harwell]

Jim, that is exactly my thought -- the main focus of g-r as far as I was
aware is to maintain interoperability between project dependencies for
openstack deploys, and since our amphora image is totally separate, it
should not be restricted to g-r requirements. I brought this up, but others
thought it would be prudent to go the g-r route anyway. So, I don't really
care what g-r says in this case, but I am aware my personality tends a bit
towards anarchistic, so I ceded the argument in an attempt to play nice. :)
If others also agree that g-r should not apply in cases like these, we can
re-evaluate our choice to add gunicorn to our main requirements file, and
install it via alternate mechanisms.

--Adam

On Tue, Oct 18, 2016 at 3:16 AM Doug Wiegley 
wrote:

> On Oct 17, 2016, at 12:02 PM, Jim Rollenhagen 
> wrote:
> >
> > On Mon, Oct 17, 2016 at 1:33 PM, Doug Wiegley
> >  wrote:
> >> Hi,
> >>
> >> On a review to add gunicorn to global requirements[1], we were asked to
> send a notice to the ML. In this particular application, it’s for use
> inside a service VM for Octavia. Objections/comments/other?
> >
> > global-requirements is meant to ensure co-installability between
> > OpenStack services.
> > Is it safe to assume that software running in service VMs does not need
> to be
> > co-installable with other OpenStack services, since it's separated
> > from the control
> > plane?
> >
>
> In this particular case, yes, that’s not a concern, but if added to g-r,
> it might proliferate elsewhere over time.
>
> Thanks,
> doug
>
> > // jim
> >
> >
> __
> > 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] Neutron team social event in Barcelona

[Adam Harwell]

+1

On Tue, Oct 18, 2016 at 3:05 AM Michael Johnson  wrote:

> +1
>
> On Fri, Oct 14, 2016 at 11:30 AM, Miguel Lavalle 
> wrote:
> > Dear Neutrinos,
> >
> > I am organizing a social event for the team on Thursday 27th at 19:30.
> After
> > doing some Google research, I am proposing Raco de la Vila, which is
> located
> > in Poblenou: http://www.racodelavila.com/en/index.htm. The menu is here:
> > http://www.racodelavila.com/en/carta-racodelavila.htm
> >
> > It is easy to get there by subway from the Summit venue:
> > https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people
> under
> > 'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can
> get
> > a final count.
> >
> > Here's some reviews:
> >
> https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html
> >
> > Cheers
> >
> > Miguel
> >
> >
> __
> > 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] [lbaas] [octavia] Proposing Bharath Munirajulu as Octavia Core

[Adam Harwell]

+1

From: Brandon Logan 
Sent: Thursday, March 31, 2016 8:04 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [lbaas] [octavia] Proposing Bharath Munirajulu as 
Octavia Core

+1

On Wed, 2016-03-30 at 13:56 -0700, Michael Johnson wrote:
> I would like to nominate Bharath Munirajulu (bharathm) as a OpenStack
> Octavia core reviewer.
> His contributions [1] are in line with other cores and he has been an
> active member of our community.  I have been impressed with the
> insight and quality of his reviews.
>
> Current Octavia cores, please vote by replying to this e-mail.
>
> Michael
>
>
> [1] http://stackalytics.com/report/contribution/octavia/90
>
> __
> 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] [lbaas] [octavia] Proposing Stephen Balukoff as Octavia Core

[Adam Harwell]

+1 from me!

From: Michael Johnson 
Sent: Thursday, February 4, 2016 7:03 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [lbaas] [octavia] Proposing Stephen Balukoff as 
Octavia Core

Octavia Team,

I would like to nominate Stephen Balukoff as a core reviewer for the
OpenStack Octavia project.  His contributions[1] are in line with
other cores and he has been an active member of our community.

Octavia cores please vote by replying to this e-mail.

Michael

[1] http://stackalytics.com/report/contribution/octavia/90

__
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][barbican]TLS container could not be found

[Adam Harwell]

Could you provide your neutron-lbaas.conf? Depending on what version you're 
using, barbican may not be the default secret backend (I believe this has been 
fixed). Alternatively, it depends on what user accounts are involved -- this 
should definitely work if you are using only the single admin account, but we 
haven't done a lot of testing around the ACLs yet to make sure they are working 
(and I believe there is still an outstanding bug in Barbican that would cause 
the ACLs to not function properly in our use-case).


?--Adam



From: Jiahao Liang 
Sent: Thursday, January 28, 2016 12:18 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron][LBaaS][barbican]TLS container could not be 
found

Hi community,

I was going through 
https://wiki.openstack.org/wiki/Network/LBaaS/docs/how-to-create-tls-loadbalancer
 with devstack. I was stuck at a point when I tried to create a listener within 
a loadbalancer with this command:

neutron lbaas-listener-create --loadbalancer lb1 --protocol-port 443 --protocol 
TERMINATED_HTTPS --name listener1 --default-tls-container=$(barbican secret 
container list | awk '/ tls_container / {print $2}')

But the command failed with output:

TLS container 
http://192.168.100.149:9311/v1/containers/d8b25d56-4fc5-406d-8b2d-5a85de2a1e34 
could not be found

When I run:

barbican secret container list

I was able to see the corresponding container in the list and the status is 
active.
(Sorry, the format is a little bit ugly.)
+++---++-+-+---+
| Container href
 | Name   | Created   | Status | Type| Secrets  
   
| Consumers |
+++---++-+-+---+
| 
http://192.168.100.149:9311/v1/containers/d8b25d56-4fc5-406d-8b2d-5a85de2a1e34 
| tls_container  | 2016-01-28 04:58:42+00:00 | ACTIVE | certificate | 
private_key=http://192.168.100.149:9311/v1/secrets/1bbe33fc-ecd2-43e5-82ce-34007b9f6bfd
 | None  |
|   
 ||   || | 
certificate=http://192.168.100.149:9311/v1/secrets/6d0211c6-8515-4e55-b1cf-587324a79abe
 |   |
| 
http://192.168.100.149:9311/v1/containers/31045466-bf7b-426f-9ba8-135c260418ee 
| tls_container2 | 2016-01-28 04:59:05+00:00 | ACTIVE | certificate | 
private_key=http://192.168.100.149:9311/v1/secrets/dba18cbc-9bfe-499e-931e-90574843ca10
 | None  |
|   
 ||   || | 
certificate=http://192.168.100.149:9311/v1/secrets/23e11441-d119-4b24-a288-9ddc963cb698
 |   |
+++---++-+-+---+


Also, if I did a GET method from a RESTful client with correct X-Auth-Token to 
the url: 
http://192.168.100.149:9311/v1/containers/d8b25d56-4fc5-406d-8b2d-5a85de2a1e3, 
I was able to receive the JSON information of the TLS container.


Anybody could give some advice on how to fix this problem?

Thank you in advance!

Best,
Jiahao Liang
__
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] Is SSL offload config possible using non "admin" tenant?

[Adam Harwell]

That sounds like the Barbican ACLs are not working properly. The whole point of 
using Barbican ACLs is that the keystone session marked for tenant "admin" 
should be able to get access to ANY tenant’s container/secrets if the ACLs are 
set. I am still not convinced this is an issue on the LBaaS side. 
Unfortunately, I don’t have a lot of time to test this right now as we’re up 
against the clock for the gate, so your help in debugging and fixing this issue 
is greatly appreciated! I just want to make sure the expected workflow is fully 
understood.

--Adam

https://keybase.io/rm_you


From: Vijay Venkatachalam 
<vijay.venkatacha...@citrix.com<mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Friday, September 18, 2015 at 2:02 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible 
using non "admin" tenant?


>> This honestly hasn’t even been *fully* tested yet, but it SHOULD work.
It did not work. Please read on.
>> User sets ACLs on Secrets and Container in Barbican, to allow the LBaaS user 
>> (right now using whatever user-id we publish in our docs) to read their data.
I did perform the above step to give read access for the container and secrets 
to “admin”, but it did not work.

Root Cause
==
The certmanager in lbaas which connects to barbican uses the keystone session 
gathered from
neutron_lbaas.common.keystone.get_session()
Since the keystone session is marked for tenant “admin” lbaas is not able to 
get the tenant’s container/certificate.

I have filed a bug for the same.

https://bugs.launchpad.net/neutron/+bug/1497410

This is an important fix required since tenants wont be able to use SSL 
Offload. Will try to upload a fix for this next week.


Thanks,
Vijay V.

From: Adam Harwell [mailto:adam.harw...@rackspace.com]
Sent: 16 September 2015 00:32
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible 
using non "admin" tenant?

There is not really good documentation for this yet…
When I say Neutron-LBaaS tenant, I am maybe using the wrong word — I guess the 
user that is configured as the service-account in neutron.conf.
The user will hit the ACL API themselves to set up the ACLs on their own 
secrets/containers, we won’t do it for them. So, workflow is like:


  *   User creates Secrets in Barbican.
  *   User creates CertificateContainer in Barbican.
  *   User sets ACLs on Secrets and Container in Barbican, to allow the LBaaS 
user (right now using whatever user-id we publish in our docs) to read their 
data.
  *   User creates a LoadBalancer in Neutron-LBaaS.
  *   LBaaS hits Barbican using its standard configured service-account to 
retrieve the Container/Secrets from the user’s Barbican account.
This honestly hasn’t even been *fully* tested yet, but it SHOULD work. The 
question is whether right now in devstack the admin user is allowed to read all 
user secrets just because it is the admin user (which I think might be the 
case), in which case we won’t actually know if ACLs are working as intended 
(but I think we assume that Barbican has tested that feature and we can just 
rely on it working).

--Adam

https://keybase.io/rm_you


From: Vijay Venkatachalam 
<vijay.venkatacha...@citrix.com<mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Monday, September 14, 2015 at 9:12 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible 
using non "admin" tenant?

Is there a documentation which records step by step?

What is Neutron-LBaaS tenant?

Is it the tenant who is configuring the listener? *OR* is it some tenant which 
is created for lbaas plugin that is the having all secrets for all tenants 
configuring lbaas.

>>You need to set up ACLs on the Barbican side for that container, to make it 
>>readable to the Neutron-LBaaS tenant.
I checked the ACL docs
http://docs.openstack.org/developer/barbican/api/quickstart/acls.html

The ACL API is to allow “users”(not “Tenants”) access to secrets/containers. 
What is the API or CLI that the admin will use to allow access of the tenant’s 
secret+containe

Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible using non "admin" tenant?

[Adam Harwell]

There is not really good documentation for this yet…
When I say Neutron-LBaaS tenant, I am maybe using the wrong word — I guess the 
user that is configured as the service-account in neutron.conf.
The user will hit the ACL API themselves to set up the ACLs on their own 
secrets/containers, we won’t do it for them. So, workflow is like:


  *   User creates Secrets in Barbican.
  *   User creates CertificateContainer in Barbican.
  *   User sets ACLs on Secrets and Container in Barbican, to allow the LBaaS 
user (right now using whatever user-id we publish in our docs) to read their 
data.
  *   User creates a LoadBalancer in Neutron-LBaaS.
  *   LBaaS hits Barbican using its standard configured service-account to 
retrieve the Container/Secrets from the user’s Barbican account.

This honestly hasn’t even been *fully* tested yet, but it SHOULD work. The 
question is whether right now in devstack the admin user is allowed to read all 
user secrets just because it is the admin user (which I think might be the 
case), in which case we won’t actually know if ACLs are working as intended 
(but I think we assume that Barbican has tested that feature and we can just 
rely on it working).

--Adam

https://keybase.io/rm_you


From: Vijay Venkatachalam 
<vijay.venkatacha...@citrix.com<mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Monday, September 14, 2015 at 9:12 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible 
using non "admin" tenant?

Is there a documentation which records step by step?

What is Neutron-LBaaS tenant?

Is it the tenant who is configuring the listener? *OR* is it some tenant which 
is created for lbaas plugin that is the having all secrets for all tenants 
configuring lbaas.

>>You need to set up ACLs on the Barbican side for that container, to make it 
>>readable to the Neutron-LBaaS tenant.
I checked the ACL docs
http://docs.openstack.org/developer/barbican/api/quickstart/acls.html

The ACL API is to allow “users”(not “Tenants”) access to secrets/containers. 
What is the API or CLI that the admin will use to allow access of the tenant’s 
secret+container to Neutron-LBaaS tenant.


From: Adam Harwell [mailto:adam.harw...@rackspace.com]
Sent: 15 September 2015 03:00
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible 
using non "admin" tenant?

You need to set up ACLs on the Barbican side for that container, to make it 
readable to the Neutron-LBaaS tenant. For now, the tenant-id should just be 
documented, but we are looking into making an API call that would expose the 
admin tenant-id to the user so they can make an API call to discover it.

Once the user has the neutron-lbaas tenant ID, they use the Barbican ACL system 
to add that ID as a readable user of the container and all of the secrets. Then 
Neutron-LBaaS hits barbican with the credentials of the admin tenant, and is 
granted access to the user’s container.

--Adam

https://keybase.io/rm_you


From: Vijay Venkatachalam 
<vijay.venkatacha...@citrix.com<mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Friday, September 11, 2015 at 2:35 PM
To: "OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [neutron][lbaas] Is SSL offload config possible using 
non "admin" tenant?

Hi,
  Has anyone tried configuring SSL Offload as a tenant?
  During listener creation there is an error thrown saying ‘could 
not locate/find container’.
  The lbaas plugin is not able to fetch the tenant’s certificate.

  From the code it looks like the lbaas plugin is tyring to connect 
to barbican with keystone details provided in neutron.conf
  Which is by default username = “admin” and tenant_name =”admin”.
  This means lbaas plugin is looking for tenant’s ceritifcate in 
“admin” tenant, which it will never be able to find.

  What is the procedure for the lbaas plugin to get hold of the 
tenant’s certificate?

  Assuming “admin” user has access to all tenant’s certificates. 
Should the l

Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible using non "admin" tenant?

[Adam Harwell]

You need to set up ACLs on the Barbican side for that container, to make it 
readable to the Neutron-LBaaS tenant. For now, the tenant-id should just be 
documented, but we are looking into making an API call that would expose the 
admin tenant-id to the user so they can make an API call to discover it.

Once the user has the neutron-lbaas tenant ID, they use the Barbican ACL system 
to add that ID as a readable user of the container and all of the secrets. Then 
Neutron-LBaaS hits barbican with the credentials of the admin tenant, and is 
granted access to the user’s container.

--Adam

https://keybase.io/rm_you


From: Vijay Venkatachalam 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, September 11, 2015 at 2:35 PM
To: "OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org)" 
>
Subject: [openstack-dev] [neutron][lbaas] Is SSL offload config possible using 
non "admin" tenant?

Hi,
  Has anyone tried configuring SSL Offload as a tenant?
  During listener creation there is an error thrown saying ‘could 
not locate/find container’.
  The lbaas plugin is not able to fetch the tenant’s certificate.

  From the code it looks like the lbaas plugin is tyring to connect 
to barbican with keystone details provided in neutron.conf
  Which is by default username = “admin” and tenant_name =”admin”.
  This means lbaas plugin is looking for tenant’s ceritifcate in 
“admin” tenant, which it will never be able to find.

  What is the procedure for the lbaas plugin to get hold of the 
tenant’s certificate?

  Assuming “admin” user has access to all tenant’s certificates. 
Should the lbaas plugin connect to barbican with username=’admin’ and 
tenant_name =  listener’s tenant_name?

Is this, the way forward ? *OR* Am I missing something?


Thanks,
Vijay V.
__
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] [designate] and [lbaas] - GSLB API and backend support

[Adam Harwell]

I haven’t seen any responses from my team yet, but I know we’d be interested as 
well — we have done quite a bit of work on this in the past, including dealing 
with the Designate team on this very subject. We can be available most hours 
between 9am-6pm Monday-Friday CST.

--Adam

https://keybase.io/rm_you


From: Rakesh Saha rsahaos...@gmail.commailto:rsahaos...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, May 28, 2015 at 12:22 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend 
support

Hi Kunal,
I would like to participate as well.
Mon-Fri morning US Pacific time works for me.

Thanks,
Rakesh Saha

On Tue, May 26, 2015 at 8:45 PM, Vijay Venkatachalam 
vijay.venkatacha...@citrix.commailto:vijay.venkatacha...@citrix.com wrote:
We would like to participate as well.

Monday-Friday Morning US time works for me..

Thanks,
Vijay V.

From: Samuel Bercovici [mailto:samu...@radware.commailto:samu...@radware.com]
Sent: 26 May 2015 21:39

To: OpenStack Development Mailing List (not for usage questions)
Cc: kunalhgan...@gmail.commailto:kunalhgan...@gmail.com; 
v.jain...@gmail.commailto:v.jain...@gmail.com; 
do...@a10networks.commailto:do...@a10networks.com
Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend 
support

Hi,

I would also like to participate.
Friday is a non-working day in Israel (same as Saturday for most of you).
So Monday- Thursday works best for me.

-Sam.


From: Doug Wiegley [mailto:doug...@parksidesoftware.com]
Sent: Saturday, May 23, 2015 8:45 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: kunalhgan...@gmail.commailto:kunalhgan...@gmail.com; 
v.jain...@gmail.commailto:v.jain...@gmail.com; 
do...@a10networks.commailto:do...@a10networks.com
Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend 
support

Of those two options, Friday would work better for me.

Thanks,
doug

On May 22, 2015, at 9:33 PM, ki...@macinnes.iemailto:ki...@macinnes.ie wrote:

Hi Kunal,
Thursday/Friday works for me - early morning PT works best, as I'm based in 
Ireland.
I'll find some specific times the Designate folks are available over the next 
day or two and provide some options..
Thanks,
Kiall
On 22 May 2015 7:24 pm, Gandhi, Kunal 
kunalhgan...@gmail.commailto:kunalhgan...@gmail.com wrote:
Hi All

I wanted to start a discussion about adding support for GSLB to neutron-lbaas 
and designate. To be brief for folks who are new to GLB, GLB stands for Global 
Load Balancing and we use it for load balancing traffic across various 
geographical regions. A more detail description of GLB can be found at my talk 
at the summit this week herehttps://www.youtube.com/watch?v=fNR0SW3vj_s.

To my understanding, there are two sides to a GSLB - DNS side and LB side.

DNS side
Most of the GSLB’s provided by various vendors are DNS servers and 
are authoritative for the GLB domains. The global fqdn’s that belong the GLB 
domains resolve to multiple public VIP’s across various regions based on 
various configurations on the global fqdn on the GLB.

LBaaS side
A few of the common functionalities provided by a standard GSLB 
provides are health monitoring on the public VIP’s and the local LB’s on which 
these public VIP’s sit on. Some additional features that a GSLB can provide are 
configuring admin status and weights on your public VIP’s. Based on these 
configurations and settings, the GLB returns the appropriate number of public 
VIP’s to any DNS resolve queries for the global fqdn’s.

I would like to have the designate and lbaas to start a discussion on GSLB and 
discuss the following topics:


  *   What parts of GSLB belongs to Designate and LBaaS ?
  *   Once we have an understanding of the above, my team at eBay/PayPal would 
like work with the community on submitting a blueprint for this.


To kick start this conversation, I would like to schedule an irc meeting 
regarding this with folks from designate and neutron-lbaas. Please let me know 
a time and day that works for you guys. I am available on Thursday and Friday 
next week.


Regards
Kunal


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.orgmailto: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:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions

[Adam Harwell]

Barbican is using SQLAlchemy, so I assume PostgreSQL is not a hard requirement. 
I know it deploys fine with SQLite for local development, and I am not aware of 
anything that would prevent it from running on MySQL. I am told it actually 
does use MySQL in devstack, so those docs may just be out of date.

--Adam

https://keybase.io/rm_you


From: Maish Saidel-Keesing mais...@maishsk.commailto:mais...@maishsk.com
Reply-To: maishsk+openst...@maishsk.commailto:maishsk+openst...@maishsk.com 
maishsk+openst...@maishsk.commailto:maishsk+openst...@maishsk.com, 
OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, May 21, 2015 at 5:45 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between 
Octavia and Barbican and Octavia 1.0 questions

Thanks Doug! PSB my comments within.

On 05/20/15 22:49, Doug Wiegley wrote:
Hi Maish,

Thanks for the feedback, some answers below.  Please also be aware of the lbaas 
use cases session tomorrow at 9am (yuck, I know), 
https://etherpad.openstack.org/p/YVR-neutron-lbaas-use-cases

Sorry but I will not be able to attend - I will be on a plane. I will look 
monitor the etherpad and pass my comments on.

On May 19, 2015, at 12:05 AM, Maish Saidel-Keesing 
mais...@maishsk.commailto:mais...@maishsk.com wrote:

Hello all,

Going over today's presentation Load Balancing as a Service, Kilo and 
Beyond[1] (great presentation!!) - there are a few questions I have regarding 
the future release:

For Octavia 1.0:

1. Can someone explain to me how the flow would work for spinning up a new 
Amphora with regards to interaction between Neutron, LBaaS and Barbican?
Same question as well regarding how the standby is created and its relationship 
with Barbican.

The lbaas API runs inside neutron-server.  The general flow is:

- User interacts with neutron CLI/API or horizon (in liberty), and creates an 
LB.
- Lbaas plugin in neutron creates logical models, fetches cert data from 
barbican, and calls the backend lbaas driver.
From this I gather that there is a dependency on Barbican. From what I found - 
this thread looks like the HA modelling for barbican [1]. Seems to me to be 
quite solid.

There was one detail that aroused my attention. Barbican is using PostgreSQL as 
the backend database [2].
Is there any specific reason why PostgreSQL and not MySQL like the rest of 
OpenStack? Is there any tehnical limitation that specifically requires 
PostgreSQL?

*From an operators perspective inducing a new database technology (yet again) 
this will is not ideal to say the least.*
- The backend driver does what it needs to to instantiate the LB. Today this is 
a synchronous call that waits for the nova boot, but by Liberty, it will likely 
be an async call to the octavia controller to finish the job.

Once Octavia has control, it is doing:

- Get REST calls for objects,
- Talk to nova, spin up an amphora image,
- Talk to neutron, plumb in the networks,
- Send the amphora its config.


2. Will the orchestration (Heat) also be implemented when Octavia 1.0 is 
released or only further down the line?
If not what would you suggest be the way to orchestrate LBaaS until this is 
ready?

We need to talk to the Heat folks and coordinate this, which we are planning to 
do soon.
Great! It would be ideal that this is available from Day 1, otherwise there 
will be no real to utilize this in production use cases.


3. Is there some kind of hook into Security groups also planned for the Amphora 
to also protect the Load Balancer?

Not at present, but I recorded this in the feature list on the etherpad above.
Much obliged - this is a basic security requirement that should be in place to 
protect/shield the load balancers from unwanted traffic.

[1] http://lists.openstack.org/pipermail/openstack/2014-March/006102.html
[2] https://github.com/cloudkeep/barbican/wiki/Architecture

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

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

[Adam Harwell]

+1

--Adam

https://keybase.io/rm_you


From: Doug Wiegley 
doug...@parksidesoftware.commailto:doug...@parksidesoftware.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Friday, May 1, 2015 at 11:19 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto: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 
jorge.miramon...@rackspace.commailto:jorge.miramon...@rackspace.com wrote:

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

Cheers,
--Jorge

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

​+1 from me

From: Kyle Mestery mest...@mestery.commailto: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 
german.eichber...@hp.commailto: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:unsubscribehttp://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.orgmailto: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 wanjing...@hotmail.commailto:wanjing...@hotmail.com
Reply-To: OpenStack Development Mailing List not for usage questions 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, April 30, 2015 at 5:15 PM
To: OpenStack Development Mailing List not for usage questions 
openstack-dev@lists.openstack.orgmailto: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.commailto:bharath.stac...@gmail.com
To: openstack-dev@lists.openstack.orgmailto: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 
brandon.lo...@rackspace.commailto: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 
brandon.lo...@rackspace.commailto: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 wanjing...@hotmail.commailto: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:unsubscribehttp://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] Barbican : Dependency of pyenv configuration in Barbican.sh script

[Adam Harwell]

Do you have sqlite installed on your system, and do you have config.py in the 
root of your barbican directory? The database is configured there (assuming it 
hasn’t changed since I last ran Barbican locally), and mine looks like this:

config = {
'sqlalchemy': {
'url': 'sqlite:tmp/barbican.db',
'echo': True,
'echo_pool': False,
'pool_recycle': 3600,
'encoding': 'utf-8'
}
}

--Adam

https://keybase.io/rm_you


From: neetu jain nut...@gmail.commailto:nut...@gmail.com
Date: Thursday, April 23, 2015 at 10:07 AM
To: Asha Seshagiri asha.seshag...@gmail.commailto:asha.seshag...@gmail.com
Cc: John Wood john.w...@rackspace.commailto:john.w...@rackspace.com, 
openstack-dev 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, 
Reller, Nathan S. 
nathan.rel...@jhuapl.edumailto:nathan.rel...@jhuapl.edu, Douglas Mendizabal 
douglas.mendiza...@rackspace.commailto:douglas.mendiza...@rackspace.com, 
Paul Kehrer paul.keh...@rackspace.commailto:paul.keh...@rackspace.com, Adam 
Harwell adam.harw...@rackspace.commailto:adam.harw...@rackspace.com, Alexis 
Lee alex...@hp.commailto:alex...@hp.com
Subject: Re: Barbican : Dependency of pyenv configuration in Barbican.sh script

Thanks John for you answer.
I tried running the  script bin/barbican-api and ran into this issue (pasted at 
the end) . Seems like the script does not take care of the database side.

1) do we need to do something else to setup database? or its being worked on ?
2) Can we help in the process of removing dependencies in these scripts? Should 
that be through the launchpad ?


TASK: [barbican | install barbican] ***
failed: [barbican-04] = {changed: true, cmd: cd /root/barbican/; python 
bin/barbican-api, delta: 0:00:00.553279, end: 2015-04-23 
14:56:45.773115, rc: 1, start: 2015-04-23 14:56:45.219836, warnings: 
[]}
stderr: 2015-04-23 14:56:45.736 6984 CRITICAL barbican [-] BarbicanException: 
No SQL connection configured
2015-04-23 14:56:45.736 6984 TRACE barbican Traceback (most recent call last):
2015-04-23 14:56:45.736 6984 TRACE barbican   File bin/barbican-api, line 17, 
in module
2015-04-23 14:56:45.736 6984 TRACE barbican run()
2015-04-23 14:56:45.736 6984 TRACE barbican   File bin/barbican-api, line 12, 
in run
2015-04-23 14:56:45.736 6984 TRACE barbican relative_to='.')
2015-04-23 14:56:45.736 6984 TRACE barbican   File 
/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 247, in 
loadapp
2015-04-23 14:56:45.736 6984 TRACE barbican return loadobj(APP, uri, 
name=name, **kw)
2015-04-23 14:56:45.736 6984 TRACE barbican   File 
/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 272, in 
loadobj
2015-04-23 14:56:45.736 6984 TRACE barbican return context.create()
2015-04-23 14:56:45.736 6984 TRACE barbican   File 
/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 710, in create
2015-04-23 14:56:45.736 6984 TRACE barbican return 
self.object_type.invoke(self)
2015-04-23 14:56:45.736 6984 TRACE barbican   File 
/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 144, in invoke
2015-04-23 14:56:45.736 6984 TRACE barbican **context.local_conf)
2015-04-23 14:56:45.736 6984 TRACE barbican   File 
/usr/lib/python2.7/site-packages/paste/deploy/util.py, line 56, in fix_call
2015-04-23 14:56:45.736 6984 TRACE barbican val = callable(*args, **kw)
2015-04-23 14:56:45.736 6984 TRACE barbican   File 
/usr/lib64/python2.7/site-packages/paste/urlmap.py, line 31, in urlmap_factory
2015-04-23 14:56:45.736 6984 TRACE barbican app = loader.get_app(app_name, 
global_conf=global_conf)
2015-04-23 14:56:45.736 6984 TRACE barbican   File 
/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 350, in 
get_app
2015-04-23 14:56:45.736 6984 TRACE barbican name=name, 
global_conf=global_conf).create()
2015-04-23 14:56:45.736 6984 TRACE barbican   File 
/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 710, in create
2015-04-23 14:56:45.736 6984 TRACE barbican return 
self.object_type.invoke(self)
2015-04-23 14:56:45.736 6984 TRACE barbican   File 
/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 203, in invoke
2015-04-23 14:56:45.736 6984 TRACE barbican app = 
context.app_context.create()
2015-04-23 14:56:45.736 6984 TRACE barbican   File 
/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 710, in create
2015-04-23 14:56:45.736 6984 TRACE barbican return 
self.object_type.invoke(self)
2015-04-23 14:56:45.736 6984 TRACE barbican   File 
/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 146, in invoke
2015-04-23 14:56:45.736 6984 TRACE barbican return fix_call(context.object, 
context.global_conf, **context.local_conf)
2015-04-23 14:56:45.736 6984 TRACE barbican   File 
/usr/lib/python2.7/site-packages/paste/deploy/util.py, line 56, in fix_call
2015-04-23 14:56:45.736 6984 TRACE barbican val

Re: [openstack-dev] Barbican : Use of consumer resource

[Adam Harwell]

As John said, the URI is unrestricted (intentionally so) -- this could be 
'mailto:s...@person.com' just as easily as a reference to another OpenStack or 
external service. Originally, the idea was that Loadbalancers would need to use 
a Container for TLS purposes, so we'd put the LB's URI in there as a 
back-reference 
(https://loadbalancers.myservice.com/lbaas/v2/loadbalancers/12345). That way, 
you could easily show in Horizon that LB 12345 is using this container.

Registering with that POST has the side-effect of receiving the container's 
data as though you'd just done a GET - so, the design was that any time a 
service needed to GET the container data, it would do a POST to register 
instead - which would give you the data, but also mark interest. The 
registration action is idempotent, so you can register once, twice, or a 
hundred times and it has the same effect. The only tricky part is making sure 
that your service de-registers when you stop using the container.

--Adam


From: John Wood john.w...@rackspace.commailto:john.w...@rackspace.com
Date: Tuesday, March 31, 2015 12:06 AM
To: Asha Seshagiri asha.seshag...@gmail.commailto:asha.seshag...@gmail.com, 
openstack-dev 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Cc: Reller, Nathan S. 
nathan.rel...@jhuapl.edumailto:nathan.rel...@jhuapl.edu, Douglas Mendizabal 
douglas.mendiza...@rackspace.commailto:douglas.mendiza...@rackspace.com, 
a...@redhat.commailto:a...@redhat.com 
a...@redhat.commailto:a...@redhat.com, Paul Kehrer 
paul.keh...@rackspace.commailto:paul.keh...@rackspace.com, Adam Harwell 
adam.harw...@rackspace.commailto:adam.harw...@rackspace.com
Subject: Re: Barbican : Use of consumer resource

(Including Adam, who implemented this feature last year to make sure I'm not 
misspeaking here :)

Hello Asha,

The consumers feature allows clients/services to register 'interest' in a given 
secret or container. The URL provided is unrestricted. Clients that wish to 
delete a secret or consumer may add logic to hold off deleting if other 
services have registered their interest in the resource. However for Barbican 
this data is only informational, with no business logic (such as rejecting 
delete attempts) associated with it.

I hope that helps.

Thanks,
John


From: Asha Seshagiri asha.seshag...@gmail.commailto:asha.seshag...@gmail.com
Date: Monday, March 30, 2015 at 5:04 PM
To: openstack-dev 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Cc: John Wood john.w...@rackspace.commailto:john.w...@rackspace.com, 
Reller, Nathan S. 
nathan.rel...@jhuapl.edumailto:nathan.rel...@jhuapl.edu, Douglas Mendizabal 
douglas.mendiza...@rackspace.commailto:douglas.mendiza...@rackspace.com, 
a...@redhat.commailto:a...@redhat.com 
a...@redhat.commailto:a...@redhat.com, Paul Kehrer 
paul.keh...@rackspace.commailto:paul.keh...@rackspace.com
Subject: Re: Barbican : Use of consumer resource

Including Alee and Paul in the loop

Refining the above question :

The consumer resource allows the clients to register with container resources. 
Please find the command and response below


POST v1/containers/888b29a4-c7cf-49d0-bfdf-bd9e6f26d718/consumers

Header: content-type=application/json
X-Project-Id: {project_id}
{
name: foo-service,
URL: https://www.fooservice.com/widgets/1234;
}

I would like to know the following :

1. Who  does the client here refers to ? Openstack Services or any other 
services as well?

2. Once the client gets registered through the consumer resource , How does 
client consume or use the consumer resource

Any Help would be appreciated.

Thanks Asha.




On Mon, Mar 30, 2015 at 12:05 AM, Asha Seshagiri 
asha.seshag...@gmail.commailto:asha.seshag...@gmail.com wrote:
Hi All,

Once the consumer resource registers to the containers , how does the consumer 
resource consume the container resource?
Is there any API supporting the above operation.

Could any one please help on this?

--
Thanks and Regards,
Asha Seshagiri



--
Thanks and Regards,
Asha Seshagiri
__
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] LBaaS Haproxy performance benchmarking

[Adam Harwell]

At Rackspace we have been working on automated testing with Ansible and Tsung, 
but I don’t know if that code ever made it to a public repository… We found 
Tsung to be very useful for parallel testing though! :)

--Adam

https://keybase.io/rm_you


From: Varun Lodaya varun_lod...@symantec.commailto:varun_lod...@symantec.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, February 3, 2015 at 6:58 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron] [lbaas] LBaaS Haproxy performance 
benchmarking

Hi,

We were trying to use haproxy as our LBaaS solution on the overlay. Has anybody 
done some baseline benchmarking with LBaaSv1 haproxy solution?

Also, any recommended tools which we could use to do that?

Thanks,
Varun
__
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] Mid-cycle hack-a-thon

[Adam Harwell]

Any chance it could actually be the week AFTER? Or is that to close to the 
holidays? _

On Nov 6, 2014 7:21 AM, Stephen Balukoff sbaluk...@bluebox.net wrote:

I have just learned that there will be a Neutron hack-a-thon the week of Dec 8 
in Salt Lake City. Since we don't want to conflict with that, I would like to 
do the Octavia hack-a-thon the previous week: Dec. 1 through 5 in Seattle.

On Nov 5, 2014 11:05 PM, Adam Harwell 
adam.harw...@rackspace.commailto:adam.harw...@rackspace.com wrote:
I can probably make it up there to attend.

--Adam

https://keybase.io/rm_you


From: Stephen Balukoff sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, November 4, 2014 3:46 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Octavia] Mid-cycle hack-a-thon


Howdy, folks!

We are planning to have a mid-cycle hack-a-thon in Seattle from the 8th through 
the 12th of December. This will be at the HP corporate offices located in the 
Seattle convention center.

During this week we will be concentrating on Octavia code and hope to make 
significant progress toward our v0.5 milestone.

If you are interested in attending, please e-mail me. If you are interested in 
participating but can't travel to Seattle that week, please also let me know, 
and we will see about using other means to collaborate with you in real time.

Thanks!
Stephen
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][LBaaS] Paris Summit talking points

[Adam Harwell]

Let's get a list of questions / talking points set up on this etherpad: 
https://etherpad.openstack.org/p/paris_absentee_talking_points

If you can't make it to the summit (like me) then you can put any questions or 
concerns you have in this document.
If you are going to the summit, please take a look at this list (maybe keep it 
handy) and see if you can help us out by asking the questions or arguing the 
talking points for us!

I've populated it with a couple of the things that are on my mind at the 
moment. Please add anything you can think of, and ideally put answers and 
comments in once you've gotten them!
Even if you're going, it might not be a bad idea to jot some notes now so you 
don't forget during the hustle and bustle of traveling and after-parties! :)

--Adam

https://keybase.io/rm_you

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Barbican Integration for Advanced Services

[Adam Harwell]

I've made an attempt at mapping out exactly how Neutron Advanced Services will 
communicate with Barbican to retrieve Certificate/Key info for TLS purposes. 
These diagrams have gone through several revisions, but are still an early 
draft of the interactions: http://imgur.com/a/4u6Oz

Note that these diagrams use Neutron-LBaaS as the example use-case, but the 
flow would be essentially the same for any service (FWaaS, VPNaaS, etc). The 
code that handles this will be in neutron/common/ so that it can be used by any 
extension. There is a WIP CR here (though right now it doesn't look anything 
like the final version, including very badly named and organized functions): 
https://review.openstack.org/#/c/123492/

Hopefully this is not a new concept, as I believe we agreed during the Atlanta 
summit that using Barbican to store TLS cert/key data was the appropriate path 
forward for Neutron (and other OpenStack projects).

I assume there may be other teams investigating very similar integration 
schemes as well, so if anyone has comments or suggestions, I'd love to hear 
them.

Thanks,
--Adam Harwell

https://keybase.io/rm_you

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Interaction with Barbican and Keystone

[Adam Harwell]

Yeah, I was hoping for something like that... Essentially, Horizon would
need to detect that particular response and be prepared to make a simple
Yes/No dialog pop up to create that Trust, then continue with the original
operation again automatically afterwards. That said, I have not looked at
programming Horizon interfaces at all yet, so I don't know how feasible
that is.

--Adam


https://keybase.io/rm_you





On 9/24/14 5:02 PM, Eichberger, German german.eichber...@hp.com wrote:

Hi Adam,

For me the thing needs to be user friendly. So my main question is how do
things look in Horizon? Will there just be a popup saying Establish
Trust (Y/N). I am wondering as you how other teams are handling that...

Thanks,
German

-Original Message-
From: Adam Harwell [mailto:adam.harw...@rackspace.com]
Sent: Thursday, September 18, 2014 3:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: sbaluk...@bluebox.net; Doug Wiegley; Eichberger, German; Adam Young;
Balle, Susanne; Douglas Mendizabal
Subject: [openstack-dev] [Neutron][LBaaS] Interaction with Barbican and
Keystone

I've made an attempt at mapping out exactly how Neutron Advanced Services
will communicate with Barbican to retrieve Certificate/Key info for TLS
purposes. This is far from solidified, since there are some issues that
I'll go over momentarily. First, here is a *high level* diagram of the
process flow:

http://i.imgur.com/VQcbGJS.png (I use the term hijack purposefully)


And here is a more detailed flow, including each and every operation:

http://goo.gl/Wc8oIj

There are some valid concerns about this workflow, and at least one issue
that may be a blocker.

Following are the two main issues that I've run into:

1) Possible blocker: Keystone won't allow Trust creation using a Trust
Token. Example: A user creates a Trust for Heat, and gives Heat their
TrustID. The user configures Heat to spin up Load Balancers. Heat
contacts LBaaS on behalf of the user with a Trust Token. LBaaS contacts
Keystone to create a Trust using the token received from Heat. LBaaS
would be unable to create a Trust because the Token we're trying to use
doesn't have the ability to create Trusts, and our operation would fail.

2) Security concern: If the Neutron/LBaaS config contains a Service
Account's user/pass and Database URI/user/pass, then anyone with access
to the config file would be able to connect to the DB, pull out TrustIDs,
and use the Neutron Service Account to execute them. Essentially, the
only difference between storing private keys directly in the database and
storing them in Barbican is that there's one additional (trivial) step to
get the key data (contact the Barbican API).

The keystone folks I talked to (primarily Adam Young) suggested that the
solution to issue #1 is to require the user to create the Trust
beforehand in Keystone, then pass the TrustID to Neutron/LBaaS along with
the ContainerID. This could originally be based on a template we
provide to the user, probably in the form of a suggested JSON body and
keystone URI.
Eventually, there could/should/might be a system in place to allow
services to pre-define a Trust with Keystone and the user would just need
to tell Keystone that they accept that Trust. Either way, this would
require action by the user before they could create a TLS Terminated LB.
I don't particularly LIKE that option, but if 90% of our users come
through Horizon anyway, it should be as simple as having Horizon pop up a
Yes/No box prompting to enable the Trust when the user creates their
first TLS LB.

As for issue #2, I don't really have a solution to propose. There was
some talk about the Postern project, but there isn't really any usable
code yet, or even solid specs from what I can tell -- it looks like the
project was proposed and never went past the PoC stage.
https://github.com/cloudkeep/postern

I know there are some other teams looking into very similar issues, so I
have a bit of research to do on that front, but in the meantime, what are
people's thoughts? I've cc'd a few of the people who were already in the
IRC version of this discussion (I may have missed anyone who wasn't
already in my address book, sorry), but I'd love to hear from anyone who
has ideas on the subject.

   --Adam


https://keybase.io/rm_you



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][LBaaS] Interaction with Barbican and Keystone

[Adam Harwell]

I've made an attempt at mapping out exactly how Neutron Advanced Services
will communicate with Barbican to retrieve Certificate/Key info for TLS
purposes. This is far from solidified, since there are some issues that
I'll go over momentarily. First, here is a *high level* diagram of the
process flow:

http://i.imgur.com/VQcbGJS.png (I use the term hijack purposefully)


And here is a more detailed flow, including each and every operation:

http://goo.gl/Wc8oIj

There are some valid concerns about this workflow, and at least one issue
that may be a blocker.

Following are the two main issues that I've run into:

1) Possible blocker: Keystone won't allow Trust creation using a Trust
Token. Example: A user creates a Trust for Heat, and gives Heat their
TrustID. The user configures Heat to spin up Load Balancers. Heat contacts
LBaaS on behalf of the user with a Trust Token. LBaaS contacts Keystone to
create a Trust using the token received from Heat. LBaaS would be unable
to create a Trust because the Token we're trying to use doesn't have the
ability to create Trusts, and our operation would fail.

2) Security concern: If the Neutron/LBaaS config contains a Service
Account's user/pass and Database URI/user/pass, then anyone with access to
the config file would be able to connect to the DB, pull out TrustIDs, and
use the Neutron Service Account to execute them. Essentially, the only
difference between storing private keys directly in the database and
storing them in Barbican is that there's one additional (trivial) step to
get the key data (contact the Barbican API).

The keystone folks I talked to (primarily Adam Young) suggested that the
solution to issue #1 is to require the user to create the Trust beforehand
in Keystone, then pass the TrustID to Neutron/LBaaS along with the
ContainerID. This could originally be based on a template we provide to
the user, probably in the form of a suggested JSON body and keystone URI.
Eventually, there could/should/might be a system in place to allow
services to pre-define a Trust with Keystone and the user would just need
to tell Keystone that they accept that Trust. Either way, this would
require action by the user before they could create a TLS Terminated LB. I
don't particularly LIKE that option, but if 90% of our users come through
Horizon anyway, it should be as simple as having Horizon pop up a Yes/No
box prompting to enable the Trust when the user creates their first TLS LB.

As for issue #2, I don't really have a solution to propose. There was some
talk about the Postern project, but there isn't really any usable code
yet, or even solid specs from what I can tell -- it looks like the project
was proposed and never went past the PoC stage.
https://github.com/cloudkeep/postern

I know there are some other teams looking into very similar issues, so I
have a bit of research to do on that front, but in the meantime, what are
people's thoughts? I've cc'd a few of the people who were already in the
IRC version of this discussion (I may have missed anyone who wasn't
already in my address book, sorry), but I'd love to hear from anyone who
has ideas on the subject.

--Adam


https://keybase.io/rm_you


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Octavia] Responsibilities for controller drivers

[Adam Harwell]

I pretty much completely agree with Stephen here, other than believing we 
should do N:1 on VIPs (item 2 in your list) from the start. We know we're doing 
IPv6 this way, and I'd rather not put off support for it at the 
controller/driver/whatever layer just because the underlying infrastructure 
isn't there yet. I'd like to be 100% ready when it is, not wait until the 
network is ready and then do a refactor.

--Adam

https://keybase.io/rm_you


From: Stephen Balukoff sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, September 15, 2014 1:33 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Octavia] Responsibilities for controller drivers

Hi Brandon!

My responses in-line:

On Fri, Sep 12, 2014 at 11:27 AM, Brandon Logan 
brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote:
IN IRC the topic came up about supporting many-to-many load balancers to
amphorae.  I believe a consensus was made that allowing only one-to-many
load balancers to amphorae would be the first step forward, and
re-evaluate later, since colocation and apolocation will need to work
(which brings up another topic, defining what it actually means to be
colocated: On the same amphorae, on the same amphorae host, on the same
cell/cluster, on the same data center/availability zone. That should be
something we discuss later, but not right now).

I am fine with that decisions, but Doug brought up a good point that
this could very well just be a decision for the controller driver and
Octavia shouldn't mandate this for all drivers.  So I think we need to
clearly define what decisions are the responsibility of the controller
driver versus what decisions are mandated by Octavia's construct.

In my mind, the only thing dictated by the controller to the driver here would 
be things related to colocation / apolocation. So in order to fully have that 
discussion here, we first need to have a conversation about what these things 
actually mean in the context of Octavia and/or get specific requirements from 
operators here.  The reference driver (ie. haproxy amphora) will of course have 
to follow a given behavior here as well, and there's the possibility that even 
if we don't dictate behavior in one way or another, operators and users may 
come to expect the behavior of the reference driver here to become the defacto 
requirements.


Items I can come up with off the top of my head:

1) LB:Amphora - M:N vs 1:N

My opinion:  For simplicity, first revision should be 1:N, but leave open the 
possibility of M:N at a later date, depending on what people require. That is 
to say, we'll only do 1:N at first so we can have simpler scheduling algorithms 
for now, but let's not paint ourselves into a corner in other portions of the 
code by assuming there will only ever be one LB on an amphora.

2) VIPs:LB - M:N vs 1:N

So, I would revise that to be N:1 or 1:1. I don't think we'll ever want to 
support a case where multiple LBs share the same VIP. (Multiple amphorae per 
VIP, yes... but not multiple LBs per VIP. LBs are logical constructs that also 
provide for good separation of concerns, particularly around security.)

The most solid use case for N:1 that I've heard is the IPv6 use case, where a 
user wants to expose the exact same services over IPv4 and IPv6, and therefore 
it makes sense to be able to have multiple VIPs per load balancer. (In fact, 
I'm not aware of other use cases here that hold any water.) Having said this, 
we're quite a ways from IPv6 being ready for use in the underlying networking 
infrastructure.  So...  again, I would say let's go with 1:1 for now to make 
things simple for scheduling, but not paint ourselves into a corner here 
architecturally in other areas of the code by assuming there will only ever be 
one VIP per LB.

3) Pool:HMs - 1:N vs 1:1

Does anyone have a solid use case for having more than one health monitor per 
pool?  (And how do you resolve conflicts in health monitor check results?)  I 
can't think of one, so 1:1 has my vote here.



I'm sure there are others.  I'm sure each one will need to be evaluated
on a case-by-case basis.  We will be walking a fine line between
flexibility and complexity.  We just need to define how far over that
line and in which direction we are willing to go.

Thanks,
Brandon
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [neutron][lbaas][octavia]

[Adam Harwell]

I also agree with most of what Brandon said, though I am slightly
concerned by the talk of merging Octavia and [Neutron-]LBaaS-v2 codebases.

[blogan] I think the best course of action is to get Octavia itself into
the same codebase as LBaaS (Neutron or spun out).
[sballe] What I am trying to now understand is how we will move Octavia
into the new LBaaS project?


I didn't think that was ever going to be the plan -- sure, we'd have an
Octavia driver that is part of the [Neutron-]LBaaS-v2 codebase (which
Susanne did mention as well), but nothing more than that. The actual
Octavia code would still be in its own project at the end of all of this,
right? The driver code could be added to [Neutron-]LbaaS-v2 at any point
once Octavia is mature enough to be used, just by submitting it as a CR, I
believe. Doug might be able to comment on that, since he maintains the A10
driver?

Also, I know I'm opening this same can of worms again, but I am curious
about the HP mandate that everything must be OpenStack when it comes to
Octavia. Since HP's offering would be [Neutron-]LBaaS-v2, which happens
to use Octavia as a backend, does it matter whether Octavia is an official
OpenStack project**? If HP can offer Cloud Compute through Nova, and Nova
uses some hypervisor like Xen or KVM (neither of which are a part of
OpenStack), I am not sure how it is different to offer Cloud Load
Balancing via [Neutron-]LBaaS-v2 which could be using a non-Openstack
implementation for the backend. I don't see Octavia needs to be in
Openstack as a blocker so long as the LBaaS API is part of OpenStack.

**NOTE: I AM DEFINITELY STILL IN FAVOR OF OCTAVIA BEING AN OPENSTACK
PROJECT. THIS IS JUST AN EXAMPLE FOR THE SAKE OF THIS PARTICULAR ARGUMENT.
PLEASE DON'T THINK THAT I'M AGAINST OCTAVIA BEING OFFICIALLY INCUBATED!**


 --Adam


https://keybase.io/rm_you



On 9/1/14 10:12 PM, Brandon Logan brandon.lo...@rackspace.com wrote:

Hi Susanne and everyone,

My opinions are that keeping it in stackforge until it gets mature is
the best solution.  I'm pretty sure we can all agree on that.  Whenever
it is mature then, and only then, we should try to get it into openstack
one way or another.  If Neutron LBaaS v2 is still incubated then it
should be relatively easy to get it in that codebase.  If Neutron LBaaS
has already spun out, even easier for us.  If we want Octavia to just
become an openstack project all its own then that will be the difficult
part.

I think the best course of action is to get Octavia itself into the same
codebase as LBaaS (Neutron or spun out).  They do go together, and the
maintainers will almost always be the same for both.  This makes even
more sense when LBaaS is spun out into its own project.

I really think all of the answers to these questions will fall into
place when we actually deliver a product that we are all wanting and
talking about delivering with Octavia.  Once we prove that we can all
come together as a community and manage a product from inception to
maturity, we will then have the respect and trust to do what is best for
an Openstack LBaaS product.

Thanks,
Brandon

On Mon, 2014-09-01 at 10:18 -0400, Susanne Balle wrote:
 Kyle, Adam,
 
  
 
 Based on this thread Kyle is suggesting the follow moving forward
 plan: 
 
  
 
 1) We incubate Neutron LBaaS V2 in the ³Neutron² incubator ³and freeze
 LBaas V1.0²
 2) ³Eventually² It graduates into a project under the networking
 program.
 3) ³At that point² We deprecate Neutron LBaaS v1.
 
  
 
 The words in ³xx³ are works I added to make sure I/We understand the
 whole picture.
 
  
 
 And as Adam mentions: Octavia != LBaaS-v2. Octavia is a peer to F5 /
 Radware / A10 / etc appliances which is a definition I agree with BTW.
 
  
 
 What I am trying to now understand is how we will move Octavia into
 the new LBaaS project?
 
  
 
 If we do it later rather than develop Octavia in tree under the new
 incubated LBaaS project when do we plan to bring it in-tree from
 Stackforge? Kilo? Later? When LBaaS is a separate project under the
 Networking program?

  
 
 What are the criteria to bring a driver into the LBaaS project and
 what do we need to do to replace the existing reference driver? Maybe
 adding a software driver to LBaaS source tree is less of a problem
 than converting a whole project to an OpenStack project.

  
 
 Again I am open to both directions I just want to make sure we
 understand why we are choosing to do one or the other and that our
  decision is based on data and not emotions.
 
  
 
 I am assuming that keeping Octavia in Stackforge will increase the
 velocity of the project and allow us more freedom which is goodness.
 We just need to have a plan to make it part of the Openstack LBaaS
 project.
 
  
 
 Regards Susanne
 
 
 
 
 On Sat, Aug 30, 2014 at 2:09 PM, Adam Harwell
 adam.harw...@rackspace.com wrote:
 Only really have comments on two of your related points:
 
 
 [Susanne] To me Octavia is a driver so it is very

Re: [openstack-dev] [neutron][lbaas][octavia]

[Adam Harwell]

Yeah, I think I agree there. If we were to go the Neutron-incubator route, we'd 
end up with Neutron-Octavia, and I don't think that's what we want, right?
I believe to be Openstack-Octavia we need to be incubated as a separate 
project.

--Adam

https://keybase.io/rm_you


From: Kevin Benton blak...@gmail.commailto:blak...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, August 28, 2014 3:55 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron][lbaas][octavia]

I think we need some clarification here too about the difference between the 
general OpenStack Incubation and the Neutron incubation. From my understanding, 
the Neutron incubation isn't the path to a separate project and independence 
from Neutron. It's a process to get into Neutron. So if you want to keep it as 
a separate project with its own cores and a PTL, Neutron incubation would not 
be the way to go.


On Thu, Aug 28, 2014 at 3:04 PM, Susanne Balle 
sleipnir...@gmail.commailto:sleipnir...@gmail.com wrote:
Just for us to learn about the incubator status, here are some of the info on 
incubation:

https://wiki.openstack.org/wiki/Governance/Approved/Incubation
https://wiki.openstack.org/wiki/Governance/NewProjects

Susanne


On Thu, Aug 28, 2014 at 5:57 PM, Susanne Balle 
sleipnir...@gmail.commailto:sleipnir...@gmail.com wrote:
 I would like to discuss the pros and cons of putting Octavia into the Neutron 
LBaaS incubator project right away. If it is going to be the reference 
implementation for LBaaS v 2 then I believe Octavia belong in Neutron LBaaS v2 
incubator.

The Pros:
* Octavia is in Openstack incubation right away along with the lbaas v2 code. 
We do not have to apply for incubation later on.
* As incubation project we have our own core and should be able ot commit our 
code
* We are starting out as an OpenStack incubated project

The Cons:
* Not sure of the velocity of the project
* Incubation not well defined.

If Octavia starts as a standalone stackforge project we are assuming that it 
would be looked favorable on when time is to move it into incubated status.

Susanne




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [barbican] Consumer Registration API

[Adam Harwell]

That sounds sensical to me. It actually still saves me work in the long-run, I 
think. :)

--Adam

https://keybase.io/rm_you


From: Douglas Mendizabal 
douglas.mendiza...@rackspace.commailto:douglas.mendiza...@rackspace.com
Date: Wednesday, July 2, 2014 9:02 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Cc: John Wood john.w...@rackspace.commailto:john.w...@rackspace.com, Adam 
Harwell adam.harw...@rackspace.commailto:adam.harw...@rackspace.com
Subject: [barbican] Consumer Registration API

I was looking through some Keystone docs and noticed that for version 3.0 of 
their API [1] Keystone merged the Service and Admin API into a single core API. 
 I haven’t gone digging through mail archives, but I imagine they had a pretty 
good reason to do that.

Adam, I know you’ve already implemented quite a bit of this, and I hate to ask 
this, but how do you feel about adding this to the regular API instead of 
building out the Service API for Barbican?

[1] 
https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3.md#whats-new-in-version-30


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5 0CC9 AD14 1F30 2D58 923C
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas

[Adam Harwell]

Doug: The reasons a LB might be reprovisioned are fairly important — mostly 
around HA, for fail overs or capacity — exactly the times we're trying avoid a 
failure.

Stephen: yes, I am talking about storing the copy in a non-tenant way (on the 
tenant-id for the LBaaS Service Account, not visible to the user). We would 
have to delete our shadow-copy when the loadbalancer was updated with a new 
barbicanID by the user, and make a copy of the new container to take its place.
Also, yes, I think it would be quite surprising (and far from ideal) when the 
LB you set up breaks weeks or months later when an HA event occurs and you 
haven't actually made any changes in quite a long time. Unfortunately, 
making the key unusable in all other contexts on a Barbican delete isn't 
really an option, so this is the best fallback I can think of.

--Adam

https://keybase.io/rm_you


From: Doug Wiegley do...@a10networks.commailto:do...@a10networks.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, June 10, 2014 2:53 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS 
Integration Ideas

 In any case, it strikes me as misleading to have an explicit delete command 
 sent to Barbican not have the effect of making the key unusable in all other 
 contexts. It would be less surprising behavior, IMO, to have a deleted 
 barbican container result in connected load balancing services breaking. 
 (Though without notification to LBaaS, the connected service might break 
 weeks or months after the key disappeared from barbican, which would be more 
 surprising behavior.)

Since a delete in barbican will not affect neutron/lbaas, and since most 
backends will have had to make their own copy of the key at lb provision time, 
the barbican delete will not result in lbaas breaking, I think.  The shadow 
copy would only get used if the lb had to be re-provisioned for some reason 
before it was given a new key id, which seems a fair bit of complexity for what 
is gained.

doug


From: Stephen Balukoff sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, June 10, 2014 at 1:47 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS 
Integration Ideas

Adam--

Wouldn't the user see the duplicate key/cert copy in their barbican interface, 
or are you proposing storing these secrets in a not-assigned-to-the-tenant kind 
of way?

In any case, it strikes me as misleading to have an explicit delete command 
sent to Barbican not have the effect of making the key unusable in all other 
contexts. It would be less surprising behavior, IMO, to have a deleted barbican 
container result in connected load balancing services breaking. (Though without 
notification to LBaaS, the connected service might break weeks or months after 
the key disappeared from barbican, which would be more surprising behavior.)

Personally, I like your idea, as I think most of our users would rather have 
LBaaS issue warnings when the user has done something stupid like this rather 
than break entirely. I know our support staff would rather it behaved this way.

What's your proposal for cleaning up copied secrets when they're actually no 
longer in use by any LB?

Stephen


On Tue, Jun 10, 2014 at 12:04 PM, Adam Harwell 
adam.harw...@rackspace.commailto:adam.harw...@rackspace.com wrote:
So, it looks like any sort of validation on Deletes in Barbican is going
to be a no-go. I'd like to propose a third option, which might be the
safest route to take for LBaaS while still providing some of the
convenience of using Barbican as a central certificate store. Here is a
diagram of the interaction sequence to create a loadbalancer:
http://bit.ly/1pgAC7G

Summary: Pass the Barbican TLS Container ID to the LBaaS create call,
get the container from Barbican, and store a shadow-copy of the
container again in Barbican, this time on the LBaaS service account.
The secret will now be duplicated (it still exists on the original tenant,
but also exists on the LBaaS tenant), but we're not talking about a huge
amount of data here -- just a few kilobytes. With this approach, we retain
most of the advantages we wanted to get from using Barbican -- we don't
need to worry about taking secret data through the LBaaS API (we still
just take a barbicanID from the user), and the user can still use a single
barbicanID (the original one they created -- the copies are invisible to
them) when passing their TLS info to other services. We

Re: [openstack-dev] [Neutron][LBaaS] Meetup?

[Adam Harwell]

I'm not sure if there's anything super important today that everyone is 
attending. I'm in the Future of Neutron panel right now, but would people want 
to meet up after that? Maybe over some lunch, since I think most of my team 
missed breakfast? :)
After that would probably work too, again provided there aren't any other super 
important panels we'd be missing.

  --Adam

On May 12, 2014 11:32 AM, Eugene Nikanorov enikano...@mirantis.com wrote:

Hi,

what time are you suggesting?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Meetup?

[Adam Harwell]

Some of us are at a table towards the back by the B3b door (and a large 
restrooms sign).

On May 12, 2014 12:24 PM, Adam Harwell adam.harw...@rackspace.com wrote:

Yeah, I guess we'll try to catch people after this session (lunch officially 
starts at 12:45 apparently).

On May 12, 2014 11:48 AM, Eugene Nikanorov enikano...@mirantis.com wrote:

I'm going to attend the next nw session @b103, we can meet in between. Im in 
b103 too.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] API proposal review thoughts

[Adam Harwell]

Just a couple of quick comments since it is super late here and I don't want to 
reply to the entire email just yet...

Firstly, I think most of us at Rackspace like the way your proposal handles L7 
(hopefully my team actually agrees and I am not speaking out of turn, but I 
definitely like it), so I wouldn't really consider that as a difference because 
I think we'd like to incorporate your method into our proposal anyway. 
Similarly, upon further review I think I would agree that our SSL cert handling 
is also a bit wonky, and could be much improved by another draft. In fact, I'd 
like to assume that what we're really discussing is making a third revision of 
the proposal, rather than whether to use one or the other verbatim.

Secondly, technical descriptions are great, but I'd like to talk about the term 
load balancer in a more approachable manner. I forget which thread I used 
this example in before, but to get an idea of what we mean by the term, I like 
to use it in some sentences.
My web servers are behind a load balancer, so they can better serve traffic to 
my customers.
I used to only have one MySQL server, but now I have three, so I put a load 
balancer in front of them to ensure they get an equal amount of traffic.
This isn't highly technical talk -- and it is definitely very generic -- but 
this is how REAL PEOPLE see the technology we're developing here. That is part 
of why the definitions we're using are so vague. I refuse to get tied down by 
an object graph full of pools and VIPs and listeners!
There are two very similar points I'd like to make here, and I feel that both 
are very important:
1. We shouldn't be looking at the current model and deciding which object is 
the root object, or what object to rename as a  loadbalancer... That's 
totally backwards! *We don't define which object is named the loadbalancer by 
looking for the root object -- we define which object is the root by looking 
for the object named loadbalancer.* I had hoped that was clear from the JSON 
examples in our API proposal, but I think maybe there was too much focus on the 
object model chart, where this isn't nearly as clearly communicated.
2. As I believe I have also said before, if I'm using X as a Service then I 
expect to get back an object of type X. I would be very frustrated/confused 
if, as a user, LBaaS returned me an object of type VIP when I POST a Create 
for my new load balancer. On this last point, I feel like I've said this enough 
times that I'm beating a dead horse...

Anyway, I should get at least a little bit of sleep tonight, so I'll see you 
all in IRC in a few hours!

  --Adam

PS: I really hope that colloquialism translates appropriately. I've got nothing 
against horses. :)

On May 7, 2014 7:44 PM, Stephen Balukoff sbaluk...@bluebox.net wrote:
Howdy y'all!

Per the e-mail I sent out earlier today, I wanted to share some thoughts on the 
API proposals from Rackspace and Blue Box that we're currently working on 
evaluating, presumably to decide which will be the version will be the 
starting point from which we make revisions going forward.  I'll try to be 
relatively brief.

First, some thanks!

The Rackspace team really pulled out the stops this last week producing an 
abundance of documentation that very thoroughly covers a bunch of the use cases 
available at that time in excruciating detail. They've produced a glossary and 
suggested object diagram, and their proposal is actually looking pretty dang 
good in my opinion.

I'm especially interested in hearing your opinion on the stuff I'm laying out 
below-- especially if I'm misunderstanding or mis-representing your viewpoint 
on any issue, eh!

Why the review process we're using probably won't be conclusive

So, at the last week's meeting we decided that the RAX team and I would work on 
producing a spreadsheet listing the use cases in question and go over how each 
of these would be accomplished using our API.

Having gone through this exercise, I see the following problems with this 
approach to evaluation:

  *   While we have thorough documentation, it's probably more than the average 
participant here is going to go through with a fine-toothed comb to find the 
subtle differences. Furthermore, there's already a huge amount of documentation 
produced, and we've only gone over about 1/5th of the use cases!
  *   Since the BBG version API proposal is actually a revision of the 
Rackspace proposal in many ways, at its core, our models are actually so 
similar that the subtle differences don't come out with general / generic use 
cases in many ways. And the only use cases we've evaluated so far are pretty 
general. :/
  *   In fact, the only significant ways in which the proposals differ are:
 *   BBG proposal uses VIP as single-call interface, and it's the root of 
the object tree from the user's perspective.
 *   Rackspace proposal uses loadbalancer as single-call interface, and 
it's the root of the object tree from the 

Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

[Adam Harwell]

I'd like to add that size of the organization (or really, size of the
development team) that is voting in this quiz does not directly correlate
to size of customer base. If there were any weighting happening, I'd hope
these answers would be weighted by size of user base, since really it is
the users' interests we are all trying to represent, not our own!

--Adam

On 5/6/14 2:16 PM, Jorge Miramontes jorge.miramon...@rackspace.com
wrote:

I agree that everyone's thoughts should be in it. I don't see why a
representative vote does not allow for that. Sam put a text box on each
use case to capture extra thoughts.

I would hope that no organization would be so confused as to have widely
varying viewpoints on *what their customers want*, since that is the
supposed purpose of all of this, right? We're supposed to be deciding
which use-cases matter *to our customers*, so there should be no real
variance for what I would vote versus what my teammates would vote, since
we have the same customersŠ


Also, if we are using this as a type of voting mechanism then interests of
large/vocal organizations drown out smaller organizations. If this is
being used as a voting mechanism then how do you suggest we weight votes
for smaller companies so that we do not alienate them from further
voting/discussions?

Cheers,
--Jorge




On 5/6/14 1:52 PM, Jay Pipes jaypi...@gmail.com wrote:

On 05/06/2014 02:42 PM, Jorge Miramontes wrote:
 Sam,

 I'm assuming you want one person from each company to answer correct?
 I'm pretty sure people in each organization will vote the sameŠat least
 I'd hope!

I'd hope not! :)

Even within the same organization or company, we all have different
ideas on use cases, the appropriateness of certain things in the
cloud, and the role of a load balancer service in the general mix of
things.

I certainly would hope that lots of Mirantis engineers other than myself
fill out the use case survey and offer their own insights.

Best,
-jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Fulfilling Operator Requirements: Driver / Management API

[Adam Harwell]

My comments in red (sorry again).

From: Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Friday, May 2, 2014 5:08 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] Fulfilling Operator Requirements: 
Driver / Management API

Hi Adam,

My comments inline:


On Fri, May 2, 2014 at 1:33 AM, Adam Harwell 
adam.harw...@rackspace.commailto:adam.harw...@rackspace.com wrote:
I am sending this now to gauge interest and get feedback on what I see as an 
impending necessity — updating the existing haproxy driver, replacing it, or 
both.
I agree with Stephen's first point here.
For HAProxy driver to support advanced use cases like routed mode, it's agent 
should be severely changed and receive some capabilities of L3 agent.
In fact, I'd suggest making additional driver, not for haproxy in VMs, but 
for... dedicated haproxy nodes.
Dedicated haproxy node is a host (similar to compute) with L2 agent and lbaas 
(not necessarily existing) agent on it.

In fact, it's essentially the same model as used right now, but i think it has 
it's advantages over haproxy-in-vm, at least:
- plugin driver doesn't need to manage VM life cycle (no orchestration)
- immediate natural multitenant support with isolated networks
- instead of adding haproxy in VM, you add a process (which is both faster and 
more efficient);
more scaling is achieved by adding physical haproxy node; existing agent health 
reporting will make it available for loadbalancer scheduling automatically.

I think that driver sounds like a good idea — I think we agree in essence, that 
there will need to be drivers to provide a variety of different approaches. I 
guess the question becomes, is there a smart way to accomplish this?

HAProxy: This references two things currently, and I feel this is a source of 
some misunderstanding. When I refer to  HAProxy (capitalized), I will be 
referring to the official software package (found here: http://haproxy.1wt.eu/ 
), and when I refer to haproxy (lowercase, and in quotes) I will be referring 
to the neutron-lbaas driver (found here: 
https://github.com/openstack/neutron/tree/master/neutron/services/loadbalancer/drivers/haproxy
 ). The fact that the neutron-lbaas driver is named directly after the software 
package seems very unfortunate, and while it is not directly in the scope of 
what I'd like to discuss here, I would love to see it changed to more 
accurately reflect what it is --  one specific driver implementation that 
coincidentally uses HAProxy as a backend. More on this later.
We also was referring existing driver as haproxy-on-host.
Ok, I will use that term from now on (I just hadn't seen it anywhere, and you 
can understand how it is confusing to just see haproxy as the driver name).


Operator Requirements: The requirements that can be found on the wiki page 
here:  
https://wiki.openstack.org/wiki/Neutron/LBaaS/requirements#Operator_Requirements
 and focusing on (but not limited to) the following list:
* Scalability
* DDoS Mitigation
* Diagnostics
* Logging and Alerting
* Recoverability
* High Availability (this is in the User Requirements section, but will be 
largely up to the operator to handle, so I would include it when discussing 
Operator Requirements)
Those requirements are of very different kinds and they are going to be 
addressed by quite different components of lbaas, not solely by the driver.

Management API: A restricted API containing resources that Cloud Operators 
could access, including most of the list of Operator Requirements (above).
The work is being done on this front: we're designing a way for plugin drivers 
to expose their own API, that specifically is needed for operator API which 
might not be common between providers.
Ok, this sounds like what some other people mentioned, and does sound like 
essentially what we'd need to do for this to work in any real capacity. The 
question I have then is, do we still need to talk about this at all, or just 
agree to make sure this method works, and then go our own ways implementing our 
Management APIs?


Load Balancer (LB): I use this term very generically — essentially a logical 
entity that represents one use case. As used in the sentence: I have a Load 
Balancer in front of my website. or The Load Balancer I set up to offload SSL 
Decryption is lowering my CPU load nicely.

--
 Overview
--
What we've all been discussing for the past month or two (the API, Object 
Model, etc) is being directly driven by the User and Operator Requirements that 
have somewhat recently been enumerated (many thanks to everyone who has 
contributed to that discussion!). With that in mind

Re: [openstack-dev] [Neutron][LBaaS] Use-Cases with VPNs Distinction

[Adam Harwell]

Sounds about right to me. I guess I agree with your agreement. :)
Does anyone actually oppose this arrangement?

--Adam

From: Stephen Balukoff sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Friday, May 2, 2014 7:53 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] Use-Cases with VPNs Distinction

Hi guys,

Yep, so what I'm hearing is that we should be able to assume that either all 
members in a single pool are adjacent (ie. layer-2 connected), or are routable 
from that subnet.

Adam-- I could see it going either way with regard to how to communicate with 
members:  If the particular device that the provider uses lives outside tenant 
private networks, the driver for said devices would need to make sure that VIFs 
(or some logical equivalent) are added such that the devices can talk to the 
members. This is also the case for virtual load balancers (or other devices) 
which are assigned to the tenant but live on an external network. (In this 
topology, VIP subnet and pool subnet could differ, and the driver needs to make 
sure that the load balancer has a virtual interface/neutron port + IP address 
on the pool subnet.)

There's also the option that if the device being used for load balancing 
exists as a virtual appliance that can be deployed on an internal network, one 
can make it publicly accessible by adding a neutron floating IP (ie. static 
NAT rule) that forwards any traffic destined for a public external IP to the 
load balancer's internal IP address.  (In this topology, VIP subnet and pool 
subnet would be the same thing.) The nifty thing about this topology is that 
load balancers that don't have this static NAT rule added are implicitly 
private to the tenant internal subnet.

Having seen what our customers do with their topologies, my gut reaction is to 
say that the 99.9% use case is that all the members of a pool will be in the 
same subnet, or routable from the pool subnet. And I agree that if someone has 
a really strange topology in use that doesn't work with this assumption, it's 
not the job of LBaaS to try and solve this for them.

Anyway, I'm hearing general agreement that subnet_id should be an attribute of 
the pool.


On Fri, May 2, 2014 at 5:24 AM, Eugene Nikanorov 
enikano...@mirantis.commailto:enikano...@mirantis.com wrote:
Agree with Sam here,
Moreover, i think it makes sense to leave subnet an attribute of the pool.
Which would mean that members reside in that subnet or are available (routable) 
from this subnet, and LB should have a port on this subnet.

Thanks,
Eugene.


On Fri, May 2, 2014 at 3:51 PM, Samuel Bercovici 
samu...@radware.commailto:samu...@radware.com wrote:
I think that associating a VIP subnet and list of member subnets is a good 
choice.
This is declaratively saying to where is the configuration expecting layer 2 
proximity.
The minimal would be the VIP subnet which in essence means the VIP and members 
are expected on the same subnet.

Any member outside the specified subnets is supposedly accessible via routing.

It might be an option to state the static route to use to access such member(s).
On many cases the needed static routes could also be computed automatically.

Regards,
   -Sam.

On 2 במאי 2014, at 03:50, Stephen Balukoff 
sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net wrote:

Hi Trevor,

I was the one who wrote that use case based on discussion that came out of the 
question I wrote the list last week about SSL re-encryption:  Someone had 
stated that sometimes pool members are local, and sometimes they are hosts 
across the internet, accessible either through the usual default route, or via 
a VPN tunnel.

The point of this use case is to make the distinction that if we associate a 
neutron_subnet with the pool (rather than with the member), then some members 
of the pool that don't exist in that neutron_subnet might not be accessible 
from that neutron_subnet.  However, if the behavior of the system is such that 
attempting to reach a host through the subnet's default route still works 
(whether that leads to communication over a VPN or the usual internet routes), 
then this might not be a problem.

The other option is to associate the neutron_subnet with a pool member. But in 
this case there might be problems too. Namely:

  *   The device or software that does the load balancing may need to have an 
interface on each of the member subnets, and presumably an IP address from 
which to originate requests.
  *   How does one resolve cases where subnets have overlapping IP ranges?

In the end, it may be simpler not to associate neutron_subnet with a pool at 
all. Maybe it only makes sense to do this for a VIP, and then the assumption 
would 

Re: [openstack-dev] [Neutron][LBaaS] Thoughts on current process

[Adam Harwell]

With regard to the last paragraph/sentence about a new driver, I am writing a 
lengthy analysis of that specific topic currently — hopefully we will be able 
to start an in-depth discussion on that later today.

--Adam

From: Jorge Miramontes 
jorge.miramon...@rackspace.commailto:jorge.miramon...@rackspace.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, May 1, 2014 1:46 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] Thoughts on current process

Hey Eugene,

I think there is a misunderstanding on what iterative development means to you 
and me and I want to make sure we are on the same page. First of all, I'll try 
not to use the term duct-taping even though it's a widely used term in the 
industry. My main concern is that implementing code on top of the current 
codebase to meet the smorgasbord of new requirements without thinking about 
overall design (since we know we will eventually want all the requirements 
satisfied at some point per your words) is that some requirement implemented 6 
months from now may change code architecture. Since we know we want to meet all 
requirements eventually, its makes logical sense to design for what we know we 
need and then figure out how to iteratively implement code over time. That 
being said, if it makes sense to use existing code first then fine. In fact, I 
am a fan of trying manipulate as little code as possible unless we absolutely 
have to. I just want to be a smart developer and design knowing I will 
eventually have to implement something. Not keeping things in mind can be 
dangerous. In short, I want to avoid having to perform multiple code refactors 
if possible and design upfront with the list of requirements the community has 
spent time fleshing out.

Also, it seems like you have some implicit developer requirements that I'd like 
written somewhere. This may ease confusion as well. For example, you stated 
Consistency is important. A clear definition in the form of a developer 
requirement would be nice so that the community understands your expectations.

Lastly, in relation to operator requirements I didn't see you comment on 
whether you are fan of working on an open-source driver together. Just so you 
know, operator requirements are very important for us and I honestly don't see 
how we can use any current driver without major modifications. This leads me to 
want to create a new driver with operator requirements being central to the 
design.

Cheers,
--Jorge

From: Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, May 1, 2014 8:12 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] Thoughts on current process

Hi Jorge,

A couple of inline comments:

Now that we have a set of requirements the next question to ask is, How
doe we prioritize requirements so that we can start designing and
implementing them?
Prioritization basically means that we want to support everything and only 
choose what is
more important right now and what is less important and can be implemented 
later.

Assuming requirements are prioritized (which as of today we have a pretty
good idea of these priorities) the next step is to design before laying
down any actual code.
That's true. I'd only would like to notice that there were actually a road map 
and requirements
with design before the code was written, that's both for the features that are 
already implemented,
and those which now are hanging in limbo.

I agree with Samuel that pushing the cart before the
horse is a bad idea in this case (and it usually is the case in software
development), especially since we have a pretty clear idea on what we need
to be designing for. I understand that the current code base has been
worked on by many individuals and the work done thus far is the reason why
so many new faces are getting involved. However, we now have a completely
updated set of requirements that the community has put together and trying
to fit the requirements to existing code may or may not work.

In my experience, I would argue that 99% of the time duct-taping existing code
I really don't like the term duct-taping here.
Here's the problem: you'll never will be able to implement everything at once, 
you have to do it incrementally.
That's how ecosystem works.
Each step can be then considered as 'duct-taping' because each state you're 
getting to
is not accounting for everything what was planned.
And for sure, there will be design mistakes that need 

[openstack-dev] [Neutron][LBaaS] Fulfilling Operator Requirements: Driver / Management API

[Adam Harwell]

 might decide to create more than one 
additional driver (depending on which approaches people want to use and what 
features are most important to them). The only concern I have about that 
outcome is the necessary amount of code-reuse, and whether it would be possible 
to share certain aspects of these drivers without too much copy/pasting.

An example of one possible new driver could be the following (just off the top 
of my head):
* Use a pair of new Nova VMs for each LB (Scalability), configured to use a 
Shared IP (High Availability).
* Log to Swift / Ceilometer (Logging / Alerting / Metering).
* Provide calls that could be exposed via a Management API to show low level 
diagnostic details (Diagnostics).
* Provide calls that could be exposed via a Management API to allow 
syncing/reloading existing LBs or moving them across clusters (Recoverability, 
DDoS Mitigation).
This new driver would be named to reflect what features it provides, or at 
least given a unique name that can be referenced without confusion (something 
like OpenHA or NovaHA would work if that's not taken).

--
 2) Management API
--
Going forward, it should then be required (can we enforce this?) that any 
mainline driver include support for calls to handle these named Operator 
Requirements, for example: obtaining logs (or log locations?), diagnostic 
information, and admin type actions including rebuilding or migrating LB 
instances. So far we haven't really talked about any of these features in 
depth, though I believe the general need for a Management API was alluded to on 
several occasions. Should we shelve this discussion until after we have the 
User API specification locked down? Should we begin defining a contract for 
this Management API at the summit, since it would be the main gateway to the 
Operator Requirements that we have all been stressing recently?

--
 Summary
--
I would apologize for not having much concrete specification here, but I think 
it is better to validate my basic assumptions first, before jumping deeper down 
this rabbit hole. The type of comments I'm hoping to prompt are along the lines 
of:
* We should just focus on the existing haproxy driver.
* We should definitely collaborate to make a new driver as a community.
* I don't think a Management API is necessary.
* This is definitely what I was thinking we'd need to do.
 Anything specific implementation details I've mentioned are intended be taken 
as one possible example, not as a well thought out proposal. I am, as one might 
say, speaking my mind. My hope is that some of this will simmer on the 
general subconscious. I'd like to hear what the general consensus is on these 
topics, because these are some of the assumptions I've been operating under 
during the rest of our discussions, and if they're invalid, I may need to 
rebase my view on the API discussion as a whole.

Thanks ya'll, I'm looking forward to getting some additional viewpoints!
--Adam Harwell (rm_work)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS]L7 conent switching APIs

[Adam Harwell]

My thoughts are inline (in red, since I can't figure out how to get Outlook to 
properly format the email the way I want).

From: Stephen Balukoff sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, May 1, 2014 6:52 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS]L7 conent switching APIs

Hi Samuel,

We talked a bit in chat about this, but I wanted to reiterate a few things here 
for the rest of the group.  Comments in-line:


On Wed, Apr 30, 2014 at 6:10 AM, Samuel Bercovici 
samu...@radware.commailto:samu...@radware.com wrote:
Hi,

We have compared the API the is in the blue print to the one described in 
Stephen documents.
Follows the differences we have found:

1)  L7PolicyVipAssoc is gone, this means that L7 policy reuse is not 
possible. I have added use cases 42 and 43 to show where such reuse makes sense.

Yep, my thoughts were that:

  *   The number of times L7 policies will actually get re-used is pretty 
minimal. And in the case of use cases 42 and 43, these can be accomplished by 
duplicating the L7policies and rules (with differing actions) for each type of 
connection.
  *   Fewer new objects is usually better and less confusing for the user. 
Having said this, a user advanced enough to use L7 features like this at all is 
likely going to be able to understand what the 'association' policy does.

The main counterpoint you shared with me was (if I remember correctly):

  *   For different load balancer vendors, it's much easier to code for the 
case where a specific entire feature set that isn't available (ie. L7 switching 
or content modification functionality) by making that entire feature set 
modular. A driver in this case can simply return with a feature not supported 
error if anyone tries using L7 policies at all.

 I agree that re-use should not be required for L7 policies, which should 
simplify things.

2)  There is a mix between L7 content switching and L7 content 
modification, the API in the blue print only addresses L7 content switching. I 
think that we should separate the APIs from each other. I think that we should 
review/add use cases targeting L7 content modifications to the use cases 
document.

Fair enough. There aren't many such use cases in there yet.

a.   You can see this in L7Policy: APPEND_HEADER, DELETE_HEADER 
actions

3)  The action to redirect to a URL is missing in Stephen’s document. The 
'redirect' action in Stephen’s document is equivalent to the “pool” action in 
the blue print/code.

Yep it is. But this is actually pretty easily added.  We would just add the 
'action' of URL_REDIRECT and the action_argument would then be the URL to 
which to redirect.


4)  All the objects have their parent id as an optional argument 
(L7Rule.l7_policy_id, L7Policy.listener_id), is this a mistake?

That's actually not a mistake--  a user can create orphaned rules in this 
model. However, the point was raised earlier by Brandon that it may make sense 
for members to be child objects of a specific pool since they can't be shared. 
If we do this for members, it also makes sense to do it for L7Rules since they 
also can't be shared. At which point the API for manipulating L7Rules would 
shift to:

/l7_policy/{policy_uuid}/l7_rules

And in this case, the parent L7Policy ID would be implicit.

(I'm all for this change, by the way.)

Sounds good to me too!

5)  There is also the additional behavior based on L3 information (matching 
the client/source IP to a subnet). This is addressed by L7Rule.type with a 
value of 'CLIENT_IP' and L7Rule.compare_type with a value of 'SUBNET'. I think 
that using Layer 3 type information should not be part of L7 content switching 
as the use cases I am aware of, might require more than just selecting a 
different pool (ex: user with ip from internet browsing to an https based 
application, might need to be secured using 2K SSL keys while internal users 
could use weaker keys)

While it's true that having a way to manipulate this without being part of an 
HTTP or unwrapped HTTPS session is also useful--  it's still useful to be able 
to create L7 rules which also make decisions based on subnet.  (Notice also 
with TLS_SNI_Policies there is a 'hostname' attribute, and also with L7 rules 
there is a 'hostname' type of rule? Again, useful to have in two places, eh!)

I would like to state that although the WIKI describes the solution from a high 
level it is not totally in sync with the actual code.
The key thing which is missing is that, L7 Policies in a specific listener/vip 
are ordered (ordered list) and are processed in order so that the 1st policy 
that has a match will be activated and traversal of the L7 policy 

Re: [openstack-dev] [Neutron][LBaaS] Use-Cases with VPNs Distinction

[Adam Harwell]

Comments in red. I'm tired, so hopefully most of what I say makes sense. :)

From: Stephen Balukoff sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, May 1, 2014 7:48 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] Use-Cases with VPNs Distinction

Hi Trevor,

I was the one who wrote that use case based on discussion that came out of the 
question I wrote the list last week about SSL re-encryption:  Someone had 
stated that sometimes pool members are local, and sometimes they are hosts 
across the internet, accessible either through the usual default route, or via 
a VPN tunnel.

The point of this use case is to make the distinction that if we associate a 
neutron_subnet with the pool (rather than with the member), then some members 
of the pool that don't exist in that neutron_subnet might not be accessible 
from that neutron_subnet.  However, if the behavior of the system is such that 
attempting to reach a host through the subnet's default route still works 
(whether that leads to communication over a VPN or the usual internet routes), 
then this might not be a problem.

Right, we list a subnet that theoretically most of the pool members use, but 
it's not STRICTLY enforced. As long as there is a route out from the host, they 
should work (and assuming your VIP is public, you will have a route to the 
internet, so any external member should be fine). Really, the subnet is just 
used as a hint for for assigning VIFs to whatever device is handling the load 
balancing (e.g., if the LB is HAProxy running on a Nova VM, we will know to 
create the VM with an IP on the VIP's subnet and an IP on the Pool's subnet).

The other option is to associate the neutron_subnet with a pool member. But in 
this case there might be problems too. Namely:

  *   The device or software that does the load balancing may need to have an 
interface on each of the member subnets, and presumably an IP address from 
which to originate requests.
  *   How does one resolve cases where subnets have overlapping IP ranges?

This would also work, and is more flexible, in the case that you wanted members 
that are on multiple private subnets. When deciding which VIFs to assign a 
machine, you'd just make a set of subnet_ids from all members, and assign one 
VIF for each. As for overlapping IP ranges, I honestly don't think this needs 
to be a use-case we should consider. If you're setting up your network topology 
using overlapping CIDRs, you deserve whatever messed up result you get. I don't 
think there's ANY way to handle that properly, just given how routing works on 
the machine…

In the end, it may be simpler not to associate neutron_subnet with a pool at 
all. Maybe it only makes sense to do this for a VIP, and then the assumption 
would be that any member addresses one adds to pools must be accessible from 
the VIP subnet.  (Which is easy, if the VIP exists on the same neutron_subnet. 
But this might require special routing within Neutron itself if it doesn't.)

I don't think it's safe to assume all members are accessible on the same subnet 
as the VIP, as I'd assume the most common use case would actually be a VIP on a 
public network and members on private networks. We will need the subnet_id 
somewhere.

This topology question (ie. what is feasible, what do people actually want to 
do, and what is supported by the model) is one of the more difficult ones to 
answer, especially given that users of OpenStack that I've come in contact with 
barely understand the Neutron networking model, if at all.

In our case, we don't actually have any users in the scenario of having members 
spread across different subnets that might not be be routable, so the use case 
is somewhat contrived, but I thought it was worth mentioning based on what 
people were saying in the SSL re-encryption discussion last week.

I believe one of the things we were really hoping to do is exactly that — allow 
member nodes to be on private networks so they are only accessible to the 
public via the public VIP. I'd recommend we maintain this case (at least, 
allowing ONE private subnet, so at a minimum attaching subnet_id to the pool).

--Adam


On Thu, May 1, 2014 at 1:52 PM, Trevor Vardeman 
trevor.varde...@rackspace.commailto:trevor.varde...@rackspace.com wrote:
Hello,

After going back through the use-cases to double check some of my
understanding, I realized I didn't quite understand the ones I had
already answered.  I'll use a specific use-case as an example of my
misunderstanding here, and hopefully the clarification can be easily
adapted to the rest of the use-cases that are similar.

Use Case 13:  A project-user has an HTTPS application in which some of
the 

[openstack-dev] Summit ticket needed, help?

[Adam Harwell]

Hello  everyone!
I was originally not going to be able to attend the summit next month, but 
things have changed and I would now like to attend. Unfortunately, tickets have 
become prohibitively expensive at this point. If any of you have or know anyone 
who has a ticket that they are not going to be able to use (for whatever 
reason), please let me know and we could discuss a transfer! I could afford to 
reimburse you for at least some of the ticket cost, if necessary. It looks like 
transfers are available until April 28, so please let me know, and don't let a 
ticket go to waste!

Thanks very much for your consideration,
--Adam Harwell (prospective Neutron-LBaaS contributor)

PS: I apologize if this is not the place for this, I am on IRC often but 
somewhat unused to Mailing List etiquette.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases and web ui screen captures

[Adam Harwell]

Most everything non-http(s) related can simply be load-balanced under the 
generic umbrella of UDP or TCP protocol. MySQL often gets it's own special 
protocol (Libra has MySQL/Galera), but of what you listed,  SSH is the only 
real special case I can think of, wherein something more specialized like 
Ballast* would be useful.

* http://code.nasa.gov/project/balancing-load-across-systems-ballast/

--Adam

From: Fox, Kevin M kevin@pnnl.govmailto:kevin@pnnl.gov
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, April 9, 2014 7:21 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, 
Eugene Nikanorov (enikano...@mirantis.commailto:enikano...@mirantis.com) 
enikano...@mirantis.commailto:enikano...@mirantis.com
Subject: Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases and web 
ui screen captures

I'm not seeing anything here about non http(s) related Load balancing.  We're 
interested in load balancing ssh, ftp, and other services too.

Thanks,
Kevin

From: Samuel Bercovici [samu...@radware.commailto:samu...@radware.com]
Sent: Sunday, April 06, 2014 5:51 AM
To: OpenStack Development Mailing List 
(openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org); 
Eugene Nikanorov (enikano...@mirantis.commailto:enikano...@mirantis.com)
Subject: [openstack-dev] [Neutron][LBaaS] Load balancing use cases and web ui 
screen captures

Per the last LBaaS meeting.


1.   Please find a list of use cases.
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?usp=sharing


a)  Please review and see if you have additional ones for the project-user

b)  We can then chose 2-3 use cases to play around with how the CLI, API, 
etc. would look


2.   Please find a document to place screen captures of web UI. I took the 
liberty to place a few links showing ELB.
https://docs.google.com/document/d/10EOCTej5CvDfnusv_es0kFzv5SIYLNl0uHerSq3pLQA/edit?usp=sharing


Regards,
-Sam.




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev