[openstack-dev] An authentication error occurred while openstack dashboard logged in

[FrankenFunc]

Dear Openstack-dev,
 
 
 
 
 
 
 
I installed the openstack according to your official documents, I found the 
following problems after installing the Horizon at the end.
 

 The openstack I installed is in the Newton version, and the system used is 
centos 7.
 Here is the error log I found./var/log/httpd/keystone.conf
  
 2018-03-19 03:47:58.856414 mod_wsgi (pid=5286): Target WSGI script 
'/usr/bin/keystone-wsgi-public' cannot be loaded as Python module.
2018-03-19 03:47:58.856448 mod_wsgi (pid=5286): Exception occurred processing 
WSGI script '/usr/bin/keystone-wsgi-public'.
2018-03-19 03:47:58.856479 Traceback (most recent call last):
2018-03-19 03:47:58.856507   File "/usr/bin/keystone-wsgi-public", line 51, in 

2018-03-19 03:47:58.856579 application = initialize_public_application()
2018-03-19 03:47:58.856604   File 
"/usr/lib/python2.7/site-packages/keystone/server/wsgi.py", line 137, in 
initialize_public_application
2018-03-19 03:47:58.856635 config_files=_get_config_files())
2018-03-19 03:47:58.856650   File 
"/usr/lib/python2.7/site-packages/keystone/server/wsgi.py", line 56, in 
initialize_application
2018-03-19 03:47:58.856673 common.configure(config_files=config_files)
2018-03-19 03:47:58.856686   File 
"/usr/lib/python2.7/site-packages/keystone/server/common.py", line 30, in 
configure
2018-03-19 03:47:58.856710 keystone.conf.configure()
2018-03-19 03:47:58.856724   File 
"/usr/lib/python2.7/site-packages/keystone/conf/__init__.py", line 126, in 
configure
2018-03-19 03:47:58.856748 help='Do not monkey-patch threading system 
modules.'))
2018-03-19 03:47:58.856762   File 
"/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2193, in __inner
2018-03-19 03:47:58.856786 result = f(self, *args, **kwargs)
2018-03-19 03:47:58.856800   File 
"/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2378, in 
register_cli_opt
2018-03-19 03:47:58.856823 raise ArgsAlreadyParsedError("cannot register 
CLI option")
2018-03-19 03:47:58.856853 ArgsAlreadyParsedError: arguments already parsed: 
cannot register CLI option

 
  
  
Please help.Thanks!
  
 Best regards
 Franken__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][requirements] a plan to stop syncing requirements into projects

[Doug Hellmann]

Excerpts from Robert Collins's message of 2018-03-26 10:46:22 +1300:
> On 26 March 2018 at 09:08, Doug Hellmann  wrote:
> > Excerpts from Doug Hellmann's message of 2018-03-25 16:04:11 -0400:
> >> A few of the jobs failed because the dependencies were wrong. In a few
> >> cases I was able to figure out what was wrong, but I can use some help
> >> from project teams more familiar with the code bases to debug the
> >> remaining failures.
> >
> > If you need to raise the lower bounds in a requirements file, please
> > update that file as well as lower-constraints.txt in the patch. You may
> > need to add a Depends-On for https://review.openstack.org/555402 in
> > order to have a version specifier that is different from the value in
> > the global requirements list.
> 
> Nice stuff; I'm so glad to see this evolution happening.
> 
> -Rob
> 

Thanks for laying such a firm foundation for us, Robert!

Doug

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

Re: [openstack-dev] [all][requirements] a plan to stop syncing requirements into projects

[Robert Collins]

On 26 March 2018 at 09:08, Doug Hellmann  wrote:
> Excerpts from Doug Hellmann's message of 2018-03-25 16:04:11 -0400:
>> A few of the jobs failed because the dependencies were wrong. In a few
>> cases I was able to figure out what was wrong, but I can use some help
>> from project teams more familiar with the code bases to debug the
>> remaining failures.
>
> If you need to raise the lower bounds in a requirements file, please
> update that file as well as lower-constraints.txt in the patch. You may
> need to add a Depends-On for https://review.openstack.org/555402 in
> order to have a version specifier that is different from the value in
> the global requirements list.

Nice stuff; I'm so glad to see this evolution happening.

-Rob

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

Re: [openstack-dev] [all][requirements] a plan to stop syncing requirements into projects

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-03-25 16:04:11 -0400:
> A few of the jobs failed because the dependencies were wrong. In a few
> cases I was able to figure out what was wrong, but I can use some help
> from project teams more familiar with the code bases to debug the
> remaining failures.

If you need to raise the lower bounds in a requirements file, please
update that file as well as lower-constraints.txt in the patch. You may
need to add a Depends-On for https://review.openstack.org/555402 in
order to have a version specifier that is different from the value in
the global requirements list.

Doug

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

Re: [openstack-dev] [all][requirements] a plan to stop syncing requirements into projects

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-03-22 16:16:06 -0400:
> Excerpts from Doug Hellmann's message of 2018-03-21 16:02:06 -0400:
> > Excerpts from Doug Hellmann's message of 2018-03-15 07:03:11 -0400:
> > > 
> > > TL;DR
> > > -
> > > 
> > > Let's stop copying exact dependency specifications into all our
> > > projects to allow them to reflect the actual versions of things
> > > they depend on. The constraints system in pip makes this change
> > > safe. We still need to maintain some level of compatibility, so the
> > > existing requirements-check job (run for changes to requirements.txt
> > > within each repo) will change a bit rather than going away completely.
> > > We can enable unit test jobs to verify the lower constraint settings
> > > at the same time that we're doing the other work.
> > 
> > The new job definition is in https://review.openstack.org/555034 and I
> > have updated the oslo.config patch I mentioned before to use the new job
> > instead of one defined in the oslo.config repo (see
> > https://review.openstack.org/550603).
> > 
> > I'll wait for that job patch to be reviewed and approved before I start
> > adding the job to a bunch of other repositories.
> > 
> > Doug
> 
> The job definition for openstack-tox-lower-constraints [1] was approved
> today (thanks AJaegar and pabelenger).
> 
> I have started proposing the patches to add that job to the repos listed
> in openstack/requirements/projects.txt using the topic
> "requirements-stop-syncing" [2]. I hope to have the rest of those
> proposed by the end of the day tomorrow, but since they have to run in
> batches I don't know if that will be possible.
> 
> The patch to remove the update proposal job is ready for review [3].
> 
> As is the patch to allow project requirements to diverge by changing the
> rules in the requirements-check job [4].
> 
> We ran into a snag with a few of the jobs for projects that rely on
> having service projects installed. There have been a couple of threads
> about that recently, but Monty has promised to start another one to
> provide all of the necessary context so we can fix the issues and move
> ahead.
> 
> Doug
> 

All of the patches to define the lower-constraints test jobs have been
proposed [1], and many have already been approved and merged (thank you
for your quick reviews).

A few of the jobs are failing because the projects depend on installing
some other service from source. We will work out what to do with those
when we solve that problem in a more general way.

A few of the jobs failed because the dependencies were wrong. In a few
cases I was able to figure out what was wrong, but I can use some help
from project teams more familiar with the code bases to debug the
remaining failures.

In a few cases projects didn't have python 3 unit test jobs, so I
configured the new job to use python 2. Teams should add a step to their
python 3 migration plan to update the version of python used in the new
job, when that is possible.

I believe we are now ready to proceed with updating the
requirements-check job to relax the rules about which changes are
allowed [2].

Doug

[1] https://review.openstack.org/#/q/topic:requirements-stop-syncing+status:open
[2] https://review.openstack.org/555402

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

Re: [openstack-dev] [nova] [cyborg] Race condition in the Cyborg/Nova flow

[Nadathur, Sundar]

On 3/23/2018 12:44 PM, Eric Fried wrote:

Sundar-

First thought is to simplify by NOT keeping inventory information in
the cyborg db at all.  The provider record in the placement service
already knows the device (the provider ID, which you can look up in the
cyborg db) the host (the root_provider_uuid of the provider representing
the device) and the inventory, and (I hope) you'll be augmenting it with
traits indicating what functions it's capable of.  That way, you'll
always get allocation candidates with devices that *can* load the
desired function; now you just have to engage your weigher to prioritize
the ones that already have it loaded so you can prefer those.

Eric,
   Thanks for the response.

   Traits only indicate whether a qualitative capability exists. To 
check if a free instance of the requested function exists in the host, 
we have to count the total count and free count of the needed function. 
Otherwise, we may pick a host because it *can* host a function, though 
it doesn't have a free instance of the function.


IIUC, your reply seems to expect that we can always reprogram a function 
as needed. The specific case we are looking at here is one where no 
reprogramming is involved. In the terminology of Cyborg/Nova 
rescheduling spec , this is 
the pre-programmed scenario (reasons why an operator may want this are 
stated in the spec). However, even if reprogramming is allowed, to 
prioritize hosts with free instances of the needed function, we will 
need to count how many free instances there are.


Since we said that only device types will be tracked as resource 
classes, and not functions, the scheduler will count available instances 
of device types, and Cyborg would have to count the functions separately.


Please let me know if I missed something.

Thanks & Regards,
Sundar


Am I missing something?

efried

On 03/22/2018 11:27 PM, Nadathur, Sundar wrote:

Hi all,
     There seems to be a possibility of a race condition in the
Cyborg/Nova flow. Apologies for missing this earlier. (You can refer to
the proposed Cyborg/Nova spec

for details.)

Consider the scenario where the flavor specifies a resource class for a
device type, and also specifies a function (e.g. encrypt) in the extra
specs. The Nova scheduler would only track the device type as a
resource, and Cyborg needs to track the availability of functions.
Further, to keep it simple, say all the functions exist all the time (no
reprogramming involved).

To recap, here is the scheduler flow for this case:

   * A request spec with a flavor comes to Nova conductor/scheduler. The
 flavor has a device type as a resource class, and a function in the
 extra specs.
   * Placement API returns the list of RPs (compute nodes) which contain
 the requested device types (but not necessarily the function).
   * Cyborg will provide a custom filter which queries Cyborg DB. This
 needs to check which hosts contain the needed function, and filter
 out the rest.
   * The scheduler selects one node from the filtered list, and the
 request goes to the compute node.

For the filter to work, the Cyborg DB needs to maintain a table with
triples of (host, function type, #free units). The filter checks if a
given host has one or more free units of the requested function type.
But, to keep the # free units up to date, Cyborg on the selected compute
node needs to notify the Cyborg API to decrement the #free units when an
instance is spawned, and to increment them when resources are released.

Therein lies the catch: this loop from the compute node to controller is
susceptible to race conditions. For example, if two simultaneous
requests each ask for function A, and there is only one unit of that
available, the Cyborg filter will approve both, both may land on the
same host, and one will fail. This is because Cyborg on the controller
does not decrement resource usage due to one request before processing
the next request.

This is similar to this previous Nova scheduling issue
.
That was solved by having the scheduler claim a resource in Placement
for the selected node. I don't see an analog for Cyborg, since it would
not know which node is selected.

Thanks in advance for suggestions and solutions.

Regards,
Sundar








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


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [tripleo] Updates on containerized undercloud

[Emilien Macchi]

This is an update on what has been achieved the last month with the regard
of Containerized Undercloud efforts in TripleO:

## CI
- Running OVB (ovs-ha, fs001) with a containerized undercloud: it finally
works, with some workarounds, all work in progress.
Results can be seen here:
https://logs.rdoproject.org/56/542556/79/openstack-check/
gate-tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset001-master/
Ze1390e6e0df54a88836d75316da4b206/console.txt.gz#_2018-03-24_06_07_23_171
List of workarounds/blockers:
* we need a new release of python-openstackclient that includes
https://review.openstack.org/#/c/553374/ and therefore we need
https://review.openstack.org/#/c/553026/
* container workflow to be finished (sbaker is on it) (in the meantime
we're loading envs in quickstart).
* masquerading workaround: https://review.openstack.org/#/c/553620 (long
term solution will be https://review.openstack.org/#/c/553427/ but still
WIP)
Once we clear the workarounds/blockers and have a clean / stable
deployment, we'll switch featureset001 (ovb-ha) to deploy a containerized
undercloud. The target was end of rocky-m1 and we still aim for it.

- Running an CI job that test upgrades from a non containerized undercloud
on Queens to a containerized undercloud on Rocky. Work is in progress and
can be monitored here: https://review.openstack.org/#/c/553633/
Special thanks to the Upgrade squads who help a lot on that front!

## Upgrades support
We said we would provide a way to upgrade a non containerized undercloud to
a containerized undercloud by rocky-m1 and we still aim for it.
This is a demo of an upgrade from Queens (non containerized) to Rocky
(containerized): https://youtu.be/5gLKL3YkC2c
We'll wait a bit for feedback from the demo and start documenting. Note
that most of the workflow remains the same as before (we still use
openstack undercloud upgrade command).
We'll also continue to push efforts to have this workflow tested by the CI
job in progress.

## Other items
- TripleO UI has been containerized.
- Routed networks is still in progress by Harald (we probably aim for
rocky-m2 now).
- We're investigating some way to validate than an upgrade to a
containerized undercloud worked fine (with Ansible?). More to come.
- Containerization of Tempest so we can run Tempest against a containerized
undercloud and also investigate how we could switch CI scenarios to be
deployed on one node.
- Port the TLS by default done in instack-undercloud.

Any feedback or help on testing is very welcome.
All efforts can be seen here: https://trello.com/b/nmGSNPoQ/containerized-
undercloud

Thanks everyone who helped in these efforts so far!

On Sun, Feb 18, 2018 at 10:18 AM, Emilien Macchi  wrote:

> This is an update on what has been achieved this week with the regard of
> Containerized Undercloud efforts in TripleO:
>
> TL;DR: really good efforts have been made and we can now deploy a full
> (multinode) overcloud in CI. OVB testing in progress and lot of remaining
> items!
>
> ## Bugfixes
> docker-registry: add missing firewall rules - https://review.openstack.
> org/#/c/545185/
> mistral-executor: mount /var/lib/mistral - https://review.openstack.
> org/#/c/545143/
> docker: configure group/user for deployment_user -
> https://review.openstack.org/#/c/544761/ + dependencies
> Fix PublicVirtualFixedIPs in envs - https://review.openstack.
> org/#/c/544744/
> Align zaqar max_messages_post_size with undercloud -
> https://review.openstack.org/#/c/544756/
> undercloud_post: fix subnet name - https://review.openstack.
> org/#/c/544587/
>
> ## CI
> We manage to run a containerized overcloud deployed by a containerized
> undercloud in CI, results can be seen here: https://review.
> openstack.org/#/c/542906/
> The job is running on featureser010 now (for testing purpose) but as James
> mentioned in the review, we won't switch this job to run a containerized
> undercloud. Note there is no impact on the job runtime.
> We'll need to properly deprecate the non-containerized undercloud first
> but we'll need to find a CI job that we can use for gating, so we avoid
> regression during the cycle.
> Now we're working on deploying featureset001 (ovb-ha), with TLS, net-iso,
> Ironic/Nova/Neutron (baremetal bits) from a containerized undercloud:
> https://review.openstack.org/#/c/542556/
> It's not working yet but we're working toward the blockers as they come
> during testing.
>
> # TLS Support
> All patches that were in progress have been merged, and now under testing
> in ovb-ha + containerized u/c (see above).
>
> # UI Support
> Work is still in progress, patches are ready for review, but some one them
> don't pass pep8 yet. We'll hopefully fix it soon.
>
> # Other items
> routed ctlplane networking: Harald is currently making progress on the
> items, some patches are ready for review.
> Create temp copy of tripleo-heat-templates before processing them: Bogdan
> is working on https://review.openstack.org/#/c/542875 - the patch is
> under 

Re: [openstack-dev] [glance] python-glanceclient release status

[Brian Rosmaita]

Adding another review to the list:
https://review.openstack.org/#/c/556292/

Also, https://review.openstack.org/50 has been updated with more tests.

Once those are approved, they'll need to be backported to
stable/queens so we can release 2.10.0

On Thu, Mar 22, 2018 at 8:55 PM, Brian Rosmaita
 wrote:
> As promised at today's Glance meeting, here's an update on the release
> status for the glanceclient bugfix release for stable/queens.
>
> There's another bug I think needs to be addressed:
> https://bugs.launchpad.net/python-glanceclient/+bug/1758149
>
> I've got a patch up so I can get feedback (particularly on the error 
> messages):
> https://review.openstack.org/50
>
> I'll be adding more tests to the patch (it needs them).
>
> It's already Friday UTC, so we won't be releasing 2.10.0 until Monday
> at the earliest.  Here are the backports that still require approval:
>
> https://review.openstack.org/#/c/555277/
> https://review.openstack.org/#/c/555390/
> https://review.openstack.org/#/c/555436/
>
> and a cherry-pick of 50 when that's done.
>
>
> cheers,
> brian

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

Re: [openstack-dev] [vitrage] Nominating Dong Wenjuan for Vitrage core

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

I added Dong Wenjuan to the list of core contributors.
Welcome ☺

From: Eyal B 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, 21 March 2018 at 16:57
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [vitrage] Nominating Dong Wenjuan for Vitrage core

+2

On 21 March 2018 at 16:37, Afek, Ifat (Nokia - IL/Kfar Sava) 
> wrote:
Hi,

I would like to nominate Dong Wenjuan for Vitrage core.
Wenjuan has been contributing to Vitrage for a long time, since Newton version. 
She implemented several important features and has a deep knowledge of Vitrage 
architecture. I’m sure she can be a great addition to our team.

Thanks,
Ifat.


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

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