Re: [openstack-dev] [keystone] Does the policy.json for trusts works?

[Boris Bobrov]

Hi,

On 13.09.2017 18:54, Adrian Turjak wrote:
> Hello Keystone devs!
> 
> I've been playing with some policy changes and realised that the trust
> policy rules were mostly blank. Which, based on how the policy logic
> works means that any authed user can list trusts:
> https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json#L137-L142
> 
> But... in practive that doesn't appear to be the case, only admin can
> list/create/etc trusts. Which is good since it doesn't really make sense
> for any authed user to see all trusts (or does it?). What it does raise
> is, does the policy actually work for trusts, or is an admin requirement
> policy hardcoded somewhere for them?
> 
> Now I've played with the keystone policy, setting an admin only policy
> blank, lets say project list, does let any authed user to use that API.
> So from that we know that a blank policy has that logic. The 'default'
> rule only comes into play when a rule isn't present. Such as me setting
> a policy as "rule:rule_that_doesnt_exist" which would invoke the default
> rule, so we know that is happening here either.
> 
> So... back to how I got here. The policy for trusts doesn't appear to
> work as written. They are blank (and they probably shouldn't be), and
> based on that policy, they should be visible to all authed users. Even
> if I do put an explicit rule in them, they don't seem to take effect.
> Can someone else confirm I'm not going mad? Or that potentially I'm
> missing the point entirely (which for my sanity is also welcome :P).

Trusts are not controlled by policy.json. Checks for them are
performed in code. So you're not mad ;)

> I even checked if it was maybe extension specific, but the consumer
> policy for the oauth extension does appear to work. If I blank it, any
> authed user can list consumers.
> 
> If I'm not mad, we should probably work out why this doesn't work, but
> before we fix it, we should also add a better default rule since we
> probably don't want all authed users seeing ALL trusts.

I agree. Could you please create a bugreport?

> Cheers,
> Adrian
> 
> 
> 
> 
> __
> 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] review.openstack.org downtime and Gerrit upgrade

[Clark Boylan]

On Wed, Aug 2, 2017, at 03:57 PM, Clark Boylan wrote:
> Hello,
> 
> The Infra team is planning to upgrade review.openstack.org from Gerrit
> 2.11 to Gerrit 2.13 on September 18, 2017. This downtime will begin at
> 1500UTC and is expected to take many hours as we have to perform an
> offline update of Gerrit's secondary indexes. The outage should be
> complete by 2359UTC.
> 
> This upgrade is a relatively minor one for users. You'll find that
> mobile use of Gerrit is slightly better (though still not great). The
> bug that forces us to reapply Approval votes rather than just rechecking
> has also been addressed. If you'd like to test out Gerrit 2.13 you can
> do so at https://review-dev.openstack.org.
> 
> The date we have chosen is the Monday after the PTG. The
> expectation/hope is that many people will still be traveling or
> otherwise recovering from the PTG so demand for Gerrit will be low. By
> doing it on Monday we also hope that there will be load on the service
> the following day which should help shake out any issues quickly (in the
> past we've done it on weekends then had to wait a couple days before
> problems are noticed).
> 
> If you have any concerns or feedback please let the Infra team know.

As a friendly reminder we are planning to move ahead with this upgrade
on Monday at 1500UTC. We are reviewing the process and getting some
final preparations done on our last day at the PTG.

Thank you for your patience,
Clark

__
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] Simplification in OpenStack

[Mike Perez]

On 15:53 Sep 12, Boris Pavlovic wrote:
> Mike,
> 
> Great intiative, unfortunately I wasn't able to attend it, however I have
> some thoughts...
> You can't simplify OpenStack just by fixing few issues that are described
> in the etherpad mostly..



Definitely agree that it's not going to be a few issues to fix. I purposely was
leading this effort being broad so we can take the comments of OpenStack being
complex, and have a conversation on what that actually means to people. 

The feedback from people on the etherpad, as well as the in person discussions
have been valuable in getting those different perspectives. Unfortunately
participation was low, but I'm interested in seeing if we can identify some
themes to have some actual doable objectives.

I appreciate you taking the time in writing up your feedback on this Boris.
I will make sure it's included in the more polished summary I'll be giving the
TC and the Board to act on. Thank you!

-- 
Mike Perez


signature.asc
Description: PGP 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

Re: [openstack-dev] [ptg] Simplification in OpenStack

[Mike Perez]

Hey all,

I would like to encourage people from different teams to add items of
things they learned at the PTG about simplifying their own projects.
Maybe we can see some themes that can contribute to community wide
goals?

https://etherpad.openstack.org/p/simplifying-os

—
Mike Perez

On September 12, 2017 at 15:33:14, Mike Perez (thin...@gmail.com) wrote:
> Hey all,
>
> The session is over. I’m hanging near registration if anyone wants to discuss 
> things.
> Shout out to John for coming by on discussions with simplifying dependencies. 
> I welcome
> more packagers to join the discussion.
>
> https://etherpad.openstack.org/p/simplifying-os
>
> —
> Mike Perez
>
>
> On September 12, 2017 at 11:45:05, Mike Perez (thin...@gmail.com) wrote:
> > Hey all,
> >
> > Back in a joint meeting with the TC, UC, Foundation and The Board it was 
> > decided as an area
> > of OpenStack to focus was Simplifying OpenStack. This intentionally was 
> > very broad
> > so the community can kick start the conversation and help tackle some broad 
> > feedback
> > we get.
> >
> > Unfortunately yesterday there was a low turn out in the Simplification 
> > room. A group
> > of people from the Swift team, Kevin Fox and Swimingly were nice enough to 
> > start the conversation
> > and give some feedback. You can see our initial ether pad work here:
> >
> > https://etherpad.openstack.org/p/simplifying-os
> >
> > There are efforts happening everyday helping with this goal, and our team 
> > has made some
> > documented improvements that can be found in our report to the board within 
> > the ether
> > pad. I would like to take a step back with this opportunity to have in 
> > person discussions
> > for us to identify what are the area of simplifying that are worthwhile. 
> > I’m taking a
> break
> > from the room at the moment for lunch, but I encourage people at 13:30 
> > local time to meet
> > at the simplification room level b in the big thompson room. Thank you!
> >
> > —
> > Mike Perez
>

__
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] Anyone know CNCF and how to get their landscape 'tweaked'

[John Dickinson]

I submitted an issue on the landscape[1], but there's been no activity or 
comments on it. It looks like David Flanders had some interaction on it a long 
time ago [2].

Big poster-pictures like this inevitably get used to promote marketing messages 
(the linked ML thread explicitly says that was the point of the diagram), so it 
would be nice to have OpenStack projects accurately represented.[3]

[1] https://github.com/cncf/landscape/issues/150
[2] https://github.com/cncf/landscape/issues/41
[3] Please no "But what *is* OpenStack?" debates for the thousandth time. ;-)


--John



On 15 Sep 2017, at 12:15, Joshua Harlow wrote:

> Hi folks,
>
> Something that has been bugging me (a tiny bit, not a lot) is the following 
> CNCF landscape picture.
>
> https://raw.githubusercontent.com/cncf/landscape/master/landscape/CloudNativeLandscape_v0.9.7.jpg
>
> If you look for openstack (for some reason it's under bare metal) in that you 
> may also get the weird feeling (as I did) that there is some kind of 
> misunderstanding that the CNCF leadership/technical community/... as to what 
> is openstack.
>
> I am wondering if we (or the openstack foundation?) can have a larger 
> sit-down with those folks and explain to them what is openstack and why its 
> components are not just baremetal...
>
> Full cncf-toc thread at:
>
> https://lists.cncf.io/pipermail/cncf-toc/2017-September/thread.html#1170
>
> -Josh
>
> __
> 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-dev] Anyone know CNCF and how to get their landscape 'tweaked'

[Joshua Harlow]

Hi folks,

Something that has been bugging me (a tiny bit, not a lot) is the 
following CNCF landscape picture.


https://raw.githubusercontent.com/cncf/landscape/master/landscape/CloudNativeLandscape_v0.9.7.jpg

If you look for openstack (for some reason it's under bare metal) in 
that you may also get the weird feeling (as I did) that there is some 
kind of misunderstanding that the CNCF leadership/technical 
community/... as to what is openstack.


I am wondering if we (or the openstack foundation?) can have a larger 
sit-down with those folks and explain to them what is openstack and why 
its components are not just baremetal...


Full cncf-toc thread at:

https://lists.cncf.io/pipermail/cncf-toc/2017-September/thread.html#1170

-Josh

__
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] [relmgt] Libraries published to pypi with YYYY.X.Z versions

[Rong Zhu]

+1 for murano-dashboard and murano-agent

On Fri, Sep 1, 2017 at 1:51 AM, Thierry Carrez  wrote:
> Claudiu Belu wrote:
>> So, I believe the general consensus is that the easiest thing to do is to 
>> unpublish the 2015.1.0 version from pypi, with which I also agree.
>> [...]
>
> Yes, for a first batch I propose we clean up the following:
>
> python-congressclient 2015.1.0
> python-congressclient 2015.1.0rc1
> python-designateclient 2013.1.a8.g3a2a320
> networking-hyperv 2015.1.0
>
> For the remaining (official) ones (mistral-extra, networking-odl,
> murano-dashboard, networking-hyperv, networking-midonet,
> sahara-image-elements, freezer-api, murano-agent, mistral-dashboard,
> sahara-dashboard) let's wait until we can get PTL signoff.
>
> --
> Thierry Carrez (ttx)
>
> __
> 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?)

[Morales, Victor]

Howdy,

Well, my point is that *neutron-server* can be called with several 
configuration files[1][2][3] as arguments like 

$ neutron-server --config-file /etc/neutron/neutron.conf --config-file 
/etc/neutron/ml2.ini --config-file /root/experimental.ini

Which depends on the needs of the user.  Usually these are stored in the same 
configuration directory but there is no guarantee on that.  The other thing 
that I was thinking is that given that neutron has a pluggable architecute 
maybe there are config values that define folders to load configuration info, 
something like *api_extensions_path* which defines the place of the extension 
classes.

Regards/Saludos
Victor Morales

[1] https://github.com/openstack-dev/devstack/blob/master/lib/neutron#L391-L397
[2] 
https://github.com/openstack/neutron/blob/master/neutron/server/__init__.py#L30
[3] 
https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L76-L78


On 9/15/17, 3:23 AM, "Thomas Bechtold"  wrote:

Hi Victor,

On 13.09.2017 17:37,  Morales, Victor  wrote:
> As far as I remember the reason to have everything on a single file is 
because we’re trying to make Apache to load the configuration values during the 
startup.

Hm. I don't understand. With config-dirs, the service automatically 
reads also the extra files from the directories.
Am I missing something?

Best,

Tom

> 
> On 9/6/17, 9:19 PM, "Thomas Bechtold"  wrote:
> 
>  Hi Kevin,
>  
>  On 04.09.2017 15:01, 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).
>  
>  You don't have to put everything into one file. oslo.config supports 
per
>  service config files and conf.d dirs[1].
>  So eg. dhcp_agent.ini could be put into
>  /etc/neutron/neutron-dhcp-agent.conf.d/foo.conf (it must end with 
.conf).
>  Maybe that's more readable than a single huge config file?
>  
>  Best,
>  
>  Tom
>  
>  [1] 
https://docs.openstack.org/releasenotes/oslo.config/ocata.html#id2
>  
>  
>  
__
>  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] [k8s][deployment][kolla-kubernetes][magnum][kuryr][qa][api] Proposal for SIG-K8s

[Chris Hoge]

Link to the etherpad for the upcoming meeting.

https://etherpad.openstack.org/p/queens-ptg-sig-k8s 



