[openstack-dev] [manila][share-migration] query about host-assisted migration

Rodrigo Barbieri rodrigo.barbieri2010 at gmail.com
Fri Oct 21 14:35:59 UTC 2016


Hi Peter,

You stated "I wonder is it's possible to migrate between backends in
different share network". From context, I assume that you meant neutron
networks, since "share networks" is a logic entity in manila that groups
share-servers related to a certain neutron network.

It is possible, this design follows the prior "Admin Network" design, which
states that drivers should implement a way to provide an additional export
location of a share in the adminstrator network where the Data Service node
is running, the same network that runs the cloud nodes such as the
controller. Therefore, the data service node mounts both shares in the same
network with a single access IP. If the involved backend drivers do not
support this, it is up to the administrator to set up such a network that
would allow connectivity. Example: use a provider network that connects the
administrator network (or just put the Data Service node in there) and
connect it to the backend data networks (where shares are served) through
routers or neutron ports.

If you really meant "share network", then you can use the migration-start
API command --new-share-network and specify the share network ID you would
like to change in the share model entry so it is compatible with the driver
mode/share-type/availability zone of the destination host.


I hope I have provided the info you need, feel free to ask if you need more
information about this.


Regards,


On Fri, Oct 21, 2016 at 11:20 AM, Wang, Peter (Xu) <Peter.Wang13 at dell.com>
wrote:

> Hi all
>
> I was trying the share migration function these days.
>
> I just succeeded in migrating a share from one backend to another
> (actually they are in same neutron network)
> My "data_node_access_ip" can access both source back-end and the
> destination back-end.
>
> I wonder is it's possible to migrate between backends in different share
> network( say, one is in VLAN1 and other is VLAN2)
> My questions are:
> 1. While data_node_access_ip is a single IP, how manila data node mount
> the both source share and destination share with one IP?
> 2. Even if data node have 2 IPs, can access both 2 network, but m-data
> (configure 1 IP in manila.conf) service cannot allow access (ro/rw) for
> both 2 shares respectively.
>
> If share can be migrated in different share network, can anyone point me
> the right direction?
>
> Thanks
> Peter
>
> -----Original Message-----
> From: openstack-dev-request at lists.openstack.org [mailto:
> openstack-dev-request at lists.openstack.org]
> Sent: Friday, October 21, 2016 8:00 PM
> To: openstack-dev at lists.openstack.org
> Subject: OpenStack-dev Digest, Vol 54, Issue 52
>
> Send OpenStack-dev mailing list submissions to
>         openstack-dev at 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 at lists.openstack.org
>
> You can reach the person managing the list at
>         openstack-dev-owner at 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 at 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 at 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)
>   10. Re: [vitrage][aodh] about aodh notifier to create a event
>       alarm (Afek, Ifat (Nokia - IL))
>   11. Re: [release][ptl] pausing releases until 1 Nov (Julien Danjou)
>   12. Re: [glance][VMT][Security] Glance coresec reorg (Flavio Percoco)
>   13. Re: [neutron][calico][tempest][gate] Help setting up DSVM
>       gate job for networking-calico (Neil Jerram)
>   14. [Keystone][Design Session] Where to propose       extensions to
>       trusts? (Johannes Grassler)
>   15. [daisycloud-core] Meeting minutes for IRC meeting 0800UTC
>       Oct. 21 2016 (hu.zhijiang at zte.com.cn)
>   16. Re: [OpenStack-dev][Fuel][Plugin] (Julia Aranovich)
>   17. [all] Automation and self described APIs (Gilles Dubreuil)
>   18. Re: Does it make sense to have self links to things that
>       don't exist? (Chris Dent)
>   19. [nova][cinder] Addressing mangled LUKS passphrases
>       (bug#1633518) (Lee Yarwood)
>   20. Re: Endpoint structure: a free-for-all (Chris Dent)
>   21. Re: [all] indoor climbing break at summit? (Chris Dent)
>   22. Re: Endpoint structure: a free-for-all (Doug Hellmann)
>   23. Re: [api] [nova] microversion edge case query (Chris Dent)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 21 Oct 2016 02:42:14 +0000
> From: joehuang <joehuang at huawei.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Endpoint structure: a free-for-all
> Message-ID:
>         <5E7A3D1BF5FD014E86E5F971CF446EFF559BC5E6 at 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 at 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 at 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 at zte.com.cn
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [daisycloud-core] Agenda for IRC meeting
>         0800UTC Oct. 21 2016
> Message-ID:
>         <OF5F3A0595.970F811C-ON48258053.001178BE-48258053.
> 00118AD1 at 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 at intel.com>
> To: "openstack-dev at lists.openstack.org"
>         <openstack-dev at lists.openstack.org>
> Cc: "openstack-operators at lists.openstack.org"
>         <openstack-operators at lists.openstack.org>,
>         "user-committee at lists.openstack.org"
>         <user-committee at 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 at 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 at intel.com>
> To: "openstack-dev at lists.openstack.org"
>         <openstack-dev at lists.openstack.org>,
>         "openstack-operators at lists.openstack.org"
>         <openstack-operators at 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 at 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 at redhat.com>
> To: cwolfe at redhat.com,  "OpenStack Development Mailing List (not for
>         usage questions)" <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [heat] Rolling Upgrades
> Message-ID:
>         <CABJHmF7E+hZJs1YHZ-QMk8n5R+Jxr8Xjzm=v9qTTK6TtzQed6w at 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 at 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 future_args 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 at 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 at wipro.com>
> To: <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [OpenStack-dev][Fuel][Plugin]
> Message-ID:
>         <SIXPR0301MB13386D15FF13B35C13865D0486D40 at 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 text_list and textarea_list ..
>
> 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
> -------------- 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 at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [api] [nova] microversion edge case query
> Message-ID:
>         <CAH7mGauaFBeGt9njyBfg2Y840exN6i_3FdJS0p+K91yLrBAU_Q at mail.
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2016-10-19 0:58 GMT+08:00 Ed Leafe <ed at leafe.com>:
>
> > On Oct 18, 2016, at 11:01 AM, Chris Dent <cdent+os at 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 at 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 at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [Congress] IRC during summit
> Message-ID: <D42F04D8.3F4BA%ekcs.openstack at 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 at benton.pub>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at 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 at 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 at 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 ${OS_TOP_LEVEL:-./}
> > ${OS_TEST_PATH:-./tempest/test_discover}  --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_api_discovery.
> TestApiDiscovery)
> > ... SKIPPED: TestApiDiscovery skipped as Ironic is not available
> > 2016-10-19 17:43:02.373 30902 INFO tempest.test [-] <class
> > 'tempest.lib.exceptions.InvalidCredentials'> 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.test_drivers.TestDrivers)
> ...
> > SKIPPED: TestDrivers skipped as Ironic is not available
> > {2} setUpClass (tempest.api.baremetal.admin.test_ports_negative.
> 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.test_agents.
> 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 [-] <class
> > 'tempest.lib.exceptions.InvalidCre908 INFO- t19de
> 90empe17st.:4tes3:0tn22
> > t. [i3-8aIN]l6 FOs  t'30em90<p>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 ${OS_TOP_LEVEL:-./}
> > ${OS_TEST_PATH:-./tempest/test_discover}  --load-list /tmp/tmpl_uSDt
> > {0} setUpClass (tempest.api.baremetal.admin.test_nodestates.
> TestNodeStates)
> > ... SKIPPED: TestNodeStates skipped as Ironic is not available
> > {2} setUpClass (tempest.api.baremetal.admin.test_api_discovery.
> 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.test_chassis.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.test_nodes.TestNodes) ...
> > SKIPPED: TestNodes skipped as Ironic is not available
> > {1} setUpClass (tempest.api.baremetal.admin.test_ports_negative.
> TestPortsNegative)
> > ... SKIPPED: TestPortsNegative skipped as Ironic is not available
> > {1} setUpClass (tempest.api.compute.admin.test_baremetal_nodes.
> BaremetalNodesAdminTestJSON)
> > ... SKIPPED: BaremetalNodesAdminTestJSON skipped as Ironic is not
> available
> > {1} tempest.api.compute.admin.test_flavors.FlavorsAdminTestJSON.test_
> create_flavor_using_string_ram
> > [0.232261s] ... ok
> > {1} tempest.api.compute.admin.test_flavors.FlavorsAdminTestJSON.test_
> > create_flavor_verify_entry_in_list_details [0.101537s] ... ok
> > {1} tempest.api.compute.admin.test_flavors.FlavorsAdminTestJSON.test_
> create_flavor_with_int_id
> > [0.081664s] ... ok
> > {1} tempest.api.compute.admin.test_flavors.FlavorsAdminTestJSON.test_
> create_flavor_with_none_id
> > [0.079674s] ... ok
> > {1} tempest.api.compute.admin.test_flavors.FlavorsAdminTestJSON.test_
> create_flavor_with_uuid_id
> > [0.075899s] ... ok
> > {1} tempest.api.compute.admin.test_flavors.FlavorsAdminTestJSON.test_
> > create_list_flavor_without_extra_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 at 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 at nokia.com>
> To: "dong.wenjuan at zte.com.cn" <dong.wenjuan at zte.com.cn>, gordon chung
>         <gord at live.ca>
> Cc: "OpenStack Development Mailing List \(not for usage questions\)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [vitrage][aodh] about aodh notifier to
>         create a event alarm
> Message-ID: <AA498EFB-1739-43B4-8021-89DCEC588DC3 at alcatel-lucent.com>
> Content-Type: text/plain; charset="utf-8"
>
> dwj,
>
> This would be great! Thanks for your help.
>
> Ifat.
>
> From: "dong.wenjuan at zte.com.cn<mailto:dong.wenjuan at 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 at nokia.com<mailto:ifat.afek at nokia.com
> >>
>
> 2016-10-21 01:23
>
>
> ???
>         gordon chung <gord at live.ca<mailto:gord at live.ca>>, "
> dong.wenjuan at zte.com.cn<mailto:dong.wenjuan at zte.com.cn>" <
> dong.wenjuan at zte.com.cn<mailto:dong.wenjuan at zte.com.cn>>
> ??
>         "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org<mailto:openstack-dev at 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 at live.ca<mailto:gord at 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 at danjou.info>
> To: Emilien Macchi <emilien at redhat.com>
> Cc: "OpenStack Development Mailing List \(not for usage questions\)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [release][ptl] pausing releases until 1
>         Nov
> Message-ID: <m0lgxib14s.fsf at 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 at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [glance][VMT][Security] Glance coresec
>         reorg
> Message-ID: <20161021080712.lpr3xhkupwrbbvmx at 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 at 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 at 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 at 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 at tigera.io>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [neutron][calico][tempest][gate] Help
>         setting up DSVM gate job for networking-calico
> Message-ID:
>         <CAMGh4hMMnCdQ1Do8x-ohWtzJymekMkvA3UN=CMsziP0QXhJg
> YQ at 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 at 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 at 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 ${OS_TOP_LEVEL:-./}
> > ${OS_TEST_PATH:-./tempest/test_discover}  --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_api_discovery.TestApiDiscovery) ...
> > SKIPPED: TestApiDiscovery skipped as Ironic is not available
> > 2016-10-19 17:43:02.373 30902 INFO tempest.test [-] <class
> > 'tempest.lib.exceptions.InvalidCredentials'> 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.test_drivers.TestDrivers)
> ...
> > SKIPPED: TestDrivers skipped as Ironic is not available
> > {2} setUpClass
> > (tempest.api.baremetal.admin.test_ports_negative.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.test_agents.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 [-] <class
> > 'tempest.lib.exceptions.InvalidCre908 INFO- t19de
> 90empe17st.:4tes3:0tn22
> > t. [i3-8aIN]l6 FOs  t'30em90<p>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 ${OS_TOP_LEVEL:-./}
> > ${OS_TEST_PATH:-./tempest/test_discover}  --load-list /tmp/tmpl_uSDt
> > {0} setUpClass
> > (tempest.api.baremetal.admin.test_nodestates.TestNodeStates) ...
> SKIPPED:
> > TestNodeStates skipped as Ironic is not available
> > {2} setUpClass
> > (tempest.api.baremetal.admin.test_api_discovery.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.test_chassis.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.test_nodes.TestNodes) ...
> > SKIPPED: TestNodes skipped as Ironic is not available
> > {1} setUpClass
> > (tempest.api.baremetal.admin.test_ports_negative.TestPortsNegative) ...
> > SKIPPED: TestPortsNegative skipped as Ironic is not available
> > {1} setUpClass
> > (tempest.api.compute.admin.test_baremetal_nodes.
> BaremetalNodesAdminTestJSON)
> > ... SKIPPED: BaremetalNodesAdminTestJSON skipped as Ironic is not
> available
> > {1}
> > tempest.api.compute.admin.test_flavors.FlavorsAdminTestJSON.test_
> create_flavor_using_string_ram
> > [0.232261s] ... ok
> > {1}
> > tempest.api.compute.admin.test_flavors.FlavorsAdminTestJSON.test_
> create_flavor_verify_entry_in_list_details
> > [0.101537s] ... ok
> > {1}
> > tempest.api.compute.admin.test_flavors.FlavorsAdminTestJSON.test_
> create_flavor_with_int_id
> > [0.081664s] ... ok
> > {1}
> > tempest.api.compute.admin.test_flavors.FlavorsAdminTestJSON.test_
> create_flavor_with_none_id
> > [0.079674s] ... ok
> > {1}
> > tempest.api.compute.admin.test_flavors.FlavorsAdminTestJSON.test_
> create_flavor_with_uuid_id
> > [0.075899s] ... ok
> > {1}
> > tempest.api.compute.admin.test_flavors.FlavorsAdminTestJSON.test_
> create_list_flavor_without_extra_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 at 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 at 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 at suse.de>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [Keystone][Design Session] Where to propose
>         extensions to trusts?
> Message-ID: <41b5666f-3c09-eb8d-537e-5d56fafaefeb at 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.
>
>
> 2. 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 at zte.com.cn
> To: openstack-dev at 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 at 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 at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [OpenStack-dev][Fuel][Plugin]
> Message-ID:
>         <CAMfgBLVa61Gz4Rtzu+F4PVOWby1gQdAgqmSFpJmPpGpvRqB6
> 1A at 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 "text_list" and "textarea_list" 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 text_list/textarea_list controls for each field from a group that
> represents storage backend configuration:
>
> Field1  value_for_backend_1 +/-
>             value_for_backend_2 +/-
>             value_for_backend_3 +/-
>
> Field2  value_for_backend_1 +/-
>             value_for_backend_2 +/-
>             value_for_backend_3 +/-
>
> Field3  value_for_backend_1 +/-
>             value_for_backend_2 +/-
>             value_for_backend_3 +/-
>
> 2) use text_list/textarea_list controls to configure a list of storage
> backends by declaring their settings as a single comma-separated string:
>
> Backends Settings    comma_separated_settings_for_backend_1 +/-
>                     comma_separated_settings_for_backend_2 +/-
>                                   comma_separated_settings_for_backend_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 at 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 text_list and textarea_list ..
> >
> > 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 at 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 at redhat.com>
> To: OpenStack-dev at lists.openstack.org
> Subject: [openstack-dev] [all] Automation and self described APIs
> Message-ID: <3ce11c50-24da-9e30-9017-92c20c57f213 at 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 at anticdent.org>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at 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 at 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 at redhat.com>
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [nova][cinder] Addressing mangled LUKS
>         passphrases     (bug#1633518)
> Message-ID:
>         <20161021110708.sqql3h3sddaezld7 at 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 at anticdent.org>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Endpoint structure: a free-for-all
> Message-ID: <alpine.OSX.2.20.1610211213490.52839 at 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 at anticdent.org>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [all] indoor climbing break at summit?
> Message-ID: <alpine.OSX.2.20.1610211239040.52839 at 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 at doughellmann.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Endpoint structure: a free-for-all
> Message-ID: <99262145-B20A-4A8A-8AFF-465BF2E8E7B2 at doughellmann.com>
> Content-Type: text/plain;       charset=utf-8
>
>
>
> > On Oct 21, 2016, at 7:22 AM, Chris Dent <cdent+os at 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 at 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 at anticdent.org>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [api] [nova] microversion edge case query
> Message-ID: <alpine.OSX.2.20.1610211242140.52839 at 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 at 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 at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Rodrigo Barbieri
MSc Computer Scientist
OpenStack Manila Core Contributor
Federal University of São Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/ff7ead32/attachment-0001.html>


More information about the OpenStack-dev mailing list