Re: [Openstack-operators] How to restrict AvZones to Tenants

[joehuang]

Hi,

There is only region endpoint filter currently,  I did not find a way to 
restrict Availability Zones visibility for tenants. I think it could be a user 
story or discuss this in openstack-dev maillist:  
openstack-...@lists.openstack.org


region endpoint filter   
http://docs.openstack.org/developer/keystone/extensions/endpoint_filter.html

Best Regards
Chaoyi Huang ( Joe Huang )

From: raju [mailto:raju.r...@gmail.com]
Sent: Thursday, August 27, 2015 4:48 AM
To: openstack-operators@lists.openstack.org
Subject: [Openstack-operators] How to restrict AvZones to Tenants

Hi,

I want to restrict Avzones to particular Tenant so that users in the Tenant can 
only see the particular Avzone from drop down while provisioning instances.


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

Re: [Openstack-operators] How to restrict AvZones to Tenants

[gustavo panizzo]

On Thu, Aug 27, 2015 at 11:26:42 +1000, Marcus Furlong wrote:
> On 27 August 2015 at 06:48, raju  wrote:
> > Hi,
> >
> > I want to restrict Avzones to particular Tenant so that users in the Tenant
> > can only see the particular Avzone from drop down while provisioning
> > instances.

you can add a *filter_tenant_id* key on the aggregate which makes the AZ
and configure AggregateMultiTenancyIsolation filter, that will exclude
other tenants from those hypervisors, AZ will still be visible by other
tenants but they won't be able to use it

-- 
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333

keybase: http://keybase.io/gfa

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

Re: [Openstack-operators] How to restrict AvZones to Tenants

[Marcus Furlong]

On 27 August 2015 at 06:48, raju  wrote:
> Hi,
>
> I want to restrict Avzones to particular Tenant so that users in the Tenant
> can only see the particular Avzone from drop down while provisioning
> instances.

Hi Raju,

I don't think it's possible at the moment, however there is currently
a review in progress that will hopefully implement quotas per AZ:

   https://review.openstack.org/#/c/206160/

Regards,
Marcus.
-- 
Marcus Furlong

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

Re: [Openstack-operators] Juno and Kilo Interoperability

[Sam Morrison]

Yeah we run a multitude of versions at the same time. We usually run N and N-1 
in the same env but have also done N-2 (eg. Havana, Icehouse and Juno)

Currently we are mainly Juno (keystone, heat, ceilometer, cinder) with a couple 
of icehouse things lying around. We are in the progress of upgrading to Kilo so 
some of our nova control is kilo now.

With clients the only issue I’ve had is with the designate client not being 
backwards compatible between icehouse and juno.
Ceilometer changed the way they signed messaged between Icehouse and Juno which 
was a pain so we had to set up parallel virtual hosts and collectors to push it 
into mongo.

All the APIs are pretty stable so it shouldn’t really matter what version of 
say keystone can work with what version of nova etc. 
We basically take it for granted now although of course test in your own env.

With nova make sure you set upgrade_levels so your nova control can talk to you 
computes that are on version N-1 etc.

Sam


> On 27 Aug 2015, at 3:09 am, David Medberry  wrote:
> 
> Hi Eren,
> 
> I'm pretty sure NECTaR is doing diff versions at different sites in a widely 
> distributed way.
> 
> https://www.openstack.org/user-stories/nectar/ 
> 
> 
> I've cc'd Sam as well. He's your man.
> 
> On Wed, Aug 26, 2015 at 5:24 AM, Eren Türkay  > wrote:
> Hello operators,
> 
> I am wondering if anyone is using different versions of Openstack in different
> sites.
> 
> We have our first site which is Juno, and we are now having another site where
> we are planning to deploy Kilo. Does anyone have experience with different
> versions of installation? Particularly, our Horizon and other clients will be
> Juno, but they will talk to secondary site which is Kilo. Inferring from the
> release notes, Kilo API looks backward compatible with Juno, so I'm a little
> optimistic about it but still I'm not sure.
> 
> Any help is appreciated,
> Eren
> 
> --
> Eren Türkay, System Administrator
> https://skyatlas.com/  | +90 850 885 0357 
> 
> 
> Yildiz Teknik Universitesi Davutpasa Kampusu
> Teknopark Bolgesi, D2 Blok No:107
> Esenler, Istanbul Pk.34220
> 
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators 
> 
> 
> 

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

Re: [Openstack-operators] [openstack-dev] PLEASE READ: VPNaaS API Change - not backward compatible

[James Dempsey]

On 26/08/15 23:43, Paul Michali wrote:
> James,
> 
> Great stuff! Please see @PCM in-line...
> 
> On Tue, Aug 25, 2015 at 6:26 PM James Dempsey 



>> 1) Horizon compatibility
>>
>> We run a newer version of horizon than we do neutron.  If Horizon
>> version X doesn't work with Neutron version X-1, this is a very big
>> problem for us.
>>
> 
> @PCM Interesting. I always thought that Horizon updates lagged Neutron
> changes, and this wouldn't be a concern.
> 

@JPD
Our Installed Neutron typically lags Horizon by zero or one release.  My
concern is how will Horizon version X cope with a point-in-time API
change?  Worded slightly differently: We rarely update Horizon and
Neutron at the same time so there would need to be a version(or
versions) of Horizon that could detect a Neutron upgrade and start using
the new API.  (I'm fine if there is a Horizon config option to select
old/new VPN API usage.)

> 
> 
>>
>> 2) Service interruption
>>
>> How much of a service interruption would the 'migration path' cause?
> 
> 
> @PCM The expectation of the proposal is that the migration would occur as
> part of the normal OpenStack upgrade process (new services installed,
> current services stopped, database migration occurs, new services are
> started).
> 
> It would have the same impact as what would happen today, if you update
> from one release to another. I'm sure you folks have a much better handle
> on that impact and how to handle it (maintenance windows, scheduled
> updates, etc).
> 

@JPD This seems fine.

> 
> We
>> all know that IPsec VPNs can be fragile...  How much of a guarantee will
>> we have that migration doesn't break a bunch of VPNs all at the same
>> time because of some slight difference in the way configurations are
>> generated?
>>
> 
> @PCM I see the risk as extremely low. With the migration, the end result is
> really just moving/copying fields from one table to another. The underlying
> configuration done to *Swan would be the same.
> 
> For example, the subnet ID, which is specified in the VPN service API and
> stored in the vpnservices table, would be stored in a new vpn_endpoints
> table, and the ipsec_site_connections table would reference that entry
> (rather than looking up the subnet in the vpnservices table).
> 

@JPD This makes me feel more comfortable; thanks for explaining.

> 
> 
>> 3) Heat compatibility
>>
>> We don't always run the same version of Heat and Neutron.
>>
> 
> @PCM I must admit, I've never used Heat, and am woefully ignorant about it.
> Can you elaborate on Heat concerns as may be related to VPN API differences?
> 
> Is Heat being used to setup VPN connections, as part of orchestration?
> 

@JPD
My concerns are two-fold:

1) Because Heat makes use of the VPNaaS API, it seems like the same
situation exists as with Horizon.  Some version or versions of Heat will
need to be able to make use of both old and new VPNaaS APIs in order to
cope with a Neutron upgrade.

2) Because we use Heat resource types like
OS::Neutron::IPsecSiteConnection [1], we may lose the ability to
orchestrate VPNs if endpoint groups are not added to Heat at the same time.


Number 1 seems like a real problem that needs a fix.  Number 2 is a fact
of life that I am not excited about, but am prepared to deal with.

Yes, Heat is being used to build VPNs, but I am prepared to make the
decision on behalf of my users... VPN creation via Heat is probably less
important than the new VPNaaS features, but it would be really great if
we could work on the updated heat resource types in parallel.

[1]
http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::IPsecSiteConnection

> 
> 
>>

 Is there pain for the customers beyond learning about the new API
>> changes
 and capabilities (something that would apply whether there is backward
 compatibility or not)?

>>
>> See points 1,2, and 3 above.
>>
> 
>>>
>>> Another implication of not having backwards compatibility would be that
>>> end-users would need to immediately switch to using the new API, once the
>>> migration occurs, versus doing so on their own time frame.  Would this
>> be a
>>> concern for you (customers not having the convenience of delaying their
>>> switch to the new API)?
>>>
>>>
 I was thinking that backward incompatible changes would adversely affect
 people who were using client scripts/apps to configure (a large number
>> of)
 IPsec connections, where they'd have to have client scripts/apps
>> in-place
 to support the new API.

>>
>> This is actually less of a concern.  We have found that VPN creation is
>> mostly done manually and anyone who is clever enough to make IPsec go is
>> clever enough to learn a new API/horizon interface.
>>
> 
> @PCM Do you see much reliance on tooling to setup VPN (such that having to
> update the tooling would be a concern for end-users), or is this something
> that could be managed through process/preparation?
> 

@JPD  I see very little reliance 

[Openstack-operators] How to restrict AvZones to Tenants

[raju]

Hi,

I want to restrict Avzones to particular Tenant so that users in the Tenant
can only see the particular Avzone from drop down while provisioning
instances.


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

Re: [Openstack-operators] Juno and Kilo Interoperability

[Matthias Runge]

On 26/08/15 19:11, David Medberry wrote:
> and we generally run a much newer Horizon and Keystone than the rest of
> the services. We had Horizon and Keystone on POST KILO (master after
> Kilo released) while still running Juno on all other services. Worked fine.

Horizon used to work cross versions in the past without an issue. At
some point we gave up testing on this. Still things look very good.
You might see issues, if horizon requires much newer python-client
libraries though.

Matthias


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

Re: [Openstack-operators] Juno and Kilo Interoperability

[David Medberry]

and we generally run a much newer Horizon and Keystone than the rest of the
services. We had Horizon and Keystone on POST KILO (master after Kilo
released) while still running Juno on all other services. Worked fine.

On Wed, Aug 26, 2015 at 11:09 AM, David Medberry 
wrote:

> Hi Eren,
>
> I'm pretty sure NECTaR is doing diff versions at different sites in a
> widely distributed way.
>
> https://www.openstack.org/user-stories/nectar/
>
> I've cc'd Sam as well. He's your man.
>
> On Wed, Aug 26, 2015 at 5:24 AM, Eren Türkay  wrote:
>
>> Hello operators,
>>
>> I am wondering if anyone is using different versions of Openstack in
>> different
>> sites.
>>
>> We have our first site which is Juno, and we are now having another site
>> where
>> we are planning to deploy Kilo. Does anyone have experience with different
>> versions of installation? Particularly, our Horizon and other clients
>> will be
>> Juno, but they will talk to secondary site which is Kilo. Inferring from
>> the
>> release notes, Kilo API looks backward compatible with Juno, so I'm a
>> little
>> optimistic about it but still I'm not sure.
>>
>> Any help is appreciated,
>> Eren
>>
>> --
>> Eren Türkay, System Administrator
>> https://skyatlas.com/ | +90 850 885 0357
>>
>> Yildiz Teknik Universitesi Davutpasa Kampusu
>> Teknopark Bolgesi, D2 Blok No:107
>> Esenler, Istanbul Pk.34220
>>
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Juno and Kilo Interoperability

[David Medberry]

Hi Eren,

I'm pretty sure NECTaR is doing diff versions at different sites in a
widely distributed way.

https://www.openstack.org/user-stories/nectar/

I've cc'd Sam as well. He's your man.

On Wed, Aug 26, 2015 at 5:24 AM, Eren Türkay  wrote:

> Hello operators,
>
> I am wondering if anyone is using different versions of Openstack in
> different
> sites.
>
> We have our first site which is Juno, and we are now having another site
> where
> we are planning to deploy Kilo. Does anyone have experience with different
> versions of installation? Particularly, our Horizon and other clients will
> be
> Juno, but they will talk to secondary site which is Kilo. Inferring from
> the
> release notes, Kilo API looks backward compatible with Juno, so I'm a
> little
> optimistic about it but still I'm not sure.
>
> Any help is appreciated,
> Eren
>
> --
> Eren Türkay, System Administrator
> https://skyatlas.com/ | +90 850 885 0357
>
> Yildiz Teknik Universitesi Davutpasa Kampusu
> Teknopark Bolgesi, D2 Blok No:107
> Esenler, Istanbul Pk.34220
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Juno and Kilo Interoperability