> On Sep 14, 2017, at 10:23 AM, Chris Hoge  wrote:
> 
> This Friday, September 15 at the PTG we will be hosting an organizational
> meeting for SIG-K8s. More information on the proposal, meeting time, and
> remote attendance is in the openstack-sigs mailing list [1].
> 
> Thanks,
> Chris Hoge
> Interop Engineer
> OpenStack Foundation
> 
> [1] 
> http://lists.openstack.org/pipermail/openstack-sigs/2017-September/51.html
> __
> 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][deployment][kolla][tripleo][osa] Service diagnostics task force

[Carter, Kevin]

Sounds like a worthwhile goal. Count me in.

--

Kevin Carter
IRC: Cloudnull


On Sep 14, 2017 01:46, "Michał Jastrzębski"  wrote:

Hello my dearest of communities,

During deployment tools session on PTG we discussed need for deep
health checking and metering of running services. It's very relevant
in context of containers (especially k8s) and HA. Things like
watchdog, heartbeats or exposing relative metrics (I don't want to get
into design here, suffice to say it's non-trivial problem to solve).

We would like to start a "task force", few volunteers from both
deployment tool side (ops, ha) and project dev teams. We would like to
design together a proper health check mechanism for one of projects to
create best practices and design, that later could be implemented in
all other services.

We would to ask for volunteer project team to join us and spearhead this
effort.

Regards,
Michal

__
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] Should we be using subprocess32?

[Doug Hellmann]

Excerpts from Tony Breeds's message of 2017-09-14 16:18:35 -0600:
> On Tue, Sep 12, 2017 at 11:29:22AM -0700, Joshua Harlow wrote:
> > Hi folks,
> > 
> > I know there is a bunch of usage of subprocess in openstack and especially
> > since there is heavy usage of python 2.7 it made me wonder if we should try
> > to move to subprocess32 to avoid some of the bugs that seem to exist (maybe
> > distributors backported them?):
> > 
> > For example a major one (seems to be):
> > 
> > - https://github.com/google/python-subprocess32/commit/6ef1fea55
> > 
> > """Popen.wait() is now thread safe so that multiple
> > 
> >   threads may be calling wait() or poll() on a Popen instance at the same
> > time
> >   without losing the Popen.returncode value.
> > """
> > 
> > That one concerns me slightly, because I know that certain openstack
> > projects do use threads (and not eventlet monkey-patched green-thread
> > hybrids).
> > 
> > TLDR; should we (could we?) switch?
> 
> We could.  It wouldn't be hard to propose a change to the requirements
> repo and that could be used to test what breaks.
> 
> As to should we I'm not convinced.  It does give us a slightly more
> modern subprocess module but it hasn't been updated in nearly 2 years.
> I get that it's a backport from 3.3 which isn't getting updated but ...
> 
> Also it means adding something like:
> if os.name == 'posix' and sys.version_info[0] < 3:
> import subprocess32 as subprocess
> else:
> import subprocess
> 
> All over the place which isn't so great.
> 
> So overall I'm not certain it's worth it.
> 
> Yours Tony.

We might get more value by continuing the migration to python 3 so we
can drop python 2 support.

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] [glance] Queens PTG: Thursday summary

[Brian Rosmaita]

For those who couldn't attend, here's a quick synopsis of what was
discussed yesterday.

Please consult the etherpad for each session for details.  Feel free
to put questions/comments on the etherpads, and then put an item on
the agenda for the weekly meeting on Thursday 21 September, and we'll
continue the discussion.


Complexity removal
--
https://etherpad.openstack.org/p/glance-queens-ptg-complexity-removal

In terms of a complexity contribution barrier, everyone agreed that
the domain model is the largest factor.

We also agreed that simplifying it is not something that could happen
in the Queens cycle.  It's probably a two-cycle effort, one cycle to
ensure sufficient test coverage, and one cycle to refactor.  Given the
strategic planning session yesterday, we probably wouldn't want to
tackle this until after the registry is completely removed, which is
projected to happen in S.


Image lifecycle support
---
https://etherpad.openstack.org/p/glance-queens-ptg-lifecycle

We sketched out several approaches, but trying to figure out a
solution that would work across different types of deployments and
various use cases gets complicated fast.  It would be better for
deployers to use Searchlight to configure complex queries that could
use all appropriate image metadata specified by the deployer.

For interoperability, deployers could use the common image properties
with suggested values on their public images.

We looked at two particular approaches that might help operators.  The
first would be introducing a kind of 'local_version' field that would
be auto-incremented by Glance, the idea being that an image-list query
that asked for the max value would yield the most recent version of
that image.  One problem, however, is what other metadata would be
used in the query, as there might be several versions of images with
the same os_distro and os_version properties (for example, the base
CentOS 7 image and the LAMP CentOS 7 image).

The second approach is introducing a 'hidden' property which would
cause the image to be hidden from any image list calls (except for the
image owner or glance admin).  This has been requested before, but
hasn't been enthusiastically endorsed because it leaves out several
use cases.  But combined with Searchlight (with an updated glance
plugin to understand the 'hidden' field), it might be the best
solution.


Should Glance be replaced?
--
https://etherpad.openstack.org/p/glance-queens-ptg-glance-removal

The short answer is No.  Glance is the best way for deployments to
provide the Images API v2.  The project team has recently regained the
team:diverse-affiliation tag and is in a healthier state that it was
immediately after the downsizing craze of 2017 that happened early in
the Pike cycle.  The Glance project team is committed to the long term
stability of Glance.


glance_store

https://etherpad.openstack.org/p/glance-queens-ptg-glance_store

We had a combined session with the Glare team, who also consume the
glance_store library, and worked out a list of items to improve the
library.



Multiple same store type support

https://etherpad.openstack.org/p/glance-queens-ptg-multi-store

This has been requested by operators, and the interoperable image
import introduced in v2.6 of the Images API can be used to allow end
users to request what store to use.  The Glance design will be
consistent (to the largest extent possible) with Cinder (at least as
far as configuration goes, to make it easy on operators).



Queens Prioritization and Roadmapping
-
https://etherpad.openstack.org/p/glance-queens-ptg-roadmap

See the etherpad for what we think we can get done.  I'll put up a
patch for the Queens priorities to the glance-specs repo before the
Glance meeting on Sept 21, and we can have a final discussion of any
outstanding issues.



If you missed the Wednesday summary, here it is:
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122156.html

The scheduling etherpad has links to all the session etherpads:
https://etherpad.openstack.org/p/glance-queens-ptg

__
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] [horizon] [ceilometer] A Monitoring panel plugin for Horizon

[Esra Celik]

Hi Julien, 

- 15 Eyl 2017 tarihinde, 15:20 saatinde, julien  
şunları yazdı: 

> I guess if you found everything you wanted in the Gnocchi API that's
> awesome. If there are feature you think you miss, please let us know!

I think Gnocchi API is very handy, the resource, metric and measure hierarchy 
is well designed. 
Using a default Ceilometer configuration Measures class in [1] does everything 
we need to monitor the utilization data. 
If Ceilometer is configured to save memory_util and disk_util it will be even 
easier. 
We will soon add checks if these x_util data are in gnocchiclient.metric.list. 

By the way I realized that a host typed resource's hardware.disk.size.total and 
hardware.disk.size.used metrics are collected with value 0 every time. 
But host_disk typed resource's have meaningful values. This happens with the 
default configuration of Ceilometer. 

[1] 
https://github.com/b3lab/safir_monitor_dashboard/blob/master/monitor_dashboard/api/rest/gnocchi.py
 

ecelik 
__
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] CLI extensions for the undercloud

[Steven Hardy]

On Thu, Sep 14, 2017 at 8:02 PM, Ricardo Noriega De Soto
 wrote:
> Hello guys,
>
> After integrating BGPVPN and L2GW Neutron drivers in TripleO, I've realized
> I always have to jump to the overcloud controller (and copy-pasting the
> overcloudrc file) in order to use the CLI extensions such "neutron
> l2-gateway list".

That option seems to be available on my undercloud:

(undercloud) [stack@undercloud tmp]$ neutron help | grep l2
neutron CLI is deprecated and will be removed in the future. Use
openstack CLI instead.
  l2-gateway-connection-create   [l2_gateway_connection] Create
l2gateway-connection information.
  l2-gateway-connection-delete   [l2_gateway_connection] Delete a
given l2gateway-connection.
  l2-gateway-connection-list [l2_gateway_connection] List
l2gateway-connections.
  l2-gateway-connection-show [l2_gateway_connection] Show
information of a given l2gateway-connection.
  l2-gateway-create  [l2_gateway] Create l2gateway information.
  l2-gateway-delete  [l2_gateway] Delete a given l2gateway.
  l2-gateway-list[l2_gateway] List l2gateway that
belongs to a given tenant.
  l2-gateway-show[l2_gateway] Show information of
a given l2gateway.
  l2-gateway-update  [l2_gateway] Update a given l2gateway.

So is it not just a case of sourcing the overcloudrc on the undercloud
(or any other node with the correct client packages installed and
access to the overcloud endpoints) ?

Maybe I'm missing something but I'm not clear why you need to SSH to
the overcloud controller - that's never expected for any tenant
API/CLI operations, but clearly wherever they do connect from needs an
appropriate client - is your undercloud build missing whatever package
provides l2-gateway-list perhaps?

> I'd like to know what's the current strategy on other services and if it's
> possible to use those extensions from the undercloud. From the UX
> perspective it would be much appreciated! :-)

AFAIK the expectation is, much like any OpenStack cloud, that the user
interacts with the ReST APIs exposed by the overcloud endpoints, and
TripleO itself doesn't really care about how that happens, even though
we do install many of the clients on the undercloud (which isn't
intended for use of end users, only cloud administrators).

Hope that helps,

Steve

__
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] [horizon] A Monitoring panel plugin for Horizon

[Julien Danjou]

On Fri, Sep 15 2017, Esra Celik wrote:

Hi Esra,

> We published a new release of our Monitor Panel which uses Gnocchi api as the 
> backend [1]. 
> As Gokhan said, our cloud platform is still on Mitaka so we tested this new
> release on Devstack,

That sounds cool.

> It seems quite faster than mongodb, so we also added the weekly and monthly
> monitoring options.

It is way faster than MongoDB indeed, which was a starting point for the
project back then. :)

> Do you have any other suggestions? 

I guess if you found everything you wanted in the Gnocchi API that's
awesome. If there are feature you think you miss, please let us know!

-- 
Julien Danjou
# Free Software hacker
# https://julien.danjou.info


signature.asc
Description: PGP 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-dev] [horizon] A Monitoring panel plugin for Horizon

[Esra Celik]

Hi Julien, 
On Tue, Aug 11 2017, Julien Danjou wrote:

>> We are happy to share with you that we developed an AngularJS based usage >> 
>> monitoring panel for Horizon. >> The panel visualizes the collected 
>> utilization data by Ceilometer. >> >> Source code is now available on github 
>> [1]. >> >> The plugin consists of 3 panels; a monitoring panel for users, a 
>> project >> monitoring panel and a hypervisor monitoring panel for admins. >> 
>> >> A user can display utilization charts for the current project's 
>> instances, >> export the metrics in csv format and launch alarms using the 
>> dashboard. >> We have another service to capture these alarms and send 
>> notification e-mails >> to the cloud users which is also available on 
>> github.com/b3lab. >> An admin can display projects' utilization charts, 
>> export the metrics in csv >> format in Project Monitor panel. And the 
>> Hypervisor Monitor panel is to >> visualize SNMP based metrics collected 
>> from hypervisors. >> >> We are currently improving some features. >> >> Some 
>> screenshots published at our website [2]. We also uploaded two videos >> 
>> showing some features of the plugin [3][4]. >> >> All comments and ideas are 
>> welcome! > 
> Did you build all of this against the deprecated Ceilometer API rather
> than Gnocchi? :( 
We published a new release of our Monitor Panel which uses Gnocchi api as the 
backend [1]. 
As Gokhan said, our cloud platform is still on Mitaka so we tested this new 
release on Devstack, 
It seems quite faster than mongodb, so we also added the weekly and monthly 
monitoring options. 
Do you have any other suggestions? 

[1] https://github.com/b3lab/safir_monitor_dashboard 

Thanks in advance, 

ecelik 

__
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?)

[Thomas Bechtold]

Hi Victor,

On 13.09.2017 17:37,  Morales, Victor  wrote:

As far as I remember the reason to have everything on a single file is because 
we’re trying to make Apache to load the configuration values during the startup.


Hm. I don't understand. With config-dirs, the service automatically 
reads also the extra files from the directories.

Am I missing something?

Best,

Tom



On 9/6/17, 9:19 PM, "Thomas Bechtold"  wrote:

 Hi Kevin,
 
 On 04.09.2017 15:01, 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).
 
 You don't have to put everything into one file. oslo.config supports per

 service config files and conf.d dirs[1].
 So eg. dhcp_agent.ini could be put into
 /etc/neutron/neutron-dhcp-agent.conf.d/foo.conf (it must end with .conf).
 Maybe that's more readable than a single huge config file?
 
 Best,
 
 Tom
 
 [1] https://docs.openstack.org/releasenotes/oslo.config/ocata.html#id2
 
 
 __

 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] 答复: [mogan] python-moganclient 0.1.0 released

[Sheng Liu]

Thanks Zhenguo for proposing that!

 FYI, following is the complete documentation of moganclient, you can find
more details if you are insteresting :)

http://python-moganclient.readthedocs.io/en/latest/

2017-09-15 14:17 GMT+08:00 Tao Li :

> Cool
>
>
>
> *发件人:* openstack-dev-boun...@lists.openstack.org [mailto:
> openstack-dev-boun...@lists.openstack.org] *代表 *Zhenguo Niu
> *发送时间:* 2017年9月15日 11:30
> *收件人:* OpenStack Development Mailing List  openstack.org>
> *主题:* [openstack-dev] [mogan] python-moganclient 0.1.0 released
>
>
>
> hi all,
>
>
>
> python-moganclient 0.1.0 released.
>
>
>
> Tarball: http://tarballs.openstack.org/python-moganclient/
>
> PYPI: https://pypi.python.org/pypi/python-moganclient/
>
> --
>
> Best Regards,
>
> Zhenguo Niu
>
> __
> 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] 答复: Re: [senlin] Meeting for Queens Goal

[Lee Yi]

So do I.  I'll attend both if time permits.

where is the Meetup?

On Fri, Sep 15, 2017 at 12:16 PM,  wrote:

>
> Me too. I'll attend both if time permits.
>
>
> 原始邮件
> *发件人：* ;
> *收件人：* ;
> *日 期 ：*2017年09月15日 08:43
> *主 题 ：**Re: [openstack-dev] [senlin] Meeting for Queens Goal*
>
>
> I'll attend both if time permits.
>
> - Qiming
> On Thu, Sep 14, 2017 at 06:58:38PM +0800, YUAN RUIJIE wrote:
> > Hi Senlin Core Team,
> >
> > We are going to have a meetup to discuss the goal &
> features we want to
> > implement in Queens cycle. As we discussed during the latest weekly
> > meeting, we have the follow options:
> >
> > 1. Have a virtual meeting by some meeting softwares
> > 2. Organize a Meetup in middle Oct, since the National Day is coming.
> >
> > Suggestions are welcomed,
> >
> > Sincerely,
> > ruijie
>
> > __
> 
> > 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] 答复: [mogan] python-moganclient 0.1.0 released

[Tao Li]

Cool

 

发件人: openstack-dev-boun...@lists.openstack.org 
[mailto:openstack-dev-boun...@lists.openstack.org] 代表 Zhenguo Niu
发送时间: 2017年9月15日 11:30
收件人: OpenStack Development Mailing List 
主题: [openstack-dev] [mogan] python-moganclient 0.1.0 released

 

hi all,

 

python-moganclient 0.1.0 released.

 

Tarball: http://tarballs.openstack.org/python-moganclient/

PYPI: https://pypi.python.org/pypi/python-moganclient/

-- 

Best Regards,

Zhenguo Niu

__
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