Re: [Openstack] [OpenStack] Can Mitaka RamFilter support free hugepages?

[Weichih Lu]

Thanks for your response.

Is this mean if I want to create an instance with flavor: 16G memory
(hw:mem_page_size=large),
I need to preserve memory more than 16GB ?
This instance consume hugepages resource.

2017-09-06 1:47 GMT+08:00 Jay Pipes :

> Please remember to add a topic [nova] marker to your subject line. Answer
> below.
>
> On 09/05/2017 04:45 AM, Weichih Lu wrote:
>
>> Dear all,
>>
>> I have a compute node with 64GB ram. And I set 50 hugepages wiht 1GB
>> hugepage size. I used command "free", it shows free memory is about 12GB.
>> And free hugepages is 50.
>>
>
> Correct. By assigning hugepages, you use the memory allocated to the
> hugepages.
>
> Then I launch an instance with 16GB memory, set flavor tag :
>> hw:mem_page_size=large. It show Error: No valid host was found. There are
>> not enough hosts available.
>>
>
> Right, because you have only 12G of RAM available after
> creating/allocating 50G out of your 64G.
>
> Huge pages are entirely separate from the normal memory that a flavor
> consumes. The 16GB memory in your flavor is RAM consumed on the host. The
> huge pages are individual things that are consumed by the NUMA topology
> that your instance will take. RAM != huge pages. Totally different things.
>
>  And I check nova-scheduler log. My
>
>> compute is removed by RamFilter. I can launch an instance with 8GB memory
>> successfully, or I can launch an instance with 16GB memory sucessfully by
>> remove RamFilter.
>>
>
> That's because RamFilter doesn't deal with huge pages. Because huge pages
> are a different resource than memory. The page itself is the resource.
>
> The NUMATopologyFilter is the scheduler filter that evaluates the huge
> page resources on a compute host and determines if the there are enough
> *pages* available for the instance. Note that I say *pages* because the
> unit of resource consumption for huge pages is not MB of RAM. It's a single
> memory page.
>
> Please read this excellent article by Steve Gordon for information on what
> NUMA and huge pages are and how to use them in Nova:
>
> http://redhatstackblog.redhat.com/2015/09/15/driving-in-the-
> fast-lane-huge-page-support-in-openstack-compute/
>
> Best,
> -jay
>
> Does RamFilter only check free memory but not free hugepages?
>> How can I solve this problem?
>>
>> I use openstack mitaka version.
>>
>> thanks
>>
>> WeiChih, Lu.
>>
>> Best Regards.
>>
>>
>> ___
>> Mailing list: http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>>
>>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> k
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> k
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [Ceilometer][Gnocchi] Ocata - Ceilometer with Gnocchi

[Adhi Priharmanto]

Hi all,

I'm trying to add telemetry into my running openstack, as I read at

https://docs.openstack.org/project-install-guide/
telemetry/ocata/get_started.html

ceilometer now using gnocchi as backend, so I dig more reference for easily
installed gnocchi on my openstack environment, and I found about
openstack-gnocchi-* package from the openstack repo .

I'm installed gnocchi & ceilometer services at a node separate from
controller node, this node have IP 192.168.26.10, so I create metric
endpoint using this IP address.

then I'm using gnocchi from openstack repo , and here my gnocchi config

[DEFAULT]
> log_dir = /var/log/gnocchi/
> verbose = true
> transport_url = rabbit://openstack:my_passw...@ct-oc-srg.adhi
> [api]
> auth_mode = keystone
> [archive_policy]
> default_aggregation_methods = mean,min,max,sum,std,median,count,last,95pct
> [cors]
> [cors.subdomain]
> [database]
> connection = mysql+pymysql://gnocchi:my_passw...@ct-oc-srg.adhi/gnocchi
> [healthcheck]
> [incoming]
> [indexer]
> url = mysql+pymysql://gnocchi:my_passw...@ct-oc-srg.adhi/
> gnocchi?charset=utf8
> driver = sqlalchemy
> [metricd]
> [oslo_middleware]
> [oslo_policy]
> [statsd]
> resource_id = 70de8fd2-7619-4c70-bb4e-6628fe1aa68e
> user_id =
> project_id =
> archive_policy_name = low
> [storage]
> driver = file
> file_basepath = /var/lib/gnocchi
> coordination_url = file:///var/lib/gnocchi/locks
> [keystone_authtoken]
> auth_uri = http://ct-oc-srg.adhi:5000
> auth_url = http://ct-oc-srg.adhi:35357/v3
> auth_type = password
> memcached_servers = ct-oc-srg.adhi:11211
> project_domain_name = default
> user_domain_name = default
> project_name = service
> username = gnocchi
> password = MY_PASSWORD
> interface = internalURL
> region_name = RegionOne


according from the guide above, we just using
openstack-ceilometer-notification.service
openstack-ceilometer-central.service openstack-ceilometer-collector.service
, this is my ceilometer config

[DEFAULT]
> verbose = true
> meter_dispatchers = gnocchi
> event_dispatchers = gnocchi
> transport_url = rabbit://openstack:my_passw...@ct-oc-srg.adhi
> [api]
> [collector]
> [compute]
> [coordination]
> [cors]
> [cors.subdomain]
> [database]
> [dispatcher_file]
> [dispatcher_gnocchi]
> url = http://192.168.26.10:8041
> filter_service_activity = true
> archive_policy = low
> resources_definition_file = gnocchi_resources.yaml
> filter_project = service
> [dispatcher_http]
> [event]
> [hardware]
> [ipmi]
> [keystone_authtoken]
> auth_uri = http://ct-oc-srg.adhi:5000
> auth_url = http://ct-oc-srg.adhi:35357
> memcached_servers = ct-oc-srg.adhi:11211
> auth_type = password
> project_domain_name = default
> user_domain_name = default
> project_name = service
> username = ceilometer
> password = MY_PASSWORD
> [matchmaker_redis]
> [meter]
> [notification]
> store_events = false
> [oslo_concurrency]
> [oslo_messaging_amqp]
> [oslo_messaging_kafka]
> [oslo_messaging_notifications]
> [oslo_messaging_rabbit]
> [oslo_messaging_zmq]
> [oslo_middleware]
> [oslo_policy]
> [polling]
> [publisher]
> [publisher_notifier]
> [rgw_admin_credentials]
> [service_credentials]
> auth_type = password
> auth_url = http://ct-oc-srg.adhi:5000
> project_domain_name = default
> user_domain_name = default
> project_name = service
> username = ceilometer
> password = MY_PASSWORD
> interface = internalURL
> region_name = RegionOne
> [service_types]
> [storage]
> [vmware]
> [xenapi]



While doing ceilometer-upgrade --skip-metering-database, it's look no
problem. When I look into the gnocchi database on mysql , I can see some
tables add into the gnocchi database.

the problem comes when I start the ceilometer services, specially with logs
from ceilometer collector, I've got this error :

2017-09-05 16:03:40.808 23012 ERROR ceilometer.dispatcher.gnocchi [-] A
server error occurred.  Please contact the administrator. (HTTP 500)

I also got this error when I reboot an instance. I also can get measure
from the image download like describe in the guide above, can somebody help
me ?

-- 
Cheers,



[image: --]
Adhi Priharmanto
[image: http://]about.me/a_dhi

+62-812-82121584
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [all] [oslo] schedule for Denver PTG is ready !

[Lance Bragstad]

Thanks! That should work. We have a couple things set up with the
baremetal/VM SIG [0] during that time, but I don't think there is a set
schedule for that SIG anyway. We should be able to go through some of those
topics on Tuesday if we don't get to them on Monday.

[0] https://etherpad.openstack.org/p/keystone-queens-ptg

On Tue, Sep 5, 2017 at 7:25 AM, ChangBo Guo  wrote:

> Lance,  I just update the schedule in [1] and add your new proposal topic
> in the schedule, kindly let me know when you're available, then we can
> rearrange your topics if you still have conflicts :-)
>
> [1] https://etherpad.openstack.org/p/oslo-ptg-queens
>
> 2017-09-02 6:16 GMT+08:00 Lance Bragstad :
>
>> Thanks for the schedule! I should be somewhat available Monday afternoon
>> for the policy deprecation discussion. The only conflict that might come up
>> for me is with the Baremetal/VM group [0]. Keystone has a few topics to
>> iron out there, but I'm not exactly sure when that group plans to talk
>> about those things. Also, I proposed another oslo spec detailing some
>> additional policy work [1]. Let me know if you have thoughts, or would like
>> to discuss it in Denver.
>>
>> [0] https://etherpad.openstack.org/p/keystone-queens-ptg
>> [1] https://review.openstack.org/#/c/500207/
>>
>>
>> On 08/28/2017 09:44 PM, ChangBo Guo wrote:
>>
>> sure, will adjust the schedule
>>
>> 2017-08-29 2:24 GMT+08:00 Doug Hellmann :
>>
>>> Excerpts from ChangBo Guo's message of 2017-08-28 23:14:05 +0800:
>>> > Please check  for the draft in [1], we can adjust if you have conflicts
>>> > with other discussions.
>>> >
>>> > We have specific cross projects coding event  in the Tuesday
>>> afternoon, for
>>> > more details please
>>> > check [2] and [3],  please join us if you're free from 1:00 PM to 3:
>>> PM on
>>> > Tuesday.
>>> >
>>> > [1] https://etherpad.openstack.org/p/oslo-ptg-queens
>>> > [2]
>>> > http://lists.openstack.org/pipermail/openstack-dev/2017-Augu
>>> st/121345.html
>>> > [3] https://etherpad.openstack.org/p/oslo-queens-tasks
>>> >
>>>
>>> I think we can drop the discussion of retiring oslosphinx from the
>>> schedule. We had no objections, and the way forward is clear (see the
>>> other thread [4] for details).
>>>
>>> Doug
>>>
>>> [4] http://lists.openstack.org/pipermail/openstack-dev/2017-Augu
>>> st/121564.html
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> ChangBo Guo(gcb)
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> ChangBo Guo(gcb)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [OpenStack-Infra] [zuul] v3 UI enquiry

[James E. Blair]

Darragh Bailey  writes:

> Hi,
>
> Currently the main issue from end users, is the user experience around the
> UI when looking at job results once the run is complete, and to a lesser
> extend looking at your jobs in the zuul status page when running.
>
> I'm wondering if there is a plan to have a full UI covering both historical
> job runs for projects as well as live status reporting?

Yes, Tristan has started work on that, and we plan to continue it after
we migrate openstack to Zuul v3.

> I've noticed there is an SQL reporter, should that be leveraged to provide
> access to the sort of information that needs to be tracked? Or should
> something else be used such as simple files to identify success/failure?

Yes, we plan on using it to supply the historical data.

> 1) Project status view:
>
> The main status page can be useful for those supporting zuul in an
> environment to have a quick overview of everything, however feedback we've
> received locally suggests most developers are frequently only interested in
> a single project and find this to be overwhelming This suggests there
> should be a per-project status view, showing only the pipelines and changes
> of interest for a single project, along with any CRD that are linked.
>
> Possibly under an endpoint of "//" as the default view showing any
> pipelines relevant to the project along with any changes going through them.

That sounds reasonable once we have the new web framework in place.

> 2) Project build history view:
>
> Returning links at the end of a run in a comment to the raw log files as
> the only build history is somewhat jarring for people used to the
> Travis/Drone/Circle CI services available, there's the expectation that it
> should be easily to see the previous runs, seeing whether they passed,
> which jobs within a set failed, and to display the detailed log when
> desired. Providing a reasonable UI is becoming a pre-requisite for
> adoption, no matter how good the functionality, it can be difficult to get
> acceptance if the "form" is deemed limiting (non all follow this, but it
> does seem that some of the most vocal objectors can fall into this area).

I'm a little confused by this one.  I agree they should be available,
but I think they already are.  Zuul currently provides (in a comment, as
you say) the overall pass/fail status of the build set, the pass/fail
status of individual jobs, that same information for previous runs on
the change, and links to the detailed logs.  In Github, the presentation
of that available to us is somewhat limited, but I think in Zuul v3
we're approaching a reasonable compromise.  Note this may be
significantly different that what you are running.

If you're suggesting that there should *also* be a way to find that
information from a main Zuul web page, yes, I think that would be
covered by the previous point.

I would like to point out though that Zuul's primary user interface
always has been, and will continue to be, the code review system.
That's on purpose.  The recognition that a developer should have all the
information about a change, including test results, at their fingertips
is one of the earliest innovations in Zuul; only now are facilities
appearing in Github *and* Gerrit to support this the way we've always
wanted.  The web interface will be a complement, not a replacement, for
this.  That doesn't mean the on-change reporting is frozen, we will
happily continue to improve the UX there (especially with the new tools
available to us).

> 3) Change view
>
> Users of tools such as GitHub are expecting a link to appear on the PR
> status checks that can then be followed to see the state of the job(s)
> currently executing. Currently this can be enabled through setting of a
> config option "status_url_with_change" in the zuul section. This can also
> be used with Gerrit making it easy to quickly see a single change.

That config option does not appear in my tree.  However, I believe the
Github support in Zuul v3 already supports what you describe.

> Are these of any interest?
>
> I'm no UI expert, so I'm just identifying some of the pieces that we hear
> feedback over and hoping that if I can help get the necessary information
> exposed and appearing at the right places someone else might know how to
> make it look nice..

Thanks for the use cases.  I think what you're looking for is not
radically different than the rest of the team.  It may be helpful for
you to start testing Zuul v3, as I think some of the areas you're
finding rough edges are different there.  Once you do so, I'm sure I and
others will be happy to help work out any remaining issues.

Expect effort on the historical web interface and rest API to begin
after OpenStack migrates to Zuul v3.  It'd be great if you can pitch in
on that with either reviews or code once we get going.  None of us
describe ourselves as javascript developers, so we aim to keep that area
pretty accessible.

-Jim

Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

[Waines, Greg]

That worked :)
Thanks a lot Ifat.

I see the cpu alarm reported in vitrage now :).
( and in the /tmp/python-notifications.dump file that volodomyr helped me with )

Only final issue is that the vitrage alarm does not clear when I see the clear 
notification ( ? severity 4 ? )in /tmp/python-notifications.dump.
I waited about 10 mins ... in case there was some hysteresis or something.

I am using a late version of ocata.

in /tmp/python-notifications.dump:
host: devstack-vitrage
plugin: cpu
plugin_instance: 0
type: percent
type_instance: idle
time: 1504655183.27
severity: 1
message: Host devstack-vitrage, plugin cpu (instance 0) type percent (instance 
idle): Data source "value" is currently 0.00. That is below the failure 
threshold of 20.00.



host: devstack-vitrage
plugin: cpu
plugin_instance: 0
type: percent
type_instance: idle
time: 1504655228.27
severity: 4
message: Host devstack-vitrage, plugin cpu (instance 0) type percent (instance 
idle): All data sources are within range again. Current value of "value" is 
96.306246.

// 20 minutes later ,,, still see
stack@devstack-vitrage:~/devstack$ vitrage alarm list --max-width 80
++--+--+---+-+-+--+--+
| vitrage_id | vitrage_type | name | vitrage_resource_type | 
vitrage_resource_id | vitrage_aggregated_severity | 
vitrage_operational_severity | update_timestamp |
++--+--+---+-+-+--+--+
| af0cd49f-8 | collectd | Host dev | nova.host | 
a7bca8d3-c84f-46cd- | FAILURE | CRITICAL
 | 2017-09-05T23:46 |
| d02-4173-8 |  | stack-   |   | 
a8db-cccab2851660   | | 
 | :23Z |
| b56-37e19e |  | vitrage, |   |
 | |  | 
 |
| cf7dfb |  | plugin   |   |
 | |  | 
 |
||  | cpu (ins |   |
 | |  | 
 |
||  | tance 0) |   |
 | |  | 
 |
||  | type |   |
 | |  | 
 |
||  | percent  |   |
 | |  | 
 |
||  | (instanc |   |
 | |  | 
 |
||  | e idle): |   |
 | |  | 
 |
||  | Data |   |
 | |  | 
 |
||  | source   |   |
 | |  | 
 |
||  | "value"  |   |
 | |  | 
 |
||  | is curre |   |
 | |  | 
 |
||  | ntly 0.0 |   |
 | |  | 
 |
||  | 0.   |   |
 | |  | 
 |
||  | That is  |   |
 | |  | 
 |
||  | below|   |
 | |  | 
 |
||  | the  |   |
 | |  | 
 |
||  | failure  |   |
 | | 

Re: [openstack-dev] [ironic] Team dinner at the PTG?

[Ruby Loo]

