Re: [Openstack-operators] [osops] OSOps Meeting Notes from Summit
Joseph, Comments inline. From: Joseph Bajin mailto:josephba...@gmail.com>> Date: Monday, May 2, 2016 at 8:06 PM To: OpenStack Operators mailto:openstack-operators@lists.openstack.org>> Subject: [Openstack-operators] [osops] OSOps Meeting Notes from Summit Hello Operators, I wanted to provide some updates to the OSOps Operators Meeting that was held last week. You can find the etherpad located here. [1] The highlights of the meeting were the following: - People see OSOps as an advocation group for patches, tools, and features that operators need to get done. - The OSOps group should pick a topic and work on getting that issue resolved for the Operator community to help kick off the group's work. Feel free to borrow our defaults for all the services we implement. They are conditional and have variable replacement at present, and I'm not sure how we could make them not-so in Kolla itself and still have a functional system. One option for you to consider is to just keep them as jinja2 files and define the variables to replace. We have a policy of not adding a bunch of variables to our system so this wouldn't become onerous for you. See: http://docs.openstack.org/developer/kolla/deployment-philosophy.html An example set of configuration files is here for keystone: https://github.com/openstack/kolla/tree/master/ansible/roles/keystone/templates Feel free to reach out to the kolla community on irc at #openstack-kolla if you have questions, comments, or concerns with our defaults. I'd like to see this effort produce a common set of defaults all the projects could use. I think OSAD also has some good pre-defined defaults which could be borrowed and merged in. If you have an irc channel formed, let me know, and I'll put it in our topic for other interested in deployment operations. Regards, -steve - The repo's that OSOps maintains can be used to help in a few different ways. One primary one mentioned was configuration files. Providing bare minimum configuration files to use as a sanity check. The Kolla project can help produce a few of these to jumpstart the project. - Documentation Issues - Help facilitate the update of missing documentation. - Provide packaging examples that could eventually work into a framework for operators to use to pull upstream and apply patches. We are not talking about finding one method, but providing options for operators to choose. Lots of great feedback in both sessions. The first session was around how OSOps can help the provide information to and from projects for them to review. The second half was held to find other ways that OSOps can help and utilize the current repo's to give Operators more tools to better manage their environments. Anyone with additional feedback or would like to help is welcome to join the upcoming OSOps Meeting. Thanks Joe [1] https://etherpad.openstack.org/p/AUS-ops-OSOps ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] How are folks providing GPU instance types?
This page [0] is not up to date but you can use it for configuration examples
or at least that's what I've done. I started this process in Liberty and then
migrated to Mitaka and while I have successfully passed in a device to a VM
from Nova, I have not tried to initialize or use that device yet since I don't
have any EFI images yet. In Liberty I found that Nova comes with all of the
functionality already to do pci passthrough given you have your Hypervisor
configured correctly. Some of it has changed in Mitaka like needing to set
type on the alias and including support to boot EFI images but in general it is
close. I think the filter is already included in the list of available filters
so you would just have to add it to your default filter list. I'm not sure you
would even have to setup host aggregates, just new flavors that define what
aliases that flavor is going to allocate. My assumption has been that
scheduling other VMs on a GPU node might starve the GPU flavor from bei
ng able to launch on that node but I have not tried it yet.
Here's some example configuration:
pci_alias={"name": "Tesla_K80", "vendor_id": "10de", "product_id": "102d",
"device_type": "type-PCI"}
pci_passthrough_whitelist={"vendor_id": "10de", "product_id": "102d"}
The API parts of that webpage currently seem to be integrated in the Nova
codebase but not enabled. You can use the Nova database itself to check for
the pci devices in the pci_devices table.
You will also have to enable iommu on your hypervisors to have libvirt expose
the capability to Nova for PCI passthrough. I use Centos 7 and had to set
'iommu=pt intel_iommu=on' for my kernel parameters. Along with this, you'll
have to start using EFI for your VMs by installing OVMF on your Hypervisors and
configuring your images appropriately. I don't have a link handy for this but
the gist is that Legacy bootloaders have a much more complicated process to
initialize the devices being passed to the VM where EFI is much easier.
[0]: https://wiki.openstack.org/wiki/Pci_passthrough
Peter Nordquist
-Original Message-
From: Jonathan Proulx [mailto:j...@csail.mit.edu]
Sent: Monday, May 09, 2016 13:13
To: openstack-operators@lists.openstack.org
Subject: [Openstack-operators] How are folks providing GPU instance types?
Hi All,
Having trouble finding any current info on best practices for providing GPU
instances. Most of what Google is feeding me is Grizzly or older.
I'm currently on Kilo (Mitaka upgrade planned in 60-90 days) with
Ubuntu14.04 and kvm hypervisor. Looking to add some NVidia GPUs but haven't
invested in hardware yet. Presumably I'd be using host aggregates and instance
metadata to separate these out from the general pool so not tied to kvm though
it would be nice to have image compatibility across GPU and nonGPU instance
types (this is currently 'raw' images in ceph rbd).
Any pointers to good info online or general advice as I travel down this path?
I suppose particularly urgent is any hardware caveats I need ot be aware of
before I sink cash into the wrong thing (I'm presuming that the k10,k20,k40,k80
are all equivalent in this regard).
-Jon
--
___
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] OpenStack Developer Mailing List Digest April 23 - May 6
HTML version: http://www.openstack.org/blog/2016/05/openstack-developer-mailing-list-digest-20160506/ Success Bot Says * Sdague: nova-network is deprecated [1] * Ajaeger: OpenStack content on Transifex has been removed, Zanata on translate.openstack.org has proven to be stable platform for all translators and thus Transifex is not needed anymore. * All: https://wiki.openstack.org/wiki/Successes Backwards Compatibility Follow-up = * Agreements from recent backwards compatibility for clients and libraries session: - Clients need to talk to all versions of OpenStack. Clouds. - Oslo libraries already do need to do backwards compatibility. - Some fraction of our deploys between 1% to 50% are trying to do in place upgrades where for example Nova is upgrade, and Neutron later. But now Neutron has to work with the upgraded libraries from the Nova upgrade. * Should we support in-place upgrades? If we do, we need at least 1 or more versions of compatibility where Mitaka Nova can run Newton Oslo+client libraries. - If we don't support in-place upgrades, deployment methods must be architected to avoid ever encountering where a client or one of N services is going to be upgraded on a single python environment. All clients and services must be upgraded together on a single python environment or none. * If we decide to support in-place upgrades, we need to figure out how to test that effectively; its a linear growth with the number of stable releases we choose to support. * If we decide not to, we have no further requirement to have any cross-over compatibility between OpenStack releases. * We still have to be backwards compatible on individual changes. * Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-April/thread.html#93403 Installation Guide Plans for Newton === * Continuing from a previous Dev Digest [2], big tent is growing and our documentation team would like for projects to maintain their own installation documentation. This should be done while still providing quality in valid working installation information and consistency the team strives for. * The installation guide team held a session at the summit that was packed and walked away with some solid goals to achieve for Newton. * Two issues being discussed: - What to do with the existing install guide. - Create a way for projects to write installation documentation in their own repository. * All guides will be rendered from individual repositories and appear in docs.openstack.org. * The Documentation team has recommendations for projects writing their install guides: - Build on existing install guide architecture, so there is no reinventing the wheel. - Follow documentation conventions [3]. - Use the same theme called openstackdocstheme. - Use the same distributions as the install guide does. Installation from source is an alternative. - Guides should be versioned. - RST is the preferred documentation format. RST is also easy for translations. - Common naming scheme: “X Service Install Guide” - where X is your service name. * The chosen URL format is docs.openstack.org/project-install-guide/RELEASE/SERVICE. * Plenty of work items to follow [4] and volunteers are welcome! * Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-April/093475.html Proposed Revision To Magnum's Mission = * From a summit discussion, there was a proposed revision to Magnum's mission statement [5]. * The idea is to narrow the scope of Magnum to allow the team to focus on making popular container orchestration engines (COE) software work great with OpenStack. Allowing users to setup fleets of cloud capacity managed by COE's such as Swarm, Kubernetes, Mesos, etc. * Deprecate /containers resource from Magnum's API. Any new project may take on the goal of creating an API service that abstracts one or more COE's. * Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-April/093542.html Supporting the Go Programming Language == * The Swift community has a git branch feature/hummingbird that contains some parts of Swift reimplemented in Go. [6] * The goal is to have a reasonably read-to-merge feature branch ready by the Barcelona summit. Shortly after the summit, the plan is to merge the Go code into master. * An amended Technical Committee resolution will follow to suggest Go as a supported language in OpenStack projects [7]. * Some Technical Committee members have expressed wanting to see technical benefits that outweigh the community fragmentation and increase in infrastructure tasks that result from adding that language. * Some open questions: - How do we run unit tests? - How do we provide code coverage? - How do we manage dependencies? - How do we
[Openstack-operators] How are folks providing GPU instance types?
Hi All, Having trouble finding any current info on best practices for providing GPU instances. Most of what Google is feeding me is Grizzly or older. I'm currently on Kilo (Mitaka upgrade planned in 60-90 days) with Ubuntu14.04 and kvm hypervisor. Looking to add some NVidia GPUs but haven't invested in hardware yet. Presumably I'd be using host aggregates and instance metadata to separate these out from the general pool so not tied to kvm though it would be nice to have image compatibility across GPU and nonGPU instance types (this is currently 'raw' images in ceph rbd). Any pointers to good info online or general advice as I travel down this path? I suppose particularly urgent is any hardware caveats I need ot be aware of before I sink cash into the wrong thing (I'm presuming that the k10,k20,k40,k80 are all equivalent in this regard). -Jon -- ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Can I authenticate a Kilo service against an Icehouse identity server?
solved; I was hitting this bug:
https://bugs.launchpad.net/keystone/+bug/1343579
:)
On Mon, May 9, 2016 at 2:24 PM, Gustavo Randich
wrote:
> ok here is a little more log detail...
>
> 2016-05-09 13:18:53.246 8014 INFO eventlet.wsgi.server [-] (8014) accepted
> ('10.181.0.6', 35939)
> 2016-05-09 13:18:53.253 8014 DEBUG keystoneclient.session [-] REQ: curl -g
> -i --cacert "/etc/ssl/certs/cgp-cert.pem" -X GET
> https://icehouse-api:35357 -H "Accept: application/json" -H "User-Agent:
> python-keystoneclient" _http_log_request
> /usr/lib/python2.7/dist-packages/keystoneclient/session.py:195
> 2016-05-09 13:18:53.352 8014 DEBUG keystoneclient.session [-] RESP: [300]
> content-length: 350 vary: X-Auth-Token server: Apache/2.4.7 (Ubuntu) date:
> Mon, 09 May 2016 17:18:53 GMT content-type: application/json
> x-distribution: Ubuntu
> RESP BODY: {"versions": {"values": [{"status": "stable", "updated":
> "2013-03-06T00:00:00Z", "media-types": [{"base": "application/json",
> "type": "application/vnd.openstack.identity-v3+json"}, {"base":
> "application/xml", "type": "application/vnd.openstack.identity-v3+xml"}],
> "id": "v3.0", "links": [{"href": "https://icehouse-api:35357/v3/";, "rel":
> "self"}]}]}}
> _http_log_response
> /usr/lib/python2.7/dist-packages/keystoneclient/session.py:223
> 2016-05-09 13:18:53.353 8014 DEBUG keystoneclient.auth.identity.v3 [-]
> Making authentication request to https://icehouse-api:35357/v3/auth/tokens
> get_auth_ref
> /usr/lib/python2.7/dist-packages/keystoneclient/auth/identity/v3.py:125
> 2016-05-09 13:18:53.549 8014 DEBUG keystoneclient.session [-] REQ: curl -g
> -i --cacert "/etc/ssl/certs/cgp-cert.pem" -X GET
> https://icehouse-api:35357/ -H "Accept: application/json" -H "User-Agent:
> python-keystoneclient" _http_log_request
> /usr/lib/python2.7/dist-packages/keystoneclient/session.py:195
> 2016-05-09 13:18:53.574 8014 DEBUG keystoneclient.session [-] RESP: [300]
> content-length: 350 vary: X-Auth-Token server: Apache/2.4.7 (Ubuntu) date:
> Mon, 09 May 2016 17:18:53 GMT content-type: application/json
> x-distribution: Ubuntu
> RESP BODY: {"versions": {"values": [{"status": "stable", "updated":
> "2013-03-06T00:00:00Z", "media-types": [{"base": "application/json",
> "type": "application/vnd.openstack.identity-v3+json"}, {"base":
> "application/xml", "type": "application/vnd.openstack.identity-v3+xml"}],
> "id": "v3.0", "links": [{"href": "https://icehouse-api:35357/v3/";, "rel":
> "self"}]}]}}
> _http_log_response
> /usr/lib/python2.7/dist-packages/keystoneclient/session.py:223
> 2016-05-09 13:18:53.575 8014 WARNING keystonemiddleware.auth_token [-]
> Authorization failed for token
> 2016-05-09 13:18:53.576 8014 INFO eventlet.wsgi.server [-] 10.181.0.6 - -
> [09/May/2016 13:18:53] "GET /v2/ceaa212d5fe949d4b0319d28e8872ff0/volumes
> HTTP/1.1" 401 261 0.327230
>
>
> On Mon, May 9, 2016 at 1:56 PM, Gustavo Randich > wrote:
>
>> Hi,
>>
>> Is it possible to integrate python-keystoneclient as of Kilo release
>> (1.2.0) with keystone Icehouse (2014.1)?
>>
>> Specifically, I'm trying to make cinder-api (Kilo) authenticate against
>> an Icehouse keystone server, but the following appears in the log:
>>
>> 2016-05-09 12:55:06.846 7623 INFO eventlet.wsgi.server [-] (7623)
>> accepted ('10.181.0.6', 35909)
>>
>> 2016-05-09 12:55:06.851 7623 DEBUG keystoneclient.session [-] REQ: curl
>> -g -i --cacert "/etc/ssl/certs/cgp-cert.pem" -X GET
>> https://icehouse-api:35357 -H "Accept: application/json" -H "User-Agent:
>> python-keystoneclient" _http_log_request
>> /usr/lib/python2.7/dist-packages/keystoneclient/session.py:195
>>
>> 2016-05-09 12:55:06.866 7623 WARNING
>> keystoneclient.auth.identity.generic.base [-] Discovering versions from the
>> identity service failed when creating the password plugin. Attempting to
>> determine version from URL.
>>
>> 2016-05-09 12:55:06.867 7623 WARNING keystonemiddleware.auth_token [-]
>> Authorization failed for token
>>
>> 2016-05-09 12:55:06.868 7623 INFO eventlet.wsgi.server [-] 10.181.0.6 - -
>> [09/May/2016 12:55:06] "GET /v2//volumes/detail HTTP/1.1" 401 261 0.019666
>>
>>
>> Thanks!
>>
>>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Can I authenticate a Kilo service against an Icehouse identity server?
ok here is a little more log detail...
2016-05-09 13:18:53.246 8014 INFO eventlet.wsgi.server [-] (8014) accepted
('10.181.0.6', 35939)
2016-05-09 13:18:53.253 8014 DEBUG keystoneclient.session [-] REQ: curl -g
-i --cacert "/etc/ssl/certs/cgp-cert.pem" -X GET https://icehouse-api:35357
-H "Accept: application/json" -H "User-Agent: python-keystoneclient"
_http_log_request
/usr/lib/python2.7/dist-packages/keystoneclient/session.py:195
2016-05-09 13:18:53.352 8014 DEBUG keystoneclient.session [-] RESP: [300]
content-length: 350 vary: X-Auth-Token server: Apache/2.4.7 (Ubuntu) date:
Mon, 09 May 2016 17:18:53 GMT content-type: application/json
x-distribution: Ubuntu
RESP BODY: {"versions": {"values": [{"status": "stable", "updated":
"2013-03-06T00:00:00Z", "media-types": [{"base": "application/json",
"type": "application/vnd.openstack.identity-v3+json"}, {"base":
"application/xml", "type": "application/vnd.openstack.identity-v3+xml"}],
"id": "v3.0", "links": [{"href": "https://icehouse-api:35357/v3/";, "rel":
"self"}]}]}}
_http_log_response
/usr/lib/python2.7/dist-packages/keystoneclient/session.py:223
2016-05-09 13:18:53.353 8014 DEBUG keystoneclient.auth.identity.v3 [-]
Making authentication request to https://icehouse-api:35357/v3/auth/tokens
get_auth_ref
/usr/lib/python2.7/dist-packages/keystoneclient/auth/identity/v3.py:125
2016-05-09 13:18:53.549 8014 DEBUG keystoneclient.session [-] REQ: curl -g
-i --cacert "/etc/ssl/certs/cgp-cert.pem" -X GET https://icehouse-api:35357/
-H "Accept: application/json" -H "User-Agent: python-keystoneclient"
_http_log_request
/usr/lib/python2.7/dist-packages/keystoneclient/session.py:195
2016-05-09 13:18:53.574 8014 DEBUG keystoneclient.session [-] RESP: [300]
content-length: 350 vary: X-Auth-Token server: Apache/2.4.7 (Ubuntu) date:
Mon, 09 May 2016 17:18:53 GMT content-type: application/json
x-distribution: Ubuntu
RESP BODY: {"versions": {"values": [{"status": "stable", "updated":
"2013-03-06T00:00:00Z", "media-types": [{"base": "application/json",
"type": "application/vnd.openstack.identity-v3+json"}, {"base":
"application/xml", "type": "application/vnd.openstack.identity-v3+xml"}],
"id": "v3.0", "links": [{"href": "https://icehouse-api:35357/v3/";, "rel":
"self"}]}]}}
_http_log_response
/usr/lib/python2.7/dist-packages/keystoneclient/session.py:223
2016-05-09 13:18:53.575 8014 WARNING keystonemiddleware.auth_token [-]
Authorization failed for token
2016-05-09 13:18:53.576 8014 INFO eventlet.wsgi.server [-] 10.181.0.6 - -
[09/May/2016 13:18:53] "GET /v2/ceaa212d5fe949d4b0319d28e8872ff0/volumes
HTTP/1.1" 401 261 0.327230
On Mon, May 9, 2016 at 1:56 PM, Gustavo Randich
wrote:
> Hi,
>
> Is it possible to integrate python-keystoneclient as of Kilo release
> (1.2.0) with keystone Icehouse (2014.1)?
>
> Specifically, I'm trying to make cinder-api (Kilo) authenticate against an
> Icehouse keystone server, but the following appears in the log:
>
> 2016-05-09 12:55:06.846 7623 INFO eventlet.wsgi.server [-] (7623) accepted
> ('10.181.0.6', 35909)
>
> 2016-05-09 12:55:06.851 7623 DEBUG keystoneclient.session [-] REQ: curl -g
> -i --cacert "/etc/ssl/certs/cgp-cert.pem" -X GET
> https://icehouse-api:35357 -H "Accept: application/json" -H "User-Agent:
> python-keystoneclient" _http_log_request
> /usr/lib/python2.7/dist-packages/keystoneclient/session.py:195
>
> 2016-05-09 12:55:06.866 7623 WARNING
> keystoneclient.auth.identity.generic.base [-] Discovering versions from the
> identity service failed when creating the password plugin. Attempting to
> determine version from URL.
>
> 2016-05-09 12:55:06.867 7623 WARNING keystonemiddleware.auth_token [-]
> Authorization failed for token
>
> 2016-05-09 12:55:06.868 7623 INFO eventlet.wsgi.server [-] 10.181.0.6 - -
> [09/May/2016 12:55:06] "GET /v2//volumes/detail HTTP/1.1" 401 261 0.019666
>
>
> Thanks!
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Can I authenticate a Kilo service against an Icehouse identity server?
Hi,
Is it possible to integrate python-keystoneclient as of Kilo release
(1.2.0) with keystone Icehouse (2014.1)?
Specifically, I'm trying to make cinder-api (Kilo) authenticate against an
Icehouse keystone server, but the following appears in the log:
2016-05-09 12:55:06.846 7623 INFO eventlet.wsgi.server [-] (7623) accepted
('10.181.0.6', 35909)
2016-05-09 12:55:06.851 7623 DEBUG keystoneclient.session [-] REQ: curl -g
-i --cacert "/etc/ssl/certs/cgp-cert.pem" -X GET https://icehouse-api:35357
-H "Accept: application/json" -H "User-Agent: python-keystoneclient"
_http_log_request
/usr/lib/python2.7/dist-packages/keystoneclient/session.py:195
2016-05-09 12:55:06.866 7623 WARNING
keystoneclient.auth.identity.generic.base [-] Discovering versions from the
identity service failed when creating the password plugin. Attempting to
determine version from URL.
2016-05-09 12:55:06.867 7623 WARNING keystonemiddleware.auth_token [-]
Authorization failed for token
2016-05-09 12:55:06.868 7623 INFO eventlet.wsgi.server [-] 10.181.0.6 - -
[09/May/2016 12:55:06] "GET /v2//volumes/detail HTTP/1.1" 401 261 0.019666
Thanks!
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [Telco][NFV][Austin Summit] Telco/NFV Ops Working Group Session
Hi All, We had our working group session at the summit and it was well attended. During the session it seemed like the consensus was to have some meetings and explore what operators are doing in the telco/NFV space. I've setup an initial recurring meeting [1], and the first one is Wed, June 1st. There's an agenda etherpad as well [2], so if you think you can attend please fill out some things you'd like to talk about. My hope is to work on issues related to _operators_, like myself :), deploying and managing telco/nfv related deployments, be it in the lab or otherwise, and not to duplicate any work being done better by other groups. Thanks, Curtis. [1]: http://eavesdrop.openstack.org/#OpenStack_Operators_Telco_and_NFV_Working_Group [2]: https://etherpad.openstack.org/p/ops-telco-nfv-meeting-agenda On Tue, Apr 19, 2016 at 11:03 AM, Curtis wrote: > Hi, > > I've started to put together the etherpad [1] for the Telco/NFV Ops > Working Group Session [2] which is on Monday, April 25th from 4:40PM > to 6:10PM in MR-410. > > If you can attend, please take a few minutes to fill out some ideas > and topics for discussion, as well as other thoughts on how we can > create concrete actions from the session. :) > > Thanks, and looking forward to the session, > Curtis. > > [1]: https://etherpad.openstack.org/p/AUS-ops-NFV-Telco > [2]: https://www.openstack.org/summit/austin-2016/summit-schedule/events/9522 -- Blog: serverascode.com ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