[Matt Riedemann]

On 8/26/2015 9:30 AM, Eren Türkay wrote:

On 26-08-2015 17:17, Jonathan Proulx wrote:

We recently upgraded from Juno to Kilo and many of our clients
(including Horizon) are still Juno with no problems.


Great news. That's our use case. We will have Juno clients and Kilo API 
endpoints.

Thank you for your help.



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



In the case of nova, control node services need to be newer than or 
equal to the compute services.


This is a good blog post about doing rolling upgrades for nova:

http://superuser.openstack.org/articles/upgrading-nova-to-kilo-with-minimal-downtime

--

Thanks,

Matt Riedemann


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

Re: [Openstack-operators] IP - availability monitoring

[Kris G. Lindgren]

Hello,

As you know, much discussion has been around the naming and the url pathing for 
the ip-usages extension.  We also discussed this at the neutron mid-cycle as 
well.  Since we are the ones the made the extension, we use the extension to 
help with scheduling in our layer 3 network design.We have no preference as 
to the url's but the only thing that we want to maintain is the ability to 
query for all subnets at once.  We have a nova scheduling filter that makes a 
call into the  ip-usages extension.  Otherwise every time we provision a vm we 
would have to make N number of calls to get all the subnets and their usages.


Kris Lindgren
Senior Linux Systems Engineer
GoDaddy, LLC.

From: Salvatore Orlando mailto:salv.orla...@gmail.com>>
Date: Tuesday, August 25, 2015 at 4:33 PM
To: Assaf Muller mailto:amul...@redhat.com>>
Cc: 
"openstack-operators@lists.openstack.org"
 
mailto:openstack-operators@lists.openstack.org>>
Subject: Re: [Openstack-operators] IP - availability monitoring

As the specification linked by Assaf has without doubt value for operators, I 
think the drivers team might consider it for inclusion in the Liberty release.
Unfortunately the specification and the patch have not received many reviews, 
but can still be sorted, especially considering that the patch's size is 
manageable and its impact contained.

Nevertheless, Daniel in his post referred to providing information about usage 
of IPs in resources like subnets, whereas the patch under review proposes the 
addition of a new read-only resource called 'network_ip_usage'. The only thing 
I'd change is that I'd make this information available in a different way.
For instance:

- through a sub-url of subnets: GET /v2.0/subnets//ip_usage
- through a query paramer on subnet GET /v2.0/subnets/?ip_usage=True
- making IPs a read only resource GET /v2.0/ips?subnet_id=&count=True

I think from a user perspective the latter would be the more elegant and simple 
to use, but it will require additional work for introducing resource counting 
in Neutron APIs; and for this there's an old spec too [1]. Having operators 
providing feedback on how they reckon this is information is best consumed 
would be valuable.

[1] https://review.openstack.org/#/c/102199/

Salvatore






On 24 August 2015 at 03:21, Assaf Muller 
mailto:amul...@redhat.com>> wrote:


On Sun, Aug 23, 2015 at 8:23 PM, Daniel Speichert 
mailto:dan...@speichert.pl>> wrote:
On 8/22/2015 23:24, Balaji Narayanan (பாலாஜி நாராயணன்) wrote:
> Hello Operators,
>
> In the capacity management discussions at the Ops Summit last week, I
> thought there was a some discussion on monitoring of fixed / floating
> subnets and availability.
>
> At Yahoo, we use nova-network and have an API extension available for
> reporting how much ip subnets are configured on a cluster and how much
> of them are used / remaining. We use this to trigger an alert /
> augment additional subnets to the cluster.
>
> If there is enough interest in this, we can look at pushing this upstrem.
>
> Here is a blue print that vilobh wrote initially for this -
> https://review.openstack.org/#/c/94299/
This sounds like a very useful extension, considering there's really no
quotas for IP addresses and IPs are a scarce resource.
I'm aware of multiple big private cloud operators using custom scripts
to generate reports of available IP addresses.

I'm pretty sure an extension like this would be great for neutron (I'm
not using nova-network). Considering that most networking scenarios
(flat, provider networks, floating IPs with L3) have subnets as a
resource in neutron, with allocation pools, it seems enough to create an
extension that would provide statistics for a subnet or summary
statistics for all subnets within a network if so requested.

I can work on a new blueprint version for neutron.

There already is one.

Code:
https://review.openstack.org/#/c/212955/

RFE bug:
https://bugs.launchpad.net/neutron/+bug/1457986

Blueprint:
https://blueprints.launchpad.net/neutron/+spec/network-ip-usage-api

Spec:
https://review.openstack.org/#/c/180803/5/specs/liberty/network-ip-usage-api.rst


Regards,
Daniel Speichert



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


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


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

Re: [Openstack-operators] Juno and Kilo Interoperability

[Eren Türkay]

On 26-08-2015 17:17, Jonathan Proulx wrote:
> We recently upgraded from Juno to Kilo and many of our clients
> (including Horizon) are still Juno with no problems.

Great news. That's our use case. We will have Juno clients and Kilo API 
endpoints.

Thank you for your help.

-- 
Eren Türkay, System Administrator
https://skyatlas.com/ | +90 850 885 0357

Yildiz Teknik Universitesi Davutpasa Kampusu
Teknopark Bolgesi, D2 Blok No:107
Esenler, Istanbul Pk.34220



signature.asc
Description: OpenPGP digital signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Juno and Kilo Interoperability

[Jonathan Proulx]

Juno clients with Kilo endpoints are fine.

We recently upgraded from Juno to Kilo and many of our clients
(including Horizon) are still Juno with no problems.

We also had a Kilo Horizon (for testing) running against Juno
endpoints prior to the upgrade and that seemed to work as well but it
wasn't thoroughly tested so can't recommend it without further
testing.

-Jon

On Wed, Aug 26, 2015 at 7:24 AM, Eren Türkay  wrote:
> Hello operators,
>
> I am wondering if anyone is using different versions of Openstack in different
> sites.
>
> We have our first site which is Juno, and we are now having another site where
> we are planning to deploy Kilo. Does anyone have experience with different
> versions of installation? Particularly, our Horizon and other clients will be
> Juno, but they will talk to secondary site which is Kilo. Inferring from the
> release notes, Kilo API looks backward compatible with Juno, so I'm a little
> optimistic about it but still I'm not sure.
>
> Any help is appreciated,
> Eren
>
> --
> Eren Türkay, System Administrator
> https://skyatlas.com/ | +90 850 885 0357
>
> Yildiz Teknik Universitesi Davutpasa Kampusu
> Teknopark Bolgesi, D2 Blok No:107
> Esenler, Istanbul Pk.34220
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

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

Re: [Openstack-operators] [openstack-dev] PLEASE READ: VPNaaS API Change - not backward compatible

[Paul Michali]

James,

Great stuff! Please see @PCM in-line...



On Tue, Aug 25, 2015 at 6:26 PM James Dempsey 
wrote:

> Oops, sorry about the blank email.  Answers/Questions in-line.
>
> On 26/08/15 07:46, Paul Michali wrote:
> > Previous post only went to dev list. Ensuring both and adding a bit
> more...
> >
> >
> >
> > On Tue, Aug 25, 2015 at 8:37 AM Paul Michali  wrote:
> >
> >> Xav,
> >>
> >> The discussion is very important, and hence why both Kyle and I have
> been
> >> posting these questions on the operator (and dev) lists. Unfortunately,
> I
> >> wasn't subscribed to the operator's list and missed some responses to
> >> Kyle's message, which were posted only to that list.
> >>
> >> As a result, I had an incomplete picture and posted this thread to see
> if
> >> it was OK to do this without backward compatibility, based on the
> >> (incorrect) assumption that there was no production use. That is
> corrected
> >> now, and I'm getting all the messages and thanks to everyone, have
> input on
> >> messages I missed.
> >>
> >> So given that, let's try a reset on the discussion, so that I can better
> >> understand the issues...
> >>
>
> Great!  Thanks very much for expanding the scope.  We really appreciate it.
>
> >> Do you feel that not having backward compatibility (but having a
> migration
> >> path) would seriously affect you or would it be manageable?
>
> Currently, this feels like it would seriously affect us.  I don't feel
> confident that the following concerns won't cause us big problems.
>
>
> As Xav mentioned previously, we have a few major concerns:
>