Thanks Julia, for taking this on. I'm actually fine if we take a cab to
wherever, it seems like the PTG is in some sort of 'dead' zone wrt great
food for large groups :-(  Having said that, stapleton-caseys works for me,
especially if they take reservations.

My personal preference is for sushi since I love that. However, I would bet
that I am the anomaly there and that most folks would prefer
stapleton-caseys even if they don't speak up :)

--ruby

On Mon, Sep 4, 2017 at 11:23 AM, Julia Kreger 
wrote:

> I did some searching around yesterday near the venue for places to
> eat. The area is very spread out, but
> http://coloradopubco.com/stapleton-caseys/ is with-in walking
> distance. I spoke with some of the staff, and they said they were good
> with large groups, and that Mondays is somewhat hit or miss regarding
> being busy or not.
>
> I've been thinking it might be best for us to descend upon the bar,
> and kind of go from there, but I'll call and see if they they can do
> reservations. That being said, the space really doesn't lend it's self
> to a large reservation. There is also a sushi restaurant next door as
> an alternative.
>
> -Julia
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] pingtest vs tempest

[Emilien Macchi]

On Wed, Apr 5, 2017 at 1:49 PM, Emilien Macchi  wrote:
[...]

> == Solutions
>
> 1) Switch pingtest to Tempest run on some specific tests, with feature
> parity of what we had with pingtest.
> For example, we could imagine to run the scenarios that deploys VM and
> boot from volume. It would test the same thing as pingtest (details
> can be discussed here).
> Each scenario would run more tests depending on the service that they
> run (scenario001 is telemetry, so it would run some tempest tests for
> Ceilometer, Aodh, Gnocchi, etc).
> We should work at making the tempest run as short as possible, and the
> close as possible from what we have with a pingtest.
[...]

4 months later :-)

We enabled Tempest on the following jobs:

gate-tripleo-ci-centos-7-scenario001-multinode-oooq-container
gate-tripleo-ci-centos-7-scenario002-multinode-oooq-container
gate-tripleo-ci-centos-7-scenario003-multinode-oooq-container
gate-tripleo-ci-centos-7-scenario004-multinode-oooq-container

gate-tripleo-ci-centos-7-scenario001-multinode-oooq
gate-tripleo-ci-centos-7-scenario002-multinode-oooq
gate-tripleo-ci-centos-7-scenario003-multinode-oooq
gate-tripleo-ci-centos-7-scenario004-multinode-oooq

gate-tripleo-ci-centos-7-nonha-multinode-oooq
gate-tripleo-ci-centos-7-containers-multinode

It has a feature parity with what pingtest did.
For example, scenario001 (focused on Telemetry) test boot from volume
and the whole autoscsaling scenario from Telemetry services, so we can
test end-to-end that our users can deploy autocsaling apps using
OpenStack.

We run Tempest on stable/pike and master, and still run pingtest on
stable/newton and stable/ocata (no change is planned for stable
branches).
No change has been planned yet for OVB jobs but we might want to think
about it later.

You can go on 
http://status.openstack.org/openstack-health/#/job/gate-tripleo-ci-centos-7-scenario001-multinode-oooq-container
and see stats as well.
We also watched the amount of time spent on pingtest versus tempest
and we knew tempest would take more time. It's the case and we've
noticed the average is ~2 min more for now. It's acceptable I guess
for now.

Anyway, we hope this effort was useful and we can make progress to the
next steps:
- notify teams when some tests fail
- increase test coverage depending on which services are deployed

-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ptls] 1 Week Out PTG Reminders

[Kendall Nelson]

Hello :)

I wanted to send one more reminder before the week disappears and we are
all in Denver.

*PTGbot*
If you don't already have PTGbot powers[1], drop by the #openstack-ptg
channel and ping me/fungi/ttx/clarkb to get them :) If you aren't attending
the PTG, then whoever is moderating should have them to be able to edit the
now/next schedule page[2].


*Team Photo's*
You have until Monday next week (Sept 11th) to sign up and spots are
filling up so don't wait![3]

-Kendall (diablo_rojo)

[1] https://github.com/openstack/ptgbot
[2] http://ptg.openstack.org/ptg.html
[3]
https://docs.google.com/spreadsheets/d/18DmI9ydq6dKr4hAcoAN83vYXWn8TV1NEvy09Ll02_Y0/edit?usp=sharing
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [OpenStack-Infra] [zuul] v3 UI enquiry

[Clark Boylan]

On Tue, Sep 5, 2017, at 09:25 AM, Darragh Bailey wrote:
> Hi,
> 
> 
> Part of a team using Zuul internally with both GitHub Enterprise and
> Gerrit
> projects. Currently we're using the fork from https://github.com/bonnyci/
> zuul with cherry-picks from the openstack-infra/zuul v2 applied. Hoping
> to
> migrate to v3 in the next few months, so for any improvements we'd like
> to
> try and work on adding them to upstream v3 rather than delivering on our
> current code-base.
> 
> 
> Looking for some guidance/suggestions on where the zuul UI is going and
> how
> our customer needs/wants can be achieved so we can plan to help out
> adding
> the improvements. Perhaps this fits into Monty's request a few months
> back
> for "Priorties, backlog and awesome new future things"?
> 
> Currently the main issue from end users, is the user experience around
> the
> UI when looking at job results once the run is complete, and to a lesser
> extend looking at your jobs in the zuul status page when running.
> 
> 
> I'm wondering if there is a plan to have a full UI covering both
> historical
> job runs for projects as well as live status reporting?
> 
> There seems to be an expectation from many users familiar with the CI
> tools
> that support GitHub that you can easily look at previous build runs, see
> what sets failed, support status badges, report on configuration
> settings,
> etc. see http://beta.drone.io/drone-demos/drone-with-go for an example
> with
> drone. While I'm not expecting that all of these can be delivered
> immediately, rather than hacking on specific UI pieces in isolation, it
> might be more useful to focus on them in the context of how they should
> fit
> into a UI overall.
> 
> I've noticed there is an SQL reporter, should that be leveraged to
> provide
> access to the sort of information that needs to be tracked? Or should
> something else be used such as simple files to identify success/failure?
> 
> 
> Some suggestions below that cover the main aspects that there are asks
> for,
> by no means a complete UI, but perhaps there is something already
> partially
> thought out where I can focus on the pieces that will be of most impact
> initially for our use case.
> 

I can't speak for Jim et al, but have some thoughts below.

> 
> 
> 1) Project status view:
> 
> The main status page can be useful for those supporting zuul in an
> environment to have a quick overview of everything, however feedback
> we've
> received locally suggests most developers are frequently only interested
> in
> a single project and find this to be overwhelming This suggests there
> should be a per-project status view, showing only the pipelines and
> changes
> of interest for a single project, along with any CRD that are linked.
> 
> Possibly under an endpoint of "//" as the default view showing
> any
> pipelines relevant to the project along with any changes going through
> them.
> 

This is already possible via the status page filter right? The
difference would be that the filter is cookie based and not path based.
Thinking about it, both provide nice features (with cookie based filter
I don't have to remember links I just always get things filtered the way
I want, with url it is easier to link to what you are seeing).

> 
> 
> 2) Project build history view:
> 
> Returning links at the end of a run in a comment to the raw log files as
> the only build history is somewhat jarring for people used to the
> Travis/Drone/Circle CI services available, there's the expectation that
> it
> should be easily to see the previous runs, seeing whether they passed,
> which jobs within a set failed, and to display the detailed log when
> desired. Providing a reasonable UI is becoming a pre-requisite for
> adoption, no matter how good the functionality, it can be difficult to
> get
> acceptance if the "form" is deemed limiting (non all follow this, but it
> does seem that some of the most vocal objectors can fall into this area).
> 
> Users can be quick to blame the infrastructure when a chance working on
> their system fails in CI and seeing previous runs is non trivial.  Making
> it easy to see that previous changes were working (or failing) can make
> it
> more likely that they will look closer at their own change for the cause
> of
> the failure. It also tends to be easier to understand a failing job, when
> you can easily view the output from a passing one.

Yup, this is the reason the openstack health dashboard,
http://status.openstack.org/openstack-health/#/, exists. Being able to
see the bigger picture and status of a project is important. It also
provides rss feeds so you don't have to actively look at a screen to get
notifications which is nice. A lot of the health dashboard features are
probably fairly openstack specific, like the integration with
elastic-recheck and subunit, but my hunch is that we can probably make a
health dashboard that falls back gracefully to a base 

[Openstack-operators] September 8 Early Bird Registration Deadline - OpenStack Summit Sydney

[Allison Price]

Hi everyone,

Friendly reminder that this Friday, September 8, at 11:59pm Pacific Time 
(September 9 at 6:59 UTC) is the deadline to purchase passes for the OpenStack 
Summit in Sydney at the early bird price, which saves you 50% off full price 
passes.

Register NOW  before the 
prices increase! 

Cheers,
Allison

Allison Price
OpenStack Foundation
alli...@openstack.org


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

[openstack-dev] September 8 Early Bird Registration Deadline - OpenStack Summit Sydney

[Allison Price]

Hi everyone,

Friendly reminder that this Friday, September 8, at 11:59pm Pacific Time 
(September 9 at 6:59 UTC) is the deadline to purchase passes for the OpenStack 
Summit in Sydney at the early bird price, which saves you 50% off full price 
passes.

Register NOW  before the 
prices increase! 

Cheers,
Allison

Allison Price
OpenStack Foundation
alli...@openstack.org


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo] no meeting next week

[Emilien Macchi]

We don't run the weekly meeting during the PTG, so next meeting is
scheduled for September 19th.

Safe travels,
-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Panko] Ways to go through events in the order they appear in database

[gordon chung]

On 05/09/17 09:27 AM, Jay Pipes wrote:
>
> Why not sort by created date/timestamp? Wouldn't that give you the same
> behaviour (for the most part).

we actually do that by default currently. the issue Mikhail ran into was 
because the timestamp we store is the timestamp of the message, not the 
timestamp it's actually recorded in the db. because of that, if we 
record the following(msg_id, timestamp, traits):

(event1, 01:00, {})
(event2, 01:10, {})
(event4, 01:30, {})

if a new event comes in as (event3, 01:20, {}), it will be invisible to 
the user if they "get events" with marker=event4 because while it is 
"newer" in terms of when it was recorded, it's not newer in terms of 
event timestamp.

i imagine if we were to support the ability to see event3 even if the 
marker is event4, we'd need to do what Jay suggested, and add a 
recorded_at/created_at field. supporting sorting by id as i previously 
suggested is probably not a great idea since id is implementation details.

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs][neutron] checking link integrity in the gate

[Tim Burke]

On Sep 5, 2017, at 10:53 AM, Doug Hellmann  wrote:
> 
> Excerpts from Boden Russell's message of 2017-09-05 11:25:34 -0600:
>> 
>> On 9/5/17 11:03 AM, Doug Hellmann wrote:
>>> Is eventlet being initialized (or partially initialized) when a module
>>> from the application is imported for the auto-generated API
>>> documentation?
>> More than likely :)
>> But even if they are, what's the fix/workaround?
>> 
> 
> Ensure that it is fully initialized, or not initialized at all, I would
> think. I'm sure Sphinx does not expect to be running under eventlet.
> 
> I see a comment in neutron's doc/source/conf.py about another issue with
> eventlet and some of the test code. I would start by configuring pbr to
> ignore the test code when generating class documentation and see if that
> eliminates both problems. See "autodoc_tree_excludes" in
> https://docs.openstack.org/pbr/latest/user/using.html#pbr for details.
> 
> If that doesn't help, then I would try to find a way to avoid
> initializing eventlet at all. For example, set an environment variable
> in doc/source/conf.py and then look for it in
> neutron/common/eventlet_utils.py and skip the call to
> eventlet.monkey_patch().
> 
> If neither of those options work, we can continue thinking of other
> ideas.
> 
> Doug

Hey, this sounds familiar! We hit a similar problem in swift [1] where eventlet 
patched out threading.RLock (which gets used by logging) to be green, but we 
still wanted to log from separate posix threads. This patching even happens for 
RLocks that were created *before* monkey_patch was called [2]. Our fix [3] 
involved writing a mutex that would be green- *and* posix-thread friendly, but 
I'm not sure how you might fit that into a doc build. Maybe it'd be easier (as 
Doug suggests) to have the module-import stop monkey-patching?

Tim

[1] https://bugs.launchpad.net/swift/+bug/1710328
[2] 
https://github.com/eventlet/eventlet/blob/b756447/eventlet/patcher.py#L338-L362
[3] https://github.com/openstack/swift/commit/6d16079
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] summit free passes

[Jimmy McArthur]

Hi William,

You will get a code if you check in at the Denver PTG. If you attended 
the Atlanta PTG, you should have already received a code. Either code is 
for a 100% discount, but must be used by October 27.


Please let us know if yo have further questions.

Thanks!
Jimmy


William M Edmonds 
September 5, 2017 at 12:02 PM

It has been stated that attending the PTG will get you a free code for 
the summit. Is that still true even though the PTG falls after the 
early registration deadline in this case, or will it simply be a 
discount of the early-registration cost?


Similarly, would someone with a free registration code from the 
Atlanta PTG have to use it by the early-registration deadline in order 
for their registration to be completely free and not simply 
discounted? That has been the case in the past, but the emails that 
went out with those codes seemed to imply that you could use them for 
free registration until October 27th.



W. Matthew Edmonds
Sr. Software Engineer, IBM Power Systems
Email: edmon...@us.ibm.com
Phone: (919) 543-7538 / Tie-Line: 441-7538

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Add support for Neutron NSX driver

[Tong Liu]

Thanks Emilien and Ben. The situation is exactly as what Ben mentioned. The
feature patches have been merged in Pike. But it is broken and we are
trying to fix it. If we can backport it to Pike where the feature has been
originally introduced, that would be great.

Here are the patches that cherry-picked to Pike:
https://review.openstack.org/#/c/500946/
https://review.openstack.org/#/c/500794/
https://review.openstack.org/#/c/500674/

Thanks,
Tong

On Tue, Sep 5, 2017 at 10:32 AM, Emilien Macchi  wrote:

> On Tue, Sep 5, 2017 at 10:16 AM, Ben Nemec  wrote:
> >
> >
> > On 09/04/2017 11:50 PM, Emilien Macchi wrote:
> >>
> >> On Fri, Sep 1, 2017 at 2:37 PM, Tong Liu  wrote:
> >>>
> >>> Hi,
> >>>
> >>> In pike release, we added supported for Neutron NSX driver in TripleO
> [1]
> >>> by
> >>> the following patches. This will enable TripleO overcloud deployment to
> >>> use
> >>> vmware_nsx as Neutron core_plugin.
> >>> https://review.openstack.org/#/c/441668/
> >>> https://review.openstack.org/#/c/452047/
> >>> https://review.openstack.org/#/c/452391/
> >>>
> >>> However, there are some critical issues which prevent it from
> functional
> >>> correctly, and we fixed them in master with the following patches.
> >>> https://review.openstack.org/#/c/499395/
> >>> https://review.openstack.org/#/c/498143/
> >>> https://review.openstack.org/#/c/498142/
> >>>
> >>> Can we merged these patches and back port to pike?
> >>
> >>
> >> So if we follow all the rules, it goes against how to we handle stable
> >> branches and release management in general.
> >
> >
> > I don't know that I agree.  These patches are all for a feature that
> merged
> > earlier in Pike, but apparently is broken.  The only real issue I see is
> > that the first one doesn't have a bug reference and thus isn't valid for
> > backport as-is.  That one might need further discussion, but the others
> seem
> > to be legitimate bug fixes.
> >
> > I also don't see any blueprint references, so I'm not sure how that came
> > into the discussion.  Maybe some confusion about the process for FFE's
> vs.
> > bugs?  It doesn't appear to me that a bp should be needed for these
> changes,
> > but maybe I'm missing something.
>
> In that case let's threat them as bug fixes and let's do the backports
> to stable/pike.
>
> >
> >>
> >> Usually what happens is we discuss about blueprints at PTG and then
> >> during the cycle developers implement the blueprints.
> >> Sometimes some blueprint get deferred for some reason (quite often
> >> it's because of overcommit but that's a separated topic) so they can
> >> as for FFE (feature freeze exception), granted by the PTL.
> >>
> >> In your case, it's a bit more complex. You created the blueprint a few
> >> days before final release of Pike and you're asking us to merge the
> >> code AND backport it to Pike.
> >> That's for the facts & context, hope it helps to understand why this
> >> request is tricky.
> >>
> >> Now you're a vendor and you're helping to support your driver, which is
> >> good.
> >>
> >> We'll need to evaluate each commit and see if they are backward
> >> compatible and actually don't beak any interface (because we want our
> >> stable branches stable).
> >>
> >> I'm ok to make an exception if next time you can do a better job in
> >> scheduling the work that will be done during one cycle.
> >> The way we propose blueprint is really lightweight, and in the open,
> >> so really no complication here.
> >>
> >>
> >> For now, most of the team is quite busy on Pike release (and PTG
> >> coming next week), so I'm not sure your patches will be reviewed soon
> >> (if yes, that's good).
> >> For the backports, we'll have to evaluate case by case and see if it's
> >> possible.
> >>
> >> Thanks for your work and we hope our collaboration can happen earlier
> >> the next time.
> >>
> >>> Thanks,
> >>> Tong
> >>> [1] Blueprint:
> >>> https://blueprints.launchpad.net/tripleo/+spec/neutron-nsx-driver
> >>
> >>
> >>
> >
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack] [OpenStack] Can Mitaka RamFilter support free hugepages?

[Jay Pipes]

Please remember to add a topic [nova] marker to your subject line. 
Answer below.


On 09/05/2017 04:45 AM, Weichih Lu wrote:

Dear all,

I have a compute node with 64GB ram. And I set 50 hugepages wiht 1GB 
hugepage size. I used command "free", it shows free memory is about 
12GB. And free hugepages is 50.


Correct. By assigning hugepages, you use the memory allocated to the 
hugepages.


Then I launch an instance with 16GB memory, set flavor tag 
: hw:mem_page_size=large. It show Error: No valid host was found. There 
are not enough hosts available.


Right, because you have only 12G of RAM available after 
creating/allocating 50G out of your 64G.


Huge pages are entirely separate from the normal memory that a flavor 
consumes. The 16GB memory in your flavor is RAM consumed on the host. 
The huge pages are individual things that are consumed by the NUMA 
topology that your instance will take. RAM != huge pages. Totally 
different things.


 And I check nova-scheduler log. My
compute is removed by RamFilter. I can launch an instance with 8GB 
memory successfully, or I can launch an instance with 16GB memory 
sucessfully by remove RamFilter.


That's because RamFilter doesn't deal with huge pages. Because huge 
pages are a different resource than memory. The page itself is the resource.


The NUMATopologyFilter is the scheduler filter that evaluates the huge 
page resources on a compute host and determines if the there are enough 
*pages* available for the instance. Note that I say *pages* because the 
unit of resource consumption for huge pages is not MB of RAM. It's a 
single memory page.


Please read this excellent article by Steve Gordon for information on 
what NUMA and huge pages are and how to use them in Nova:


http://redhatstackblog.redhat.com/2015/09/15/driving-in-the-fast-lane-huge-page-support-in-openstack-compute/

Best,
-jay


Does RamFilter only check free memory but not free hugepages?
How can I solve this problem?

I use openstack mitaka version.

thanks

WeiChih, Lu.

Best Regards.


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack



___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [docs][neutron] checking link integrity in the gate

[Doug Hellmann]

Excerpts from Boden Russell's message of 2017-09-05 11:25:34 -0600:
> 
> On 9/5/17 11:03 AM, Doug Hellmann wrote:
> > Is eventlet being initialized (or partially initialized) when a module
> > from the application is imported for the auto-generated API
> > documentation?
> More than likely :)
> But even if they are, what's the fix/workaround?
> 

Ensure that it is fully initialized, or not initialized at all, I would
think. I'm sure Sphinx does not expect to be running under eventlet.

I see a comment in neutron's doc/source/conf.py about another issue with
eventlet and some of the test code. I would start by configuring pbr to
ignore the test code when generating class documentation and see if that
eliminates both problems. See "autodoc_tree_excludes" in
https://docs.openstack.org/pbr/latest/user/using.html#pbr for details.

If that doesn't help, then I would try to find a way to avoid
initializing eventlet at all. For example, set an environment variable
in doc/source/conf.py and then look for it in
neutron/common/eventlet_utils.py and skip the call to
eventlet.monkey_patch().

If neither of those options work, we can continue thinking of other
ideas.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Add support for Neutron NSX driver

[Emilien Macchi]

On Tue, Sep 5, 2017 at 10:16 AM, Ben Nemec  wrote:
>
>
> On 09/04/2017 11:50 PM, Emilien Macchi wrote:
>>
>> On Fri, Sep 1, 2017 at 2:37 PM, Tong Liu  wrote:
>>>
>>> Hi,
>>>
>>> In pike release, we added supported for Neutron NSX driver in TripleO [1]
>>> by
>>> the following patches. This will enable TripleO overcloud deployment to
>>> use
>>> vmware_nsx as Neutron core_plugin.
>>> https://review.openstack.org/#/c/441668/
>>> https://review.openstack.org/#/c/452047/
>>> https://review.openstack.org/#/c/452391/
>>>
>>> However, there are some critical issues which prevent it from functional
>>> correctly, and we fixed them in master with the following patches.
>>> https://review.openstack.org/#/c/499395/
>>> https://review.openstack.org/#/c/498143/
>>> https://review.openstack.org/#/c/498142/
>>>
>>> Can we merged these patches and back port to pike?
>>
>>
>> So if we follow all the rules, it goes against how to we handle stable
>> branches and release management in general.
>
>
> I don't know that I agree.  These patches are all for a feature that merged
> earlier in Pike, but apparently is broken.  The only real issue I see is
> that the first one doesn't have a bug reference and thus isn't valid for
> backport as-is.  That one might need further discussion, but the others seem
> to be legitimate bug fixes.
>
> I also don't see any blueprint references, so I'm not sure how that came
> into the discussion.  Maybe some confusion about the process for FFE's vs.
> bugs?  It doesn't appear to me that a bp should be needed for these changes,
> but maybe I'm missing something.

In that case let's threat them as bug fixes and let's do the backports
to stable/pike.

>
>>
>> Usually what happens is we discuss about blueprints at PTG and then
>> during the cycle developers implement the blueprints.
>> Sometimes some blueprint get deferred for some reason (quite often
>> it's because of overcommit but that's a separated topic) so they can
>> as for FFE (feature freeze exception), granted by the PTL.
>>
>> In your case, it's a bit more complex. You created the blueprint a few
>> days before final release of Pike and you're asking us to merge the
>> code AND backport it to Pike.
>> That's for the facts & context, hope it helps to understand why this
>> request is tricky.
>>
>> Now you're a vendor and you're helping to support your driver, which is
>> good.
>>
>> We'll need to evaluate each commit and see if they are backward
>> compatible and actually don't beak any interface (because we want our
>> stable branches stable).
>>
>> I'm ok to make an exception if next time you can do a better job in
>> scheduling the work that will be done during one cycle.
>> The way we propose blueprint is really lightweight, and in the open,
>> so really no complication here.
>>
>>
>> For now, most of the team is quite busy on Pike release (and PTG
>> coming next week), so I'm not sure your patches will be reviewed soon
>> (if yes, that's good).
>> For the backports, we'll have to evaluate case by case and see if it's
>> possible.
>>
>> Thanks for your work and we hope our collaboration can happen earlier
>> the next time.
>>
>>> Thanks,
>>> Tong
>>> [1] Blueprint:
>>> https://blueprints.launchpad.net/tripleo/+spec/neutron-nsx-driver
>>
>>
>>
>



-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] [neutron] Should we continue providing FQDNs for instance hostnames?

[Ben Nemec]

On 09/04/2017 07:48 AM, Stephen Finucane wrote:

On Mon, 2017-09-04 at 11:51 +, Gary Kotton wrote:

On 9/4/17, 11:18 AM,

"Stephen Finucane"  wrote:

Nova has a feature whereby

it will provide instance host names that cloud-

init can extract and use

inside the guest, i.e. this won't happen without

cloud-init. These host

names are fully qualified domain names (FQDNs) based

upon the instance name

and local domain name. However, as noted in bug

#1698010 [1], the domain

name part of this is based up nova's 'dhcp_domain'

option, which is a nova-

network option that has been deprecated [2].
 
I've started work on a

fix [3] that will allow us to retrieve this

information from neutron

instead, uncoupling us from this legacy option.

However, some commentators

have pointed out that this may not necessarily

be what we want to do: a

FQDN is a hostname and domain name, and using one

as a hostname may not be

that clever nor correct.


My networking fu isn't strong enough to deliver

a verdict so I'm hoping

someone else can make my mind up for me: do we want

to migrate this feature

to neutron, or do we want to stop using FQDN and

just use instance names?


Hi,

Your patch https://review.openstack.org/#/c/48

0616/ requires that neutron

expose the ‘DNS Integration’ extension be support

by neutron and the relevant

networking plugin. If it does not then will be a

regression and things will

not work.

In addition to this that is per network

and not global so there will also be

a regression for running instances if

nova is updated.

OK, so ultimately this isn't something we can rely on from neutron? Does that
mean we should abandon the idea of providing FQDN when using neutron? Mores to
the original point, is there any reason we would want to/should use FQDN?


TripleO gets its FQDNs from this feature, which is how I noticed it was 
still using the deprecated nova.conf value.  So we need some way to 
maintain that functionality.  I'm not sure what would happen if 
cloud-init stopped getting an FQDN - would it just set the hostname but 
leave the domain as whatever was provided via DHCP?  If so I think that 
would be acceptable for us.


On the other hand, since it turns out this configuration option isn't 
only used with nova-network maybe it should just be un-deprecated? 
Perhaps with an update so that it is only used when Neutron doesn't 
provide an FQDN?




Stephen


[1] https://bugs.launchpad.net/nova/+bug/1698010
[2] https://review.openstack.org/#/c/395683/
[3] https://review.openstack.org/#/c/480616/


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack] [OpenStack] Can Mitaka RamFilter support free hugepages?

[Vagner Farias]

Em 5 de set de 2017 05:52, "Weichih Lu" 
escreveu:

Dear all,

I have a compute node with 64GB ram. And I set 50 hugepages wiht 1GB
hugepage size. I used command "free", it shows free memory is about 12GB.
And free hugepages is 50.

Then I launch an instance with 16GB memory, set flavor tag
: hw:mem_page_size=large. It show Error: No valid host was found. There are
not enough hosts available. And I check nova-scheduler log. My compute is
removed by RamFilter. I can launch an instance with 8GB memory
successfully, or I can launch an instance with 16GB memory sucessfully by
remove RamFilter.

Does RamFilter only check free memory but not free hugepages?
How can I solve this problem?

I use openstack mitaka version.


Did you enable NUMATopologyFilter? This is required for using huge
pages[1].

1: https://docs.openstack.org/nova/pike/admin/huge-pages.html

Regards,

Vagner Farias.
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [docs][neutron] checking link integrity in the gate

[Boden Russell]

On 9/5/17 11:03 AM, Doug Hellmann wrote:
> Is eventlet being initialized (or partially initialized) when a module
> from the application is imported for the auto-generated API
> documentation?
More than likely :)
But even if they are, what's the fix/workaround?

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet][puppet-ceph]

[Andrew Woodward]

On Tue, Sep 5, 2017 at 6:47 AM Mohammed Naser  wrote:

> On Tue, Sep 5, 2017 at 4:15 AM, Emil Enemærke  wrote:
> > Hi,
> >
> > I have stated using the puppet-ceph module for deploying ceph, and have
> > noticed a heavy use of exec in fx define 'ceph::osd'
> > (https://github.com/openstack/puppet-ceph/blob/master/manifests/osd.pp).
> Is
> > there a reason for not writing this define as an ensurable type/provider?
> > Otherwise I will fork the module an start on rewriting it for a
> > type/provider.
> >
>
> Thanks for helping out.  I'm happy to see folks using the puppet-ceph
> modules!  I think the reason why we've relied of the Exec's is purely
> historic.  If you have a patch that would convert it to an ensurable
> type and provider, we'd be more than happy to merge it!
>

As manser pointed out, the reason for the exec's is purely historic, in
that the initial implementation team  wasn't comfortable with developing
ruby providers given our familiarity at the time. It was easier for us to
develop and troubleshoot the execs directly.

We'd be more than happy to have reviews to migrate to a ruby implementation

If you have any questions, feel free to pop by on #puppet-openstack on
freenode


> >
> > Cheers
> > Emil
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Andrew Woodward
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Add support for Neutron NSX driver

[Ben Nemec]

On 09/04/2017 11:50 PM, Emilien Macchi wrote:

On Fri, Sep 1, 2017 at 2:37 PM, Tong Liu  wrote:

Hi,

In pike release, we added supported for Neutron NSX driver in TripleO [1] by
the following patches. This will enable TripleO overcloud deployment to use
vmware_nsx as Neutron core_plugin.
https://review.openstack.org/#/c/441668/
https://review.openstack.org/#/c/452047/
https://review.openstack.org/#/c/452391/

However, there are some critical issues which prevent it from functional
correctly, and we fixed them in master with the following patches.
https://review.openstack.org/#/c/499395/
https://review.openstack.org/#/c/498143/
https://review.openstack.org/#/c/498142/

Can we merged these patches and back port to pike?


So if we follow all the rules, it goes against how to we handle stable
branches and release management in general.


I don't know that I agree.  These patches are all for a feature that 
merged earlier in Pike, but apparently is broken.  The only real issue I 
see is that the first one doesn't have a bug reference and thus isn't 
valid for backport as-is.  That one might need further discussion, but 
the others seem to be legitimate bug fixes.


I also don't see any blueprint references, so I'm not sure how that came 
into the discussion.  Maybe some confusion about the process for FFE's 
vs. bugs?  It doesn't appear to me that a bp should be needed for these 
changes, but maybe I'm missing something.




Usually what happens is we discuss about blueprints at PTG and then
during the cycle developers implement the blueprints.
Sometimes some blueprint get deferred for some reason (quite often
it's because of overcommit but that's a separated topic) so they can
as for FFE (feature freeze exception), granted by the PTL.

In your case, it's a bit more complex. You created the blueprint a few
days before final release of Pike and you're asking us to merge the
code AND backport it to Pike.
That's for the facts & context, hope it helps to understand why this
request is tricky.

Now you're a vendor and you're helping to support your driver, which is good.

We'll need to evaluate each commit and see if they are backward
compatible and actually don't beak any interface (because we want our
stable branches stable).

I'm ok to make an exception if next time you can do a better job in
scheduling the work that will be done during one cycle.
The way we propose blueprint is really lightweight, and in the open,
so really no complication here.


For now, most of the team is quite busy on Pike release (and PTG
coming next week), so I'm not sure your patches will be reviewed soon
(if yes, that's good).
For the backports, we'll have to evaluate case by case and see if it's possible.

Thanks for your work and we hope our collaboration can happen earlier
the next time.


Thanks,
Tong
[1] Blueprint:
https://blueprints.launchpad.net/tripleo/+spec/neutron-nsx-driver





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs][neutron] checking link integrity in the gate

[Doug Hellmann]

Excerpts from Boden Russell's message of 2017-09-05 10:51:09 -0600:
> We've (neutron) run into a few cases where our doc links become
> outdated/invalid and are dead. These dead links are not detected in the
> doc build today, but is something we might be interested in enabling.
> 
> I'm no sphinx expert, but best I can tell that's done with the
> "linkcheck" builder [1]. I've tried munking with this, but sporadically
> get an eventlet error [2] followed by an indefinite hang; I've yet to
> find a way around this even if setting linkcheck_workers to 1.
> 
> Also note that most project's doc/Makefile have a linkcheck target, but
> that's also failing.
> 
> Does anyone know the best way to have our links checked during the doc
> build?
> 
> Thanks
> 
> [1]
> http://www.sphinx-doc.org/en/stable/config.html#options-for-the-linkcheck-builder
> [2] http://paste.openstack.org/show/620423/
> 

Is eventlet being initialized (or partially initialized) when a module
from the application is imported for the auto-generated API
documentation?

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] summit free passes

[William M Edmonds]

It has been stated that attending the PTG will get you a free code for the
summit. Is that still true even though the PTG falls after the early
registration deadline in this case, or will it simply be a discount of the
early-registration cost?

Similarly, would someone with a free registration code from the Atlanta PTG
have to use it by the early-registration deadline in order for their
registration to be completely free and not simply discounted? That has been
the case in the past, but the emails that went out with those codes seemed
to imply that you could use them for free registration until October 27th.


W. Matthew Edmonds
Sr. Software Engineer, IBM Power Systems
Email: edmon...@us.ibm.com
Phone: (919) 543-7538 / Tie-Line: 441-7538
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [docs][neutron] checking link integrity in the gate

[Boden Russell]

We've (neutron) run into a few cases where our doc links become
outdated/invalid and are dead. These dead links are not detected in the
doc build today, but is something we might be interested in enabling.

I'm no sphinx expert, but best I can tell that's done with the
"linkcheck" builder [1]. I've tried munking with this, but sporadically
get an eventlet error [2] followed by an indefinite hang; I've yet to
find a way around this even if setting linkcheck_workers to 1.

Also note that most project's doc/Makefile have a linkcheck target, but
that's also failing.

Does anyone know the best way to have our links checked during the doc
build?

Thanks

[1]
http://www.sphinx-doc.org/en/stable/config.html#options-for-the-linkcheck-builder
[2] http://paste.openstack.org/show/620423/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] Add Mohammed Naser to cores

[Dmitry Tantsur]

I think it's not unreasonable to give core rights to the PTL :)

On 09/05/2017 05:42 PM, Alex Schultz wrote:

Hey folks,

I'm writing to ask that we add mnaser to the cores list for the puppet
modules.  He's been a user and contributor for some time and is also
the new PTL.  Let me know if there are any objections.

Thanks,
-Alex

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] Add Mohammed Naser to cores

[Emilien Macchi]

+1 - thanks for stepping up and all your contributions :-)

On Tue, Sep 5, 2017 at 8:45 AM, Iury Gregory  wrote:
> +1 =)
> And also Tks for running for PTL Mohammed
>
> On Sep 5, 2017 12:43, "Alex Schultz"  wrote:
>>
>> Hey folks,
>>
>> I'm writing to ask that we add mnaser to the cores list for the puppet
>> modules.  He's been a user and contributor for some time and is also
>> the new PTL.  Let me know if there are any objections.
>>
>> Thanks,
>> -Alex
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptg][interop][refstack][all][ironic][cinder]RefStack and Interop WG PTG Agenda

[Jay S Bryant]

On 9/4/2017 3:04 AM, Dmitry Tantsur wrote:

On 09/01/2017 07:07 PM, Chris Hoge wrote:

The RefStack and Interop WG teams will host a small work room on Monday
and Tuesday at the PTG. We would like for projects interested in the
interop guideline expansion to participate in guiding the development of
future guidelines. The draft schedule focuses on Interop work for 
Monday,

and RefStack work for Tuesday.

The Interop WG work will have a general session for future planning and
guideline work. We will also have sessions targeted towards new vertical
programs, with a focus on NFV. We would also like to invite
representatives from projects that can be installed as standalone
services, like Cinder and Ironic, to discuss the creation of vertical
programs to test for standalone interoperability of their services. In
another session covering extension programs, we would like to invite
representatives from the Designate and Heat projects to attend to 
discuss

the plans for the two proposed extension programs[1][2]. Any other
projects interested in building an extension program are invited to
attend as well.


Re "Verticals: Cinder, Ironic, Swift discussion", I'm very interested 
to come. Can we please schedule a specific slot for it? We will be 
participating in a Kolla discussion with Cinder folks at 4pm, maybe 
after that?


Adding tags to get more attention.


Dmitry,

Thanks for catching this note and adding tags.  I agree this would be 
good to have on Monday after the Kolla/Cinder/Ironic meeting.


Chris,

Do you think we can make that happen?

Thanks!
Jay



On Tuesday the RefStack team will meet to discuss general planning, and
new features such as refstack-client auto configuration, and secure
uploading and storage of subunit test results to the RefStack server.
Members of adjacent communities such as NFV that are using RefStack for
their own interoperability programs are encoraged to attend as well.

If you're interested in attending any of the sessions, please add your
name and availability to the agenda[3]. We will also accomodate remote
attendance for anyone who can't make it to Denver in person. If the
scheduling doesn't work out for you, I will be at the PTG all week 
and am

available to drop into any other projects.

Chris

[1] https://review.openstack.org/#/c/490648/ [2]
https://review.openstack.org/#/c/492635/ [3]
https://etherpad.openstack.org/p/InteropDenver2017PTG


__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] Add Mohammed Naser to cores

[Iury Gregory]

+1 =)
And also Tks for running for PTL Mohammed

On Sep 5, 2017 12:43, "Alex Schultz"  wrote:

> Hey folks,
>
> I'm writing to ask that we add mnaser to the cores list for the puppet
> modules.  He's been a user and contributor for some time and is also
> the new PTL.  Let me know if there are any objections.
>
> Thanks,
> -Alex
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] question about healthcheck

[Alex Schultz]

On Sun, Sep 3, 2017 at 7:44 PM, Emilien Macchi  wrote:
> Can someone explain me (sorry for the dumb question) why do we force
> healthcheck to be positive when deploying TripleO containers?
>
> healthcheck:
> test: /bin/true
>
> https://github.com/openstack/tripleo-heat-templates/blob/master/docker/services/keystone.yaml#L180-L181
>
> Instead of real checks?
> I probably missed something (it's WIP?) but I found useful to clarify
> now, since we're about to release final Pike.
>

Since that's the cron container, other than checking that cron is
running (which is the container command) I'm not sure if there's much
to check.

Thanks,
-Alex

> Thanks,
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [puppet] Add Mohammed Naser to cores

[Alex Schultz]

Hey folks,

I'm writing to ask that we add mnaser to the cores list for the puppet
modules.  He's been a user and contributor for some time and is also
the new PTL.  Let me know if there are any objections.

Thanks,
-Alex

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] [neutron] Should we continue providing FQDNs for instance hostnames?

[Michael Johnson]

FYI, code in Octavia that checks for the extensions you could borrow:
https://github.com/openstack/octavia/blob/master/octavia/network/drivers/neutron/base.py#L49

On Mon, Sep 4, 2017 at 11:18 PM, Gary Kotton  wrote:
>
>
> On 9/4/17, 3:47 PM, "Stephen Finucane"  wrote:
>
> On Mon, 2017-09-04 at 11:51 +, Gary Kotton wrote:
> > On 9/4/17, 11:18 AM, "Stephen Finucane"  wrote:
> > > Nova has a feature whereby it will provide instance host names that 
> cloud-
> > > init can extract and use inside the guest, i.e. this won't happen 
> without
> > > cloud-init. These host names are fully qualified domain names (FQDNs) 
> based
> > > upon the instance name and local domain name. However, as noted in bug
> > > #1698010 [1], the domain name part of this is based up nova's 
> 'dhcp_domain'
> > > option, which is a nova-network option that has been deprecated [2].
> > >
> > > I've started work on a fix [3] that will allow us to retrieve this
> > > information from neutron instead, uncoupling us from this legacy 
> option.
> > > However, some commentators have pointed out that this may not 
> necessarily
> > > be what we want to do: a FQDN is a hostname and domain name, and 
> using one
> > > as a hostname may not be that clever nor correct.
> > >
> > > My networking fu isn't strong enough to deliver a verdict so I'm 
> hoping
> > > someone else can make my mind up for me: do we want to migrate this 
> feature
> > > to neutron, or do we want to stop using FQDN and just use instance 
> names?
> >
> > Hi,
> >
> > Your patch https://review.openstack.org/#/c/480616/ requires that 
> neutron
> > expose the ‘DNS Integration’ extension be support by neutron and the 
> relevant
> > networking plugin. If it does not then will be a regression and things 
> will
> > not work.
> >
> > In addition to this that is per network and not global so there will 
> also be
> > a regression for running instances if nova is updated.
>
> OK, so ultimately this isn't something we can rely on from neutron?
> [Gary] No, you can rely on it from Neutron – you just need to be aware that 
> if the extension is supported then it can be used. If not then you should 
> continue to use the existing configuration vaiable
>
>  Does that
> mean we should abandon the idea of providing FQDN when using neutron? 
> Mores to
> the original point, is there any reason we would want to/should use FQDN?
>
> [Gary] Yes, we should support this. Applications make use of this and hence 
> the support
>
> Stephen
>
> > > [1] https://bugs.launchpad.net/nova/+bug/1698010
> > > [2] https://review.openstack.org/#/c/395683/
> > > [3] https://review.openstack.org/#/c/480616/
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack-operators] Forum Brainstorming

[Erik McCormick]

Hello Ops!

As a followup to this, the Ops Meetup Team has set up a brainstorming
etherpad to discuss possible forum sessions for Sydney.

https://etherpad.openstack.org/p/SYD-ops-session-ideas

This works the same as our Ops Mid-Cycle meetups. Post your session
ideas, comment on other listed proposals, and +1 the ones you are
interested in seeing included. As always, please share your ideas even
if you will be unable to attend the Sydney Summit.

Cheers,
Erik

On Mon, Sep 4, 2017 at 2:05 PM, Jimmy McArthur  wrote:
> Hi all,
>
> Welcome to the topic selection process for our Forum in Sydney. If you've
> participated in an ops meetup before, this should seem pretty comfortable.
> If not, note that this is not a classic conference track with speakers and
> presentations. OpenStack community members (participants  in development
> teams, working groups, and other interested individuals) discuss the topics
> they want to cover and get alignment on and we welcome your participation.
>
> The Forum is for the entire community to come together, to create a neutral
> space rather than having separate “ops” and “dev” days. Sydney marks the
> start of the Rocky release cycle, where ideas and requirements will be
> gathered. Users should aim to come  armed with feedback from Augusts's Pike
> release if at all possible. We aim to ensure the broadest coverage of topics
> that will allow for multiple  parts of the community getting together to
> discuss key areas within our community/projects.
>
> There are two stages to the brainstorming:
>
> Starting today, set up an etherpad with your group/team, or use one on the
> list and start discussing ideas you'd like to talk about at the Forum. Then,
> through mailing list discussion work out which ones are the most needed -
> just like you did prior to the ops events.
> Then, in a couple of weeks, we will open up a more formal web-based tool for
> submission of abstracts that came out of the brainstorming on top.
>
>
> Make an etherpad, or use one from the list at:
> https://wiki.openstack.org/wiki/Forum/Sydney2017
>
> One key thing we'd like to see is collaboration between every area of ther
> community. Find an interested development project or three and share to your
> ideas.
>
> Think about what kind of session ideas might end up as: Project-specific,
> cross-project or strategic/whole-of-community discussions. There'll be more
> slots for the latter two, so do try and think outside the box!
>
> This part of the process is where we gather broad community consensus - in
> theory the second part is just about fitting in as many of the good ideas
> into the schedule as we can.
>
> Further details about the forum can be found at:
> https://wiki.openstack.org/wiki/Forum
>
> Thanks!
> Jimmy McArthur on behalf of the OpenStack Foundation and User Committee
>
> ___
> 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] Ops Meetups team meeting minutes 2017-9-5

[Chris Morgan]

The OpenStack Operators Ops Meetups team meeting was held today on IRC on
#openstack-operators. Minutes are linked below:


10:55 AM Minutes:
http://eavesdrop.openstack.org/meetings/ops_meetup_team/2017/ops_meetup_team.2017-09-05-14.01.html
10:55 AM Minutes (text):
http://eavesdrop.openstack.org/meetings/ops_meetup_team/2017/ops_meetup_team.2017-09-05-14.01.txt
10:55 AM Log:
http://eavesdrop.openstack.org/meetings/ops_meetup_team/2017/ops_meetup_team.2017-09-05-14.01.log.html

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

Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack meets ETSI NFV workshop on 12.09.2017

[Csatari, Gergely (Nokia - HU/Budapest)]

Hi,

We can try to squeeze it into the schedule. Can you collect your discussion 
topics to an etherpad so we can decide on the timing of the timeslot?

Br,
Gerg0

From: Mikhail Fedosin [mailto:mfedo...@gmail.com]
Sent: Tuesday, September 5, 2017 3:46 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack 
meets ETSI NFV workshop on 12.09.2017

Yes, It will be even better! I can record a demo and publish it before the 
meeting.

Could you schedule a short talk about IFA007 during the workshop?

Best regards,
Mikhail Fedosin

On Fri, Sep 1, 2017 at 5:30 PM, Csatari, Gergely (Nokia - HU/Budapest) 
> wrote:
Hi,

Thanks for the proposal. The aim of this workshop is to accelerate the 
collaboration between OpenStack and ETSI and not to execute demonstrations. 
However if you have technical questions to IFA about IFA007 then we can add 
that as an agenda point.

Br,
Gerg0

From: Mikhail Fedosin [mailto:mfedo...@gmail.com]
Sent: Friday, September 1, 2017 1:03 PM
To: OpenStack Development Mailing List (not for usage questions) 
>

Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack 
meets ETSI NFV workshop on 12.09.2017

Hello!

I would also like to discuss the possibility of using Glare for cataloging VNF 
packages. Generally speaking Glare satisfies all the requirements from the 
standard 
http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/007/02.01.01_60/gs_NFV-IFA007v020101p.pdf
Could we include this topic in the discussions, too?

I plan to create an artifact type and present a short demo there, about how 
glare can work with the packages. If this topic is interesting, then we can 
discuss it in more detail on Wednesday or Thursday in dedicated Glare team room.

Best regards,
Mikhail Fedosin

On Mon, Aug 28, 2017 at 5:06 PM, Csatari, Gergely (Nokia - HU/Budapest) 
> wrote:
Hi,

Thanks for the clarification.

Our understanding was that with Panko it is possible to subscribe to the state 
of the different resource of the cloud as it is descibed in [1]. This is why we 
mapped the Virtualised [Compute|Network|Storage] Resources Capacity Management 
Interfaces to Panko.

[1]: https://wiki.openstack.org/wiki/Telemetry#Managed

Br,
Gerg0


-Original Message-
From: gordon chung [mailto:g...@live.ca]
Sent: Monday, August 28, 2017 3:05 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack 
meets ETSI NFV workshop on 12.09.2017


> Gaps to be discussed are here:
> https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-expla
> ined

i added a note in etherpad but it seems you want Ceilometer (+Gnocchi if you 
need storagE) and not Panko. Panko only handles storage of events (more 
metadata focused data) while Ceilometer handles the actual generation of both 
events and metrics, the latter being the one you want it seems. Gnocchi is used 
for optimised time-series metric storage.

unfortunately, i don't believe anyone from Telemetry teams are attending the 
PTG but we can be reached on ML or #openstack-telemetry.

cheers,

--
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] [placement] Modeling SR-IOV with nested resource providers

[Andrey Volkov]

For example, I have SR-IOV PF with four ports (P_i), two of them are
connected to one switch (SW_1) and other two to another (SW_2). I
would like to get VFs from distinct ports connected to distinct
switches (more details can be found in spec [1]), how it can be
modeled with nested resource providers?

Several possible solutions I see:

1)
  --- compute node -
 / /  \ \--
   -/ /\\---
  /  /  \   \
 SR-IOV PF SR-IOV PF SR-IOV PF SR-IOV PF
   (traits:P1,SW1)  (traits:P2,SW1)   (traits:P3,SW2)(traits:P4,SW2)
: : : :
   / \   / \   / \   / \
  /   \ /   \ /   \ /   \
   VF1VF2VF3VF4VF5VF6VF7VF8


2)
compute node
  /  \
/  \
   SR-IOV PF   SR-IOV PF
  (traits:SW1)(traits:SW2)
/  \/  \
   /\  /\
  SR-IOV PF SR-IOV PF SR-IOV PF SR-IOV PF
 (traits:P1)   (traits:P2)   (traits:P3)   (traits:P4)
 : : : :
/ \   / \   / \   / \
   /   \ /   \ /   \ /   \
VF1VF2VF3VF4VF5VF6VF7VF8


3) Use tags for inventories, so the problem can be solved without complex
structures.

Are the described options applicable or there are other to solve the issue?

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


-- 
Thanks,

Andrey Volkov,
Software Engineer, Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][puppet] mod_wsgi support (pike bug?)

[Kevin Benton]

>For the record, oslo.config already reads /etc/neutron/neutron.conf

Yeah, I think this is the only reason it even manages to get some of the
correct configuration (loading a core plugin at all).

>Also for the record, I consider not being able to load existing split 
>configuration
files a regression.

+1. That would make an upgrade nightmare. In my earlier email I didn't mean
to imply that was the only way forward. I was just curious if it still
broke when everything was in one file.

On Tue, Sep 5, 2017 at 7:01 AM, Ihar Hrachyshka  wrote:

> On Mon, Sep 4, 2017 at 8:07 AM, Kevin Benton  wrote:
> > #2 would be preferable as well just because we have so many
> guides/distros
> > mentioning the different file locations. I'm not familiar with mod_wsgi
> > enough to know if it's possible.
> >
> > Another 3rd option may be to edit the oslo config constructor call when
> > using that entry point to add some well-known paths for additional config
> > files rather than only parsing 'sys.argv[1]'. For example, we could
> always
> > try to add /etc/neutron/plugin.ini to the list which we can document that
> > distros/deployment tools should always create or have a symbolic link to
> a
> > plugin-specific config (e.g. ml2_conf.ini).
>
> For the record, oslo.config already reads /etc/neutron/neutron.conf
> (and some other locations) when no arguments are passed:
>
> https://github.com/openstack/oslo.config/blob/master/oslo_
> config/cfg.py#L711-L739
>
> Also for the record, I consider not being able to load existing split
> configuration files a regression. We won't be able to move to the new
> operation mode unless we figure out how to load them. If mod_wsgi is
> not willing to bend their argv, a envvar could be a good option.
>
> Ihar
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] PTG schedule (preliminary version)

[Dmitry Tantsur]

Hi all!

We're close to finalizing our schedule, and the current version can be seen at 
https://etherpad.openstack.org/p/ironic-queens-ptg.


I've created four etherpads per block of topics for our notes:
https://etherpad.openstack.org/p/ironic-queens-ptg-ongoing-work
https://etherpad.openstack.org/p/ironic-queens-ptg-contentious-topics
https://etherpad.openstack.org/p/ironic-queens-ptg-feature-proposals
https://etherpad.openstack.org/p/ironic-queens-ptg-processes-tools-priorities

Please put your notes in these etherpads (not the main one!). If you lead a 
topic, please populate an appropriate section with links to specs, comments, etc.


Please keep in mind that we're waiting for Nova schedule to finalize before 
finalizing our schedule. We need the bare metal scheduling discussion to happen, 
and preferably before we start discussing it ourselves.


Thanks and see you in Denver!

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][oslo.db][keystone] A POC of Keystone over CockroachDB

[Lance Bragstad]

On 09/04/2017 11:06 AM, Ronan-Alexandre Cherrueau wrote:
> Hi folks,
>
> Recently in the Inria's Discovery initiative[1], we got in touch with
> CockroachLabs guys with an idea: make Keystone supports CockorachDB. So
> we give it a try and you can find a very first result on our GitHub[2].
> The GitHub project consists of a Vagrant file that spawns a VM with a
> CockroachDB database and then installs Keystone with Devstack using
> CockroachDB as backend.
>
> CockroachDB claims to support the PostgreSQL protocol. It also provides
> support for SQLAlchemy that mostly inherits from the PostgreSQL one. So,
> making Keystone working with CockroachDB should be easy peasy right?
> Almost! The rest of this email describes what we have done, to make it
> works.
>
>
> sqlalchemy-migrate doesn't work with CockroachDB
> 
>
> Keystone uses a database migration tool named sqlalchemy-migrate[3].
> This tool is called during the deployment of Keystone to migrate the
> database from its initial versions to its actual version.
> Unfortunately, migration failed with the following (partial)
> stacktrace:
>
> ,
> | DEBUG migrate.versioning.repository [-] Config:
> OrderedDict([('db_settings', OrderedDict([('__name__', 'db_settings'),
> ('repository_id', 'keystone'), ('version_table', 'migrate_version'),
> ('required_dbs', '[]'), ('use_timestamp_numbering', 'False')]))])
> __init__ 
> /usr/local/lib/python2.7/dist-packages/migrate/versioning/repository.py:83
> | INFO migrate.versioning.api [-] 66 -> 67...
> | CRITICAL keystone [-] KeyError: 'cockroachdb'
> | ...
> | TRACE keystone visitorcallable = get_engine_visitor(engine, 
> visitor_name)
> | TRACE keystone   File
> "/usr/local/lib/python2.7/dist-packages/migrate/changeset/databases/visitor.py",
> line 47, in get_engine_visitor
> | TRACE keystone return get_dialect_visitor(engine.dialect, name)
> | TRACE keystone   File
> "/usr/local/lib/python2.7/dist-packages/migrate/changeset/databases/visitor.py",
> line 62, in get_dialect_visitor
> | TRACE keystone migrate_dialect_cls = DIALECTS[sa_dialect_name]
> | TRACE keystone KeyError: 'cockroachdb'
> `
>
> As we understand it, sqlalchemy-migrate contains dedicated SQL backend
> codes and there is no such code for CockroachDB. As a workaround, we
> have performed a second OS deployment with PostgreSQL as backend and
> made a dump of the database after migrations. We then bypassed
> migrations in our first deployment by setting up CockroachDB with the
> dumped script. Note that we had to edit the pgdump script a little bit
> because some features are missing in CockroachDB.
>
> The workaround we have to go with represents an obstacle to test
> CockroachDB with other OpenStack core services. We would be grateful
> if some of you would help us with adding the support of CockroachDB in
> sqlalchemy-migrate.
>
>
> oslo.db contains backend specific code for error handling
> =
>
> The `oslo.db' library contains one file with backend-specific codes
> (`oslo_db/sqlalchemy/exc_filters.py'[4]). This file aims at
> abstracting database exceptions that differ but target the same class
> of error (because each backend produces a specific exception with a
> specific error message). Intercepted exceptions are wrapped into a
> common OS exception to abstract backend errors in the rest of
> `oslo.db'. CockroachDB doesn't produce same errors than PostgreSQL, so
> we have to update this class. Note that our POC is not exhaustive
> since we only added error messages we saw during Tempest/Rally tests.
>
> You can look at the differences between OpenStack/oslo.db/stable/pike
> and our fork on GitHub[5]. We only add two lines!
>
>
> CockroachDB manages isolation without lock
> ==
>
> CockroachDB lets you write transactions that respect ACID properties.
> Regarding the "I" (Isolation), CockroachDB offers snapshot and
> serializable isolation but doesn't rely on locks to do that. So every
> time there is concurrent editing transactions that end in a conflict,
> then you have to retry the transactions. Fortunately, `oslo.db'
> already offers a decorator[6] to do that automatically. But, based on
> tests we run with Tempest/Rally, we figured out that some Keystone's
> SQL requests needed the decorator.
>
> You can look at the differences between OpenStack/keystone/stable/pike
> and our fork on GitHub[7].

Correct me if I'm wrong, but wouldn't this be useful in keystone
regardless of using CockroachDB? It looks like we use the same decorator
in a couple other places in keystone already [0]. Would you mind
proposing this through gerrit directly? It seems like it would be useful
to iterate on it in review. Unless there is a bug exposed in
stable/pike, I don't think we'll be able to back port it. Getting it
into master seems like a good thing, though.

[0] https://review.openstack.org/#/c/416872/

>

Re: [openstack-dev] [neutron][puppet] mod_wsgi support (pike bug?)

[Ihar Hrachyshka]

On Mon, Sep 4, 2017 at 8:07 AM, Kevin Benton  wrote:
> #2 would be preferable as well just because we have so many guides/distros
> mentioning the different file locations. I'm not familiar with mod_wsgi
> enough to know if it's possible.
>
> Another 3rd option may be to edit the oslo config constructor call when
> using that entry point to add some well-known paths for additional config
> files rather than only parsing 'sys.argv[1]'. For example, we could always
> try to add /etc/neutron/plugin.ini to the list which we can document that
> distros/deployment tools should always create or have a symbolic link to a
> plugin-specific config (e.g. ml2_conf.ini).

For the record, oslo.config already reads /etc/neutron/neutron.conf
(and some other locations) when no arguments are passed:

https://github.com/openstack/oslo.config/blob/master/oslo_config/cfg.py#L711-L739

Also for the record, I consider not being able to load existing split
configuration files a regression. We won't be able to move to the new
operation mode unless we figure out how to load them. If mod_wsgi is
not willing to bend their argv, a envvar could be a good option.

Ihar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-dev][keystone][AAA] Unable to log in to DLUX UI using keystone created users

[Lance Bragstad]

To authenticate to keystone directly, you'll need to make an
authentication request to the identity API endpoint. We have
documentation describing the process [0] and what the request should
look like. This can also be done using python-openstackclient [1][2].


[0]
https://developer.openstack.org/api-ref/identity/v3/#authentication-and-token-management
[1] https://pypi.python.org/pypi/python-openstackclient
[2]
https://docs.openstack.org/python-openstackclient/latest/cli/authentication.html

On 09/04/2017 02:51 AM, A Vamsikrishna wrote:
>
> Hi *Lance*,
>
>  
>
> Thanks for your kind response!!
>
>  
>
> Can you please help me with the process to authenticate the created
> users directly against keystone ??
>
>  
>
> Best regards,
>
> Vamsi krishna
>
>  
>
> *From:*Lance Bragstad [mailto:lbrags...@gmail.com]
> *Sent:* Saturday, September 02, 2017 2:19 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Openstack-dev][keystone][AAA] Unable
> to log in to DLUX UI using keystone created users
>
>  
>
> It looks like the users exist in keystone. Are you able to
> authenticate directly against keystone and see if that works?
>
> On 09/01/2017 06:22 AM, A Vamsikrishna wrote:
>
> Hi All,
>
>  
>
> *Setup details: *
>
>  
>
> ubuntu-16.04.2-server-amd64
>
> Docker version 1.12.6
>
> Installed keystone in the docker
>
>  
>
> *Inside the keystone container:*
>
>  
>
> root@82c53b328012 /root #
>
> root@82c53b328012 /root # mysql --version
>
> mysql  Ver 15.1 Distrib 10.0.28-MariaDB, for Linux (x86_64) using
> readline 5.1
>
> root@82c53b328012 /root #
>
> root@82c53b328012 /root #
>
>  
>
> *Issue:*
>
> 1.created some users in keystone container (PFA)  [creating users
> and assigning roles.txt]
>
> 2.Can see those user details in mysql DB (PFA) [users stored in
> mysql DB.txt]
>
> 3.But I see some warnings in keystone logs (PFA) [keystone logs.txt]
>
> *4.And Unable to log in to DLUX UI using the created users(PFA)
> [DLUX UI snapshot]*
>
>  
>
> PFA for *karaf.log* and wireshark captures*(docker0.pcap)* taken
> during authentication.
>
>  
>
> Can someone help me out on this ?
>
>  
>
> Please let me now if you need any more details from myside.
>
>  
>
>  
>
> Thanks,
>
> Vamsi
>
>  
>
>  
>
>
>
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
>
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>  
>



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack-operators] Ops Meetup team meeting today!

[Chris Morgan]

We are meeting on #openstack-operators in less than 10 minutes! Agenda for
today's meeting is here:

https://etherpad.openstack.org/p/ops-meetups-team

main topics: mexico city followups, forum planning (sydney), mid-cycle #1
2018 (tokyo) planning

Chris

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

[openstack-dev] [kolla] kolla 5.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for kolla for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/kolla/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/kolla/log/?h=stable/pike

Release notes for kolla can be found at:

http://docs.openstack.org/releasenotes/kolla/




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet][puppet-ceph]

[Mohammed Naser]

On Tue, Sep 5, 2017 at 4:15 AM, Emil Enemærke  wrote:
> Hi,
>
> I have stated using the puppet-ceph module for deploying ceph, and have
> noticed a heavy use of exec in fx define 'ceph::osd'
> (https://github.com/openstack/puppet-ceph/blob/master/manifests/osd.pp). Is
> there a reason for not writing this define as an ensurable type/provider?
> Otherwise I will fork the module an start on rewriting it for a
> type/provider.
>

Thanks for helping out.  I'm happy to see folks using the puppet-ceph
modules!  I think the reason why we've relied of the Exec's is purely
historic.  If you have a patch that would convert it to an ensurable
type and provider, we'd be more than happy to merge it!

>
> Cheers
> Emil
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack meets ETSI NFV workshop on 12.09.2017

[Mikhail Fedosin]

Yes, It will be even better! I can record a demo and publish it before the
meeting.

Could you schedule a short talk about IFA007 during the workshop?

Best regards,
Mikhail Fedosin

On Fri, Sep 1, 2017 at 5:30 PM, Csatari, Gergely (Nokia - HU/Budapest) <
gergely.csat...@nokia.com> wrote:

> Hi,
>
>
>
> Thanks for the proposal. The aim of this workshop is to accelerate the
> collaboration between OpenStack and ETSI and not to execute demonstrations.
> However if you have technical questions to IFA about IFA007 then we can add
> that as an agenda point.
>
>
>
> Br,
>
> Gerg0
>
>
>
> *From:* Mikhail Fedosin [mailto:mfedo...@gmail.com]
> *Sent:* Friday, September 1, 2017 1:03 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
>
> *Subject:* Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]:
> OpenStack meets ETSI NFV workshop on 12.09.2017
>
>
>
> Hello!
>
>
>
> I would also like to discuss the possibility of using Glare for
> cataloging VNF packages. Generally speaking Glare satisfies all the
> requirements from the standard http://www.etsi.org/
> deliver/etsi_gs/NFV-IFA/001_099/007/02.01.01_60/gs_NFV-IFA007v020101p.pdf
>
> Could we include this topic in the discussions, too?
>
>
>
> I plan to create an artifact type and present a short demo there, about
> how glare can work with the packages. If this topic is interesting, then we
> can discuss it in more detail on Wednesday or Thursday in dedicated Glare
> team room.
>
>
>
> Best regards,
>
> Mikhail Fedosin
>
>
>
> On Mon, Aug 28, 2017 at 5:06 PM, Csatari, Gergely (Nokia - HU/Budapest) <
> gergely.csat...@nokia.com> wrote:
>
> Hi,
>
> Thanks for the clarification.
>
> Our understanding was that with Panko it is possible to subscribe to the
> state of the different resource of the cloud as it is descibed in [1]. This
> is why we mapped the Virtualised [Compute|Network|Storage] Resources
> Capacity Management Interfaces to Panko.
>
> [1]: https://wiki.openstack.org/wiki/Telemetry#Managed
>
> Br,
> Gerg0
>
>
>
> -Original Message-
> From: gordon chung [mailto:g...@live.ca]
> Sent: Monday, August 28, 2017 3:05 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]:
> OpenStack meets ETSI NFV workshop on 12.09.2017
>
>
> > Gaps to be discussed are here:
> > https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-expla
> > ined
>
> i added a note in etherpad but it seems you want Ceilometer (+Gnocchi if
> you need storagE) and not Panko. Panko only handles storage of events (more
> metadata focused data) while Ceilometer handles the actual generation of
> both events and metrics, the latter being the one you want it seems.
> Gnocchi is used for optimised time-series metric storage.
>
> unfortunately, i don't believe anyone from Telemetry teams are attending
> the PTG but we can be reached on ML or #openstack-telemetry.
>
> cheers,
>
> --
> gord
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Greg,

There is an exception in vitrage-graph, since the configuration for 
devstack-vitrage/cpu/0 was not found.

Please verify that your collectd_conf.yaml looks like that:

collectd:
- collectd_host: devstack-vitrage/cpu/0
   type: 
   name: 
- collectd_host: …

If this doesn’t help, please send me the file and I’ll have a look.

Best Regards,
Ifat.


From: "Waines, Greg" 
Date: Tuesday, 5 September 2017 at 15:38
To: "Afek, Ifat (Nokia - IL/Kfar Sava)" , "OpenStack 
Development Mailing List (not for usage questions)" 

Cc: "TAHHAN, MARYAM" 
Subject: Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

Hi Ifat,

I was able to fix and verify that my collectd configuration is correct and 
working with the help of volodomyr ... i.e. I have a much simpler collectd.conf 
with a threshold set on cpu-0 idle percentage and a simple python plugin to 
dump notifications to a file.

I added in the vitrage collectd plugin to this simple setup ... but still don’t 
see vitrage alarms displayed on the vitrage dashboard ☹ .

I have attached the vitrage-graph.log
I have attached my now much simpler collectd.conf file
I have also attached the only templates I have defined under 
/etc/vitrage/templates  ... wondering if I need updated templates for working 
with collectd notifications ?

let me know if you have any ideas,
Greg.



From: "Afek, Ifat (Nokia - IL/Kfar Sava)" 
Date: Sunday, September 3, 2017 at 3:20 AM
To: Greg Waines , 
"openstack-dev@lists.openstack.org" 
Cc: "TAHHAN, MARYAM" 
Subject: Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

Hi Greg,

You should access the vitrage-graph.log using journalctl:
sudo journalctl --no-pager --unit 
devstack@vitrage-graph.service

Best Regards,
Ifat.


From: "Waines, Greg" 
Date: Thursday, 31 August 2017 at 20:10
To: "Afek, Ifat (Nokia - IL/Kfar Sava)" , "OpenStack 
Development Mailing List (not for usage questions)" 

Cc: "TAHHAN, MARYAM" 
Subject: Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

Hi Ifat,
I actually have ‘debug = true’ in /etc/vitrage/vitrage.conf .
However I don’t see vitrage-graph.log anywhere ?
Where is it suppose to be ?   in /var/log/ ?
Greg.


root@devstack-vitrage:/# more /etc/vitrage/vitrage.conf



[DEFAULT]

debug = True

transport_url = rabbit://stackrabbit:admin@10.10.10.13:5672/



[oslo_policy]

policy_file = /etc/vitrage/policy.json



[service_credentials]

auth_url = http://10.10.10.13/identity

region_name = RegionOne

project_name = admin

password = admin

project_domain_id = default

user_domain_id = default

username = vitrage

auth_type = password



[datasources]

types = 
nova.host,nova.instance,nova.zone,static,static_physical,aodh,cinder.volume,neutron.network,neutron.port,doctor,collectd



[keystone_authtoken]

memcached_servers = 10.10.10.13:11211

signing_dir = /var/cache/vitrage

cafile = /opt/stack/data/ca-bundle.pem

project_domain_name = Default

project_name = admin

user_domain_name = Default

password = admin

username = vitrage

auth_url = http://10.10.10.13/identity

auth_type = password



[api]

pecan_debug = False



[collectd]

config_file = /etc/vitrage/collectd_conf.yaml



root@devstack-vitrage:/#


From: "Afek, Ifat (Nokia - IL/Kfar Sava)" 
Date: Thursday, August 31, 2017 at 3:52 AM
To: Greg Waines , 
"openstack-dev@lists.openstack.org" 
Cc: "TAHHAN, MARYAM" 
Subject: Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

Hi Greg,

Vitrage listens to Collectd notifications, not statistics.
Can you please turn on the debug option in /etc/vitrage/vitrage.conf (set 
“debug = true”), and send me the vitrage-graph.log?

Thanks,
Ifat.

From: "Waines, Greg" 
Date: Wednesday, 30 August 2017 at 22:17
To: "OpenStack Development Mailing List (not for usage questions)" 

Cc: "Afek, Ifat (Nokia - IL/Kfar Sava)" , "TAHHAN, MARYAM" 

Subject: Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

Hi Ifat,
thanks for the reply ... just got around to trying your suggestions.

This definitely helps ... I no longer get any errors on re-starting collectd or 
vitrage-graph.
i.e. it appears to load the collectd and updated vitrage conf files correctly 
now.

Now still don’t get any alarms in vitrage.
HOWEVER I suspect it may be my collectd setup now.
( WARNING I am NOT a collectd expert. ;) )

I suspect that the vitrage-collectd plugin only sends collectd NOTIFICATIONS or 

Re: [openstack-dev] [Panko] Ways to go through events in the order they appear in database

[Jay Pipes]

On 09/05/2017 08:44 AM, gordon chung wrote:

On 04/09/17 11:17 AM, Mikhail Kebich wrote:

Hello Gordon,

Any feedback? Did you get a chance to take a look at the cursor api prototype?

Thanks,
Mike

On Wed, Aug 30, 2017 at 6:00 PM, Mikhail Kebich
 wrote:

On Wed, Aug 30, 2017 at 4:22 PM, gordon chung  wrote:

ah, i see. iirc, we can choose what we sort on. can this be solved by
just passing in a different sort key? or maybe we need to support
returning results without sort.


I thought about this. The key issue I see here is that the api does
not include "id" sort key to the result. Because of this api clients
can't specify a value of marker that points to the next batch of
events. And I believe we should think carefully about exposing this
filed because it may be meaningless depending on a storage back-end.

Actually, cursors are intended to solve this issue by specifying a
value of marker explicitly without making an assumption what marker
is.

I attached a prototype. It is based on stable/ocata branch. I did not
replace existing pagination and just provided another URL route to use
cursors. But, I think it is possible to replace current pagination
logic with cursors, because if a storage back-end understands markers
it can specify the value explicitly.



sorry, i thought you were going to post your patch to gerrit.

i just took a look at your patch. you can correct me if i misunderstand
your patch but it just seems that you want to add support to use id as a
marker, specifically the following:

+marker = models.Event(None, None, None, None)
+marker.id = cursor
+sort_keys = ['id']
+sort_dirs = ['asc']
+query = oslo_sql_utils.paginate_query(
+query, models.Event, limit, sort_keys,
+sort_dirs=sort_dirs, marker=marker)

the one concern i have with raising id is because its just an
autoincremented number (i believe) and it has no meaning outside of the
db. i also don't believe it exists in any of the other backends.


Correct.


based on the code above, i would imagine the equivalent could be
achieved by just sorting by id and continuing to use message_id as a
marker. (sorting by id might not be necessary but sql apparently doesn't
guarantee default order)


Why not sort by created date/timestamp? Wouldn't that give you the same 
behaviour (for the most part).


Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [skip-level-upgrades][upgrades] Denver PTG room & etherpad

[Lee Yarwood]

On 21-08-17 15:56:53, Lee Yarwood wrote:
> Hello all,
> 
> This is a brief announcement to highlight that there will be a skip
> level upgrades room again at the PTG in Denver. I'll be chairing the
> room and have seeded the etherpad below with a few goal and topic ideas.
> I'd really welcome additional input from others, especially if you were
> present at the previous discussions in Boston!
> 
> https://etherpad.openstack.org/p/queens-PTG-skip-level-upgrades

As suggested on the pad I've associated each topic with a timeslot
leaving as much time as I could for people to attend other tracks over
the two days. At present we have the following:

Monday

10:00 - 10:30 - Retrospective of what was discussed in Boston 
10:30 - 11:00 - Have operator requirements changed since Boston?
14:00 - 16:00 - What efforts (if any) are underway to enable skip level
upgrades within the community?

Tuesday

10:30 - 11:00 - NFV considerations
11:00 - 11:30 - API versions control
14:00 - 16:00 - How can we collaborate and share tools for skip level
upgrades within the community?
16:00 - 18:00 - Should we think about a different way of releasing?

Can I ask anyone who had previously added a topic to the pad to revisit
and add additional details to these suggestions prior to the PTG.
Obviously this is all subject to change and so I'd be happy to see more
suggestions from community before Monday!

Thanks again,

Lee
-- 
Lee Yarwood A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla] kolla-ansible 5.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for kolla-ansible for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/kolla-ansible/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/kolla-ansible/log/?h=stable/pike

Release notes for kolla-ansible can be found at:

http://docs.openstack.org/releasenotes/kolla-ansible/




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra][docs] Why Manila api-ref doc isn't published?

[Eric Fried]

Sigh.

[3] https://review.openstack.org/#/c/495326/1/www/.htaccess@52

On 09/05/2017 07:30 AM, Eric Fried wrote:
> Agree with everything fungi has said here.
> 
> Per
> https://git.openstack.org/cgit/openstack/service-types-authority/tree/README.rst#n97
> we want the official service type to be singular rather than plural.
> 
> And per the doc migration movement, we want the API references to live
> at standard URLs based on their official service type.
> 
> So the official API reference should indeed be at [1], which it seems to
> be, as you pointed out.
> 
> However, I also agree with your point that there are obviously stale
> links in the world pointing to the plural version, and adding a redirect
> would be a good idea while those get cleaned up.  I have proposed [2]
> for this.
> 
> Please also note that, per my comment at [3], I feel we should be moving
> toward a place where sources linking to API references should be
> gleaning the URLs dynamically from the service-types-authority rather
> than hardcoding them.
> 
> [1] https://developer.openstack.org/api-ref/shared-file-system/
> [2] https://review.openstack.org/#/c/500792/
> 
> Thanks,
> efried
> 
> On 09/04/2017 01:24 PM, Jeremy Stanley wrote:
>> On 2017-09-04 12:45:59 -0500 (-0500), Anne Gentle wrote:
>>> I want to say there are a couple of in-progress patches to clear
>>> this up.
>>>
>>> https://review.openstack.org/#/c/495326/
>>> and
>>> https://review.openstack.org/#/c/495887/
>> [...]
>>
>> Only insofar as the service-types-authority change is switching to
>> match the URL where the document is now being published, but this
>> doesn't actually address all the places where the old URL is still
>> being used. At least that confirms for me that the new URL really is
>> the one we want, so maybe the old "shared-file-systems" name should
>> be added as an alias for the "shared-file-system" service (giving us
>> a redirect as I understand it) and then cleanup of various uses for
>> the old URL can happen at everyone's convenience?
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Panko] Ways to go through events in the order they appear in database

[gordon chung]

On 04/09/17 11:17 AM, Mikhail Kebich wrote:
> Hello Gordon,
>
> Any feedback? Did you get a chance to take a look at the cursor api prototype?
>
> Thanks,
> Mike
>
> On Wed, Aug 30, 2017 at 6:00 PM, Mikhail Kebich
>  wrote:
>> On Wed, Aug 30, 2017 at 4:22 PM, gordon chung  wrote:
>>> ah, i see. iirc, we can choose what we sort on. can this be solved by
>>> just passing in a different sort key? or maybe we need to support
>>> returning results without sort.
>>
>> I thought about this. The key issue I see here is that the api does
>> not include "id" sort key to the result. Because of this api clients
>> can't specify a value of marker that points to the next batch of
>> events. And I believe we should think carefully about exposing this
>> filed because it may be meaningless depending on a storage back-end.
>>
>> Actually, cursors are intended to solve this issue by specifying a
>> value of marker explicitly without making an assumption what marker
>> is.
>>
>> I attached a prototype. It is based on stable/ocata branch. I did not
>> replace existing pagination and just provided another URL route to use
>> cursors. But, I think it is possible to replace current pagination
>> logic with cursors, because if a storage back-end understands markers
>> it can specify the value explicitly.
>>

sorry, i thought you were going to post your patch to gerrit.

i just took a look at your patch. you can correct me if i misunderstand 
your patch but it just seems that you want to add support to use id as a 
marker, specifically the following:

+marker = models.Event(None, None, None, None)
+marker.id = cursor
+sort_keys = ['id']
+sort_dirs = ['asc']
+query = oslo_sql_utils.paginate_query(
+query, models.Event, limit, sort_keys,
+sort_dirs=sort_dirs, marker=marker)

the one concern i have with raising id is because its just an 
autoincremented number (i believe) and it has no meaning outside of the 
db. i also don't believe it exists in any of the other backends.

based on the code above, i would imagine the equivalent could be 
achieved by just sorting by id and continuing to use message_id as a 
marker. (sorting by id might not be necessary but sql apparently doesn't 
guarantee default order)

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra][docs] Why Manila api-ref doc isn't published?

[Eric Fried]

Agree with everything fungi has said here.

Per
https://git.openstack.org/cgit/openstack/service-types-authority/tree/README.rst#n97
we want the official service type to be singular rather than plural.

And per the doc migration movement, we want the API references to live
at standard URLs based on their official service type.

So the official API reference should indeed be at [1], which it seems to
be, as you pointed out.

However, I also agree with your point that there are obviously stale
links in the world pointing to the plural version, and adding a redirect
would be a good idea while those get cleaned up.  I have proposed [2]
for this.

Please also note that, per my comment at [3], I feel we should be moving
toward a place where sources linking to API references should be
gleaning the URLs dynamically from the service-types-authority rather
than hardcoding them.

[1] https://developer.openstack.org/api-ref/shared-file-system/
[2] https://review.openstack.org/#/c/500792/

Thanks,
efried

On 09/04/2017 01:24 PM, Jeremy Stanley wrote:
> On 2017-09-04 12:45:59 -0500 (-0500), Anne Gentle wrote:
>> I want to say there are a couple of in-progress patches to clear
>> this up.
>>
>> https://review.openstack.org/#/c/495326/
>> and
>> https://review.openstack.org/#/c/495887/
> [...]
> 
> Only insofar as the service-types-authority change is switching to
> match the URL where the document is now being published, but this
> doesn't actually address all the places where the old URL is still
> being used. At least that confirms for me that the new URL really is
> the one we want, so maybe the old "shared-file-systems" name should
> be added as an alias for the "shared-file-system" service (giving us
> a redirect as I understand it) and then cleanup of various uses for
> the old URL can happen at everyone's convenience?
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [oslo] schedule for Denver PTG is ready !

[ChangBo Guo]

Lance,  I just update the schedule in [1] and add your new proposal topic
in the schedule, kindly let me know when you're available, then we can
rearrange your topics if you still have conflicts :-)

[1] https://etherpad.openstack.org/p/oslo-ptg-queens

2017-09-02 6:16 GMT+08:00 Lance Bragstad :

> Thanks for the schedule! I should be somewhat available Monday afternoon
> for the policy deprecation discussion. The only conflict that might come up
> for me is with the Baremetal/VM group [0]. Keystone has a few topics to
> iron out there, but I'm not exactly sure when that group plans to talk
> about those things. Also, I proposed another oslo spec detailing some
> additional policy work [1]. Let me know if you have thoughts, or would like
> to discuss it in Denver.
>
> [0] https://etherpad.openstack.org/p/keystone-queens-ptg
> [1] https://review.openstack.org/#/c/500207/
>
>
> On 08/28/2017 09:44 PM, ChangBo Guo wrote:
>
> sure, will adjust the schedule
>
> 2017-08-29 2:24 GMT+08:00 Doug Hellmann :
>
>> Excerpts from ChangBo Guo's message of 2017-08-28 23:14:05 +0800:
>> > Please check  for the draft in [1], we can adjust if you have conflicts
>> > with other discussions.
>> >
>> > We have specific cross projects coding event  in the Tuesday afternoon,
>> for
>> > more details please
>> > check [2] and [3],  please join us if you're free from 1:00 PM to 3: PM
>> on
>> > Tuesday.
>> >
>> > [1] https://etherpad.openstack.org/p/oslo-ptg-queens
>> > [2]
>> > http://lists.openstack.org/pipermail/openstack-dev/2017-Augu
>> st/121345.html
>> > [3] https://etherpad.openstack.org/p/oslo-queens-tasks
>> >
>>
>> I think we can drop the discussion of retiring oslosphinx from the
>> schedule. We had no objections, and the way forward is clear (see the
>> other thread [4] for details).
>>
>> Doug
>>
>> [4] http://lists.openstack.org/pipermail/openstack-dev/2017-Augu
>> st/121564.html
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> ChangBo Guo(gcb)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
ChangBo Guo(gcb)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] connecting nova notification users and developers

[gordon chung]

On 04/09/17 09:55 PM, Lingxian Kong wrote:
> ​Hi Gordon, does Aodh rely on Ceilometer to receive events or it could
> receive notifications directly from other services?​

yes. Ceilometer normalises the message into something Aodh can 
understand. (that's how it behaves currently)

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][scheduling] Can VM placement consider the VM network traffic need?

[Mooney, Sean K]

Interesting timeing
Would love to talk about this at the ptg.
Comments inline.
Regards
sean

> -Original Message-
> From: Balazs Gibizer [mailto:balazs.gibi...@ericsson.com]
> Sent: Tuesday, September 5, 2017 8:23 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Cc: Mooney, Sean K ; mosh...@mellanox.com
> Subject: Re: [openstack-dev] [nova][scheduling] Can VM placement
> consider the VM network traffic need?
> 
> On Mon, Sep 4, 2017 at 9:11 PM, Jay Pipes  wrote:
> > On 09/01/2017 04:42 AM, Rua, Philippe (Nokia - FI/Espoo) wrote:
> > > Will it be possible to include network bandwidth as a resource in
> > Nova scheduling, for VM placement decision?
> >
> > Yes.
> >
> > See here for a related Neutron spec that mentions Placement:
> > https://review.openstack.org/#/c/396297/7/specs/pike/strict-minimum-
> ba
> > ndwidth-support.rst
> >
> > > Context: in telecommunication applications, the network traffic is
> > an important dimension of resource usage. For example, it is often
> > important to distribute "bandwidth-greedy" VMs to different compute
> > nodes. There were some earlier discussions on this topic, but I could
> > not find a concrete outcome. [1][2][3]
> > >
> > > After some reading, I wonder whether the Custom resource classes
> > can provide a generic mechanism? [4][5][6]
> >
> > No :) Custom resource classes are antithetical to generic/standard
> > mechanisms.
> >
> > We want to add two *standard* resource classes, one called
> > NET_INGRESS_BYTES_SEC and another called NET_EGRESS_BYTES_SEC which
> > would represent the total bandwidth in bytes per second the for
> > corresponding traffic directions.
> 
> While I agree that the end goal is to have standard resource classes
> for bandwidth I think custom resource classes are generic enough to
> model bandwidth resource. If you want to play with the bandwidth based
> scheduling idea based on Pike then custom resource classes are
> available as a tool for a proof of concept.
[Mooney, Sean K] 
Form a queens perspective Rodolfo is currently working creating a spec
To introduce a standard bandwidth resource class and resource provider.
He has opened the blueprint to track this here:
https://blueprints.launchpad.net/nova/+spec/bandwidth-resource-provider
currently the scope we are proposing our work to cover is end to end
minimum bandwidth guarantee for sriov interfaces.in this case the bandwidth
resource provider will be a child of the PF. This could be extended
to vSwitches also but in the linux bridge and ovs case neither can support
multi-tenant minimum bandwidth gurrentess at present so from a nova perspective
while we can make sure we do not over subscribe on bandwidth for ovs, neutron
cannot enforce the minimum bandwidth allocation on the vswitch. Hardware 
offloaded
ovs may be able to provide a minimum bandwidth guarantee in the future as might 
vpp
> 
> >
> >
> > What would be the resource provider, though? There are at least two
> > potential answers here:
> >
> > 1) A network interface controller on the compute host
> >
> > In this case, the NIC on the host would be a child provider of the
> > compute host resource provider. It would have an inventory record of
> > resource class NET_INGRESS_BYTES_SEC with a total value representing
> > the entire bandwidth of the host NIC. Instances would consume some
> > amount of NET_INGRESS_BYTES_SEC corresponding to *either* the Nova
> > flavor (if the resources:NET_INGRESS_BYTES_SEC extra-spec is set)
> *or*
> > to the sum of consumed bandwidth amounts from the port profile of any
> > ports specified when launching the instance (and thus would be part
> of
> > the pci device request collection attached to the build request).
> >
> > 2) A "network slice" of a network interface controller on the compute
> > host
> >
> > In this case, assume that the NIC on the compute host has had its
> > total bandwidth constrained via traffic control so that 50% of its
> > available ingress bandwidth is allocated to network A and 50% is
> > allocated to network B.
> >
> > There would be multiple resources providers, each with an inventory
> > record of resource class NET_INGRESS_BYTES_SEC with a total value of
> > 1/2
> > the total NIC bandwidth. Both of these resource providers would be
> > child providers of the compute host resource provider. One of these
> > child resource providers will be decorated with the trait
> > "CUSTOM_NETWORK_A"
> > and the other with trait "CUSTOM_NETWORK_B".
> >
> > The scheduler would be able to determine which resource provider to
> > consume the NET_INGRESS_BYTES_SEC resources from by looking for a
> > resource provider that has both the required amount of
> > NET_INGRESS_BYTES_SEC as well as the trait required by the port
> > profile.
> > If, say, the port profile specifies that the port is to go on a NIC
> > with access to network "A", then the build request would contain 

Re: [openstack-dev] [oslo][oslo.serialization]

[ChangBo Guo]

Tom,  it's good to backport the fix into previous branch. I just
cherry-pick the fix in  https://review.openstack.org/#/c/500781/
I will release new version of oslo.serialization for branch stable/ocata.

2017-09-04 22:15 GMT+08:00 Tom STAPPAERTS 
:

> Hi guys,
>
> We are having an issue when trying to json.dumps() an object that contains
> an IPNetwork. oslo.serialization.jsonutils.to_primitive() tries to
> include every single ip address in the ip network in the dumped json. This
> of course creates issues with an ipv6 network.
>
> You guys fixed this in https://review.openstack.org/#/c/475052/ , but
> only for master / 2.19.0 upwards.
>
> Is there a way to backport this to newton/ocata releases as well? I am
> more than happy to do the heavy lifting on this, but wanted to check with
> you guys before I start submitting anything :)
>
> Kind regards,
> Tom Stappaerts
> Nokia OpenStack software engineer
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
ChangBo Guo(gcb)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack-operators] [User-committee] [scientific] WG IRC meeting: 2100 UTC - opportunistic capacity etc.

[Blair Bethwaite]

Hi Stig,

It occurs to me we have not yet had any discussion on the recent WG->SIG
proposal, which includes the [scientific] posse, so adding that to the
agenda too.

Cheers,

On 5 September 2017 at 19:29, Stig Telfer  wrote:

> Hello all -
>
> We have a Scientific WG IRC meeting today at 2100 UTC in channel
> #openstack-meeting.  Everyone is welcome.
>
> The agenda is here: https://wiki.openstack.org/
> wiki/Scientific_working_group#IRC_Meeting_September_5th_2017
>
> Today we’d like to discuss people’s solutions for making use of
> opportunistic capacity in OpenStack, to achieve maximum utilisation from
> private cloud resources.  We’ve also got updates on the new edition of the
> Scientific OpenStack book, and plenty of upcoming events to plan for.
>
> Cheers,
> Stig
>
>
> ___
> User-committee mailing list
> user-commit...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee
>
>


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

[Openstack-operators] [scientific] WG IRC meeting: 2100 UTC - opportunistic capacity etc.

[Stig Telfer]

Hello all -We have a Scientific WG IRC meeting today at 2100 UTC in channel #openstack-meeting.  Everyone is welcome.The agenda is here: https://wiki.openstack.org/wiki/Scientific_working_group#IRC_Meeting_September_5th_2017Today we’d like to discuss people’s solutions for making use of opportunistic capacity in OpenStack, to achieve maximum utilisation from private cloud resources.  We’ve also got updates on the new edition of the Scientific OpenStack book, and plenty of upcoming events to plan for.Cheers,Stig
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack] Ocata - Ceilometer with Gnocchi

[Adhi Priharmanto]

Hi all,

I'm trying to add telemetry into my running openstack, as I read at

https://docs.openstack.org/project-install-guide/telemetry/ocata/get_started.html

ceilometer now using gnocchi as backend, so I dig more reference for easily
installed gnocchi on my openstack environment, and I found about
openstack-gnocchi-* package from the openstack repo .

I'm installed gnocchi & ceilometer services at a node separate from
controller node, this node have IP 192.168.26.10, so I create metric
endpoint using this IP address.

then I'm using gnocchi from openstack repo , and here my gnocchi config

[DEFAULT]
> log_dir = /var/log/gnocchi/
> verbose = true
> transport_url = rabbit://openstack:my_passw...@ct-oc-srg.adhi
> [api]
> auth_mode = keystone
> [archive_policy]
> default_aggregation_methods = mean,min,max,sum,std,median,count,last,95pct
> [cors]
> [cors.subdomain]
> [database]
> connection = mysql+pymysql://gnocchi:my_passw...@ct-oc-srg.adhi/gnocchi
> [healthcheck]
> [incoming]
> [indexer]
> url = mysql+pymysql://gnocchi:my_passw...@ct-oc-srg.adhi
> /gnocchi?charset=utf8
> driver = sqlalchemy
> [metricd]
> [oslo_middleware]
> [oslo_policy]
> [statsd]
> resource_id = 70de8fd2-7619-4c70-bb4e-6628fe1aa68e
> user_id =
> project_id =
> archive_policy_name = low
> [storage]
> driver = file
> file_basepath = /var/lib/gnocchi
> coordination_url = file:///var/lib/gnocchi/locks
> [keystone_authtoken]
> auth_uri = http://ct-oc-srg.adhi:5000
> auth_url = http://ct-oc-srg.adhi:35357/v3
> auth_type = password
> memcached_servers = ct-oc-srg.adhi:11211
> project_domain_name = default
> user_domain_name = default
> project_name = service
> username = gnocchi
> password = MY_PASSWORD
> interface = internalURL
> region_name = RegionOne


according from the guide above, we just
using openstack-ceilometer-notification.service
openstack-ceilometer-central.service openstack-ceilometer-collector.service
, this is my ceilometer config

[DEFAULT]
> verbose = true
> meter_dispatchers = gnocchi
> event_dispatchers = gnocchi
> transport_url = rabbit://openstack:my_passw...@ct-oc-srg.adhi
> [api]
> [collector]
> [compute]
> [coordination]
> [cors]
> [cors.subdomain]
> [database]
> [dispatcher_file]
> [dispatcher_gnocchi]
> url = http://192.168.26.10:8041
> filter_service_activity = true
> archive_policy = low
> resources_definition_file = gnocchi_resources.yaml
> filter_project = service
> [dispatcher_http]
> [event]
> [hardware]
> [ipmi]
> [keystone_authtoken]
> auth_uri = http://ct-oc-srg.adhi:5000
> auth_url = http://ct-oc-srg.adhi:35357
> memcached_servers = ct-oc-srg.adhi:11211
> auth_type = password
> project_domain_name = default
> user_domain_name = default
> project_name = service
> username = ceilometer
> password = MY_PASSWORD
> [matchmaker_redis]
> [meter]
> [notification]
> store_events = false
> [oslo_concurrency]
> [oslo_messaging_amqp]
> [oslo_messaging_kafka]
> [oslo_messaging_notifications]
> [oslo_messaging_rabbit]
> [oslo_messaging_zmq]
> [oslo_middleware]
> [oslo_policy]
> [polling]
> [publisher]
> [publisher_notifier]
> [rgw_admin_credentials]
> [service_credentials]
> auth_type = password
> auth_url = http://ct-oc-srg.adhi:5000
> project_domain_name = default
> user_domain_name = default
> project_name = service
> username = ceilometer
> password = MY_PASSWORD
> interface = internalURL
> region_name = RegionOne
> [service_types]
> [storage]
> [vmware]
> [xenapi]



While doing ceilometer-upgrade --skip-metering-database, it's look no
problem. When I look into the gnocchi database on mysql , I can see some
tables add into the gnocchi database.

the problem comes when I start the ceilometer services, specially with logs
from ceilometer collector, I've got this error :

2017-09-05 16:03:40.808 23012 ERROR ceilometer.dispatcher.gnocchi [-] A
server error occurred.  Please contact the administrator. (HTTP 500)

I also got this error when I reboot an instance. I also can get measure
from the image download like describe in the guide above, can somebody help
me ?

-- 
Cheers,



[image: --]
Adhi Priharmanto
[image: http://]about.me/a_dhi

+62-812-82121584
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [OpenStack] Can Mitaka RamFilter support free hugepages?

[Weichih Lu]

Dear all,

I have a compute node with 64GB ram. And I set 50 hugepages wiht 1GB
hugepage size. I used command "free", it shows free memory is about 12GB.
And free hugepages is 50.

Then I launch an instance with 16GB memory, set flavor tag
: hw:mem_page_size=large. It show Error: No valid host was found. There are
not enough hosts available. And I check nova-scheduler log. My compute is
removed by RamFilter. I can launch an instance with 8GB memory
successfully, or I can launch an instance with 16GB memory sucessfully by
remove RamFilter.

Does RamFilter only check free memory but not free hugepages?
How can I solve this problem?

I use openstack mitaka version.

thanks

WeiChih, Lu.

Best Regards.
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [neutron][puppet] mod_wsgi support (pike bug?)

[Kevin Benton]

Did you look into setting config files in an env var? That seemed like the
best bet given that #2 is out.

On Mon, Sep 4, 2017 at 8:19 AM, Mohammed Naser  wrote:

> On Mon, Sep 4, 2017 at 11:07 AM, Kevin Benton  wrote:
> > #2 would be preferable as well just because we have so many
> guides/distros
> > mentioning the different file locations. I'm not familiar with mod_wsgi
> > enough to know if it's possible.
>
> I think you might have missed my message earlier by a few seconds,
> looks like it's not really possible :(
>
> > Another 3rd option may be to edit the oslo config constructor call when
> > using that entry point to add some well-known paths for additional config
> > files rather than only parsing 'sys.argv[1]'. For example, we could
> always
> > try to add /etc/neutron/plugin.ini to the list which we can document that
> > distros/deployment tools should always create or have a symbolic link to
> a
> > plugin-specific config (e.g. ml2_conf.ini).
> >
>
> I believe that would be the best option, I did a bit of research and I
> have the following in regards to distros:
>
> - RDO uses /etc/neutron/plugin.ini:
> https://github.com/rdo-packages/neutron-distgit/blob/
> rpm-master/neutron-server.service#L8
> - Ubuntu configures `/etc/neutron/plugins/ml2/ml2_conf.ini` in
> `/etc/neutron/default` which is why in Puppet we override that to keep
> things consistent.
> (https://launchpad.net/ubuntu/+source/neutron/2:11.0.0-0ubuntu1 --
> downloaded control files from there).
>
> I have mixed feelings about this.  I think we should add
> `/etc/neutron/plugin.ini` and advice Ubuntu packaging to change their
> default (with a plugin.ini as a symlink).  If we introduce both
> `ml2_conf.ini` and `plugin.ini`, we risk creating problems if someone
> is not using the `ml2` plugin.  Alternatively, you could load
> `plugin.ini` and fallback to `/etc/neutron/plugins/ml2/ml2_conf.ini`
> if there is nothing?  It's a hard call but it should probably be
> decided by the Neutron team in coordination with the distribution
> packagers.
>
> >
> > On Mon, Sep 4, 2017 at 7:40 AM, Mohammed Naser 
> wrote:
> >>
> >> On Mon, Sep 4, 2017 at 9:01 AM, Kevin Benton  wrote:
> >> > Yes, unfortunately I didn't make it back to the patch in time to
> adjust
> >> > devstack to dump all of the configuration into one file (instead of
> >> > /etc/neutron/neutron.conf /etc/neutron/plugins/ml2.conf etc). I did
> test
> >> > locally with my dev environment around the time that RPC server patch
> >> > went
> >> > in, but there may have been a regression since it went in since it's
> not
> >> > tested as Matt pointed out.
> >> >
> >>
> >> I've added Puppet into this because I think we would have to take a
> >> decision regarding this.  The reason behind the fact that we've always
> >> used the two configuration files is because distributions which ship
> >> packages actually provide 2 configuration files.
> >>
> >> We use a configuration resource called `neutron_plugin_ml2` which
> >> configures things always in `/etc/neutron/plugins/ml2/ml2_conf.ini`.
> >>
> >> In the case of Ubuntu/Debian based systems, we update
> >> `/etc/default/neutron-server` to point the plugin configuration to
> >> `/etc/neutron/plugin.ini` and then we ensure that the file is a
> >> symbolic link to `/etc/neutron/plugins/ml2/ml2_conf.ini`.
> >>
> >> Now, we have two options in my mind (and I am open for others):
> >>
> >> 1) Configure plugins entirely inside `neutron.conf`
> >> This option would solve our issue but introduce another one.  I
> >> believe that the order in the start commands would mean that the later
> >> configuration files (in this case, the plugin.ini) would have priority
> >> over the `neutron.conf` causing an inconsistency, I don't think this
> >> is possible.  However, we can work around this by ensuring that the
> >> plugin.ini file is empty.  However, we will be introducing service
> >> restarts for no reason with that change which can be very confusing
> >> for the user as to why configuration is moving.
> >>
> >> 2) Figure out a way to pass 'args' via WSGI?
> >> I'm not sure if this is entirely possible at all.  But, could there be
> >> a way that we can pass a list of configuration files in the mod_wsgi
> >> configuration?  This would make it the most transparent fix without
> >> having to adjust all of the configuration files and bend against the
> >> set configuration paths of the distro.
> >>
> >> I'd be more than happy to hear any other ideas regarding this
> >> solution.  I would love to implement #2 if it is somehow possible
> >> (environment variables, maybe?) but #1 would work but be very messy
> >> for operators and users.
> >>
> >> >
> >> > It appears that puppet is still spreading the config files for the
> >> > server
> >> > into multiple locations as well[1]. Does it inherit that logic from
> >> > devstack? Because that will need to be changed to push all of 

Re: [openstack-dev] [all] connecting nova notification users and developers

[Juan Antonio Osorio]

Novajoin[1] uses notifications to detect when an instance is provisioned
and register it to FreeIPA (in short).

I added it to the etherpad accordingly.

We're not yet using versioned notifications.


[1] https://review.openstack.org/#/admin/projects/openstack/novajoin

On Wed, Aug 30, 2017 at 5:30 PM, Balazs Gibizer  wrote:

> Hi,
>
> Nova emits notifications for many different event, like different instance
> actions[1]. Also the nova developer community is working on making nova
> notifications well defined and easy to consume [2].
>
> The goal of this mail is twofold.
>
> 1) We in the nova developer community would like to see which projects are
> using (or planning to use) the nova notification interface. Also we would
> like to know if you are using the legacy unversioned notifications or the
> new versioned ones. We would like to know what are your use cases towards
> our notification interface and we also would like to get any type of
> feedback about the interface (both the old and the new one). Based on this
> information we can make better decision where to focus our development
> effort. As a good example we already have a  cooperation with the
> searchlight project to enhance nova's versioned notification interface
> based on their needs [3].
>
> I opened an etherpad [4] to collect the projects and the feedback and we
> can go through that feedback in the PTG to define some actions.
>
> 2) Creating a well defined and easy to use notification interface gives us
> plenty of work in nova. So we are also looking for developers who can help
> us in this work. Big chunk of [2] is considered as low hanging fruit and
> I'm happy to mentor anybody who is interested learning this part of nova.
> If you want to join to this work just ping me (gibi) or IRC.
>
> Cheers,
> gibi
>
> [1]https://docs.openstack.org/nova/latest/reference/notifications.html
> [2]https://blueprints.launchpad.net/nova/+spec/versioned-
> notification-transformation-queens
> [3]https://blueprints.launchpad.net/nova/+spec/additional-
> notification-fields-for-searchlight
> [4]https://etherpad.openstack.org/p/queens-nova-notifications
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [puppet][puppet-ceph]

[Emil Enemærke]

Hi,

I have stated using the puppet-ceph module for deploying ceph, and have
noticed a heavy use of exec in fx define 'ceph::osd' (
https://github.com/openstack/puppet-ceph/blob/master/manifests/osd.pp). Is
there a reason for not writing this define as an ensurable type/provider?
Otherwise I will fork the module an start on rewriting it for a
type/provider.

Cheers
Emil
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] connecting nova notification users and developers

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

Vitrage holds a topology graph with all resources in the system and the 
relationships between them, for fault correlation purposes[1]. It uses 
notifications from Nova (as well as from other components) to update its 
internal state[2]. 

It is important for us to get immediate notifications about state changes, so 
we can react fast. For example, if a new instance is created on a host with 
high CPU load, we will immediately raise an alarm on that instance that it may 
suffer from CPU performance degradation.

I’ll be happy to discuss our use cases at the PTG.

[1] https://wiki.openstack.org/wiki/Vitrage  
[2] 
https://github.com/openstack/vitrage/blob/master/vitrage/datasources/nova/instance/driver.py

Best Regards,
Ifat.


On 30/08/2017, 17:30, "Balazs Gibizer"  wrote:

Hi,

Nova emits notifications for many different event, like different 
instance actions[1]. Also the nova developer community is working on 
making nova notifications well defined and easy to consume [2].

The goal of this mail is twofold.

1) We in the nova developer community would like to see which projects 
are using (or planning to use) the nova notification interface. Also we 
would like to know if you are using the legacy unversioned 
notifications or the new versioned ones. We would like to know what are 
your use cases towards our notification interface and we also would 
like to get any type of feedback about the interface (both the old and 
the new one). Based on this information we can make better decision 
where to focus our development effort. As a good example we already 
have a  cooperation with the searchlight project to enhance nova's 
versioned notification interface based on their needs [3].

I opened an etherpad [4] to collect the projects and the feedback and 
we can go through that feedback in the PTG to define some actions.

2) Creating a well defined and easy to use notification interface gives 
us plenty of work in nova. So we are also looking for developers who 
can help us in this work. Big chunk of [2] is considered as low hanging 
fruit and I'm happy to mentor anybody who is interested learning this 
part of nova. If you want to join to this work just ping me (gibi) or 
IRC.

Cheers,
gibi

[1]https://docs.openstack.org/nova/latest/reference/notifications.html

[2]https://blueprints.launchpad.net/nova/+spec/versioned-notification-transformation-queens

[3]https://blueprints.launchpad.net/nova/+spec/additional-notification-fields-for-searchlight
[4]https://etherpad.openstack.org/p/queens-nova-notifications


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] mod_wsgi support (pike bug?)

[Miguel Angel Ajo Pelayo]

As a note, in OSP we also include configuration directories and things
alike:

https://review.rdoproject.org/r/gitweb?p=openstack/neutron-distgit.git;a=blob;f=neutron-server.service;h=e68024cb9dc06e474b1ac9473bff93c3d892b4d6;hb=48a9d1aa77506d0c60d5bc448b7c5c303083aa68#l8

Config directories make it a bit more future proof, and able to easily
integrate with vendor plugins without the need to modify the service file.


On Tue, Sep 5, 2017 at 9:27 AM, Miguel Angel Ajo Pelayo  wrote:

> Why do we need to put all the configuration in a single file?
>
> That would be a big big change to deployers. It'd be great if we can think
> of an alternate solution. (not sure how that's being handled for other
> services though).
>
> Best regards,
> Miguel Ángel.
>
> On Mon, Sep 4, 2017 at 3:01 PM, Kevin Benton  wrote:
>
>> Yes, unfortunately I didn't make it back to the patch in time to adjust
>> devstack to dump all of the configuration into one file (instead of
>> /etc/neutron/neutron.conf /etc/neutron/plugins/ml2.conf etc). I did test
>> locally with my dev environment around the time that RPC server patch went
>> in, but there may have been a regression since it went in since it's not
>> tested as Matt pointed out.
>>
>> It appears that puppet is still spreading the config files for the server
>> into multiple locations as well[1]. Does it inherit that logic from
>> devstack? Because that will need to be changed to push all of the relevant
>> server config into one conf.
>>
>> 1. http://logs.openstack.org/82/500182/3/check/gate-puppet-o
>> penstack-integration-4-scenario004-tempest-ubuntu-xenial/
>> 791523c/logs/etc/neutron/plugins/
>>
>> On Sun, Sep 3, 2017 at 12:03 PM, Mohammed Naser 
>> wrote:
>>
>>> On Sun, Sep 3, 2017 at 3:03 PM, Mohammed Naser 
>>> wrote:
>>> > On Sun, Sep 3, 2017 at 2:20 PM, Matthew Treinish 
>>> wrote:
>>> >> On Sun, Sep 03, 2017 at 01:47:24PM -0400, Mohammed Naser wrote:
>>> >>> Hi folks,
>>> >>>
>>> >>> I've attempted to enable mod_wsgi support in our dev environment with
>>> >>> Puppet however it results in a traceback.  I figured it was an
>>> >>> environment thing so I looked into moving the Puppet CI to test using
>>> >>> mod_wsgi and it resulted in the same error.
>>> >>>
>>> >>> http://logs.openstack.org/82/500182/3/check/gate-puppet-open
>>> stack-integration-4-scenario004-tempest-ubuntu-xenial/791523
>>> c/logs/apache/neutron_wsgi_error.txt.gz
>>> >>>
>>> >>> Would anyone from the Neutron team be able to give input on this?
>>> >>> We'd love to add gating for Neutron deployed by mod_wsgi which can
>>> >>> help find similar issues.
>>> >>>
>>> >>
>>> >> Neutron never got their wsgi support working in Devstack either. The
>>> patch
>>> >> adding that: https://review.openstack.org/#/c/439191/ never passed
>>> the gate and
>>> >> seems to have lost the attention of the author. The wsgi support in
>>> neutron
>>> >> probably doesn't work yet, and is definitely untested. IIRC, the
>>> issue they were
>>> >> hitting was loading the config files. [1] I don't think I saw any
>>> progress on it
>>> >> after that though.
>>> >>
>>> >> The TC goal doc [2] probably should say something about it never
>>> landing and
>>> >> missing pike.
>>> >>
>>> >
>>> > That would make sense.  The release notes also state that it does
>>> > offer the ability to run inside mod_wsgi which can be misleading to
>>> > deployers (that was the main reason I thought we can start testing
>>> > using it):
>>> >
>>> Sigh, hit send too early.  Here is the link:
>>>
>>> http://git.openstack.org/cgit/openstack/neutron/commit/?id=9
>>> 16bc96ee214078496b4b38e1c93f36f906ce840
>>> >
>>> >>
>>> >> -Matt Treinish
>>> >>
>>> >>
>>> >> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-June
>>> /117830.html
>>> >> [2] https://governance.openstack.org/tc/goals/pike/deploy-api-in
>>> -wsgi.html#neutron
>>> >>
>>> >> 
>>> __
>>> >> OpenStack Development Mailing List (not for usage questions)
>>> >> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
__
OpenStack 

Re: [openstack-dev] [neutron] mod_wsgi support (pike bug?)

[Miguel Angel Ajo Pelayo]

Why do we need to put all the configuration in a single file?

That would be a big big change to deployers. It'd be great if we can think
of an alternate solution. (not sure how that's being handled for other
services though).

Best regards,
Miguel Ángel.

On Mon, Sep 4, 2017 at 3:01 PM, Kevin Benton  wrote:

> Yes, unfortunately I didn't make it back to the patch in time to adjust
> devstack to dump all of the configuration into one file (instead of
> /etc/neutron/neutron.conf /etc/neutron/plugins/ml2.conf etc). I did test
> locally with my dev environment around the time that RPC server patch went
> in, but there may have been a regression since it went in since it's not
> tested as Matt pointed out.
>
> It appears that puppet is still spreading the config files for the server
> into multiple locations as well[1]. Does it inherit that logic from
> devstack? Because that will need to be changed to push all of the relevant
> server config into one conf.
>
> 1. http://logs.openstack.org/82/500182/3/check/gate-puppet-
> openstack-integration-4-scenario004-tempest-ubuntu-
> xenial/791523c/logs/etc/neutron/plugins/
>
> On Sun, Sep 3, 2017 at 12:03 PM, Mohammed Naser 
> wrote:
>
>> On Sun, Sep 3, 2017 at 3:03 PM, Mohammed Naser 
>> wrote:
>> > On Sun, Sep 3, 2017 at 2:20 PM, Matthew Treinish 
>> wrote:
>> >> On Sun, Sep 03, 2017 at 01:47:24PM -0400, Mohammed Naser wrote:
>> >>> Hi folks,
>> >>>
>> >>> I've attempted to enable mod_wsgi support in our dev environment with
>> >>> Puppet however it results in a traceback.  I figured it was an
>> >>> environment thing so I looked into moving the Puppet CI to test using
>> >>> mod_wsgi and it resulted in the same error.
>> >>>
>> >>> http://logs.openstack.org/82/500182/3/check/gate-puppet-open
>> stack-integration-4-scenario004-tempest-ubuntu-xenial/
>> 791523c/logs/apache/neutron_wsgi_error.txt.gz
>> >>>
>> >>> Would anyone from the Neutron team be able to give input on this?
>> >>> We'd love to add gating for Neutron deployed by mod_wsgi which can
>> >>> help find similar issues.
>> >>>
>> >>
>> >> Neutron never got their wsgi support working in Devstack either. The
>> patch
>> >> adding that: https://review.openstack.org/#/c/439191/ never passed
>> the gate and
>> >> seems to have lost the attention of the author. The wsgi support in
>> neutron
>> >> probably doesn't work yet, and is definitely untested. IIRC, the issue
>> they were
>> >> hitting was loading the config files. [1] I don't think I saw any
>> progress on it
>> >> after that though.
>> >>
>> >> The TC goal doc [2] probably should say something about it never
>> landing and
>> >> missing pike.
>> >>
>> >
>> > That would make sense.  The release notes also state that it does
>> > offer the ability to run inside mod_wsgi which can be misleading to
>> > deployers (that was the main reason I thought we can start testing
>> > using it):
>> >
>> Sigh, hit send too early.  Here is the link:
>>
>> http://git.openstack.org/cgit/openstack/neutron/commit/?id=9
>> 16bc96ee214078496b4b38e1c93f36f906ce840
>> >
>> >>
>> >> -Matt Treinish
>> >>
>> >>
>> >> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-June
>> /117830.html
>> >> [2] https://governance.openstack.org/tc/goals/pike/deploy-api-in
>> -wsgi.html#neutron
>> >>
>> >> 
>> __
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][scheduling] Can VM placement consider the VM network traffic need?

[Balazs Gibizer]

On Mon, Sep 4, 2017 at 9:11 PM, Jay Pipes  wrote:

On 09/01/2017 04:42 AM, Rua, Philippe (Nokia - FI/Espoo) wrote:
> Will it be possible to include network bandwidth as a resource in 
Nova scheduling, for VM placement decision?


Yes.

See here for a related Neutron spec that mentions Placement:
https://review.openstack.org/#/c/396297/7/specs/pike/strict-minimum-bandwidth-support.rst

> Context: in telecommunication applications, the network traffic is 
an important dimension of resource usage. For example, it is often 
important to distribute "bandwidth-greedy" VMs to different compute 
nodes. There were some earlier discussions on this topic, but I could 
not find a concrete outcome. [1][2][3]

>
> After some reading, I wonder whether the Custom resource classes 
can provide a generic mechanism? [4][5][6]


No :) Custom resource classes are antithetical to generic/standard
mechanisms.

We want to add two *standard* resource classes, one called
NET_INGRESS_BYTES_SEC and another called NET_EGRESS_BYTES_SEC which
would represent the total bandwidth in bytes per second the for
corresponding traffic directions.


While I agree that the end goal is to have standard resource classes 
for bandwidth I think custom resource classes are generic enough to 
model bandwidth resource. If you want to play with the bandwidth based 
scheduling idea based on Pike then custom resource classes are 
available as a tool for a proof of concept.





What would be the resource provider, though? There are at least two
potential answers here:

1) A network interface controller on the compute host

In this case, the NIC on the host would be a child provider of the
compute host resource provider. It would have an inventory record of
resource class NET_INGRESS_BYTES_SEC with a total value representing 
the
entire bandwidth of the host NIC. Instances would consume some amount 
of
NET_INGRESS_BYTES_SEC corresponding to *either* the Nova flavor (if 
the

resources:NET_INGRESS_BYTES_SEC extra-spec is set) *or* to the sum of
consumed bandwidth amounts from the port profile of any ports 
specified

when launching the instance (and thus would be part of the pci device
request collection attached to the build request).

2) A "network slice" of a network interface controller on the compute 
host


In this case, assume that the NIC on the compute host has had its 
total

bandwidth constrained via traffic control so that 50% of its available
ingress bandwidth is allocated to network A and 50% is allocated to
network B.

There would be multiple resources providers, each with an inventory
record of resource class NET_INGRESS_BYTES_SEC with a total value of 
1/2
the total NIC bandwidth. Both of these resource providers would be 
child

providers of the compute host resource provider. One of these child
resource providers will be decorated with the trait "CUSTOM_NETWORK_A"
and the other with trait "CUSTOM_NETWORK_B".

The scheduler would be able to determine which resource provider to
consume the NET_INGRESS_BYTES_SEC resources from by looking for a
resource provider that has both the required amount of
NET_INGRESS_BYTES_SEC as well as the trait required by the port 
profile.
If, say, the port profile specifies that the port is to go on a NIC 
with
access to network "A", then the build request would contain a request 
to

the scheduler for CUSTOM_NETWORK_A trait...


The above setup can be simulated with custom resource classes and 
individual resource providers per compute node connected to the given 
compute node's resource provider via an aggregate. You most probably 
need to simulate the above network traits with individual custom 
resource classes in Pike.


I definitely don't think it is something I would do in production based 
on Pike due to two reasons:
1) we have bugs in Pike GA that prevents nova to handle some edge cases 
(especially in VM moving scenarios)
2) I agree with Jay that nested providers and neutron support will 
allows us to do something much more cleaner in the future.


However I think Pike is a good base to build a PoC and gather feedback. 
For example I already foresee a need to model OVS packet processing 
limits and in the long run even include the capacity of the TOR 
switches into the picture.





If you're coming to Denver, I encourage you to get with me, Sean 
Mooney,
Moshe Levi and others who are interested in seeing this work move 
forward.


@Jay: sign me up for this list.

Cheers,
gibi



Best,
-jay

> Here is what I have in mind:
> - The VM need is specified in the flavor extra-specs, e.g. 
resources:CUSTOM_BANDWIDTH=123.
> - The compute node total capacity is specified in host aggregate 
metadata, e.g. CUSTOM_BANDWIDTH=999.
> - Nova then takes care of the rest: scheduling where the free 
capacity is sufficient, and performing simple resource usage 
accounting (updating the compute node free network bandwidth capacity 
as required).

>
> Is the outline above according to current plans?
> 

Re: [openstack-dev] [tripleo] PTG Agenda draft - action required

[Marcin Juszkiewicz]

W dniu 01.09.2017 o 15:20, Giulio Fidente pisze:

> specifically three topics:

>  - upgrade ceph to luminous (maybe also in Kolla)

Are there plans to build ceph packages then?

Debian 'stretch' is on 10.2.5, Ubuntu 16.04 is on 10.2.7 one. Packages
with 12.x are in Ubuntu 'artful' and on a way to CentOS 7.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [OpenStack-Infra] Infra Team PTG Dinner

[Tony Breeds]

On Sun, Sep 03, 2017 at 04:26:19PM -0700, Clark Boylan wrote:
> I'm not sure we need a doodle. Based on the etherpad Tuesday and
> Wednesday are the only two evenings everyone is in town and of those two
> Tuesday is the only day that hasn't already been listed as a conflict.
> 
> Can we go with Tuesday at the Lowry Beer Garden? I think there is a
> happy hour thing happening at the PTG that evening so we could meetup
> after that and shuttle over to the beer garden (looks like shouldn't be
> more than a 10-15 minute car ride).
> 
> Does this work?

#winning!

Thanks!

Yours Tony.


signature.asc
Description: PGP signature
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [openstack-dev] [nova] [neutron] Should we continue providing FQDNs for instance hostnames?

[Gary Kotton]

On 9/4/17, 3:47 PM, "Stephen Finucane"  wrote:

On Mon, 2017-09-04 at 11:51 +, Gary Kotton wrote:
> On 9/4/17, 11:18 AM, "Stephen Finucane"  wrote:
> > Nova has a feature whereby it will provide instance host names that 
cloud-
> > init can extract and use inside the guest, i.e. this won't happen 
without
> > cloud-init. These host names are fully qualified domain names (FQDNs) 
based
> > upon the instance name and local domain name. However, as noted in bug
> > #1698010 [1], the domain name part of this is based up nova's 
'dhcp_domain'
> > option, which is a nova-network option that has been deprecated [2].
> > 
> > I've started work on a fix [3] that will allow us to retrieve this
> > information from neutron instead, uncoupling us from this legacy option.
> > However, some commentators have pointed out that this may not 
necessarily 
> > be what we want to do: a FQDN is a hostname and domain name, and using 
one 
> > as a hostname may not be that clever nor correct.
> >
> > My networking fu isn't strong enough to deliver a verdict so I'm hoping
> > someone else can make my mind up for me: do we want to migrate this 
feature
> > to neutron, or do we want to stop using FQDN and just use instance 
names?
>
> Hi,
>
> Your patch https://review.openstack.org/#/c/480616/ requires that neutron
> expose the ‘DNS Integration’ extension be support by neutron and the 
relevant
> networking plugin. If it does not then will be a regression and things 
will
> not work.
>
> In addition to this that is per network and not global so there will also 
be
> a regression for running instances if nova is updated.

OK, so ultimately this isn't something we can rely on from neutron?
[Gary] No, you can rely on it from Neutron – you just need to be aware that if 
the extension is supported then it can be used. If not then you should continue 
to use the existing configuration vaiable

 Does that
mean we should abandon the idea of providing FQDN when using neutron? Mores 
to
the original point, is there any reason we would want to/should use FQDN?

[Gary] Yes, we should support this. Applications make use of this and hence the 
support

Stephen

> > [1] https://bugs.launchpad.net/nova/+bug/1698010
> > [2] https://review.openstack.org/#/c/395683/
> > [3] https://review.openstack.org/#/c/480616/



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev