Re: [Openstack-operators] Nova

2016-09-06 Thread Jonathan D. Proulx 
On Fri, Sep 02, 2016 at 04:00:17PM -0700, Adam Lawson wrote:
:Mike that's just as I suspected. To be super clear, does KVM in particular
:know how to distinguish between Ubuntu v12 versus v16? In other words, do I
:need to be running a specific version of KVM hypervisor so it can host
:guests running the latest version of Ubuntu?

You'll be fine.  Paravirtualized Xen could run you into trouble but
KVM doesn't support paravirtualized cpu, just full virtualization so
it's completely agnostic about what you run on top.

I'm definitely running 16 and 12 ontop of 14, but also much weirder
things like Gnu-Herd, FreeBSD and  Windows...

-Jon

:
:Again, this was brought up as being a firm requirement but I've never ever
:heard of such a requirement unless we're debating KVM versus ESXi so I
:wanted to get my facts straight before I confirmed to the team one way or
:another.
:
://adam
:
:
:*Adam Lawson*
:
:AQORN, Inc.
:427 North Tatnall Street
:Ste. 58461
:Wilmington, Delaware 19801-2230
:Toll-free: (844) 4-AQORN-NOW ext. 101
:International: +1 302-387-4660
:Direct: +1 916-246-2072
:
:On Fri, Sep 2, 2016 at 1:53 PM, Mike Smith  wrote:
:
:> Hi Adam -
:>
:> The OS of the guest is independent of the Openstack version.  Your choice
:> of hypervisor (KVM, VMWare, HyperV, etc) would just need to support the OS
:> version that you want to run on your guests.
:>
:> Mike Smith
:> Lead Cloud Systems Architect
:> Overstock.com 
:>
:>
:>
:> On Sep 2, 2016, at 2:46 PM, Adam Lawson  wrote:
:>
:> Hey everyone, do specific versions of OpenStack necessitate specific
:> versions of guest os's? I.e. if I'm running a mitaka cloud platform, do the
:> guest vm operating systems need to be a specific version of Linux? My
:> understanding is the two are totally unrelated when the VM's are running
:> Linux but I wanted to check if things have recently changed without my
:> knowledge.
:>
:> //adam
:> ___
:> OpenStack-operators mailing list
:> OpenStack-operators@lists.openstack.org
:> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
:>
:>
:>
:> --
:>
:> CONFIDENTIALITY NOTICE: This message is intended only for the use and
:> review of the individual or entity to which it is addressed and may contain
:> information that is privileged and confidential. If the reader of this
:> message is not the intended recipient, or the employee or agent responsible
:> for delivering the message solely to the intended recipient, you are hereby
:> notified that any dissemination, distribution or copying of this
:> communication is strictly prohibited. If you have received this
:> communication in error, please notify sender immediately by telephone or
:> return email. Thank you.
:>

:___
: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] Default user timezone

2016-09-06 Thread William Josefsson 
Hi list,

My users created seem to by default have timezone UTC. I know there's
a default TIME_ZONE variable in
/etc/openstack_dashboard/local_settings, which I have been setting to
my local time zone. However my newly created users still get UTC
timezone by default.

Is there any variable to set the user default time zone? I'm on
Liberty/CentOS7. thx will

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

[Openstack-operators] [scientific][scientific-wg] Reminder: Scientific WG meeting Tuesday 2100 UTC

2016-09-06 Thread Stig Telfer 
Hi all - 

We have a Scientific WG IRC meeting on Tuesday at 2100 UTC on channel 
#openstack-meeting.

The agenda is available here[1] and full IRC meeting details are here[2].

This week we will be updating everyone with progress on WG activities planned 
for the Barcelona summit and also Supercomputing 2016.  I’ll also have an 
update on the OpenStack/HPC white papers.

If anyone would like to add an item for discussion on the agenda, it is also 
available in an etherpad[3].

Best wishes,
Stig

[1] 
https://wiki.openstack.org/wiki/Scientific_working_group#IRC_Meeting_September_6th_2016
[2] http://eavesdrop.openstack.org/#Scientific_Working_Group
[3] https://etherpad.openstack.org/p/Scientific-WG-next-meeting-agenda
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [telecom-nfv] Ops team meeting #8 tomorrow

2016-09-06 Thread Curtis 
Hi All,

Our bi-weekly meeting will be tomorrow [1]. Now that summer is almost
over, back to work. :) Hope to see you there. I've started filling out
an agenda [2], feel free to add anything.

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

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

Re: [Openstack-operators] ElasticSearch on OpenStack

2016-09-06 Thread Randall, Nathan X 
Tim,

For the storage backing Elasticsearch data nodes, we have been using one 500GB 
Cinder volume (backed by a Ceph cluster built from DL380s filled with 1.2TB 10k 
SAS drives) per data node. However, we've found that a VM with 8 vCPU and 64GB 
RAM can make use of more than 500GB disk capacity without bottlenecking on CPU 
or memory, so we are experimenting with 1TB or 1.5TB options per data node. We 
are also moving to a different tier of storage that uses an array of SSDs 
instead of spinning rust, though this change has very little to do with 
performance and very much to do with the automatic deduplication, compression, 
and encryption offered by the hardware backend (Solidfire) for that storage 
tier.  # <-- Not a vendor promo; just letting you know what we're using for 
that tier.

We get a lot of duplicated messages in Elasticsearch since we're using if for 
log monitoring, and JSON documents compress very well... so it actually costs 
us significantly less to leverage a storage hardware platform that provides 
native deduplication and compression. Having SSDs in the mix probably helps 
reduce latency a bit (due to lower seek times), but honestly we didn't have 
enough of a latency problem to justify moving away from volumes backed by Ceph.

Guidance from Elastic is always going to advocate using local SSDs when 
possible, but I'm pretty sure that's not what Elastic uses for their own cloud 
offering...

Thanks,
Nathan Randall

From: Tim Bell mailto:tim.b...@cern.ch>>
Date: Saturday, September 3, 2016 at 1:12 AM
To: David Medberry mailto:openst...@medberry.net>>
Cc: openstack-operators 
mailto:openstack-operators@lists.openstack.org>>
Subject: Re: [Openstack-operators] ElasticSearch on OpenStack

Thanks. How's the storage handled ?

We're seeing slow I/O on local storage (which is also limited on space) and 
latencies with Ceph for block storage.

Tim

From: mailto:medbe...@gmail.com>> on behalf of David 
Medberry mailto:openst...@medberry.net>>
Date: Friday 2 September 2016 at 22:18
To: Tim Bell mailto:tim.b...@cern.ch>>
Cc: openstack-operators 
mailto:openstack-operators@lists.openstack.org>>
Subject: Re: [Openstack-operators] ElasticSearch on OpenStack

Nathan: The page at 
https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html 
gives you good advice on a maximum size for the elasticsearch VM's memory.

Nathan: suggest you pick a flavor with 64GB RAM or less, then base other sizing 
things off of that (i.e. choose a flavor with 64GB of RAM and as many CPUs as 
possible for that RAM allocation, then base disk size on testing of your use 
case)

Nathan: give java heap 30GB, and leave the rest of the memory to the OS 
filesystem cache so that Lucene can make best use of it.

Nathan: that's mostly it for tuning. elasticsearch publishes many other docs 
for tuning recommendations, but there isn't anything specific to openstack 
besides the flavor choice. i personally chose CPU size (8CPU) such that all 
vCPUs for each VM would fit on a single NUMA node, which is a best practice for 
ESXi but not sure if it applies to KVM.

(resending for clarity)

On Fri, Sep 2, 2016 at 6:46 AM, David Medberry 
mailto:openst...@medberry.net>> wrote:
Hey Tim,
We've just started this effort. I'll see if the guy running the service can 
comment today.

On Fri, Sep 2, 2016 at 6:36 AM, Tim Bell 
mailto:tim.b...@cern.ch>> wrote:

Has anyone had experience running ElasticSearch on top of OpenStack VMs ?

Are there any tuning recommendations ?

Thanks
Tim

___
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] ElasticSearch on OpenStack

2016-09-06 Thread Jeremy Stanley 
On 2016-09-06 17:49:08 + (+), Randall, Nathan X wrote:
> For the storage backing Elasticsearch data nodes, we have been
> using one 500GB Cinder volume (backed by a Ceph cluster built from
> DL380s filled with 1.2TB 10k SAS drives) per data node. However,
> we've found that a VM with 8 vCPU and 64GB RAM can make use of
> more than 500GB disk capacity without bottlenecking on CPU or
> memory, so we are experimenting with 1TB or 1.5TB options per data
> node.
[...]

As a point of comparison, the 6 ES cluster members OpenStack Infra
is using are a 60GiB RAM/16 vCPU flavor in Rackspace's DFW region
and each of them has a 1TiB Cinder SATA volume formatted ext4 (~50%
full). You can see system utilization metrics for one of those at
http://cacti.openstack.org/cacti/graph_view.php?action=tree&tree_id=1&leaf_id=123
(though we're apparently missing a graph for the
/var/lib/elasticsearch filesystem).
-- 
Jeremy Stanley

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

[Openstack-operators] 转发：Error on sync keystone to mysql db

2016-09-06 Thread fengyan1732 
Hi Everyone, I'm trying to install identify service on Ubuntu 16.04 LTS. The 
guide I use: 
http://docs.openstack.org/mitaka/install-guide-ubuntu/keystone-install.htmlWhen 
I input this command:"su -s /bin/sh -c "keystone-manage db_sync" keystone", it 
report error below: 2016-09-06 19:01:07.303 4905 CRITICAL keystone [-] 
KeyError: 'connection' 2016-09-06 19:01:07.303 4905 ERROR keystone Traceback 
(most recent call last): 2016-09-06 19:01:07.303 4905 ERROR keystone   File 
"/usr/bin/keystone-manage", line 10, in 2016-09-06 19:01:07.303 4905 
ERROR keystone sys.exit(main()) 2016-09-06 19:01:07.303 4905 ERROR keystone 
  File "/usr/lib/python2.7/dist-packages/keystone/cmd/manage.py", line 47, in 
main 2016-09-06 19:01:07.303 4905 ERROR keystone cli.main(argv=sys.argv, 
config_files=config_files) 2016-09-06 19:01:07.303 4905 ERROR keystone   File 
"/usr/lib/python2.7/dist-packages/keystone/cmd/cli.py", line 992, in main 
2016-09-06 19:01:07.303 4905 ERROR keystone CONF.command.cmd_class.main() 
2016-09-06 19:01:07.303 4905 ERROR keystone   File 
"/usr/lib/python2.7/dist-packages/keystone/cmd/cli.py", line 371, in main 
2016-09-06 19:01:07.303 4905 ERROR keystone 
migration_helpers.sync_database_to_version(extension, version) 2016-09-06 
19:01:07.303 4905 ERROR keystone   File 
"/usr/lib/python2.7/dist-packages/keystone/common/sql/migration_helpers.py", 
line 210, in sync_database_to_version 2016-09-06 19:01:07.303 4905 ERROR 
keystone _sync_common_repo(version) 2016-09-06 19:01:07.303 4905 ERROR 
keystone   File 
"/usr/lib/python2.7/dist-packages/keystone/common/sql/migration_helpers.py", 
line 132, in _sync_common_repo 2016-09-06 19:01:07.303 4905 ERROR keystone 
with sql.session_for_write() as session: 2016-09-06 19:01:07.303 4905 ERROR 
keystone   File "/usr/lib/python2.7/contextlib.py", line 17, in __enter__ 
2016-09-06 19:01:07.303 4905 ERROR keystone return self.gen.next() 
2016-09-06 19:01:07.303 4905 ERROR keystone   File 
"/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line 
759, in _transaction_scope 2016-09-06 19:01:07.303 4905 ERROR keystone 
allow_async=self._allow_async) as resource: 2016-09-06 19:01:07.303 4905 ERROR 
keystone   File "/usr/lib/python2.7/contextlib.py", line 17, in __enter__ 
2016-09-06 19:01:07.303 4905 ERROR keystone return self.gen.next() 
2016-09-06 19:01:07.303 4905 ERROR keystone   File 
"/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line 
491, in _session 2016-09-06 19:01:07.303 4905 ERROR keystone 
bind=self.connection, mode=self.mode) 2016-09-06 19:01:07.303 4905 ERROR 
keystone   File 
"/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line 
272, in _create_session 2016-09-06 19:01:07.303 4905 ERROR keystone 
self._start() 2016-09-06 19:01:07.303 4905 ERROR keystone   File 
"/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line 
337, in _start 2016-09-06 19:01:07.303 4905 ERROR keystone 
url_args['connection'], 2016-09-06 19:01:07.303 4905 ERROR keystone KeyError: 
'connection' 2016-09-06 19:01:07.303 4905 ERROR keystone I don't know how to 
triage and fix this problem, would you like to help me?___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators