settingsLogin | Registersettings

[openstack-dev] [Fuel][Plugin]Add multiple backends support

0 votes

I also have the same requirement for Fuel UI.

Agree that we need the capability in Fuel UI framework to manage multiple groups of data, the data usually have same fields/structure

These data could not be able to simple separated by "comma", since this is error-prone for both administrators and plugin developers

My suggestion is to introduce "table grid" to manage "groups" of data, and user can edit detail info for each of line in a pop up window
A add/remove button can be added around the "table grid"
You can refer to adding a controller/cinder node from fuel UI.

For each plugin, they handle the table data like below:


For line in lines:
Process line......

End


Any thoughts?

Thanks
Peter

-----Original Message-----
From: openstack-dev-request@lists.openstack.org [mailto:openstack-dev-request@lists.openstack.org]
Sent: Friday, October 21, 2016 8:00 PM
To: openstack-dev@lists.openstack.org
Subject: OpenStack-dev Digest, Vol 54, Issue 52

Send OpenStack-dev mailing list submissions to
openstack-dev@lists.openstack.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
or, via email, send a message with subject or body 'help' to
openstack-dev-request@lists.openstack.org

You can reach the person managing the list at
openstack-dev-owner@lists.openstack.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenStack-dev digest..."

Today's Topics:

  1. Re: Endpoint structure: a free-for-all (joehuang)
  2. [daisycloud-core] Agenda for IRC meeting 0800UTC Oct. 21 2016
    (hu.zhijiang@zte.com.cn)
  3. Participate in a Usability Study at Barcelona: Get a free
    bluetooth speaker and OpenStack t-shirt for your time
    (Kruithof Jr, Pieter)
  4. What do customers want?: Six studies conducted by the
    OpenStack UX project on behalf of the community (Kruithof Jr, Pieter)
  5. Re: [heat] Rolling Upgrades (Rabi Mishra)
  6. [OpenStack-dev][Fuel][Plugin] (nidhi.hada@wipro.com)
  7. Re: [api] [nova] microversion edge case query (Alex Xu)
  8. [Congress] IRC during summit (Eric K)
  9. Re: [neutron][calico][tempest][gate] Help setting up DSVM
    gate job for networking-calico (Kevin Benton)

    1. Re: [vitrage][aodh] about aodh notifier to create a event
      alarm (Afek, Ifat (Nokia - IL))
    2. Re: [release][ptl] pausing releases until 1 Nov (Julien Danjou)
    3. Re: [glance][VMT][Security] Glance coresec reorg (Flavio Percoco)
    4. Re: [neutron][calico][tempest][gate] Help setting up DSVM
      gate job for networking-calico (Neil Jerram)
    5. [Keystone][Design Session] Where to propose extensions to
      trusts? (Johannes Grassler)
    6. [daisycloud-core] Meeting minutes for IRC meeting 0800UTC
      Oct. 21 2016 (hu.zhijiang@zte.com.cn)
    7. Re: [OpenStack-dev][Fuel][Plugin] (Julia Aranovich)
    8. [all] Automation and self described APIs (Gilles Dubreuil)
    9. Re: Does it make sense to have self links to things that
      don't exist? (Chris Dent)
    10. [nova][cinder] Addressing mangled LUKS passphrases
      (bug#1633518) (Lee Yarwood)
    11. Re: Endpoint structure: a free-for-all (Chris Dent)
    12. Re: [all] indoor climbing break at summit? (Chris Dent)
    13. Re: Endpoint structure: a free-for-all (Doug Hellmann)
    14. Re: [api] [nova] microversion edge case query (Chris Dent)

Message: 1
Date: Fri, 21 Oct 2016 02:42:14 +0000
From: joehuang joehuang@huawei.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Endpoint structure: a free-for-all
Message-ID:
5E7A3D1BF5FD014E86E5F971CF446EFF559BC5E6@szxema505-mbx.china.huawei.com

Content-Type: text/plain; charset="us-ascii"

Hi,

I recalled one issue during using endpoint structure in public cloud
based on OpenStack.

Currently each service listens on its own port, the format of the endpoint
is like: service-specific ports, e.g., https://cloud.com:1234/v2

If the end user want to access Nova/Cinder/Neutron service endpoint
directly, for example using curl or other tools, then these ports 8774, 8776, 9696 have to be
exposed to the end user. Then you have to open these ports
in many devices if you want to provide these services in the public cloud directly to
end user. The more services are added to the public cloud, the more have to be
configured in these devices for security purpose.

From public cloud point of view, the port 80 will be opened by default, but if you have
to open so many non-80 ports, it brings additional work and challenge to manage these ports,
especially in firewalls, anti-DDoS, etc.

So I think that it would be better to use sub-domain or path to expose different
services end-point.

A. subdomains, e.g., https://service.cloud.com/v2
B. paths, e.g., https://cloud.com/service/v2

Best Regards
Chaoyi Huang (joehuang)


From: Brian Curtin [brian@python.org]
Sent: 19 October 2016 23:32
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] Endpoint structure: a free-for-all

I'm currently facing what looks more and more like an impossible
problem in determining the root of each service on a given cloud. It
is apparently a free-for-all in how endpoints can be structured, and I
think we're out of ways to approach it that catch all of the ways that
all people can think of.

In openstacksdk, we can no longer use the service catalog for
determining each service's endpoints. Among other things, this is due
to a combination of some versions of some services not actually being
listed, and with things heading the direction of version-less services
anyway. Recently we changed to using the service catalog as a pointer
to where services live and then try to find the root of that service
by stripping the path down and making some extra requests on startup
to find what's offered. Despite a few initial snags, this now works
reasonably well in a majority of cases.

We have seen endpoints structured in the following ways:
A. subdomains, e.g., https://service.cloud.com/v2
B. paths, e.g., https://cloud.com/service/v2 (sometimes there are
more paths in between the root and /service/)
C. service-specific ports, e.g., https://cloud.com:1234/v2
D. both A and B plus ports

Within all of these, we can find the root of the given service just
fine. We split the path and build successively longer paths starting
from the root. In the above examples, we need to hit the path just
short of the /v2, so in B it actually takes two requests as we'd make
one to cloud.com which fails, but then a second one to
cloud.com/service gives us what we need.

However, another case came up: the root of all endpoints is itself
another service. That makes it look like this:

E. https://cloud.com:9999/service/v2
F. https://cloud.com:9999/otherservice

In this case, https://cloud.com:9999 is keystone, so trying to get E's
base by going from the root and outward will give me a versions
response I can parse properly, but it points to keystone. We then end
up building requests for 'service' that go to keystone endpoints and
end up failing. We're doing this using itertools.accumulate on the
path fragments, so you might think 'just throw it through
reversed()' and go the other way. If we do that, we'll also get a
versions response that we can parse, but it's the v2 specific info,
not all available versions.

So now that we can't reliably go from the left, and we definitely
can't go from the right, how about the middle?

This sounds ridiculous, and if it sounds familiar it's because they
devise a "middle out" algorithm on the show Silicon Valley, but in
most cases it'd actually work. In E above, it'd be fine. However,
depending on the number of path fragments and which direction we chose
to move first, we'd sometimes hit either a version-specific response
or another service's response, so it's not reliable.

Ultimately, I would like to know how something like this can be solved.

  1. Is there any reliable, functional, and accurate programmatic way to
    get the versions and endpoints that all services on a cloud offer?

  2. Are there any guidelines, rules, expectations, or other
    documentation on how services can be installed and their endpoints
    structured that are helpful to people build apps that use them, not in
    those trying to install and operate them? I've looked around a few
    times and found nothing useful. A lot of what I've found has
    referenced suggestions for operators setting them up behind various
    load balancing tools.

  3. If 1 and 2 won't actually help me solve this, do you have any other
    suggestions that will? We already go left, right, and middle of each
    URI, so I'm out of directions to go, and we can't go back to the
    service catalog.

Thanks,

Brian


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

Message: 2
Date: Fri, 21 Oct 2016 11:12:14 +0800
From: hu.zhijiang@zte.com.cn
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [daisycloud-core] Agenda for IRC meeting
0800UTC Oct. 21 2016
Message-ID:
OF5F3A0595.970F811C-ON48258053.001178BE-48258053.00118AD1@zte.com.cn
Content-Type: text/plain; charset="US-ASCII"

1) Roll Call
2) OPNFV: Escalator Support
3) OPNFV: Daisy4nfv CI Framework Progress
4) Core Code Abstraction
5) Newton Release Related

B.R.,
Zhijiang


Message: 3
Date: Fri, 21 Oct 2016 03:20:01 +0000
From: "Kruithof Jr, Pieter" pieter.kruithof.jr@intel.com
To: "openstack-dev@lists.openstack.org"
openstack-dev@lists.openstack.org
Cc: "openstack-operators@lists.openstack.org"
openstack-operators@lists.openstack.org,
"user-committee@lists.openstack.org"
user-committee@lists.openstack.org
Subject: [openstack-dev] Participate in a Usability Study at
Barcelona: Get a free bluetooth speaker and OpenStack t-shirt for your
time
Message-ID: 60FF081C-DBD5-49A7-B624-B2F7583E6D1E@intel.com
Content-Type: text/plain; charset="utf-8"

Apologies for any cross-postings.

Hi Folks,

I wanted to send a second notice that there will be two usability studies being conducted in Barcelona with cloud operators. We had nearly a 100% show rate last summit and the results had a direct impact on the OpenStackClient. In fact, the results were shared at the OSC working session the next day.

Intel is providing a Philips bluetooth speaker to show our appreciation for your time. In addition, the foundation is providing a t-shirt to each person that participates in the study. I may even give anyone suffering from jetlag a Red Bull to get them through the day.


The first study will be on Monday, October 24th and is intended to investigate the current APIs to understand any specific pain points associated with completing tasks that span projects such as quotas. This study will last 45 minutes per operator.

You can schedule a time here:

http://doodle.com/poll/fwfi2sfcuctxv3u8

Note that you may need to set the time zone in Doodle to Spain > Ceuta


The second study will be on Tuesday, October 25th and is intended to investigate the OpenStackClient to understand any specific pain points and opportunities associated with completing tasks with the client. This study will last 45 minutes per operator. We ran a similar study at the previous summit and the feedback from users was that it was a good opportunity to ?test drive? the client with an OSC expert in the room with them.

You can schedule a time here:

http://doodle.com/poll/894aqsmheaa2mv5a

Note that you may need to set the time zone in Doodle to Spain > Ceuta

For both studies, someone with the OpenStack UX project will send you a calendar invite after you select a time(s) that are convenient for you.

Thanks,

Piet Kruithof
PTL OpenStack UX

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/0de6e75e/attachment-0001.html


Message: 4
Date: Fri, 21 Oct 2016 03:20:30 +0000
From: "Kruithof Jr, Pieter" pieter.kruithof.jr@intel.com
To: "openstack-dev@lists.openstack.org"
openstack-dev@lists.openstack.org,
"openstack-operators@lists.openstack.org"
openstack-operators@lists.openstack.org
Subject: [openstack-dev] What do customers want?: Six studies
conducted by the OpenStack UX project on behalf of the community
Message-ID: E0DA5CA7-83E2-44B9-875D-7A6296614876@intel.com
Content-Type: text/plain; charset="utf-8"

Hi Folks,

The OpenStack UX project and Intel have produced three booklets for the Barcelona OpenStack Summit based on the OpenStack UX?s work over the past six months.

The first is an overview of user research that was conducted on behalf of the OpenStack community including operator information needs, novice user experience for Horizon, OpenStackClient (OSC) validation and managing quotas at scale.

https://drive.google.com/file/d/0B8h-c0zHxYBoXzFMQWJsY09Eclk/view?usp=sharing

The second booklets include the OpenStack Personas and GUI Guidelines:

OpenStack Personas:
https://drive.google.com/file/d/0B8h-c0zHxYBoMXB4UVgtdFFsaDQ/view?usp=sharing

OpenStack GUI Guidelines:
https://drive.google.com/file/d/0B8h-c0zHxYBoV0tHV1l5bVpZZzg/view?usp=sharing


Unfortunately, we were unable to include the results for the searchlight/horizon integration as well as cloud architect information needs. However, the presentations are posted to the OpenStack UX YouTube channel.

https://www.youtube.com/channel/UCt6h129lzcjUqLDY005aCxw

The channel is updated regularly, so it may be worth checking from time to time.


For extra credit, my suggestion would be to read the ?State of OpenStack User Experience October 2016? which provides a succinct overview of the research that was conducted, why it matters, results, and recommendations.

https://docs.google.com/presentation/d/1hZYCOADJ1gXiFHT1ahwv8-tDIQCSingu7zqSMbKFZ_Y/edit?usp=sharing

Thanks,

Piet Kruithof
PTL OpenStack UX project
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/a395ede6/attachment-0001.html


Message: 5
Date: Fri, 21 Oct 2016 10:00:07 +0530
From: Rabi Mishra ramishra@redhat.com
To: cwolfe@redhat.com, "OpenStack Development Mailing List (not for
usage questions)" openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [heat] Rolling Upgrades
Message-ID:
CABJHmF7E+hZJs1YHZ-QMk8n5R+Jxr8Xjzm=v9qTTK6TtzQed6w@mail.gmail.com
Content-Type: text/plain; charset="utf-8"

Thanks Crag on starting the thread. Few comments inline.

On Fri, Oct 21, 2016 at 5:32 AM, Crag Wolfe cwolfe@redhat.com wrote:

At Summit, folks will be discussing the rolling upgrade issue across a
couple of sessions. I personally won't be able to attend, but thought
I would share my thoughts on the subject.

To handle rolling upgrades, there are two general cases to consider:
database model changes and RPC method signature changes.

For DB Model changes (this has already been well discussed on the
mailing list, see the footnotes), let's assume for the moment we don't
want to use triggers. If we are moving data from one column/table to
another, the pattern looks like:

legacy release: write to old location
release+1: write to old and new location, read from old
release+2: write to old and new location, read from new,
provide migration utility
release+3: write to new location, read from new

Not sure I understand this. Is it always about changing the table name or
column name of a table?
What about adding a new column to an existing table? I assume the db api
implementation have to ignore the additional column values when writing to
old location.

Works great! The main issue is if the duplicated old and new data
happens to be large. For a heat-specific example (one that is close to
my heart), consider moving resource/event properties data into a
separate table.

We could speed up the process by adding config variables that specify
where to read from, but that is putting a burden on the operator,
creating a risk that data is lost if the config variables are not
updated in the correct order after each full rolling restart, etc.

Which brings us back to triggers. AFAIK, only sqlalchemy+mariadb is
being used in production, so we really only have one backend we would
have to write triggers for. If the data duplication is too unpalatable
for a given migration (using the +1, +2, +3 pattern above), we may
have to wade into the less simple world of triggers.

I think we can only enable the trigger during the upgrade process and then
disable it.

For RPC changes, we don't have a great solution right now (looking
specifically at heat/engine/service.py). If we add a field, an older
running heat-engine will break if it receives a request from a newer
running heat-engine. For a relevant example, consider adding the
"root_id" as an argument (
https://review.openstack.org/#/c/354621/13/heat/engine/service.py ).

Looking for the simplest solution -- if we introduce a mandatory
"future_args" arg (a dict) now to all rpc methods (perhaps provide a
decorator to do so), then we could follow this pattern post-Ocata:

legacy release: accepts the futureargs param (but does nothing with it).
release+1: accept the new parameter with a default of None,
pass the value of the new parameter in future
args.
release+2: accept the new parameter, pass the value of the new parameter
in its proper placeholder, no longer in future_args.

This is something similar to the one is being used by neutron for the
agents,
i.e consistently capturing those new/unknown arguments with keyword
arguments
and ignoring them on agent side; and by not enforcing newer RPC entry point
versions on server side. However, this makes the rpc api less strict and
not ideal.

The best way would be do some kind of rpc pinning on the new engines when
they send messages(new engines can receive old messages). I was also
wondering
if it's possible/good idea to restrict engines not to communicate with
other engines
only during the upgrade process.

But, we don't have a way of deleting args. That's not super

awful... old args never die, they just eventually get ignored. As for
adding new api's, the pattern would be to add them in release+1, but
not call them until release+2. [If we really have a case where we need
to add and use a new api in release+1, the solution may be to have two
rpc api messaging targets in release+1, one for the previous
major.minor release and another for the major+1.0 release that has the
new api. Then, we of course we could remove outdated args in
major+1.0.]

I'm not sure we ever delete args, as we make the rpc servers backward
compatible.

Finally, a note about Oslo versioned objects: they don't really help
us. They work great for nova where there is just nova-conductor
reading and writing to the DB, but we have multiple heat-engines doing
that that need to be restarted in a rolling manner. See the references
below for greater detail.

--Crag

References


[openstack-dev] [Heat] Versioned objects upgrade patterns
http://lists.openstack.org/pipermail/openstack-dev/2016-
May/thread.html#95245

[openstack-dev] [keystone][nova][neutron][all] Rolling upgrades:
database triggers and oslo.versionedobjects
http://lists.openstack.org/pipermail/openstack-dev/2016-
September/102698.html
http://lists.openstack.org/pipermail/openstack-dev/2016-
October/105764.html


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

--
Regards,
Rabi Misra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/9c5274fc/attachment-0001.html


Message: 6
Date: Fri, 21 Oct 2016 05:16:08 +0000
From: nidhi.hada@wipro.com
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [OpenStack-dev][Fuel][Plugin]
Message-ID:
SIXPR0301MB13386D15FF13B35C13865D0486D40@SIXPR0301MB1338.apcprd03.prod.outlook.com

Content-Type: text/plain; charset="iso-8859-1"

Hi All,

This is regarding an info required for fuel plugin development.

We are working on Fuel Cinder Plugin where we require to

configure multiple 'n' number of backends of storage vendor ,

in one go, from Fuel UI screen. where 'n' will be known at run time.

Its like from UI, I can configure a set of fields, [field1, field2, field3]

for one backend and if user ask to configure 'n' backends then same

set of fields to be asked repeatedly.

I have found some similar provision was planned in

https://blueprints.launchpad.net/fuel/+spec/dynamic-fields

But when i see implementation https://review.openstack.org/#/q/topic:bp/dynamic-fields,n,z

which implements new type as textlist and textarealist ..

which is capability to add multiple lines of text in single field..

It does not look like same as aim of BP, where acceptance criteria for BP is

"Enable text and textarea field types to be extended - where a plugin user is able to toggle the visibility of additional fields with +/- signs and the data provided is used by plugin"

Kindly correct my understanding if its wrong, do we have capability to add a text field by pressing +/- ?

What capability do we have with Fuel UI to add fields dynamically today ?

I have read https://openstack.nimeyo.com/44264/openstack-dev-fuel-interaction-between-fuel-plugin-and-fuel

[openstack-dev] [Fuel] interaction between fuel-plugin and fuel-UI - OpenStack Mailing List Archivehttps://openstack.nimeyo.com/44264/openstack-dev-fuel-interaction-between-fuel-plugin-and-fuel
openstack.nimeyo.com
Hi all, I am working on two plugins for fuel : logrotate and cinder-netapp (to add ... /lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

where suggestions are made to use restrictions to hide display components.

Another suggestion is to use comma separated values.

But its an year back post, do we have a better solution today ?

Will be helpful if someone can suggest how do we achieve it in fuel UI.

Thanks

Nidhi

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/f7954eeb/attachment-0001.html


Message: 7
Date: Fri, 21 Oct 2016 14:20:39 +0800
From: Alex Xu soulxu@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [api] [nova] microversion edge case query
Message-ID:
CAH7mGauaFBeGt9njyBfg2Y840exN6i_3FdJS0p+K91yLrBAU_Q@mail.gmail.com
Content-Type: text/plain; charset="utf-8"

2016-10-19 0:58 GMT+08:00 Ed Leafe ed@leafe.com:

On Oct 18, 2016, at 11:01 AM, Chris Dent cdent+os@anticdent.org wrote:

If the requested microversion is greater than the maximum, a 404 still
makes some sense (no mapping now), but a 406 could as well because it
provides a signal that if you used a different microversion the
situation could be different and the time represented by the
requested microversion has conceptual awareness of its past.

What do people think?

I think I recall there was some discussion of this sort of thing
with regard to some of the proxy APIs at the nova midcycle but I
can't remember the details of the outcome.

The only way that that could happen (besides a total collapse of the
review process) is when a method is removed from the API. When that
happens, the latest version has its max set to the last microversion where
that method is supported. For microversions after that, 404 is the correct
response. For all other methods, the latest version should not have a
maximum specified.

Also think 404 is right at here. If you return 406 and it is a signal that
if you used a different microversion the situation could be different, the
thing will become strange when we raise the acceptable min_version someday.

-- Ed Leafe


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/6cff826b/attachment-0001.html


Message: 8
Date: Fri, 21 Oct 2016 00:03:21 -0700
From: Eric K ekcs.openstack@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Congress] IRC during summit
Message-ID: D42F04D8.3F4BA%ekcs.openstack@gmail.com
Content-Type: text/plain; charset="iso-8859-1"

Hi all!

To help us connect and coordinate during the upcoming summit, those who are
interested can try IRCcloud (https://www.irccloud.com ; suggested by aimeeu)
to communicate over the #congress channel. The service acts as an IRC
bouncer to keep your nick connected and send push notifications to the
mobile app. I just tried it out and it works pretty well.

To be notified of all messages on the channel, set your mobile app to
?Notify on all messages? (under display options). To be notified only of
messages that mention your nick, just keep the default settings.

See you all at the summit soon!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/91e6e835/attachment-0001.html


Message: 9
Date: Fri, 21 Oct 2016 00:05:27 -0700
From: Kevin Benton kevin@benton.pub
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron][calico][tempest][gate] Help
setting up DSVM gate job for networking-calico
Message-ID:
CAO_F6JM9efO-=nDb+fOzYCg0ogDOL_D1_9XCPmaSr39Ombk4Yg@mail.gmail.com
Content-Type: text/plain; charset="utf-8"

Left a comment on your patch. Looks like you have tempest disabled in your
devstack settings file.

On Thu, Oct 20, 2016 at 4:34 AM, Neil Jerram neil@tigera.io wrote:

I'm trying to set up a dsvm gate job for networking-calico [1] - which I
think means
- using DevStack to set up a single combined controller/compute node, with
networking-calico settings and plugin [2]
- using Tempest to run some tests on that; ideally including some
networking-related tests :-)

Unfortunately it doesn't run well yet [3][4]: I see tests failing because
of something to do with credentials, and that also seem unrelated to
networking, and I'm not sure if any networking-related tests are running.

I've tried comparing against the similar job for networking-ovn [5][6].
Before the point where Tempest starts reporting success/failure of
individual tests, the only notable difference I see is that the
networking-calico output has:

sed: can't read /opt/stack/new/tempest/etc/tempest.conf: No such file or
directory
Running tempest with a custom regex filter
all create: /opt/stack/new/tempest/.tox/tempest
all installdeps: setuptools, -r/opt/stack/new/tempest/requirements.txt
all develop-inst: /opt/stack/new/tempest

where the networking-ovn output only has:

Running tempest with a custom regex filter
all develop-inst-noop: /opt/stack/new/tempest

Is that significant?

Then the next, very obvious, difference is that the networking-calico
output seems to have the results of individual tests all jumbled up - like
output from multiple threads without a lock:

${PYTHON:-python} -m subunit.run discover -t ${OSTOPLEVEL:-./}
${OSTESTPATH:-./tempest/testdiscover} --load-list /tmp/tmpGuFAar
2016-10-19 17:43:01.981 30902 INFO tempest [-] Using tempest config file
/etc/tempest/tempest.conf
2016-10-19 17:43:02.005 30904 INFO tempest [-] Using tempest confi20g1
6file -/10e-19tc/te mp1e7s:4t3:/te02.030m 3pe0s908t INFO. tceonf
mpest [-] Using tempest config file /etc/tempest/tempest.co20n1f6
-10-19 17:43:02.059 30906 INFO tempest [-] Using tempest config file
/etc/tempest/tempest.conf
{0} setUpClass (tempest.api.baremetal.admin.test
apidiscovery.TestApiDiscovery)
... SKIPPED: TestApiDiscovery skipped as Ironic is not available
2016-10-19 17:43:02.373 30902 INFO tempest.test [-] raised in
AgentsAdminTestJSON.setUpClass. Invoking tearDownClass.
{3} setUpClass (tempest.api.baremetal.admin.test
nodes.TestNodes) ...
SKIPPED: TestNodes skipped as Ironic is not available
{2} setUpClass (tempest.api.baremetal.admin.testdrivers.TestDrivers) ...
SKIPPED: TestDrivers skipped as Ironic is not available
{2} setUpClass (tempest.api.baremetal.admin.test
portsnegative.TestPortsNegative)
... SKIPPED: TestPortsNegative skipped as Ironic is not available
20{3} setUpClass (tempest.api.baremetal.admin.test
nodestates.TestNodeStates)
... SKIPPED: TestNodeStates skipped as Ironic is not available
16{0} setUpClass (tempest.api.compute.admin.testagents.AgentsAdminTestJSON)
[0.000000s] ... FAILED
2{3} setUpClass (tempest.api.baremetal.admin.test
ports.TestPorts) ...
SKIPPED: TestPorts skipped as Ironic is not available
021-106-1-016190- -111097:- 147:13:9403:2. 104728.32 :4{1} setUpClass
(tempest.api.baremetal.admin.test_chassis.TestChassis) ... SKIPPED:
TestChassis skipped as Ironic is not available
23:3020.41356 7-9 0931300006 INFO tempest.test [-] 4 IN class resFa't.O teitesmpstt
eedst.teste[ -mp] [- in]e< s cBtl<.aarlisb.ecmetexalceptions.Invs
'temNodesAdminTestJSON.setUpCalpesidCredentitlaa.lliss 'teb.eassxce.
Inlspmtvoki'>on ras.piieInng vassliedtdC i.lrn Agitgeber.
aeergaxDcdteoepesntAdtiwmioniannlCsN'el>sga .asrItsan.iiv

whereas the networking-ovn output looks neat:

${PYTHON:-python} -m subunit.run discover -t ${OSTOPLEVEL:-./}
${OSTESTPATH:-./tempest/testdiscover} --load-list /tmp/tmpluSDt
{0} setUpClass (tempest.api.baremetal.admin.testnodestates.TestNodeStates)
... SKIPPED: TestNodeStates skipped as Ironic is not available
{2} setUpClass (tempest.api.baremetal.admin.test
apidiscovery.TestApiDiscovery)
... SKIPPED: TestApiDiscovery skipped as Ironic is not available
{2} setUpClass (tempest.api.baremetal.admin.test
ports.TestPorts) ...
SKIPPED: TestPorts skipped as Ironic is not available
{3} setUpClass (tempest.api.baremetal.admin.testchassis.TestChassis) ...
SKIPPED: TestChassis skipped as Ironic is not available
{1} setUpClass (tempest.api.baremetal.admin.test
drivers.TestDrivers) ...
SKIPPED: TestDrivers skipped as Ironic is not available
{1} setUpClass (tempest.api.baremetal.admin.testnodes.TestNodes) ...
SKIPPED: TestNodes skipped as Ironic is not available
{1} setUpClass (tempest.api.baremetal.admin.test
portsnegative.TestPortsNegative)
... SKIPPED: TestPortsNegative skipped as Ironic is not available
{1} setUpClass (tempest.api.compute.admin.test
baremetalnodes.BaremetalNodesAdminTestJSON)
... SKIPPED: BaremetalNodesAdminTestJSON skipped as Ironic is not available
{1} tempest.api.compute.admin.test
flavors.FlavorsAdminTestJSON.testcreateflavorusingstringram
[0.232261s] ... ok
{1} tempest.api.compute.admin.test
flavors.FlavorsAdminTestJSON.test_
createflavorverifyentryinlistdetails [0.101537s] ... ok
{1} tempest.api.compute.admin.testflavors.FlavorsAdminTestJSON.testcreateflavorwithintid
[0.081664s] ... ok
{1} tempest.api.compute.admin.testflavors.FlavorsAdminTestJSON.testcreateflavorwithnoneid
[0.079674s] ... ok
{1} tempest.api.compute.admin.testflavors.FlavorsAdminTestJSON.testcreateflavorwithuuidid
[0.075899s] ... ok
{1} tempest.api.compute.admin.testflavors.FlavorsAdminTestJSON.test
createlistflavorwithoutextra_data [0.409597s] ... ok

I would appreciate any help as regards what I'm doing wrong here.

Thanks,
Neil

[1] http://git.openstack.org/cgit/openstack-infra/project-
config/tree/jenkins/jobs/networking-calico.yaml
[2] http://git.openstack.org/cgit/openstack/networking-calico/
tree/devstack
[3] https://review.openstack.org/#/c/339263/
[4] http://logs.openstack.org/63/339263/5/experimental/gate-
tempest-dsvm-networking-calico-nv/8d47b1c/console.html
[5] http://git.openstack.org/cgit/openstack-infra/project-
config/tree/jenkins/jobs/networking-ovn.yaml
[6] http://logs.openstack.org/16/386016/1/check/gate-tempest-
dsvm-networking-ovn/4e3924f/console.html.gz


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/12558dc1/attachment-0001.html


Message: 10
Date: Fri, 21 Oct 2016 07:21:51 +0000
From: "Afek, Ifat (Nokia - IL)" ifat.afek@nokia.com
To: "dong.wenjuan@zte.com.cn" dong.wenjuan@zte.com.cn, gordon chung
gord@live.ca
Cc: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [vitrage][aodh] about aodh notifier to
create a event alarm
Message-ID: AA498EFB-1739-43B4-8021-89DCEC588DC3@alcatel-lucent.com
Content-Type: text/plain; charset="utf-8"

dwj,

This would be great! Thanks for your help.

Ifat.

From: "dong.wenjuan@zte.com.cndong.wenjuan@zte.com.cn"
Date: Friday, 21 October 2016 at 04:14
To: "Afek, Ifat (Nokia - IL)", gordon chung
Cc: "OpenStack Development Mailing List (not for usage questions)"
Subject: ??: Re: ??: Re: [openstack-dev] [vitrage][aodh] about aodh notifier to create a event alarm

Hi All,

I think it's clear now.
We can start to implement the Aodh-message-bus-notificationsBP. :)
Thanks~

BR,
dwj

"Afek, Ifat (Nokia - IL)" <ifat.afek@nokia.comifat.afek@nokia.com>

2016-10-21 01:23

???
gordon chung <gord@live.cagord@live.ca>, "dong.wenjuan@zte.com.cndong.wenjuan@zte.com.cn" <dong.wenjuan@zte.com.cndong.wenjuan@zte.com.cn>
??
"OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.orgopenstack-dev@lists.openstack.org>
??
Re: ??: Re: [openstack-dev] [vitrage][aodh] about aodh notifier to create a event alarm

On 20/10/2016, 20:14, "gordon chung" <gord@live.cagord@live.ca> wrote:

On 20/10/16 01:01 PM, Afek, Ifat (Nokia - IL) wrote:

Well? long time ago I asked to add another notification topic to Aodh, and you said that you blocked it. If that?s not the case, everything is fine :-)
Like I said before, we planned on implementing it in Newton, but unfortunately it didn?t happen. I really hope to improve the Vitrage-Aodh integration in Ocata.

Ifat.

i see. i wasn't being critical about no work but i'll be honest, i don't
remember what this is about since i was looking at other stuff so if you
have a patch/ML to refresh my memory, that'd help.

this is the only thread[1] i recall, and even then, i don't remember
much about it. :(

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-June/098074.html

cheers,

--
gord

What I recall was a few months earlier, we had a chat on ceilometer IRC channel? not sure if I can find the exact date.
Anyway, I guess it doesn?t matter now. If you think the change can be done, then great.

Ifat.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/2e94d9dc/attachment-0001.html


Message: 11
Date: Fri, 21 Oct 2016 09:40:51 +0200
From: Julien Danjou julien@danjou.info
To: Emilien Macchi emilien@redhat.com
Cc: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [release][ptl] pausing releases until 1
Nov
Message-ID: m0lgxib14s.fsf@danjou.info
Content-Type: text/plain; charset="us-ascii"

On Thu, Oct 20 2016, Emilien Macchi wrote:

I take this opportunity to thank doug/dims/ttx for their hard work on
release management; they always help PTLs in a productive and
responsive way to reach the goals.
As a PTL, I always feel happy to deal with release management assisted
by such a great team, with nice tools like reno and openstack/releases
repo.

Ditto.

Also I'd like to emphasize how happy I become dealing with the
openstack/releases repository even and especially for independent
projects, where nothing peculiar has been implemented. :-)

--
Julien Danjou
/* Free Software hacker
https://julien.danjou.info */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/cb62103b/attachment-0001.pgp


Message: 12
Date: Fri, 21 Oct 2016 10:07:12 +0200
From: Flavio Percoco flavio@redhat.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [glance][VMT][Security] Glance coresec
reorg
Message-ID: 20161021080712.lpr3xhkupwrbbvmx@redhat.com
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On 20/10/16 12:33 -0700, Steve Lewis wrote:

I'm not voicing as a core here, but in the course of several cycles I have
seen Erno and Ian each providing the care and insight needed by this role
and trust them to do the job well.

+1k to the above!

Thank you both for stepping up for this critical task.
Flavio

On Wed, Oct 19, 2016 at 3:50 PM, Jeremy Stanley fungi@yuggoth.org wrote:

On 2016-10-18 22:22:28 +0000 (+0000), Brian Rosmaita wrote:

Thus, the main point of this email is to propose Ian Cordasco and Erno
Kuvaja as new members of the Glance coresec team. They've both been
Glance cores for several cycles, have a broad knowledge of the software
and team, contribute high-quality reviews, and are conversant with good
security practices.
[...]

Sounds good to me. From a VMT perspective, I'm just happy to see
Glance keeping active participants with available bandwidth looking
at prospective vulnerability reports so we can continue to churn
through them faster and make them public sooner. Thanks for keeping
the wheels turning!
--
Jeremy Stanley


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

--
SteveL


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

--
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 847 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/131e9b81/attachment-0001.pgp


Message: 13
Date: Fri, 21 Oct 2016 08:51:06 +0000
From: Neil Jerram neil@tigera.io
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron][calico][tempest][gate] Help
setting up DSVM gate job for networking-calico
Message-ID:
CAMGh4hMMnCdQ1Do8x-ohWtzJymekMkvA3UN=CMsziP0QXhJgYQ@mail.gmail.com
Content-Type: text/plain; charset="utf-8"

Thanks very much, Kevin. After removing that line that disables tempest,
things are looking a lot saner [1]. There are still other detailed things
wrong with the config, and failures to look at, but I think I know how to
attack those now.

(I also realized, from your help, that networking-calico/devstack/settings
is incorrectly confusing two things: (a) What is a minimal complete
devstack configuration, to demonstrate networking-calico function? and (b)
What are the changes to devstack configuration that should be made if
someone decides to do 'enable_plugin networking-calico'? So I'll also see
about de-confusing that.)

  Neil

[1]
http://logs.openstack.org/63/339263/6/experimental/gate-tempest-dsvm-networking-calico-nv/3639cd8/console.html

On Fri, Oct 21, 2016 at 8:06 AM Kevin Benton kevin@benton.pub wrote:

Left a comment on your patch. Looks like you have tempest disabled in your
devstack settings file.

On Thu, Oct 20, 2016 at 4:34 AM, Neil Jerram neil@tigera.io wrote:

I'm trying to set up a dsvm gate job for networking-calico [1] - which I
think means
- using DevStack to set up a single combined controller/compute node, with
networking-calico settings and plugin [2]
- using Tempest to run some tests on that; ideally including some
networking-related tests :-)

Unfortunately it doesn't run well yet [3][4]: I see tests failing because
of something to do with credentials, and that also seem unrelated to
networking, and I'm not sure if any networking-related tests are running.

I've tried comparing against the similar job for networking-ovn [5][6].
Before the point where Tempest starts reporting success/failure of
individual tests, the only notable difference I see is that the
networking-calico output has:

sed: can't read /opt/stack/new/tempest/etc/tempest.conf: No such file or
directory
Running tempest with a custom regex filter
all create: /opt/stack/new/tempest/.tox/tempest
all installdeps: setuptools, -r/opt/stack/new/tempest/requirements.txt
all develop-inst: /opt/stack/new/tempest

where the networking-ovn output only has:

Running tempest with a custom regex filter
all develop-inst-noop: /opt/stack/new/tempest

Is that significant?

Then the next, very obvious, difference is that the networking-calico
output seems to have the results of individual tests all jumbled up - like
output from multiple threads without a lock:

${PYTHON:-python} -m subunit.run discover -t ${OSTOPLEVEL:-./}
${OSTESTPATH:-./tempest/testdiscover} --load-list /tmp/tmpGuFAar
2016-10-19 17:43:01.981 30902 INFO tempest [-] Using tempest config file
/etc/tempest/tempest.conf
2016-10-19 17:43:02.005 30904 INFO tempest [-] Using tempest confi20g1
6file -/10e-19tc/te mp1e7s:4t3:/te02.030m 3pe0s908t INFO. tceonf
mpest [-] Using tempest config file /etc/tempest/tempest.co20n1f6
-10-19 17:43:02.059 30906 INFO tempest [-] Using tempest config file
/etc/tempest/tempest.conf
{0} setUpClass
(tempest.api.baremetal.admin.test
apidiscovery.TestApiDiscovery) ...
SKIPPED: TestApiDiscovery skipped as Ironic is not available
2016-10-19 17:43:02.373 30902 INFO tempest.test [-] raised in
AgentsAdminTestJSON.setUpClass. Invoking tearDownClass.
{3} setUpClass (tempest.api.baremetal.admin.test
nodes.TestNodes) ...
SKIPPED: TestNodes skipped as Ironic is not available
{2} setUpClass (tempest.api.baremetal.admin.testdrivers.TestDrivers) ...
SKIPPED: TestDrivers skipped as Ironic is not available
{2} setUpClass
(tempest.api.baremetal.admin.test
portsnegative.TestPortsNegative) ...
SKIPPED: TestPortsNegative skipped as Ironic is not available
20{3} setUpClass
(tempest.api.baremetal.admin.test
nodestates.TestNodeStates) ... SKIPPED:
TestNodeStates skipped as Ironic is not available
16{0} setUpClass
(tempest.api.compute.admin.testagents.AgentsAdminTestJSON) [0.000000s] ...
FAILED
2{3} setUpClass (tempest.api.baremetal.admin.test
ports.TestPorts) ...
SKIPPED: TestPorts skipped as Ironic is not available
021-106-1-016190- -111097:- 147:13:9403:2. 104728.32 :4{1} setUpClass
(tempest.api.baremetal.admin.test_chassis.TestChassis) ... SKIPPED:
TestChassis skipped as Ironic is not available
23:3020.41356 7-9 0931300006 INFO tempest.test [-] 4 IN class resFa't.O teitesmpstt
eedst.teste[ -mp] [- in]e< s cBtl<.aarlisb.ecmetexalceptions.Invs
'temNodesAdminTestJSON.setUpCalpesidCredentitlaa.lliss 'teb.eassxce.
Inlspmtvoki'>on ras.piieInng vassliedtdC i.lrn
Agitgeber.aeergaxDcdteoepesntAdtiwmioniannlCsN'el>sga .asrItsan.iiv

whereas the networking-ovn output looks neat:

${PYTHON:-python} -m subunit.run discover -t ${OSTOPLEVEL:-./}
${OSTESTPATH:-./tempest/testdiscover} --load-list /tmp/tmpluSDt
{0} setUpClass
(tempest.api.baremetal.admin.testnodestates.TestNodeStates) ... SKIPPED:
TestNodeStates skipped as Ironic is not available
{2} setUpClass
(tempest.api.baremetal.admin.test
apidiscovery.TestApiDiscovery) ...
SKIPPED: TestApiDiscovery skipped as Ironic is not available
{2} setUpClass (tempest.api.baremetal.admin.test
ports.TestPorts) ...
SKIPPED: TestPorts skipped as Ironic is not available
{3} setUpClass (tempest.api.baremetal.admin.testchassis.TestChassis) ...
SKIPPED: TestChassis skipped as Ironic is not available
{1} setUpClass (tempest.api.baremetal.admin.test
drivers.TestDrivers) ...
SKIPPED: TestDrivers skipped as Ironic is not available
{1} setUpClass (tempest.api.baremetal.admin.testnodes.TestNodes) ...
SKIPPED: TestNodes skipped as Ironic is not available
{1} setUpClass
(tempest.api.baremetal.admin.test
portsnegative.TestPortsNegative) ...
SKIPPED: TestPortsNegative skipped as Ironic is not available
{1} setUpClass
(tempest.api.compute.admin.test
baremetalnodes.BaremetalNodesAdminTestJSON)
... SKIPPED: BaremetalNodesAdminTestJSON skipped as Ironic is not available
{1}
tempest.api.compute.admin.test
flavors.FlavorsAdminTestJSON.testcreateflavorusingstringram
[0.232261s] ... ok
{1}
tempest.api.compute.admin.test
flavors.FlavorsAdminTestJSON.testcreateflavorverifyentryinlistdetails
[0.101537s] ... ok
{1}
tempest.api.compute.admin.test
flavors.FlavorsAdminTestJSON.testcreateflavorwithintid
[0.081664s] ... ok
{1}
tempest.api.compute.admin.test
flavors.FlavorsAdminTestJSON.testcreateflavorwithnoneid
[0.079674s] ... ok
{1}
tempest.api.compute.admin.test
flavors.FlavorsAdminTestJSON.testcreateflavorwithuuidid
[0.075899s] ... ok
{1}
tempest.api.compute.admin.test
flavors.FlavorsAdminTestJSON.testcreatelistflavorwithoutextradata
[0.409597s] ... ok

I would appreciate any help as regards what I'm doing wrong here.

Thanks,
Neil

[1]
http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/networking-calico.yaml
[2]
http://git.openstack.org/cgit/openstack/networking-calico/tree/devstack
[3] https://review.openstack.org/#/c/339263/
[4]
http://logs.openstack.org/63/339263/5/experimental/gate-tempest-dsvm-networking-calico-nv/8d47b1c/console.html
[5]
http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/networking-ovn.yaml
[6]
http://logs.openstack.org/16/386016/1/check/gate-tempest-dsvm-networking-ovn/4e3924f/console.html.gz


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/0610e6ce/attachment-0001.html


Message: 14
Date: Fri, 21 Oct 2016 11:01:53 +0200
From: Johannes Grassler jgrassler@suse.de
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Keystone][Design Session] Where to propose
extensions to trusts?
Message-ID: 41b5666f-3c09-eb8d-537e-5d56fafaefeb@suse.de
Content-Type: text/plain; charset=utf-8; format=flowed

Hello,

I've got a last minute proposal, or rather two of them for the Keystone side of
the design sessions in Barcelona. I guess it's something that would fit the
Authorization work session on Friday (09:00-09:40) but I'm not sure I can
simply add it on the Etherpad. Also, I may not able to attend the session in
person since I'll need to join the Barbican session in the same time slot as
well[0], so I'd appreciate an alternative venue if that's possible.

Hence I'll put them forth here for now:

  1. Scope extensions for trusts
    ==============================

Various services (Magnum, Heat, maybe Neutron LBaaS soon) use Keystone trusts to
grant their service users or dedicated trustee users limited rights for various
purposes, such as deferred operations on behalf of the user or providing access to
certificate containers. These trusts can only be limited to a set of roles in a
given project right now. The Admin guide mentions an endpoint limitation on top of
that, but I haven't found any code in Keystone for handling that. I played with it
a bit and found that every keyword argument Keystone doesn't know what to do
with ends up in the trust table's extra column, but there's no code for doing
anything with it as far as I can tell. It would be a useful thing, though and
implementing it goes hand in hand with my proposal: I'd like to see an ability
to scope trusts to:

1) A subset of endpoints (i.e. "This trust may only access Barbican's internalURL and nothing else")
2) A fixed path (i.e. "This trust may only access /v1/secrets/238ca94d-6115-4fe6-b41f-c445eeb47df8)
3) A fixed URL (i.e. "This trust may only access
http://192.168.123.20:9311/v1/secrets/238ca94d-6115-4fe6-b41f-c445eeb47df8)

The main thing I'm currently interested in is whether this is feasible. If so,
I'd be happy to work on a blueprint and implementation. I believe this is
really important to allow services and users to limit trusts to exactly the
access level needed and not a bit more.

  1. Lightweight trusts
    =====================

When Keystone trusts are created the current practice is to either

1) Delegate the trust to a service user using the trust (example: Heat)
2) Create a dedicated trustee user for delegating the trust to (example:
Magnum)

(1) is fine as far as I'm concerned, but I think (2) could do with some
improvement. The dedicated trustee user will have a user name and password that
needs to be used to authenticate as that user (along with a trust ID to consume
the trust). I'd rather see a long-lived trust token scoped to the trust that
can be extended upon expiry for that purpose. Just like a regular token, in
other words. For the following reasons:

1) Everybody who creates such a user will have different idea of a secure
password length. A token is generated by keystone in a centralized manner
and always of a sufficient length to make for a secure secret.
2) It requires third party software that may need to authenticate as the
trustee to be aware of trusts. Example: Kubernetes' Cinder volume driver
(used by Magnum). Most such software should be able to handle an auth
token, on the other hand.
3) There is less cleanup required after the trust has served its purpose:
only the trust needs to be deleted at that point, but no trustee user.

Comments on these two proposals (and advice on a suitable forum for discussing
them at the summit) would be greatly appreciated. Thank you!

Cheers,

Johannes

Footnotes:

[0] In a pinch I could probably ask a colleague to stand in for me, but I'd
prefer a solution where I can be present for both discussions.

--
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG N?rnberg)
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
Maxfeldstr. 5, 90409 N?rnberg, Germany


Message: 15
Date: Fri, 21 Oct 2016 17:08:57 +0800
From: hu.zhijiang@zte.com.cn
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [daisycloud-core] Meeting minutes for IRC
meeting 0800UTC Oct. 21 2016
Message-ID:
OFDF353D09.BB96A698-ON48258053.00321B98-48258053.00323315@zte.com.cn
Content-Type: text/plain; charset="US-ASCII"

Minutes:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-10-21-07.59.html

Minutes (text):
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-10-21-07.59.txt

Log:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-10-21-07.59.log.html

B.R.,
Zhijiang


Message: 16
Date: Fri, 21 Oct 2016 09:19:40 +0000
From: Julia Aranovich jkirnosova@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [OpenStack-dev][Fuel][Plugin]
Message-ID:
CAMfgBLVa61Gz4Rtzu+F4PVOWby1gQdAgqmSFpJmPpGpvRqB61A@mail.gmail.com
Content-Type: text/plain; charset="utf-8"

Hi Nidhi,

This implemented https://blueprints.launchpad.net/fuel/+spec/dynamic-fields
blueprint provided an ability to use "textlist" and "textarealist" UI
control types.
They are suitable for settings where the value is a list of strings.
These controls represent on UI a list of single or multiline text inputs
with +/- buttons to add/remove an additional element:

My Setting value1 +/-
value2 +/-
value3 +/-
(the result value for the setting "My Setting" is ['value1', 'value2',
'value3']).

If I understand your case properly, you need something like dynamic groups
of inputs of different type.
This is still not supported by Fuel UI. The implementation does not look
simple, it requires changing of data structure in settings yaml, adding a
new level of nesting. There is a need to think thoroughly about the
details: how to organize such a setting yaml structure, how to declare a
set of inputs in such a group, how inputs should be aligned in the group
(horizontally/vertically), etc.

For now, I would suggest the following ways of how to organize your plugin
settings:

1) use textlist/textarealist controls for each field from a group that
represents storage backend configuration:

Field1 valueforbackend1 +/-
value
forbackend2 +/-
valueforbackend_3 +/-

Field2 valueforbackend1 +/-
value
forbackend2 +/-
valueforbackend_3 +/-

Field3 valueforbackend1 +/-
value
forbackend2 +/-
valueforbackend_3 +/-

2) use textlist/textarealist controls to configure a list of storage
backends by declaring their settings as a single comma-separated string:

Backends Settings commaseparatedsettingsforbackend1 +/-
comma
separatedsettingsforbackend2 +/-
commaseparatedsettingsforbackend_3 +/-

From my point of view, the first version looks more clear. Will it
suit your case, Nidhi?

Best regards,
Julia

On Fri, Oct 21, 2016 at 8:17 AM nidhi.hada@wipro.com wrote:

Hi All,

This is regarding an info required for fuel plugin development.

We are working on Fuel Cinder Plugin where we require to

configure multiple 'n' number of backends of storage vendor ,

in one go, from Fuel UI screen. where 'n' will be known at run time.

Its like from UI, I can configure a set of fields, [field1, field2,
field3]

for one backend and if user ask to configure 'n' backends then same

set of fields to be asked repeatedly.

I have found some similar provision was planned in

https://blueprints.launchpad.net/fuel/+spec/dynamic-fields

But when i see implementation
https://review.openstack.org/#/q/topic:bp/dynamic-fields,n,z

which implements new type as textlist and textarealist ..

which is capability to add multiple lines of text in single field..

It does not look like same as aim of BP, where acceptance criteria for BP
is

"Enable text and textarea field types to be extended - where a plugin user
is able to toggle the visibility of additional fields with +/- signs and
the data provided is used by plugin"

Kindly correct my understanding if its wrong, do we have capability to add
a text field by pressing +/- ?

What capability do we have with Fuel UI to add fields dynamically today ?

I have read
https://openstack.nimeyo.com/44264/openstack-dev-fuel-interaction-between-fuel-plugin-and-fuel

[openstack-dev] [Fuel] interaction between fuel-plugin and fuel-UI -
OpenStack Mailing List Archive
https://openstack.nimeyo.com/44264/openstack-dev-fuel-interaction-between-fuel-plugin-and-fuel
openstack.nimeyo.com
Hi all, I am working on two plugins for fuel : logrotate and cinder-netapp
(to add ... /lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

where suggestions are made to use restrictions to hide display components.

Another suggestion is to use comma separated values.

But its an year back post, do we have a better solution today ?

Will be helpful if someone can suggest how do we achieve it in fuel UI.

Thanks

Nidhi

The information contained in this electronic message and any attachments
to this message are intended for the exclusive use of the addressee(s) and
may contain proprietary, confidential or privileged information. If you are
not the intended recipient, you should not disseminate, distribute or copy
this e-mail. Please notify the sender immediately and destroy all copies of
this message and any attachments. WARNING: Computer viruses can be
transmitted via email. The recipient should check this email and any
attachments for the presence of viruses. The company accepts no liability
for any damage caused by any virus transmitted by this email.
www.wipro.com


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/1848bace/attachment-0001.html


Message: 17
Date: Fri, 21 Oct 2016 20:23:12 +1100
From: Gilles Dubreuil gdubreui@redhat.com
To: OpenStack-dev@lists.openstack.org
Subject: [openstack-dev] [all] Automation and self described APIs
Message-ID: 3ce11c50-24da-9e30-9017-92c20c57f213@redhat.com
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Ok, OpenStack ransom of success means the APIs request list is growing.
So what's the plan for self-described APIs?
Do we have a standardized solution exposing the requests' methods,
parameters to other program to exploit?

Sure, some OpenStack APIs advertise their interface using GET method
such as {"show api version", "/v1/"}.
Although consistent in the format but not available across all projects,
it doesn't seem to be following a standard anyway, right?
Besides and more importantly it isn't suitable to fully expose the
requests interfaces.

We know REST is not a standard in itself, but RESTful implementations
make use of standards, such as HTTP, URI, JSON and XML [1]
This have brought an excellent candidate tailored for the job, the HTTP
OPTION, please see RFC2616 [2] for more details.
Using such an approach would allow OpenStack APIs requests interfaces
(methods, parameters and items) to be advertised to other programs.
By offering a new level of API automation, almost over are the days of
tedious work for every OpenStack client of creating or adding every
interface corresponding code and its test code.
The next generation of RESTful clients could get up to date automatically.

In the meantime that happens, the only comprehensive APIs reference
source I've found is developer.openstack.org/api-ref.html
http://developer.openstack.org/api-ref.html [2].
BTW, great work Oslo Sphinx team, thank you!
The API-ref allows most of APIs interfaces to be partly generated using
web crawlers.
Unfortunately, there a still missing projects from the reference so the
rest still has to be manually produced and for the one automatically
generated there are various flaws which require manual intervention.

The flaws I've found:
- Missing requests from API ref: Only a few (example? Ironic: heartbeat
POST, "/v1/heartbeat/{node_ident}")
- API Inconsistencies: For instance, the call a method for Node Vendor
[3] or Driver Vendor [4] Passthru is the same, which create a conflict
for REST Clients.

So again, the API-ref is great and allow to cover the requests list but
that's not good enough for automation where the requests capabilities
need to be advertised properly and comprehensively through a standard,
such as the HTTP Option. Actually the API-ref could benefit from it too
and consume the latter.

Cheers,
Gilles

PS: In an ideal world, the API is built first and the rest upon.

[1] https://en.wikipedia.org/wiki/Representational_state_transfer
[2] https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
[3]
http://developer.openstack.org/api-ref/baremetal/?expanded=call-a-method-detail
[4] http://developer.openstack.org/api-ref/baremetal/?expanded=id73-detail

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/2864e0c5/attachment-0001.html


Message: 18
Date: Fri, 21 Oct 2016 12:06:46 +0100 (BST)
From: Chris Dent cdent+os@anticdent.org
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Does it make sense to have self links to
things that don't exist?
Message-ID: alpine.OSX.2.20.1610211205410.52839@shine.local
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On Thu, 20 Oct 2016, Matt Riedemann wrote:

It's not convenient, IMO, to provide a link to something that doesn't exist.
That's just frustrating from the API user point of view.

So is this fine?
Should it be implemented?
Or should the docs say, the link might not exist?
Or should the link to the non-existent handler just be removed?

If the discovery doc is for discovering stuff, it shouldn't list stuff
that doesn't exist. That's pretty simple and straightforward, right?
How could it be anything else?

--
Chris Dent ????( ? _ ??) https://anticdent.org/
freenode: cdent tw: @anticdent


Message: 19
Date: Fri, 21 Oct 2016 12:07:08 +0100
From: Lee Yarwood lyarwood@redhat.com
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [nova][cinder] Addressing mangled LUKS
passphrases (bug#1633518)
Message-ID:
20161021110708.sqql3h3sddaezld7@lyarwood.usersys.redhat.com
Content-Type: text/plain; charset=utf-8

Hello,

I documented bug#1633518 [1] last week in which volumes encrypted prior
to Ib563b0ea [2] used a slightly mangled passphrase instead of the
original passphrase provided by the configured key manager.

My first attempt at resolving this [3] prompted an alternative
suggestion from mdbooth of adding the correct passphrase to the LUKS
device when we detect the use of a mangled passphrase.

I'm slightly wary of this option given the changing of passphrases so
I'd really appreciate input from the wider Nova and Cinder groups on
your preference for resolving this :

  1. Keep the mangled passphrase in place and attempt to use it after
    getting a permission denied error during luksOpen.

  2. Add the correct passphrase and remove the mangled passphrase from the
    LUKS device with luksChangeKey when we detect the use of the mangled
    passphrase.

  3. An alternative suggestion.

FYI, as os-brick has now copied the encryptor classes from Nova into
their own tree any fix will be cherry-picked across shortly after
landing in Nova. I'm also looking into dropping these classes from Nova
for Ocata so we can avoid duplicating effort like this in future.

Thanks in advance,

Lee

[1] https://launchpad.net/bugs/1633518
[2] https://review.openstack.org/#/c/309614/
[3] https://review.openstack.org/#/c/386670/
--
Lee Yarwood
Senior Software Engineer
Red Hat

PGP : A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76


Message: 20
Date: Fri, 21 Oct 2016 12:22:52 +0100 (BST)
From: Chris Dent cdent+os@anticdent.org
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Endpoint structure: a free-for-all
Message-ID: alpine.OSX.2.20.1610211213490.52839@shine.local
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On Wed, 19 Oct 2016, Sean Dague wrote:

The reason we have volume, volumev2, and volumev3 is that no one actually
wants the unversioned volume endpoint. You can't do anything with it.
Everyone wants the actual endpoint that has resources.

That's right, they do want the endpoint that has the resources, but
do they care about asking for a version? I'm not sure. I think they
just want the thing that's going to work and the version is
superfluous.

We can solve this for all consumers by adding additional version field to the
catalog. This was the direction we were headed last spring before the api-ref
work took over.

I'd rather not see versions in the service catalog as a reified entity
because it increases the surface area of an endpoint request. I don't
want to have think which version I want. Or if I do, I want it to be
built into the service type. We want the service type to be the
entrypoint for endpoints...

In any case, just for reference, both the arch-wg and the api-wg
have expressed a lot of concern about and interest in the service
catalog (and the service authority idea that was bouncing around for
a while too). So I agree with everyone else who is saying "yeah,
it's time to make this better."

There are a lot of issues:

  • how to deal with versions
  • auth handling at the top-level endpoint
  • service type value consistency amongst clouds
  • public, internal, admin, whatever endpoints (can we make it so
    there is one and only one?)
  • dynamic v static service catalogs in the face of different
    contexts
  • whatever else I'm forgetting right now because the coffee is weak
    but I'm sure someone else remembers

--
Chris Dent ????( ? _ ??) https://anticdent.org/
freenode: cdent tw: @anticdent


Message: 21
Date: Fri, 21 Oct 2016 12:41:16 +0100 (BST)
From: Chris Dent cdent+os@anticdent.org
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] indoor climbing break at summit?
Message-ID: alpine.OSX.2.20.1610211239040.52839@shine.local
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On Tue, 18 Oct 2016, Miles Gould wrote:

Speaking of which: woo yeah! I'm totally up for this, schedule permitting.

The etherpad is gathering steam, on Monday I'll use the email
addresses on there and send out a plan, so anyone who wants to be
notified, look there, or just show up at the gym at the chosen time.

https://etherpad.openstack.org/p/ocata-climb

--
Chris Dent ????( ? _ ??) https://anticdent.org/
freenode: cdent tw: @anticdent


Message: 22
Date: Fri, 21 Oct 2016 07:41:52 -0400
From: Doug Hellmann doug@doughellmann.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Endpoint structure: a free-for-all
Message-ID: 99262145-B20A-4A8A-8AFF-465BF2E8E7B2@doughellmann.com
Content-Type: text/plain; charset=utf-8

On Oct 21, 2016, at 7:22 AM, Chris Dent cdent+os@anticdent.org wrote:

On Wed, 19 Oct 2016, Sean Dague wrote:

The reason we have volume, volumev2, and volumev3 is that no one actually wants the unversioned volume endpoint. You can't do anything with it. Everyone wants the actual endpoint that has resources.

That's right, they do want the endpoint that has the resources, but
do they care about asking for a version? I'm not sure. I think they
just want the thing that's going to work and the version is
superfluous.

We can solve this for all consumers by adding additional version field to the catalog. This was the direction we were headed last spring before the api-ref work took over.

I'd rather not see versions in the service catalog as a reified entity
because it increases the surface area of an endpoint request. I don't
want to have think which version I want. Or if I do, I want it to be
built into the service type. We want the service type to be the
entrypoint for endpoints...

In any case, just for reference, both the arch-wg and the api-wg
have expressed a lot of concern about and interest in the service
catalog (and the service authority idea that was bouncing around for
a while too). So I agree with everyone else who is saying "yeah,
it's time to make this better."

This is the sort of issue that would work well as a community-wide goal. If we get a group together to resolve some of the issues you list below, they can act as guides to steer the work and help teams with the transition. If we act quickly maybe we can make enough progress to do it for Pike.

Doug

There are a lot of issues:

  • how to deal with versions
  • auth handling at the top-level endpoint
  • service type value consistency amongst clouds
  • public, internal, admin, whatever endpoints (can we make it so
    there is one and only one?)
  • dynamic v static service catalogs in the face of different
    contexts
  • whatever else I'm forgetting right now because the coffee is weak
    but I'm sure someone else remembers

--
Chris Dent ????( ? _ ??) https://anticdent.org/
freenode: cdent tw: @anticdent


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

Message: 23
Date: Fri, 21 Oct 2016 12:44:21 +0100 (BST)
From: Chris Dent cdent+os@anticdent.org
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [api] [nova] microversion edge case query
Message-ID: alpine.OSX.2.20.1610211242140.52839@shine.local
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On Fri, 21 Oct 2016, Alex Xu wrote:

Also think 404 is right at here. If you return 406 and it is a signal that
if you used a different microversion the situation could be different, the
thing will become strange when we raise the acceptable min_version someday.

Thanks, yeah, what you and Ed have said has been convincing, I've
updated the code at: https://review.openstack.org/#/c/388115/

Jay's review of that has raised a new issue: which is should we even
bother with the decorator style?

--
Chris Dent ????( ? _ ??) https://anticdent.org/
freenode: cdent tw: @anticdent



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

End of OpenStack-dev Digest, Vol 54, Issue 52



OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Oct 21, 2016 in openstack-dev by Wang,_Peter_(Xu) (180 points)  
retagged Jan 26, 2017 by admin
...