Re: [openstack-dev] [Tatu][Nova] Handling instance destruction

[Pino de Candia]

Hi Michael,

Thanks for your message... and thanks for your vendordata work!

About your question, Tatu listens to events on the oslo message bus.
Specifically, it reacts to compute.instance.delete.end by cleaning up
per-instance resources. It also listens to project creation and user role
assignment changes. The code is at:
https://github.com/openstack/tatu/blob/master/tatu/notifications.py

best,
Pino


On Thu, Mar 15, 2018 at 3:42 PM, Michael Still  wrote:

> Heya,
>
> I've just stumbled across Tatu and the design presentation [1], and I am
> wondering how you handle cleaning up instances when they are deleted given
> that nova vendordata doesn't expose a "delete event".
>
> Specifically I'm wondering if we should add support for such an event to
> vendordata somehow, given I can now think of a couple of use cases for it.
>
> Thanks,
> Michael
>
> 1: https://docs.google.com/presentation/d/1HI5RR3SNUu1If-
> A5Zi4EMvjl-3TKsBW20xEUyYHapfM/edit#slide=id.p
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tatu] Tatu devstack plugin ready

[Pino de Candia]

Hi Folks,

Tatu's devstack plugin is finally working (but I've only tested it on
Ubuntu 16 with Fedora25 VM image).

Try it out with this local.conf:
https://github.com/openstack/tatu/blob/master/devstack/local.conf

And then follow these (minimal) steps to set up your client's ssh
certificate and known_hosts file:
https://github.com/openstack/tatu/blob/master/TRY_IT.rst


I've also:
- updated the top-level README.rst to provide a lot more details about
what's happening under the hood
- added a top-level INSTALLATION.rst that explains how to do a manual
install.

cheers,
Pino
__
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] [docs] Permissions to upload a PNG for my new project page

[Pino de Candia]

Hi Jeremy, that worked (succeeded in uploading and no more capthca). Thanks!

On Tue, Mar 6, 2018 at 8:21 AM, Jeremy Stanley <fu...@yuggoth.org> wrote:

> On 2018-03-05 10:35:00 -0600 (-0600), Pino de Candia wrote:
> [...]
> > But when I try to upload the file I get this error:
> >
> > "You do not have permission to upload this file, for the following
> > reason:
> >
> > The action you have requested is limited to users in one of the
> > groups: Administrators, Autopatrolled users."
> [...]
>
> I have a feeling PTG attendance and associated travel challenges
> have delayed the rate at which the volunteers patrolling recent
> edits in the wiki are verifying validity of edits made by new users.
> As such, your account wasn't marked as verified by anyone until I
> did so just now. Please try again.
>
> Unfortunately we've found that without careful control over
> operations like file uploading or page renames we quickly get
> overrun with spam, so we limit that exposure by vetting accounts
> first. You'll also hopefully find that you no longer get presented
> with a captcha challenge when making page edits now that you're
> verified.
> --
> 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

[openstack-dev] [docs] Permissions to upload a PNG for my new project page

[Pino de Candia]

Hi Folks,

I'm creating a project page for Tatu (SSH as a Service).

I created a link to a logo in my page source like this:
[[File:Project_Tatu_Logo.png|right]]


But when I try to upload the file I get this error:


"You do not have permission to upload this file, for the following reason:

The action you have requested is limited to users in one of the groups:
Administrators

, Autopatrolled users 
."


Any guidance/help is much appreciated!

Pino
__
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] [security] Security PTG Planning, x-project request for topics.

[Pino de Candia]

Hi Luke,

Yes, please - that would be great!

best,
Pino



On Wed, Feb 28, 2018 at 3:25 AM, Luke Hinds <lhi...@redhat.com> wrote:

> Hi Pino,
>
> Thank you for your time demonstrating Tatu.
>
> If you like we could incubate Tatu into the security SIG. This would mean
> no change to project structure / governance etc, its more the project gains
> a regular slot on our weekly meetings to help get patches reviewed and
> encourage other contributors / feedback etc. We did this with projects such
> as Bandit before, until it found its own legs and momentum.
>
> Cheers,
>
> Luke
>
>
> On Mon, Feb 12, 2018 at 8:45 AM, Luke Hinds <lhi...@redhat.com> wrote:
>
>>
>>
>> On Sun, Feb 11, 2018 at 4:01 PM, Pino de Candia <
>> giuseppe.decan...@gmail.com> wrote:
>>
>>> I uploaded the demo video (https://youtu.be/y6ICCPO08d8) and linked it
>>> from the slides.
>>>
>>
>> Thanks Pino , i added these to the agenda:
>>
>> https://etherpad.openstack.org/p/security-ptg-rocky
>>
>> Please let me know before the PTG, if it will be your colleague or if we
>> need to find a projector to conference you in.
>>
>>
>>> On Fri, Feb 9, 2018 at 5:51 PM, Pino de Candia <
>>> giuseppe.decan...@gmail.com> wrote:
>>>
>>>> Hi Folks,
>>>>
>>>> here are the slides for the Tatu presentation: https://docs.goo
>>>> gle.com/presentation/d/1HI5RR3SNUu1If-A5Zi4EMvjl-3TKsBW20xEUyYHapfM
>>>>
>>>> I meant to record the demo video as well but I haven't gotten around to
>>>> editing all the bits. Please stay tuned.
>>>>
>>>> thanks,
>>>> Pino
>>>>
>>>>
>>>> On Tue, Feb 6, 2018 at 10:52 AM, Giuseppe de Candia <
>>>> giuseppe.decan...@gmail.com> wrote:
>>>>
>>>>> Hi Luke,
>>>>>
>>>>> Fantastic! An hour would be great if the schedule allows - there are
>>>>> lots of different aspects we can dive into and potential future directions
>>>>> the project can take.
>>>>>
>>>>> thanks!
>>>>> Pino
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Feb 6, 2018 at 10:36 AM, Luke Hinds <lhi...@redhat.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Feb 6, 2018 at 4:21 PM, Giuseppe de Candia <
>>>>>> giuseppe.decan...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Folks,
>>>>>>>
>>>>>>> I know the request is very late, but I wasn't aware of this SIG
>>>>>>> until recently. Would it be possible to present a new project to the
>>>>>>> Security SIG at the PTG? I need about 30 minutes. I'm hoping to drum up
>>>>>>> interest in the project, sign on users and contributors and get 
>>>>>>> feedback.
>>>>>>>
>>>>>>> For the past few months I have been working on a new project - Tatu
>>>>>>> [1]- to automate the management of SSH certificates (for both users and
>>>>>>> hosts) in OpenStack. Tatu allows users to generate SSH certificates with
>>>>>>> principals based on their Project role assignments, and VMs 
>>>>>>> automatically
>>>>>>> set up their SSH host certificate (and related config) via Nova vendor
>>>>>>> data. The project also manages bastions and DNS entries so that users 
>>>>>>> don't
>>>>>>> have to assign Floating IPs for SSH nor remember IP addresses.
>>>>>>>
>>>>>>> I have a working demo (including Horizon panels [2] and OpenStack
>>>>>>> CLI [3]), but am still working on the devstack script and patches [4] to
>>>>>>> get Tatu's repositories into OpenStack's GitHub and Gerrit. I'll try to
>>>>>>> post a demo video in the next few days.
>>>>>>>
>>>>>>> best regards,
>>>>>>> Pino
>>>>>>>
>>>>>>>
>>>>>>> References:
>>>>>>>
>>>>>>>1. https://github.com/pinodeca/tatu (Please note this is still
>>>>>>>very much a work in progress, lots of TODOs in the code, very little
>>>>>>>testing and documentation doesn't reflect the latest design).
&

[openstack-dev] [tatu] Integration with Uber's pam-ussh module (and Stripe's KRL)

[Pino de Candia]

Hi Folks,


I integrated Uber's pam-ussh module in Tatu.


With this, if the user's SSH certificate is revoked while they're logged
into the VM, they lose sudo access (btw, I don't know how to close their
session, which would be even better).


Here's the demo video:

https://youtu.be/yjwWdYJRTM0


Here's my pull request to add KRL support (from
https://github.com/stripe/krl) to pam-ussh:
https://github.com/uber/pam-ussh/pull/10


And here's the Tatu code-review: https://review.openstack.org/#/c/549389/


cheers,

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

[openstack-dev] [infra] Please delete branch "notif" of project tatu

[Pino de Candia]

Hi OpenStack-Infra Team,

Please delete branch "notif" of openstack/tatu.

The project was recently created/imported from my private repo and only the
master branch is needed for the community project.


thanks for your help!
Pino
__
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] [security] Security PTG Planning, x-project request for topics.

[Pino de Candia]

Hi Luke,

Omer (in CC) has confirmed that he can stand in for me if needed, but my
preference would be that you conference me in. If you won't know until the
very day whether conference equipment is available, that's fine, we can
figure it out last minute.

A projector will be useful either way.

thanks!
Pino




On Mon, Feb 12, 2018 at 2:45 AM, Luke Hinds <lhi...@redhat.com> wrote:

>
>
> On Sun, Feb 11, 2018 at 4:01 PM, Pino de Candia <
> giuseppe.decan...@gmail.com> wrote:
>
>> I uploaded the demo video (https://youtu.be/y6ICCPO08d8) and linked it
>> from the slides.
>>
>
> Thanks Pino , i added these to the agenda:
>
> https://etherpad.openstack.org/p/security-ptg-rocky
>
> Please let me know before the PTG, if it will be your colleague or if we
> need to find a projector to conference you in.
>
>
>> On Fri, Feb 9, 2018 at 5:51 PM, Pino de Candia <
>> giuseppe.decan...@gmail.com> wrote:
>>
>>> Hi Folks,
>>>
>>> here are the slides for the Tatu presentation: https://docs.goo
>>> gle.com/presentation/d/1HI5RR3SNUu1If-A5Zi4EMvjl-3TKsBW20xEUyYHapfM
>>>
>>> I meant to record the demo video as well but I haven't gotten around to
>>> editing all the bits. Please stay tuned.
>>>
>>> thanks,
>>> Pino
>>>
>>>
>>> On Tue, Feb 6, 2018 at 10:52 AM, Giuseppe de Candia <
>>> giuseppe.decan...@gmail.com> wrote:
>>>
>>>> Hi Luke,
>>>>
>>>> Fantastic! An hour would be great if the schedule allows - there are
>>>> lots of different aspects we can dive into and potential future directions
>>>> the project can take.
>>>>
>>>> thanks!
>>>> Pino
>>>>
>>>>
>>>>
>>>> On Tue, Feb 6, 2018 at 10:36 AM, Luke Hinds <lhi...@redhat.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Feb 6, 2018 at 4:21 PM, Giuseppe de Candia <
>>>>> giuseppe.decan...@gmail.com> wrote:
>>>>>
>>>>>> Hi Folks,
>>>>>>
>>>>>> I know the request is very late, but I wasn't aware of this SIG until
>>>>>> recently. Would it be possible to present a new project to the Security 
>>>>>> SIG
>>>>>> at the PTG? I need about 30 minutes. I'm hoping to drum up interest in 
>>>>>> the
>>>>>> project, sign on users and contributors and get feedback.
>>>>>>
>>>>>> For the past few months I have been working on a new project - Tatu
>>>>>> [1]- to automate the management of SSH certificates (for both users and
>>>>>> hosts) in OpenStack. Tatu allows users to generate SSH certificates with
>>>>>> principals based on their Project role assignments, and VMs automatically
>>>>>> set up their SSH host certificate (and related config) via Nova vendor
>>>>>> data. The project also manages bastions and DNS entries so that users 
>>>>>> don't
>>>>>> have to assign Floating IPs for SSH nor remember IP addresses.
>>>>>>
>>>>>> I have a working demo (including Horizon panels [2] and OpenStack CLI
>>>>>> [3]), but am still working on the devstack script and patches [4] to get
>>>>>> Tatu's repositories into OpenStack's GitHub and Gerrit. I'll try to post 
>>>>>> a
>>>>>> demo video in the next few days.
>>>>>>
>>>>>> best regards,
>>>>>> Pino
>>>>>>
>>>>>>
>>>>>> References:
>>>>>>
>>>>>>1. https://github.com/pinodeca/tatu (Please note this is still
>>>>>>very much a work in progress, lots of TODOs in the code, very little
>>>>>>testing and documentation doesn't reflect the latest design).
>>>>>>2. https://github.com/pinodeca/tatu-dashboard
>>>>>>3. https://github.com/pinodeca/python-tatuclient
>>>>>>4. https://review.openstack.org/#/q/tatu
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Hi Giuseppe, of course you can! I will add you to the agenda. We could
>>>>> get your an hour if it allows more time for presenting and post 
>>>>> discussion?
>>>>>
>>>>> We will be meeting in an allocated room on Mon

Re: [openstack-dev] [infra] Please add me to Tatu's Gerrit groups

[Pino de Candia]

Thanks!

On Fri, Feb 9, 2018 at 1:21 PM, Jeremy Stanley <fu...@yuggoth.org> wrote:

> On 2018-02-09 10:00:25 -0600 (-0600), Pino de Candia wrote:
> > I'd like to be added to the recently created tatu-core and
> > tatu-release Gerrit groups.
>
> Since your Gerrit account is the one which proposed the change to
> add the project whose ACLs use those groups, I have added you as the
> initial member in both of them.
> --
> 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] [security] Security PTG Planning, x-project request for topics.

[Pino de Candia]

I uploaded the demo video (https://youtu.be/y6ICCPO08d8) and linked it from
the slides.

On Fri, Feb 9, 2018 at 5:51 PM, Pino de Candia <giuseppe.decan...@gmail.com>
wrote:

> Hi Folks,
>
> here are the slides for the Tatu presentation: https://docs.
> google.com/presentation/d/1HI5RR3SNUu1If-A5Zi4EMvjl-3TKsBW20xEUyYHapfM
>
> I meant to record the demo video as well but I haven't gotten around to
> editing all the bits. Please stay tuned.
>
> thanks,
> Pino
>
>
> On Tue, Feb 6, 2018 at 10:52 AM, Giuseppe de Candia <
> giuseppe.decan...@gmail.com> wrote:
>
>> Hi Luke,
>>
>> Fantastic! An hour would be great if the schedule allows - there are lots
>> of different aspects we can dive into and potential future directions the
>> project can take.
>>
>> thanks!
>> Pino
>>
>>
>>
>> On Tue, Feb 6, 2018 at 10:36 AM, Luke Hinds <lhi...@redhat.com> wrote:
>>
>>>
>>>
>>> On Tue, Feb 6, 2018 at 4:21 PM, Giuseppe de Candia <
>>> giuseppe.decan...@gmail.com> wrote:
>>>
>>>> Hi Folks,
>>>>
>>>> I know the request is very late, but I wasn't aware of this SIG until
>>>> recently. Would it be possible to present a new project to the Security SIG
>>>> at the PTG? I need about 30 minutes. I'm hoping to drum up interest in the
>>>> project, sign on users and contributors and get feedback.
>>>>
>>>> For the past few months I have been working on a new project - Tatu
>>>> [1]- to automate the management of SSH certificates (for both users and
>>>> hosts) in OpenStack. Tatu allows users to generate SSH certificates with
>>>> principals based on their Project role assignments, and VMs automatically
>>>> set up their SSH host certificate (and related config) via Nova vendor
>>>> data. The project also manages bastions and DNS entries so that users don't
>>>> have to assign Floating IPs for SSH nor remember IP addresses.
>>>>
>>>> I have a working demo (including Horizon panels [2] and OpenStack CLI
>>>> [3]), but am still working on the devstack script and patches [4] to get
>>>> Tatu's repositories into OpenStack's GitHub and Gerrit. I'll try to post a
>>>> demo video in the next few days.
>>>>
>>>> best regards,
>>>> Pino
>>>>
>>>>
>>>> References:
>>>>
>>>>1. https://github.com/pinodeca/tatu (Please note this is still very
>>>>much a work in progress, lots of TODOs in the code, very little testing 
>>>> and
>>>>documentation doesn't reflect the latest design).
>>>>2. https://github.com/pinodeca/tatu-dashboard
>>>>3. https://github.com/pinodeca/python-tatuclient
>>>>4. https://review.openstack.org/#/q/tatu
>>>>
>>>>
>>>>
>>>>
>>> Hi Giuseppe, of course you can! I will add you to the agenda. We could
>>> get your an hour if it allows more time for presenting and post discussion?
>>>
>>> We will be meeting in an allocated room on Monday (details to follow).
>>>
>>> https://etherpad.openstack.org/p/security-ptg-rocky
>>>
>>> Luke
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>> On Wed, Jan 31, 2018 at 12:03 PM, Luke Hinds <lhi...@redhat.com> wrote:
>>>>
>>>>>
>>>>> On Mon, Jan 29, 2018 at 2:29 PM, Adam Young <ayo...@redhat.com> wrote:
>>>>>
>>>>>> Bug 968696 and System Roles.   Needs to be addressed across the
>>>>>> Service catalog.
>>>>>>
>>>>>
>>>>> Thanks Adam, will add it to the list. I see it's been open since 2012!
>>>>>
>>>>>
>>>>>>
>>>>>> On Mon, Jan 29, 2018 at 7:38 AM, Luke Hinds <lhi...@redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Just a reminder as we have not had many uptakes yet..
>>>>>>>
>>>>>>> Are there any projects (new and old) that would like to make use of
>>>>>>> the security SIG for either gaining another perspective on security
>>>>>>> challenges / blueprints etc or for help gaining some cross project
>>>>>>> collaboration?
>>>>>>>
>>>>>>&g

Re: [openstack-dev] [security] Security PTG Planning, x-project request for topics.

[Pino de Candia]

Hi Folks,

here are the slides for the Tatu presentation:
https://docs.google.com/presentation/d/1HI5RR3SNUu1If-A5Zi4EMvjl-3TKsBW20xEUyYHapfM

I meant to record the demo video as well but I haven't gotten around to
editing all the bits. Please stay tuned.

thanks,
Pino


On Tue, Feb 6, 2018 at 10:52 AM, Giuseppe de Candia <
giuseppe.decan...@gmail.com> wrote:

> Hi Luke,
>
> Fantastic! An hour would be great if the schedule allows - there are lots
> of different aspects we can dive into and potential future directions the
> project can take.
>
> thanks!
> Pino
>
>
>
> On Tue, Feb 6, 2018 at 10:36 AM, Luke Hinds  wrote:
>
>>
>>
>> On Tue, Feb 6, 2018 at 4:21 PM, Giuseppe de Candia <
>> giuseppe.decan...@gmail.com> wrote:
>>
>>> Hi Folks,
>>>
>>> I know the request is very late, but I wasn't aware of this SIG until
>>> recently. Would it be possible to present a new project to the Security SIG
>>> at the PTG? I need about 30 minutes. I'm hoping to drum up interest in the
>>> project, sign on users and contributors and get feedback.
>>>
>>> For the past few months I have been working on a new project - Tatu [1]-
>>> to automate the management of SSH certificates (for both users and hosts)
>>> in OpenStack. Tatu allows users to generate SSH certificates with
>>> principals based on their Project role assignments, and VMs automatically
>>> set up their SSH host certificate (and related config) via Nova vendor
>>> data. The project also manages bastions and DNS entries so that users don't
>>> have to assign Floating IPs for SSH nor remember IP addresses.
>>>
>>> I have a working demo (including Horizon panels [2] and OpenStack CLI
>>> [3]), but am still working on the devstack script and patches [4] to get
>>> Tatu's repositories into OpenStack's GitHub and Gerrit. I'll try to post a
>>> demo video in the next few days.
>>>
>>> best regards,
>>> Pino
>>>
>>>
>>> References:
>>>
>>>1. https://github.com/pinodeca/tatu (Please note this is still very
>>>much a work in progress, lots of TODOs in the code, very little testing 
>>> and
>>>documentation doesn't reflect the latest design).
>>>2. https://github.com/pinodeca/tatu-dashboard
>>>3. https://github.com/pinodeca/python-tatuclient
>>>4. https://review.openstack.org/#/q/tatu
>>>
>>>
>>>
>>>
>> Hi Giuseppe, of course you can! I will add you to the agenda. We could
>> get your an hour if it allows more time for presenting and post discussion?
>>
>> We will be meeting in an allocated room on Monday (details to follow).
>>
>> https://etherpad.openstack.org/p/security-ptg-rocky
>>
>> Luke
>>
>>
>>
>>
>>>
>>>
>>> On Wed, Jan 31, 2018 at 12:03 PM, Luke Hinds  wrote:
>>>

 On Mon, Jan 29, 2018 at 2:29 PM, Adam Young  wrote:

> Bug 968696 and System Roles.   Needs to be addressed across the
> Service catalog.
>

 Thanks Adam, will add it to the list. I see it's been open since 2012!


>
> On Mon, Jan 29, 2018 at 7:38 AM, Luke Hinds  wrote:
>
>> Just a reminder as we have not had many uptakes yet..
>>
>> Are there any projects (new and old) that would like to make use of
>> the security SIG for either gaining another perspective on security
>> challenges / blueprints etc or for help gaining some cross project
>> collaboration?
>>
>> On Thu, Jan 11, 2018 at 3:33 PM, Luke Hinds 
>> wrote:
>>
>>> Hello All,
>>>
>>> I am seeking topics for the PTG from all projects, as this will be
>>> where we try out are new form of being a SIG.
>>>
>>> For this PTG, we hope to facilitate more cross project collaboration
>>> topics now that we are a SIG, so if your project has a security need /
>>> problem / proposal than please do use the security SIG room where a 
>>> larger
>>> audience may be present to help solve problems and gain x-project 
>>> consensus.
>>>
>>> Please see our PTG planning pad [0] where I encourage you to add to
>>> the topics.
>>>
>>> [0] https://etherpad.openstack.org/p/security-ptg-rocky
>>>
>>> --
>>> Luke Hinds
>>> Security Project PTL
>>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.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.op
> enstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


 --
 Luke Hinds | NFV Partner Engineering | CTO 

[openstack-dev] [infra] Please add me to Tatu's Gerrit groups

[Pino de Candia]

Hi Infra Team,

I'd like to be added to the recently created tatu-core and tatu-release
Gerrit groups.

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

[openstack-dev] [midonet] NAT64 support

[Giuseppe (Pino) de Candia]

Hi Devs,

MidoNet does not support IPv6 (in overlay or underlay). As a small and
practical first step towards supporting IPv6, I'm proposing support for
NAT64.

The idea is that a Tenant can configure NAT64 for any Floating IPv4. The
Operator should have control over the IPv6 prefix (well-known prefix or
network-specific prefix) used to embed the IPv4 addresses. And finally, the
prefix (and the resulting IPv6) should be known to the Tenant so that it
can:
- directly provide this address to IPv6 tenants
- configure DNS64 (outside MidoNet)

I've written some initial ideas in this Google Doc
.
Feel free to comment in the doc or to ask questions on this thread.

thanks,
Pino
__
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][networking-sfc] API clarification questions

[Giuseppe (Pino) de Candia]

On Mon, Nov 2, 2015 at 9:56 PM, Cathy Zhang <cathy.h.zh...@huawei.com>
wrote:

>
>
>
>
> *From:* Giuseppe (Pino) de Candia [mailto:gdecan...@midokura.com]
> *Sent:* Saturday, October 31, 2015 10:08 PM
> *To:* Cathy Zhang
> *Cc:* Henry Fourie; OpenStack Development Mailing List (not for usage
> questions); Irena Berezovsky
> *Subject:* RE: [openstack-dev] [neutron][networking-sfc] API
> clarification questions
>
> >
> > Cathy> No restriction as long as the ports are routable. Originally we
> think we need to specify L2 and L3 service type. But later we found out it
> is not needed if we program the switch to set the next hop destination to
> the service function’s MAC. This way no matter whether it is L2 or L3, it
> always works.
> >
>
> Hi Cathy, my understanding is that:
> -for an L2 service, don't modify the packet (ignoring possible
> encapsulation to signal policy )
> -for an L3 service, set the dst MAC in the packet equal to the the service
> port's MAC
>
> How can the SDN implementation know which kind of service it's dealing
> with to decide whether to modify the MAC?
>
> Cathy> You can always modify the MAC which will work for both L2 and L3
> service.
>
I don't think that works. For L3 services, the packet's destination MAC
must be set equal to the service port's MAC. That means that all the
original destination MACs get re-written to a single MAC.

In my L2 use-case, the VLAN is being used for signaling, and the VNF
instance is shared across multiple tenants with overlapping IPs. Therefore,
I use the MAC to identify the service chain instance and get a packet back
on its original network path.

So, I won't modify the packet at all. Can you suggest another solution? And
why so much resistance to adding a flag when we can actually show
use-cases? Note that this is already actually running code today, using
MidoNet's service chaining API.

thanks,
Pino


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

Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

[Giuseppe (Pino) de Candia]

On Oct 28, 2015 19:17, "Russell Bryant" <rbry...@redhat.com> wrote:
>
> On 10/28/2015 05:14 PM, Giuseppe (Pino) de Candia wrote:
> > On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant <rbry...@redhat.com
> > <mailto:rbry...@redhat.com>> wrote:
> >
> > I read through the proposed SFC API here:
> >
> > http://docs.openstack.org/developer/networking-sfc/api.html
> >
> > I'm looking at implementing what would be required to support this
API
> > in OVN.  I have a prototype, but I had to make some pretty big
> > assumptions, so I wanted to clarify the intent of the API.
> >
> > First, does it assume that all of the neutron ports in a chain are
on
> > the same Neutron network?  That keeps things simple.  If its
intended to
> > allow a chain of ports on different networks, is it just required
that
> > you pick ports that all have addresses routable from one port to the
> > next in the chain?  An arbitrary set of ports can't always work, so
> > there has to be some bounds around what set of ports are valid to
be in
> > a chain.
> >
> >
> > Hi Russell,
> >
> > We have similarly been experimenting with a MidoNet implementation of
> > the SFC API.
>
> Great!  It's nice to have multiple people looking at this with different
> implementations in mind.  That should help us shake out these sorts of
> issues before the API is too locked down.  Thanks for jumping in.  :-)
>
> > I hope there's no restriction on the location of the Neutron ports in a
> > chain.
>
> Yes, that makes sense.  Cathy's response seems to support that there
> isn't a limitation.  We do need to clearly define it in the API
> reference though.  Maybe something like ...
>
>   All ports must:
>   * be owned by the tenant.
>   * have IP addresses such that the address of port N+1 in the chain
> is routable from port N in the chain.

I guess you're just brainstorming... But I hope we don't adopt the second
restriction.

>
> > In terms of addresses, I believe the API is lacking (or we use a
> > chain_parameter?) a way to indicate the service insertion model:
> > - L2 - The service can accept packets sent from any MAC (service NIC in
> > promiscuous mode). The MAC address may be used to identify where the
> > packet came from before it entered the chain.
>
> If the ports in the chain don't have to all be on the same L2 network,
> then it doesn't seem like you could use the source MAC address to know
> where the packet came from before it entered the chain.
>
> > - L3 -  The service expects packets to be routed to it. So the
> > destination MAC of the packet must be set to the service's NIC's MAC.
>
> This seems to make more sense to me.  You've got the "coorelation chain
> parameter" to know what chain the packet is in, and you use the source
> IP address to know where the packet came from originally before it
> entered the chain.
>
> >
> >
> >
> > Second, where is it expected that the match is applied?  The API for
> > creating a port chain doesn't associate the chain with a network,
but
> > just matching "globally" doesn't make any sense.  If all ports are
> > expected to be on the same network, is the match applied for any
traffic
> > entering that network from any port?
> >
> >
> > Here's what we were thinking for MidoNet:
> >
> > use the logical_source_port in the flow classifier: when we render the
> > SFC API in MidoNet's models we will associate the chain with the source
> > port.
> >
> > Our packet pipeline (for packets egressing the VM) is:
> >
> >  1. Port Mirroring
> >  2. Service Chaining
> >  3. Filtering (Port Security, anti-spoofing, Security Groups)
>
> OK, so it sounds like you're applying the "flow classifier" to packets
> as the come from a neutron port and enter a neutron network.  That makes
> sense.
>
> Which ports' traffic do you apply the flow classifier to?  That's the
> key piece I'm missing.
>
> If the flow classifier includes a logical-source-port match, then it's
> easy.  You only check traffic from a specific Neutron port.  The same
> seems to apply if you only specified a logical-destination port, since
> in that case you'd be matching on traffic ingressing the VM.
>
> If tenant A creates the port chain and both logical-source-port and
> logical-destination-port are not specified, then what packets do you
> apply the flow classifier to?
>
> >
> >
> > Do you think we can standardise on a single order in all
> > impleme

Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

[Giuseppe (Pino) de Candia]

On Oct 29, 2015 08:37, "Cathy Zhang" <cathy.h.zh...@huawei.com> wrote:
>
> Hi Giuseppe,
>
>
>
> Please see inline,
>
>
>
> Regards,
>
> Cathy
>
>
>
> From: Giuseppe (Pino) de Candia [mailto:gdecan...@midokura.com]
> Sent: Wednesday, October 28, 2015 5:15 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: Cathy Zhang; Henry Fourie; Irena Berezovsky
> Subject: Re: [openstack-dev] [neutron][networking-sfc] API clarification
questions
>
>
>
> On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant <rbry...@redhat.com>
wrote:
>
> I read through the proposed SFC API here:
>
> http://docs.openstack.org/developer/networking-sfc/api.html
>
> I'm looking at implementing what would be required to support this API
> in OVN.  I have a prototype, but I had to make some pretty big
> assumptions, so I wanted to clarify the intent of the API.
>
> First, does it assume that all of the neutron ports in a chain are on
> the same Neutron network?  That keeps things simple.  If its intended to
> allow a chain of ports on different networks, is it just required that
> you pick ports that all have addresses routable from one port to the
> next in the chain?  An arbitrary set of ports can't always work, so
> there has to be some bounds around what set of ports are valid to be in
> a chain.
>
>
>
> Hi Russell,
>
>
>
> We have similarly been experimenting with a MidoNet implementation of the
SFC API.
>
>
>
> I hope there's no restriction on the location of the Neutron ports in a
chain.
>
>
>
> In terms of addresses, I believe the API is lacking (or we use a
chain_parameter?) a way to indicate the service insertion model:
>
> - L2 - The service can accept packets sent from any MAC (service NIC in
promiscuous mode). The MAC address may be used to identify where the packet
came from before it entered the chain.
>
> - L3 -  The service expects packets to be routed to it. So the
destination MAC of the packet must be set to the service's NIC's MAC.
>
>
>
> Any thoughts on this?
>
>
>
> Cathy> No restriction as long as the ports are routable. Originally we
think we need to specify L2 and L3 service type. But later we found out it
is not needed if we program the switch to set the next hop destination to
the service function’s MAC. This way no matter whether it is L2 or L3, it
always works.
>

Hi Cathy, my understanding is that:
-for an L2 service, don't modify the packet (ignoring possible
encapsulation to signal policy )
-for an L3 service, set the dst MAC in the packet equal to the the service
port's MAC

How can the SDN implementation know which kind of service it's dealing with
to decide whether to modify the MAC?

Thanks,
Pino

>
>>
>>
>> Second, where is it expected that the match is applied?  The API for
>> creating a port chain doesn't associate the chain with a network, but
>> just matching "globally" doesn't make any sense.  If all ports are
>> expected to be on the same network, is the match applied for any traffic
>> entering that network from any port?
>
>
>
> Here's what we were thinking for MidoNet:
>
>
>
> use the logical_source_port in the flow classifier: when we render the
SFC API in MidoNet's models we will associate the chain with the source
port.
>
>
>
> Cathy> Yes, that is the way to specify the flow classifier. Note that one
or more flow classifiers can be associated with the same chain.
>
>
>
> Our packet pipeline (for packets egressing the VM) is:
>
> Port Mirroring
> Service Chaining
> Filtering (Port Security, anti-spoofing, Security Groups)
>
>
>
> Do you think we can standardise on a single order in all implementations?
We'd be happy to change the order if it makes sense.
>
>
>
>
>>
>>
>> I'm in Tokyo this week, so if the group working on this would like to
>> talk in person, that would be great too.
>
>
>
> I'd love to be included.
>
>
>
> Great topic, thanks!
>
>
>
> Cathy> I discussed briefly with Russell in yesterday’s Neutron design
session. If needed, we can meet in today’s Neutron NFV session.
>
>
>
> Thanks,
>
> Cathy
>
>
>
>
>
> Pino
>
>
>>
>>
>> --
>> Russell Bryant
>>
>>
__
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

[Giuseppe (Pino) de Candia]

Hi Gal,

Sorry for the slow reply.

Actually, thinking about it now, I'm not sure.

First, I assume that the pipeline must be in reverse order for
ingress/egress. Do you agree?

For a generic VM, it might be best to have chaining between the network and
the port-level FW. This would allow a security appliance to see and log a
port scan.

But if the VM is a VPN appliance, the port scan could come from either side
of the port. So perhaps we need the possibility to specify a chain's
position relative to security?

-Pino
On Oct 28, 2015 18:16, "Gal Sagie" <gal.sa...@gmail.com> wrote:

> Hi Pino,
>
> Just one note on the order of the pipeline, shouldnt the security part be
> before the service chaining (and also after)?
> (Unless you only meant egress security and you still do the ingress before)
>
> Gal.
>
> On Wed, Oct 28, 2015 at 10:14 AM, Giuseppe (Pino) de Candia <
> gdecan...@midokura.com> wrote:
>
>> On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant <rbry...@redhat.com>
>> wrote:
>>
>>> I read through the proposed SFC API here:
>>>
>>> http://docs.openstack.org/developer/networking-sfc/api.html
>>>
>>> I'm looking at implementing what would be required to support this API
>>> in OVN.  I have a prototype, but I had to make some pretty big
>>> assumptions, so I wanted to clarify the intent of the API.
>>>
>>> First, does it assume that all of the neutron ports in a chain are on
>>> the same Neutron network?  That keeps things simple.  If its intended to
>>> allow a chain of ports on different networks, is it just required that
>>> you pick ports that all have addresses routable from one port to the
>>> next in the chain?  An arbitrary set of ports can't always work, so
>>> there has to be some bounds around what set of ports are valid to be in
>>> a chain.
>>>
>>
>> Hi Russell,
>>
>> We have similarly been experimenting with a MidoNet implementation of the
>> SFC API.
>>
>> I hope there's no restriction on the location of the Neutron ports in a
>> chain.
>>
>> In terms of addresses, I believe the API is lacking (or we use a
>> chain_parameter?) a way to indicate the service insertion model:
>> - L2 - The service can accept packets sent from any MAC (service NIC in
>> promiscuous mode). The MAC address may be used to identify where the packet
>> came from before it entered the chain.
>> - L3 -  The service expects packets to be routed to it. So the
>> destination MAC of the packet must be set to the service's NIC's MAC.
>>
>> Any thoughts on this?
>>
>>
>>>
>>> Second, where is it expected that the match is applied?  The API for
>>> creating a port chain doesn't associate the chain with a network, but
>>> just matching "globally" doesn't make any sense.  If all ports are
>>> expected to be on the same network, is the match applied for any traffic
>>> entering that network from any port?
>>>
>>
>> Here's what we were thinking for MidoNet:
>>
>> use the logical_source_port in the flow classifier: when we render the
>> SFC API in MidoNet's models we will associate the chain with the source
>> port.
>>
>> Our packet pipeline (for packets egressing the VM) is:
>>
>>1. Port Mirroring
>>2. Service Chaining
>>3. Filtering (Port Security, anti-spoofing, Security Groups)
>>
>>
>> Do you think we can standardise on a single order in all implementations?
>> We'd be happy to change the order if it makes sense.
>>
>>
>>
>>>
>>> I'm in Tokyo this week, so if the group working on this would like to
>>> talk in person, that would be great too.
>>>
>>
>> I'd love to be included.
>>
>> Great topic, thanks!
>>
>> Pino
>>
>>
>>>
>>> --
>>> Russell Bryant
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best Regards ,
>
> The G.
>
> __
> 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][networking-sfc] API clarification questions

[Giuseppe (Pino) de Candia]

On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant  wrote:

> I read through the proposed SFC API here:
>
> http://docs.openstack.org/developer/networking-sfc/api.html
>
> I'm looking at implementing what would be required to support this API
> in OVN.  I have a prototype, but I had to make some pretty big
> assumptions, so I wanted to clarify the intent of the API.
>
> First, does it assume that all of the neutron ports in a chain are on
> the same Neutron network?  That keeps things simple.  If its intended to
> allow a chain of ports on different networks, is it just required that
> you pick ports that all have addresses routable from one port to the
> next in the chain?  An arbitrary set of ports can't always work, so
> there has to be some bounds around what set of ports are valid to be in
> a chain.
>

Hi Russell,

We have similarly been experimenting with a MidoNet implementation of the
SFC API.

I hope there's no restriction on the location of the Neutron ports in a
chain.

In terms of addresses, I believe the API is lacking (or we use a
chain_parameter?) a way to indicate the service insertion model:
- L2 - The service can accept packets sent from any MAC (service NIC in
promiscuous mode). The MAC address may be used to identify where the packet
came from before it entered the chain.
- L3 -  The service expects packets to be routed to it. So the destination
MAC of the packet must be set to the service's NIC's MAC.

Any thoughts on this?


>
> Second, where is it expected that the match is applied?  The API for
> creating a port chain doesn't associate the chain with a network, but
> just matching "globally" doesn't make any sense.  If all ports are
> expected to be on the same network, is the match applied for any traffic
> entering that network from any port?
>

Here's what we were thinking for MidoNet:

use the logical_source_port in the flow classifier: when we render the SFC
API in MidoNet's models we will associate the chain with the source port.

Our packet pipeline (for packets egressing the VM) is:

   1. Port Mirroring
   2. Service Chaining
   3. Filtering (Port Security, anti-spoofing, Security Groups)


Do you think we can standardise on a single order in all implementations?
We'd be happy to change the order if it makes sense.



>
> I'm in Tokyo this week, so if the group working on this would like to
> talk in person, that would be great too.
>

I'd love to be included.

Great topic, thanks!

Pino


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