@PCM Thanks! It's good to know what things we need to be aware of.



>
> 1) Horizon compatibility
>
> We run a newer version of horizon than we do neutron.  If Horizon
> version X doesn't work with Neutron version X-1, this is a very big
> problem for us.
>

@PCM Interesting. I always thought that Horizon updates lagged Neutron
changes, and this wouldn't be a concern.



>
> 2) Service interruption
>
> How much of a service interruption would the 'migration path' cause?


@PCM The expectation of the proposal is that the migration would occur as
part of the normal OpenStack upgrade process (new services installed,
current services stopped, database migration occurs, new services are
started).

It would have the same impact as what would happen today, if you update
from one release to another. I'm sure you folks have a much better handle
on that impact and how to handle it (maintenance windows, scheduled
updates, etc).


We
> all know that IPsec VPNs can be fragile...  How much of a guarantee will
> we have that migration doesn't break a bunch of VPNs all at the same
> time because of some slight difference in the way configurations are
> generated?
>

@PCM I see the risk as extremely low. With the migration, the end result is
really just moving/copying fields from one table to another. The underlying
configuration done to *Swan would be the same.

For example, the subnet ID, which is specified in the VPN service API and
stored in the vpnservices table, would be stored in a new vpn_endpoints
table, and the ipsec_site_connections table would reference that entry
(rather than looking up the subnet in the vpnservices table).



> 3) Heat compatibility
>
> We don't always run the same version of Heat and Neutron.
>

@PCM I must admit, I've never used Heat, and am woefully ignorant about it.
Can you elaborate on Heat concerns as may be related to VPN API differences?

Is Heat being used to setup VPN connections, as part of orchestration?



>
> >>
> >> Is there pain for the customers beyond learning about the new API
> changes
> >> and capabilities (something that would apply whether there is backward
> >> compatibility or not)?
> >>
>
> See points 1,2, and 3 above.
>

> >
> > Another implication of not having backwards compatibility would be that
> > end-users would need to immediately switch to using the new API, once the
> > migration occurs, versus doing so on their own time frame.  Would this
> be a
> > concern for you (customers not having the convenience of delaying their
> > switch to the new API)?
> >
> >
> >> I was thinking that backward incompatible changes would adversely affect
> >> people who were using client scripts/apps to configure (a large number
> of)
> >> IPsec connections, where they'd have to have client scripts/apps
> in-place
> >> to support the new API.
> >>
>
> This is actually less of a concern.  We have found that VPN creation is
> mostly done manually and anyone who is clever enough to make IPsec go is
> clever enough to learn a new API/horizon interface.
>

@PCM Do you see much reliance on tooling to setup VPN (such that having to
update the tooling would be a concern for end-users), or is this something
that could be managed through process/preparation?



>
> >
> > Which is more of a logistics issue, and could be managed, IMHO.
> >
> >
> >
> >>
> >> Would there be customers that would fall into that category, or are
> >> custo

[Openstack-operators] Juno and Kilo Interoperability

[Eren Türkay]

Hello operators,

I am wondering if anyone is using different versions of Openstack in different
sites.

We have our first site which is Juno, and we are now having another site where
we are planning to deploy Kilo. Does anyone have experience with different
versions of installation? Particularly, our Horizon and other clients will be
Juno, but they will talk to secondary site which is Kilo. Inferring from the
release notes, Kilo API looks backward compatible with Juno, so I'm a little
optimistic about it but still I'm not sure.

Any help is appreciated,
Eren

-- 
Eren Türkay, System Administrator
https://skyatlas.com/ | +90 850 885 0357

Yildiz Teknik Universitesi Davutpasa Kampusu
Teknopark Bolgesi, D2 Blok No:107
Esenler, Istanbul Pk.34220



signature.asc
Description: OpenPGP digital signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators