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 mai
Only really have comments on two of your related points:
[Susanne] To me Octavia is a driver so it is very hard to me to think of it as
a standalone project. It needs the new Neutron LBaaS v2 to function which is
why I think of them together. This of course can change since we can add
whatever
f 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 em
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
i
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 fl
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
mailto:jorge.miramon...@rackspace.com>>
Reply-To: "Open
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
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 mailto:sbaluk...@bluebox.net>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date
Comments in red. I'm tired, so hopefully most of what I say makes sense. :)
From: Stephen Balukoff mailto:sbaluk...@bluebox.net>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, May 1, 2014 7:48 PM
To: "OpenStack
Mailing List (not for usage questions)"
mailto: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
mailto:adam.harw...@ra
Sounds about right to me. I guess I agree with your agreement. :)
Does anyone actually oppose this arrangement?
--Adam
From: Stephen Balukoff mailto:sbaluk...@bluebox.net>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: F
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 user
Comments inline (and not in red this time!).
On 5/6/14 3:30 PM, "Jay Pipes" wrote:
>On 05/06/2014 03:16 PM, Jorge Miramontes 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 cap
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), s
When / where are we planning to meet up? If I recall from the last IRC meeting,
we were planning to get together at least unofficially to start discussing
stuff as soon as sometime Monday (today). Are the pods already open and
available, or is that not until later?
--Adam
__
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 provid
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 wrote:
I'm going to attend the next nw session @b103, we can meet in between. Im in
b103 too.
___
Ope
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 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
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 inte
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
mailto:adam.harw...@rackspace.com>> wrote:
So, it looks like any sort of validation on Delete
I guess the issue pops back into
the forefront. This is going to be an issue that everyone using ssl certs in
barbican is going to have, so it seems we’re applying a band-aid in the wrong
place.
Doug
From: Adam Harwell
mailto:adam.harw...@rackspace.com>>
Reply-To: "OpenStack Devel
arounds if we can’t trust the
store to store things are pretty hacky.
Doug
From: Adam Harwell
mailto:adam.harw...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, June
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 speciali
hanks 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
OpenStac
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, Septe
orward 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://ke
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
I can probably make it up there to attend.
--Adam
https://keybase.io/rm_you
From: Stephen Balukoff mailto:sbaluk...@bluebox.net>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, November 4, 2014 3:46 AM
To: "Ope
uld 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"
mailto:adam.harw...@rackspace.com>> wrote:
I can probably make it up there to attend.
--Adam
https://keybase.io/rm_you
From: Stephen Balukoff m
e questions)"
mailto:openstack-dev@lists.openstack.org>>
Cc: John Wood mailto:john.w...@rackspace.com>>, Adam
Harwell mailto:adam.harw...@rackspace.com>>
Subject: [barbican] Consumer Registration API
I was looking through some Keystone docs and noticed that for version 3.0
+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:
>
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 ac
+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 t
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 discove
ble 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
g 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: Op
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
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.
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 mailto:varun_lod...@symantec.c
il.com>>,
openstack-dev
mailto:openstack-dev@lists.openstack.org>>
Cc: "Reller, Nathan S."
mailto:nathan.rel...@jhuapl.edu>>, Douglas Mendizabal
mailto:douglas.mendiza...@rackspace.com>>,
"a...@redhat.com<mailto:a...@redhat.com>"
mailto:a...@redhat.com>
;>
Date: Thursday, April 23, 2015 at 10:07 AM
To: Asha Seshagiri mailto:asha.seshag...@gmail.com>>
Cc: John Wood mailto:john.w...@rackspace.com>>,
openstack-dev
mailto:openstack-dev@lists.openstack.org>>,
"Reller, Nathan S."
mailto:nathan.rel...@jhuapl.edu>>, Dougl
+1
--Adam
https://keybase.io/rm_you
From: Doug Wiegley
mailto:doug...@parksidesoftware.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, May 1, 2015 at 11:19 AM
To: "OpenStack Development Mailing List (not f
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 co
ou 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 Percoc
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
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
de
+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,
> >
> >
+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:
>
> Hel
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 wa
imple) otherwise (though I am fully behind just using Barbican).
--Adam Harwell (LBaaS/Octavia)
On Mon, Jan 16, 2017, 11:57 Adrian Otto wrote:
>
> > On Jan 16, 2017, at 11:02 AM, Dave McCowan (dmccowan) <
> dmcco...@cisco.com> wrote:
> >
> > On 1/16/
pen years ago, but that's a much longer story).
--Adam Harwell
On Mon, Jan 16, 2017, 14:36 Duncan Thomas 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
>
+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
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 (w
t; for cert_manager and call them in neutron_lbaas as well.
>
>
> On Wed, Jan 25, 2017 at 10:48 Adam Harwell 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
&g
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
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
majorit
ks 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 wit
+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
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.
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
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 n
+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,
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
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 wrote:
> On Oct 17, 2016 7:27 PM, "Thomas Goirand" wrote:
> >
> > On 10/17/2016 08:43 PM, Adam Harwell wrote:
> >
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
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
Inline comments.
On Wed, Oct 19, 2016 at 1:38 AM Thomas Goirand wrote:
> On 10/18/2016 02:37 AM, Ian Cordasco wrote:
> > On Oct 17, 2016 7:27 PM, "Thomas Goirand" > <mailto:z...@debian.org>> wrote:
> >>
> >> On 10/17/2016 08:43 PM, Adam Harw
05 AM Adam Harwell wrote:
> Inline comments.
>
> On Wed, Oct 19, 2016 at 1:38 AM Thomas Goirand wrote:
>
> On 10/18/2016 02:37 AM, Ian Cordasco wrote:
> > On Oct 17, 2016 7:27 PM, "Thomas Goirand" > <mailto:z...@debian.org>> wrote:
> >>
> >
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 th
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 proble
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,
To reply more directly and clearly:
On Wed, Oct 19, 2016 at 9:30 PM Tony Breeds 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 de
rch.openstack.org/?q=platform&i=nope&files=bindep.txt&repos=
>
> Thanks,
> Dims
>
> On Wed, Oct 19, 2016 at 9:40 AM, Adam Harwell wrote:
> > Yes, but we need to use SOMETHING for our own devstack gate tests --
> maybe
> > it is easier to think of our devstack
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 wrote:
> We
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 la
75 matches
Mail list logo
