Re: [Openstack-operators] [nova] Do you use os-instance-usage-audit-log?

[Matt Riedemann]

On 1/11/2017 5:09 PM, Matt Riedemann wrote:


That table is populated in a periodic task from all computes that have
it enabled and by default it 'audits' instances created in the last
month (the time window is adjustable via the
'instance_get_active_by_window_joined' config option).



Oops, I meant the time window is adjustable via the 
'instance_usage_audit_period' config option.


--

Thanks,

Matt Riedemann


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

[Openstack-operators] [nova] Do you use os-instance-usage-audit-log?

[Matt Riedemann]

Nova's got this REST API [1] which pulls task_log data from the nova 
database if the 'instance_usage_audit' config option value is True on 
any compute host.


That table is populated in a periodic task from all computes that have 
it enabled and by default it 'audits' instances created in the last 
month (the time window is adjustable via the 
'instance_get_active_by_window_joined' config option).


The periodic task also emits a 'compute.instance.exists' notification 
for each instance on that compute host which falls into the audit 
period. I'm fairly certain that notification is meant to be consumed by 
Ceilometer which is going to store it in it's own time-series database.


It just so happens that Nova is also storing this audit data in it's own 
database, and never cleaning it up - the only way in-tree to move that 
data out of the nova.task_log table is to archive it into shadow tables, 
but that doesn't cut down on the bloat in your database. That 
os-instance-usage-audit-log REST API is relying on the nova database though.


So my question is, is anyone using this in any shape or form, either via 
the Nova REST API or Ceilometer? Or are you using it in one form but not 
the other (maybe only via Ceilometer)? If you're using it, how are you 
controlling the table growth, i.e. are you deleting records over a 
certain age from the nova database using a cron job?


Mike Bayer was going to try and find some large production data sets to 
see how many of these records are in a big and busy production DB that's 
using this feature, but I'm also simply interested in how people use 
this, if it's useful at all, and if there is interest in somehow putting 
a limit on the data, i.e. we could add a config option to nova to only 
store records in the task_log table under a certain max age.


[1] 
http://developer.openstack.org/api-ref/compute/#server-usage-audit-log-os-instance-usage-audit-log


--

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] [openstack-dev] [nova] [placement] Which service is using port 8778?

[Chris Dent]

On Tue, 10 Jan 2017, Mohammed Naser wrote:


We use virtual hosts, haproxy runs on our VIP at port 80 and port
443 (SSL) (with keepalived to make sure it’s always running) and
we use `use_backend` to send to the appropriate backend, more
information here:

http://blog.haproxy.com/2015/01/26/web-application-name-to-backend-mapping-in-haproxy/


Thanks for writing about this, the way you're doing things is
deliciously sane. When this discussion initially came up I was
surprised to hear that people were deploying with any correspondence
between what they had in the service catalog and the explicit
(internal) hosts and (internal) ports on which they were deploying
the services. Your model is what I've been assuming people would
(and actually) do:

* host the WSGI applications somewhere (anywhere)
* have front end proxies / load balancers/ HA services dispatching
  to those backends based on either host name or a prefix on the URL

This means that what shows up for the configured listening host and
port in somewhere like puppet-placement's actual installation of the
service is very likely completely different from what shows up in
whatever is writing the service catalog.


It makes our catalog nice and neat, we have a
-.vexxhost.net  internal
naming convention, so our catalog looks nice and clean and the API
calls don’t get blocked by firewalls (the strange ports might be
blocked on some customer-side firewalls).


[catalog snipped]


I’d be more than happy to give my comments, but I think this is
the best way.  Prefixes can work too and would make things easy
during dev, but in a production deployment, I would rather not
deal with something like that.  Also, all of those are CNAME
records pointing to api-.vexxhost.net
 so it makes it easy to move things over if
needed.  I guess the only problem is DNS setup overhead


The reason for starting to use prefixes in devstack has been because
it is easy to manage when there's just the one running apache and
modifying the /etc/hosts table was not considered. Since this topic
came up there's been discussion of adding hosts (for each service)
to /etc/hosts as a way of allowing different virtual hosts for each
service, all on the same port. This allows for the desired
cleanliness and preserves different log files for each service (when
using prefixes, it is harder to manage the error logs).

These concerns that are present in devstack don't apply in "real"
installations where having a reverse proxy of some kind is the norm.

So to bring this back round to puppet and ports: Should puppet be
expressing a default port at all? It really depends on whether the
intention is to allow multiple services to run in the same server on
the same host, how logging is being managed, whether apache is being
used, etc.

Should each service have a prescribed default port to avoid
collisions? I think not. I think the ports that the services run on,
as exposed to the users, should always be 80 and 443 (so no need to
define a port, just a scheme) and the internal ports, if necessary,
should be up to the deployer and their own internal plans. If we
define a default port, people will use it and expose it to users.

imho, iana(deployer), ymmv, etc

--
Chris Dent ¯\_(ツ)_/¯   https://anticdent.org/
freenode: cdent tw: @anticdent___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Mitaka to Newton Provider network issues

[Saverio Proto]

Hello,
in the upgrade did the version of ovs change ?

what Openstack distribution are you using ?

thanks

Saverio


2017-01-10 16:30 GMT+01:00 Telmo Morais :
>
> Hi All,
>
> We are currently on the process of upgrading from Mitaka to Newton, and on
> the upgraded compute nodes we lost all connectivity on provider networks.
>
> After digging through the ovs and ovs agent, we found that if we have only
> ONE provider network configured everything works as expected. But as soon as
> we add more providers networks in the config files we lose connectivity in
> them all. We also noticed that some flows in ovs are created, probably not
> all of them, as it doesn't work.
>
> Anyone has seen this behavior before?
>
> PS: no changes to the config were made during the upgrade.
>
> Thanks.
>
> Telmo Morais
>
> ___
> 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] [cinder]Can I run cinder-volume and cinder-backup on a same host?

[Rikimaru Honjo]

Hi All,

I have a question about cinder.
Can I run cinder-volume and cinder-backup on a same host?

I use a cinder driver that uses iscsi protocol.
I afraid that iscsi operations will be conflicted between cinder-volume and 
cinder-backup.

e.g.(Caution: This is just a forecast.)
If cinder-backup execute "iscsiadm -rescan" while cinder-volume is terminating 
connection,
the iscsi connection will remain unexpectedly.

Is there a model architecture?
Please share knowledge if you have it.
--
Rikimaru Honjo
honjo.rikim...@po.ntts.co.jp


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