[Openstack-operators] [Performance][Holidays] IRC meeting schedule

[Dina Belova]

Folks,

we had an IRC meeting yesterday, and holidays schedule was one of the
topics covered. Although, the final decision was not made, so let's
finalise everything here :)

There are few options for 2015 and 2016 now:
1) Let's *do not have more meetings this year or let's meet last time on
Dec 22nd*
3) Should we have first 2016 meeting on *Jan 5th or Jan 12*

Due to the opinions proposed on the meeting, *I'll suggest to finish
meetings for this year and have the first meeting on Jan 12, 2016* (due to
the fact that Christmas holidays almost started already, and in Russia
there will be no X-mas holidays, but we'll have about a week after NY).

Any pros / cons?

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

[Openstack-operators] [app-catalog] IRC Meeting Thursday December 17th at 17:00UTC

[Christopher Aedo]

Greetings! Our next OpenStack Community App Catalog meeting will take
place this ThursdayDecember 17th at 17:00 UTC in #openstack-meeting-3

The agenda can be found here:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Please add agenda items if there's anything specific you would like to
discuss (or of course if the meeting time is not convenient for you
join us on IRC #openstack-app-catalog).

This will be our last meeting for 2015 as the next two Thursdays fall
on dates which make attendance a challenge for some attendees.  Please
join us if you can!

-Christopher

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

[Openstack-operators] [openstack][openstack-dev][openstack-operators][chef] kitchen-openstack 2.2.0 released!

[JJ Asghar]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hey everyone!

I just released 2.2.0[1] of the kitchen-openstack driver. If your
curious the CHANGELOG is located here[2].

We're doing great work with kitchen-openstack, and would love to see
some more feedback on things the community would support or features.
Please put in an issue[3], for a feature request, so we can start the
discussion there.

If you have any questions or thoughts don't hesitate to reach out.

[1]: https://rubygems.org/gems/kitchen-openstack/versions/2.2.0
[2]:
https://github.com/test-kitchen/kitchen-openstack/blob/master/CHANGELOG.md#220
[3]: https://github.com/test-kitchen/kitchen-openstack/issues

- -- 
Best Regards,
JJ Asghar
c: 512.619.0722 t: @jjasghar irc: j^2
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWcbXfAAoJEDZbxzMH0+jT5S0P/RRHbahe0rMnzHNuiPtThilg
JODMMoHR0MmGsis/n3CSZ4WDez7Ev558Ph7iqx8upuHL3Asa/zreaK4fOlrjvDeW
WVopRa0myKVZpTssnQXNP6ZFRWcrr2nQaL8CXkk+r2ULVG64M+b/ekYfGrdOUfuw
zcNQoM6Z9vRGflPjD3WDLVDpVw2awRrZQ3AOanpPyxiIZMvVbQodJYnhBXA9pSlQ
lXgC9qG/JPhq3VYuAocLofiF8+maIvCUB6EU9i0ddfaqBMyiFrPo9l0RYaNIMQXF
f+b1WdDq5vRi8RJSl4v9TEWpaqF+spHpFqA2GS6LSeh1/Wv9R2+/xKS1C1jrAfMn
Zh29jb324tpJ6A/783+1C7+Psa6V2d8Su8I0Fr00brWovdhag7pmKliHLyWTA78A
a7wQtWohvalzGwjTofOkkbiY4IpIrwESUsOaT1pR+Gk0KZDt+s1+cwiU802IK6u1
eiCbXPOqho0Q0GNglFgVHbk/U2TqG0Z4+KV6utCCqOK9dkVJuGV5RHJ0IddEiXEr
fvZbDVIkSozWbSsJBpKZuFOcT/XWc9UUCk/ow1FdlmxDN4o8CUcV5fliM/Y0AjXf
Vh+wt9gfQNpv1Svhw+bhtjQiGoy5wkUOfT3QjE7D3Z7DFXcmmZqyh38YEDyiflZw
7Z031uewvalMgHRTeLGm
=7kGh
-END PGP SIGNATURE-

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

[Openstack-operators] [openstack-operators][osops] 2015-12-16 Meeting Notes

[JJ Asghar]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hey Everyone!

Links [1][2][3] for the meeting notes and logs.

Our next meeting is 2015-12-30[4], and with the holidays I don't
expect a large turnout, but I created the agenda[4] anyway.

If I don't see you then, have a great rest of the year and lets start
2016 off right!

[1]:
http://eavesdrop.openstack.org/meetings/operators_ops_tools_monitoring/2015/operators_ops_tools_monitoring.2015-12-16-19.00.html
[2]:
http://eavesdrop.openstack.org/meetings/operators_ops_tools_monitoring/2015/operators_ops_tools_monitoring.2015-12-16-19.00.txt
[3]:
http://eavesdrop.openstack.org/meetings/operators_ops_tools_monitoring/2015/operators_ops_tools_monitoring.2015-12-16-19.00.log.html
[4]: https://etherpad.openstack.org/p/osops-irc-meeting-20151230
- -- 
Best Regards,
JJ Asghar
c: 512.619.0722 t: @jjasghar irc: j^2
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWcerHAAoJEDZbxzMH0+jT75EP/3IRNynDyJXHBvyrQGhcBT55
o3EUjVO1IpTwxTHrLRyWGmSOQ+eWLt8s54jcbDmuZVtpw3cV87RP//jz7ERu5Vif
q7rSMKEI/XcNijvy/apPl1dlF+NhvMb6bM1kJ9tFJBiCACf8+MFB/2rrKVBhqB7G
VugEAX/xhqCbt4zKPWb2ot47+K723v2nl3g3UtiFHQKf/ORJIr9i2xnHgRtchygl
LvezBg+DnA4XYo9eo0VWB6iy7Jadg+uOwAb/XLgIOJCWugMl8Z1w5lB1ipg0IuM7
l0vvJVx6rseJLWWQ6lk2a81itxOBQP5ZRsSLhlQN9szSwQScb+gr1b1rYR712WfU
NEfFgCxOmiPWIXCYRgOxGF4MI+i+IClmb5d0pZt0DDkmF7j5t0UV77dDRCj+PX8w
t5EMqTCJIQ6ua7AIsoOvtVqUggcnusWIo5csKAk2BQFdgPPBgADJye1MRYXAfV8x
XKy29p5iHBhDb8nzTliao4cQM29YhmerIok4dOLLIlbjF0bKldQRuZ2GB7/3KkDv
1X85NJv+A/RNwIorEgfrRm6YMmP52ZMPiWV/JOUo9cP7u3Kiy1j3l8Ef4yQgHpC6
pm3aPyfDQwcSlYfNV+Y+knqXjaPRKkm6Oq80mL8X21R6mjLOADON7nPWl0g3uty1
leT/LQ9MOlaZllVWAXlK
=IRg2
-END PGP SIGNATURE-

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

Re: [Openstack-operators] Service Catalog TNG urls

[Anne Gentle]

On Thu, Dec 3, 2015 at 8:14 AM, Sean Dague  wrote:

> For folks that don't know, we've got an effort under way to look at some
> of what's happened with the service catalog, how it's organically grown,
> and do some pruning and tuning to make sure it's going to support what
> we want to do with OpenStack for the next 5 years (wiki page to dive
> deeper here - https://wiki.openstack.org/wiki/ServiceCatalogTNG).
>
> One of the early Open Questions is about urls. Today there is a
> completely free form field to specify urls, and there are conventions
> about having publicURL, internalURL, adminURL. These are, however, only
> conventions.
>
> The only project that's ever really used adminURL has been Keystone, so
> that's something we feel we can phase out in new representations.
>
> The real question / concern is around public vs. internal. And something
> we'd love feedback from people on.
>
> When this was brought up in Tokyo the answer we got was that internal
> URL was important because:
>
> * users trusted it to mean "I won't get changed for bandwidth"
> * it is often http instead of https, which provides a 20% performance
> gain for transfering large amounts of data (i.e. glance images)
>
> The question is, how hard would it be for sites to be configured so that
> internal routing is used whenever possible? Or is this a concept we need
> to formalize and make user applications always need to make the decision
> about which interface they should access?
>

I got some additional info from operators I wanted to bring here.

The publicURL has to be super denial-of-service proof as these are the
published, easily found URLs.

All URLs might have regional requirements around data privacy and where the
data is eventually housed, such as EU requirements for some products. The
data privacy requirement might mean a requirement for completely separate
networks.

Going through a proxy breaks what those promises are to customers - that
they are on a separate network. Plus a proxy may not be performant enough
for possible denial of service attacks.

Also for legal reasons some URLs are exposed internal only. So this is in
addition to the billing use case for internalURL, there may also be a
legal/contractual requirement.

Providers may need to decrypt data to determine the actual URL, so while
processing and redirection can happen on network devices, audits and
debugging mean the providers/ops need the actual URL at some point. I don't
think the design prevents that but wanted to bring it up.

Another use case I hadn't heard yet is if a public URL is DDoSed, you can
have a second URL on internal-only systems that can't be attacked from the
outside world. So it's a publicURL in that you can access the service, but
an internal-only URL so we can protect.

Some of the regional/legal requirements could be solved with split horizon
DNS - the ability for a DNS-server to give a different answer to a query
based on the source of the query - but if a provider doesn't already have
that in their network gear they'd have to invest, perhaps heavily, to get
it.

All of these use cases don't require that a deployer publish an internalURL
or adminURL in the service catalog, I realize this. It does provide
explanations for possible other endpoints you may need to tell people about
when they query a service.
Hope that helps.
Anne



>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.com
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Service Catalog TNG urls

[Mathieu Gagné]

On 2015-12-16 11:11 AM, Anne Gentle wrote:
> 
> Another use case I hadn't heard yet is if a public URL is DDoSed, you
> can have a second URL on internal-only systems that can't be attacked
> from the outside world. So it's a publicURL in that you can access the
> service, but an internal-only URL so we can protect.

This is one of the reason we have a split catalog.

We are using Keystone templated catalog to publish different URLs for
users and services. (no SQL catalog) This is so services can continue to
work if public API is DDoSed.

This is done by having 2 sets of Keystone services (all fed from the
same database for auth and assignments) but with different templated
catalog. Users use the public one and services the private one which all
have a dedicated URL.

We also don't use split DNS to ease debug and preserve our sanity. By
having an explicitly different URL, you can easily see and understand
which API is contacted (public vs internal). This greatly reduce
misunderstanding or gotcha: oh, you are querying DNS from this desktop,
nan, you won't get the "right" internal IP.

We do not use the internalURL field as we do not wish to publish those
endpoints to the end users. Our understanding is that they were meant
for a different use case than ours.

We could provide an other set of internal URLs so they can access our
API from within the cloud network but that's an other need we haven't
encounter yet.

-- 
Mathieu

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

[Openstack-operators] [nfv][telcowg] Telco Working Group meeting cancellations - Dec 23rd, Dec 30, Jan 6

[Steve Gordon]

Hi all,

We discussed in today's meeting and confirmed that we will skip our schedule 
meetings for:

* December 23rd
* December 30th
* January 6th

We will reconvene on January 13th, I will send a reminder close to that date.

Thanks,

Steve

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