Re: [openstack-dev] [goal][python3] more updates to the goal tools

[super user]

Hi Doug,

I'm Nguyen Hai. I proposed the python3-first patch set for
designate projects. However, I have met this error to designate and
designate-dashboard:

=== ../Output/designate/openstack/designate @ master ===

./tools/python3-first/do_repo.sh ../Output/designate/openstack/designate
master 24292

++ cat ../Output/designate/openstack/designate/.gitreview
++ grep project
++ cut -f2 -d=
+ actual=openstack/designate.git
+++ dirname ../Output/designate/openstack/designate
++ basename ../Output/designate/openstack
++ basename ../Output/designate/openstack/designate
+ expected=openstack/designate
+ '[' openstack/designate.git '!=' openstack/designate -a
openstack/designate.git '!=' openstack/designate.git ']'
+ git -C ../Output/designate/openstack/designate review -s
Creating a git remote called 'gerrit' that maps to:
ssh://
nguyentri...@review.openstack.org:29418/openstack/designate.git
++ basename master
+ new_branch=python3-first-master
+ git -C ../Output/designate/openstack/designate branch
+ grep -q python3-first-master
+ echo 'creating python3-first-master'
creating python3-first-master
+ git -C ../Output/designate/openstack/designate checkout -- .
+ git -C ../Output/designate/openstack/designate clean -f -d
+ git -C ../Output/designate/openstack/designate checkout -q origin/master
+ git -C ../Output/designate/openstack/designate checkout -b
python3-first-master
Switched to a new branch 'python3-first-master'
+ python3-first -v --debug jobs update
../Output/designate/openstack/designate
determining repository name from .gitreview
working on openstack/designate @ master
looking for zuul config in
../Output/designate/openstack/designate/.zuul.yaml
using zuul config from ../Output/designate/openstack/designate/.zuul.yaml
loading project settings from ../project-config/zuul.d/projects.yaml
loading project templates from
../openstack-zuul-jobs/zuul.d/project-templates.yaml
loading jobs from ../openstack-zuul-jobs/zuul.d/jobs.yaml
looking for settings for openstack/designate
looking at template 'openstack-python-jobs'
looking at template 'openstack-python35-jobs'
looking at template 'publish-openstack-sphinx-docs'
looking at template 'periodic-stable-jobs'
looking at template 'check-requirements'
did not find template definition for 'check-requirements'
looking at template 'translation-jobs-master-stable'
looking at template 'release-notes-jobs'
looking at template 'api-ref-jobs'
looking at template 'install-guide-jobs'
looking at template 'release-openstack-server'
filtering on master
merging templates
  adding openstack-python-jobs
  adding openstack-python35-jobs
  adding publish-openstack-sphinx-docs
  adding periodic-stable-jobs
  adding check-requirements
  adding release-notes-jobs
  adding install-guide-jobs
merging pipeline check
*unhashable type: 'CommentedMap'*
*Traceback (most recent call last):*
*  File
"/home/stack/python3-first/goal-tools/.tox/venv/lib/python3.6/site-packages/cliff/app.py",
line 402, in run_subcommand*
*result = cmd.run(parsed_args)*
*  File
"/home/stack/python3-first/goal-tools/.tox/venv/lib/python3.6/site-packages/cliff/command.py",
line 184, in run*
*return_code = self.take_action(parsed_args) or 0*
*  File
"/home/stack/python3-first/goal-tools/goal_tools/python3_first/jobs.py",
line 531, in take_action*
*entry,*
*  File
"/home/stack/python3-first/goal-tools/goal_tools/python3_first/jobs.py",
line 397, in merge_project_settings*
*up.get(pipeline, comments.CommentedMap()),*
*  File
"/home/stack/python3-first/goal-tools/goal_tools/python3_first/jobs.py",
line 362, in merge_pipeline*
*if job_name in job_names:*
*TypeError: unhashable type: 'CommentedMap'*
*Traceback (most recent call last):*
*  File "/home/stack/python3-first/goal-tools/.tox/venv/bin/python3-first",
line 10, in *
*sys.exit(main())*
*  File
"/home/stack/python3-first/goal-tools/goal_tools/python3_first/main.py",
line 42, in main*
*return Python3First().run(argv)*
*  File
"/home/stack/python3-first/goal-tools/.tox/venv/lib/python3.6/site-packages/cliff/app.py",
line 281, in run*
*result = self.run_subcommand(remainder)*
*  File
"/home/stack/python3-first/goal-tools/.tox/venv/lib/python3.6/site-packages/cliff/app.py",
line 402, in run_subcommand*
*result = cmd.run(parsed_args)*
*  File
"/home/stack/python3-first/goal-tools/.tox/venv/lib/python3.6/site-packages/cliff/command.py",
line 184, in run*
*return_code = self.take_action(parsed_args) or 0*
*  File
"/home/stack/python3-first/goal-tools/goal_tools/python3_first/jobs.py",
line 531, in take_action*
*entry,*
*  File
"/home/stack/python3-first/goal-tools/goal_tools/python3_first/jobs.py",
line 397, in merge_project_settings*
*up.get(pipeline, comments.CommentedMap()),*
*  File
"/home/stack/python3-first/goal-tools/goal_tools/python3_first/jobs.py",
line 362, in merge_pipeline*
*if job_name in job_names:*
*TypeError: unhashable type: 'CommentedMap'*
*+ echo 'No changes'*
*No changes*
*+ exit 1*

On 

[openstack-dev] [neutron] Broken pep8 job

[Slawomir Kaplonski]

Hi,

It looks that pep8 job in Neutron is currently broken because of new version of 
bandit (1.5.0).
If You have in Your patch failure of pep8 job with error like [1] please don’t 
recheck as it will not help.
I did some patch which should fix it [2]. Will let You know when it will be 
fixed and You will be able to rebase You patches.

[1] 
http://logs.openstack.org/37/382037/67/check/openstack-tox-pep8/e2bbd84/job-output.txt.gz#_2018-08-16_21_45_55_366148
[2] https://review.openstack.org/#/c/592884/

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] Rocky blueprint burndown chart

[Thierry Carrez]

melanie witt wrote:

[...]
If you have feedback or thoughts on any of this, feel free to reply to 
this thread or add your comments to the Rocky retrospective etherpad [4] 
and we can discuss at the PTG.


That is great data, thanks for compiling and publishing it !

As far as burndown charts go, it looks healthy (specs getting completed 
along the way, not approving a lot more than you can actually take).


--
Thierry Carrez (ttx)

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

Re: [openstack-dev] [Openstack-operators] [puppet] migrating to storyboard

[Tobias Urdin]

Hello Kendall,

I went through the list of projects [1] and could only really see two 
things.


1) puppet-rally and puppet-openstack-guide is missing

2) We have some support projects which doesn't really need bug tracking, 
where some others do.
    You can remove puppet-openstack-specs and 
puppet-openstack-cookiecutter all others would be

    nice to still have left so we can track bugs. [2]

Best regards
Tobias

[1] https://storyboard-dev.openstack.org/#!/project_group/60 

[2] Keeping puppet-openstack-integration (integration testing) and 
puppet-openstack_spec_helper (helper for testing).
  These two usually has a lot of changes so would be good to be 
able to track them.


On 08/16/2018 09:40 PM, Kendall Nelson wrote:

Hey :)

I created all the puppet openstack repos in the storyboard-dev 
envrionment and made a project group[1]. I am struggling a bit with 
finding all of your launchpad projects to perform the migrations 
through, can you share a list of all of them?


-Kendall (diablo_rojo)

[1] https://storyboard-dev.openstack.org/#!/project_group/60 



On Wed, Aug 15, 2018 at 12:08 AM Tobias Urdin > wrote:


Hello Kendall,

Thanks for your reply, that sounds awesome!
We can then dig around and see how everything looks when all
project bugs are imported to stories.

I see no issues with being able to move to Storyboard anytime soon
if the feedback for
moving is positive.

Best regards

Tobias


On 08/14/2018 09:06 PM, Kendall Nelson wrote:

Hello!

The error you hit can be resolved by adding launchpadlib to your
tox.ini if I recall correctly..

also, if you'd like, I can run a test migration of puppet's
launchpad projects into our storyboard-dev db (where I've done a
ton of other test migrations) if you want to see how it
looks/works with a larger db. Just let me know and I can kick it
off.

As for a time to migrate, if you all are good with it, we usually
schedule for Friday's so there is even less activity. Its a small
project config change and then we just need an infra core to kick
off the script once the change merges.

-Kendall (diablo_rojo)

On Tue, Aug 14, 2018 at 9:33 AM Tobias Urdin
mailto:tobias.ur...@binero.se>> wrote:

Hello all incredible Puppeters,

I've tested setting up an Storyboard instance and test migrated
puppet-ceph and it went without any issues there using the
documentation
[1] [2]
with just one minor issue during the SB setup [3].

My goal is that we will be able to swap to Storyboard during
the Stein
cycle but considering that we have a low activity on
bugs my opinion is that we could do this swap very easily
anything soon
as long as everybody is in favor of it.

Please let me know what you think about moving to Storyboard?
If everybody is in favor of it we can request a migration to
infra
according to documentation [2].

I will continue to test the import of all our project while
people are
collecting their thoughts and feedback :)

Best regards
Tobias

[1]
https://docs.openstack.org/infra/storyboard/install/development.html
[2] https://docs.openstack.org/infra/storyboard/migration.html
[3] It failed with an error about launchpadlib not being
installed,
solved with `tox -e venv pip install launchpadlib`


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

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



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

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



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

[openstack-dev] [Cinder] How to mount NFS volume?

[Chang, Clay (HPS OE-Linux TDC)]

Hi,

I have Cinder configured with NFS backend. On one bare metal node, I can use 
'cinder create' to create the volume with specified size - I saw a volume file 
create on the NFS server, so I suppose the NFS was configured correctly.

My question is, how could I mount the NFS volume on the bare metal node?

I tried:

cinder local-attach 3f66c360-e2e1-471e-aa36-57db3fcf3bdb -mountpoint /mnt/tmp

it says:

"ERROR: Connect to volume via protocol NFS not supported"

I looked at 
https://github.com/openstack/python-brick-cinderclient-ext/blob/master/brick_cinderclient_ext/volume_actions.py,
 found only iSCSI, RBD and FIBRE_CHANNEL were supported.

Wondering if there are ways to mount the NFS volume?

Thanks,
Clay
__
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][vmware] need help triaging a vmware driver bug

[Radoslav Gerganov]

Hi,

On 17.08.2018 04:10, melanie witt wrote:


Can anyone help triage this bug?



I have requested more info from the person who submitted this and provided some 
tips how to correlate nova-compute logs to vCenter logs in order to better 
understand what went wrong.
Would it be possible to include this kind of information in the Launchpad bug 
template for VMware related bugs?

Thanks,
Rado

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

[openstack-dev] [charms] Deployment guide stable/rocky cut

[Frode Nordahl]

Hello OpenStack charmers,

I am writing to inform you that  a `stable/rocky` branch has been cut for
the `openstack/charm-deployment-guide` repository.

Should there be any further updates to the guide before the release the
changes will need to be landed in `master` and then back-ported to
`stable/rocky`.

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

[openstack-dev] [mistral] Denver PTG

[Dougal Matthews]

Hey all,

I wanted to reach out and see who is interested in attending the Mistral
sessions at the Denver PTG. Unfortunately I wont be able to make it but
Renat Akhmerov may be able to go and run the sessions. Most of the other
Mistral cores wont be able to attend unfortunately.

Please reply as soon as you can.

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

[openstack-dev] [kolla][ptg] Denver PTG on-site or virtual

[Eduardo Gonzalez]

Fellow kolleages.

In september is Denver PTG, as per the etherpad [0] only 3 contributors
confirmed their presence in the PTG, we expected more people to be there as
previous PTGs were full of contributors and operators.

In the last kolla meeting [1] with discussed if we should make a virtual
PTG rather than a on-site one as we will probably reach a bigger number of
attendance.

This set us in a bad possition as per:

If we do an on-site PTG

- Small representation for a whole cycle design, being this one larger than
usual.
- Many people whiling to attend is not able to be there.

If we do a virtual PTG

- Some people already spend money to travel for kolla PTG
- PTG rooms are already reserved for kolla session
- No cross project discussion

If there are more people who is going to Denver and haven't signed up at
the etherpad, please confirm your presence as it will probably influence on
this topic.

Here is the though question...

What kind of PTG do you prefer for this one, virtual or on-site in Denver?

CC to Kendall Nelson from the foundation if she could help us on this
though decission, given the small time we have until the PTG both ways have
some kind of bad consecuencies for both the project and the contributors.

[0] https://etherpad.openstack.org/p/kolla-stein-ptg-planning
[1]
http://eavesdrop.openstack.org/meetings/kolla/2018/kolla.2018-08-15-15.00.log.html#l-13

Regards
__
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] [keystone] Keystone Team Update - Week of 6 August 2018

[Colleen Murphy]

On Sat, Aug 11, 2018, at 11:14 AM, Lance Bragstad wrote:
> On Fri, Aug 10, 2018, 23:47 Colleen Murphy  wrote:
> 
> > # Keystone Team Update - Week of 6 August 2018
> >
> > ## News
> >
> > ### RC1
> >
> > We released RC1 this week[1]. Please try it out and be on the lookout for
> > critical bugs. As of yet we don't seem to have any showstoppers that would
> > require another RC.
> 
> 
> Should we rev the keystone version for the inclusion of the new default
> roles?
> 
> 
> > [1] https://releases.openstack.org/rocky/index.html#rocky-keystone

[snipped]

To close the loop on this, we discussed on IRC[2], Lance was talking about the 
API version, not the release version, and we decided that although the 
bootstrap change allows the new roles to be created at initialization, it 
doesn't guarantee that roles will be in every deployment, and so it's not a 
feature we can advertise with an API version bump.

Colleen

[2] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-08-13.log.html#t2018-08-13T07:56:22

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

[openstack-dev] glance 17.0.0.0rc2 (rocky)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/glance/

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

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

https://git.openstack.org/cgit/openstack/glance/log/?h=stable/rocky

Release notes for glance can be found at:

https://docs.openstack.org/releasenotes/glance/




__
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] how nova should behave when placement returns consumer generation conflict

[Balázs Gibizer]

On Thu, Aug 16, 2018 at 5:34 PM, Eric Fried  wrote:

Thanks for this, gibi.


TL;DR: a).

I didn't look, but I'm pretty sure we're not caching allocations in 
the
report client. Today, nobody outside of nova (specifically the 
resource

tracker via the report client) is supposed to be mucking with instance
allocations, right? And given the global lock in the resource tracker,
it should be pretty difficult to race e.g. a resize and a delete in 
any

meaningful way. So short term, IMO it is reasonable to treat any
generation conflict as an error. No retries. Possible wrinkle on 
delete,

where it should be a failure unless forced.


Yes, today the instance_uuid and migraton_uuid consumers in placement 
are only changed from nova.


Right now I don't have any examples where nova is racing with itself on 
a instance or migration consumer. We could try hitting the Nova API in 
parallel with different server lifecycle operations against the same 
server to see if we can find races. But until such race is discovered 
we can go with option a)




Long term, I also can't come up with any scenario where it would be
appropriate to do a narrowly-focused GET+merge/replace+retry. But
implementing the above short-term plan shouldn't prevent us from 
adding
retries for individual scenarios later if we do uncover places where 
it

makes sense.



Later when resources consumed by a server will be handled outside of 
nova, like bandwidth from neutron and accelerators from cyborg we might 
see cases when nova will not be the only module changing a 
instance_uuid consumer. Then we have to decide how to handle that. I 
think one solution could be to make sure Nova knows about the bandwidth 
and accelerator resource needs of a server even if it is provided by 
neutron or cyborg. This knowledge is anyhow necessary to support atomic 
resource claim in the scheduler. For neturon ports this will be done 
through the resource_request attribute of the port. So even if the 
resource need of a port changes nova can go back to neutron and query 
the current need. This way nova can implement the following generic 
algorithm for every operation where nova wants to change the 
instance_uuid consumer in placement:
* collect the server current resource needs (might involve reading it 
from flavor, from neutron port, from cyborg accelerator) and apply the 
change nova wants to make (e.g. delete, move, resize).

* GET current consumer view from placement
* merge the two and push the result back to placement



Here's some stream-of-consciousness that led me to the above opinions:

- On spawn, we send the allocation with a consumer gen of None because
we expect the consumer not to exist. If it exists, that should be a 
hard

fail. (Hopefully the only way this happens is a true UUID conflict.)

- On migration, when we create the migration UUID, ditto above ^


I agree on both. I suggest returning HTTP 500 as we need a bug report 
about these cases.




- On migration, when we transfer the allocations in either direction, 
a

conflict means someone managed to resize (or otherwise change
allocations?) since the last time we pulled data. Given the global 
lock

in the report client, this should have been tough to do. If it does
happen, I would think any retry would need to be done all the way back
at the claim, which I imagine is higher up than we should go. So 
again,

I think we should fail the migration and make the user retry.


Do we want to fail the whole migration or just the migration step (e.g. 
confirm, revert)?
The later means that failure during confirm or revert would put the 
instance back to VERIFY_RESIZE. While the former would mean that in 
case of conflict at confirm we try an automatic revert. But for a 
conflict at revert we can only put the instance to ERROR state.




- On destroy, a conflict again means someone managed a resize despite
the global lock. If I'm deleting an instance and something about it
changes, I would think I want the opportunity to reevaluate my 
decision

to delete it. That said, I would definitely want a way to force it (in
which case we can just use the DELETE call explicitly). But neither 
case

should be a retry, and certainly there is no destroy scenario where I
would want a "merging" of allocations to happen.


Good idea about allowing forcing the delete. So a simple DELETE 
/servers/{instance_uuid} could fail on consumer conflict but a POST 
/servers/{instance_uuid}/action with forceDelete body would use DELETE 
/allocations and therefore will ignore any consumer generation.


Cheers,
gibi



Thanks,
efried


On 08/16/2018 06:43 AM, Balázs Gibizer wrote:

 reformatted for readabiliy, sorry:

 Hi,

 tl;dr: To properly use consumer generation (placement 1.28) in Nova 
we

 need to decide how to handle consumer generation conflict from Nova
 perspective:
 a) Nova reads the current consumer_generation before the allocation
   update operation and use that generation in the allocation update
   

Re: [openstack-dev] [tripleo][Edge][FEMDC] Edge clouds and controlplane updates

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

Hi,

Some comments inline.

From: Alan Bishop 
Sent: Thursday, August 16, 2018 7:09 PM

On Tue, Aug 14, 2018 at 9:20 AM Bogdan Dobrelya 
mailto:bdobr...@redhat.com>> wrote:
On 8/13/18 9:47 PM, Giulio Fidente wrote:
> Hello,
>
> I'd like to get some feedback regarding the remaining
> work for the split controlplane spec implementation [1]
>
> Specifically, while for some services like nova-compute it is not
> necessary to update the controlplane nodes after an edge cloud is
> deployed, for other services, like cinder (or glance, probably
> others), it is necessary to do an update of the config files on the
> controlplane when a new edge cloud is deployed.

[G0]: What is the reason to run a shared cinder in an edge cloud 
infrastructure? Maybe it is a better approach to run an individual Cinder in 
every edge cloud instance.

> In fact for services like cinder or glance, which are hosted in the
> controlplane, we need to pull data from the edge clouds (for example
> the newly deployed ceph cluster keyrings and fsid) to configure cinder
> (or glance) with a new backend.

[G0]: Solution ideas for Glance are listed in 
[3].

> It looks like this demands for some architectural changes to solve the > 
> following two:
>
> - how do we trigger/drive updates of the controlplane nodes after the
> edge cloud is deployed?

Note, there is also a strict(?) requirement of local management
capabilities for edge clouds temporary disconnected off the central
controlplane. That complicates the updates triggering even more. We'll
need at least a notification-and-triggering system to perform required
state synchronizations, including conflicts resolving. If that's the
case, the architecture changes for TripleO deployment framework are
inevitable AFAICT.

This is another interesting point. I don't mean to disregard it, but want to
highlight the issue that Giulio and I (and others, I'm sure) are focused on.

As a cinder guy, I'll use cinder as an example. Cinder services running in the
control plane need to be aware of the storage "backends" deployed at the
Edge. So if a split-stack deployment includes edge nodes running a ceph
cluster, the cinder services need to be updated to add the ceph cluster as a
new cinder backend. So, not only is control plane data needed in order to
deploy an additional stack at the edge, data from the edge deployment needs to
be fed back into a subsequent stack update in the controlplane. Otherwise,
cinder (and other storage services) will have no way of utilizing ceph
clusters at the edge.
>
> - how do we scale the controlplane parameters to accomodate for N
> backends of the same type?

Yes, this is also a big problem for me. Currently, TripleO can deploy cinder
with multiple heterogeneous backends (e.g. one each of ceph, NFS, Vendor X,
Vendor Y, etc.). However, the current THT do not let you deploy multiple
instances of the same backend (e.g. more than one ceph). If the goal is to
deploy multiple edge nodes consisting of Compute+Ceph, then TripleO will need
the ability to deploy multiple homogeneous cinder backends. This requirement
will likely apply to glance and manila as well.

> A very rough approach to the latter could be to use jinja to scale up
> the CephClient service so that we can have multiple copies of it in the
> controlplane.
>
> Each instance of CephClient should provide the ceph config file and
> keyring necessary for each cinder (or glance) backend.
>
> Also note that Ceph is only a particular example but we'd need a similar
> workflow for any backend type.
>
> The etherpad for the PTG session [2] touches this, but it'd be good to
> start this conversation before then.
>
> 1.
> https://specs.openstack.org/openstack/tripleo-specs/specs/rocky/split-controlplane.html
>
> 2. https://etherpad.openstack.org/p/tripleo-ptg-queens-split-controlplane
>

[3]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment

Br,
Gerg0


--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

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

Re: [openstack-dev] [kolla][ptg] Denver PTG on-site or virtual

[Mark Goddard]

As one of the lucky three kolleagues able to make the PTG, here's my
position (inline).

On 17 August 2018 at 11:52, Eduardo Gonzalez  wrote:

> Fellow kolleages.
>
> In september is Denver PTG, as per the etherpad [0] only 3 contributors
> confirmed their presence in the PTG, we expected more people to be there as
> previous PTGs were full of contributors and operators.
>
> In the last kolla meeting [1] with discussed if we should make a virtual
> PTG rather than a on-site one as we will probably reach a bigger number of
> attendance.
>
> This set us in a bad possition as per:
>
> If we do an on-site PTG
>
> - Small representation for a whole cycle design, being this one larger
> than usual.
> - Many people whiling to attend is not able to be there.
>

I agree that three is too small a number to justify an on-site PTG. I was
planning to split my time between kolla and ironic, so being able to focus
on one project would be beneficial to me, assuming the virtual PTG takes
place at a different time. I could still split my time if the virtual PTG
occurs at the same time.


>
> If we do a virtual PTG
>
> - Some people already spend money to travel for kolla PTG
>

I would be going anyway.


> - PTG rooms are already reserved for kolla session
>

If the virtual PTG occurs at the same time, we could use the (oversized)
reserved room to dial into calls.

- No cross project discussion
>

Happy to attend on behalf of kolla and feed back to the team.

>
> If there are more people who is going to Denver and haven't signed up at
> the etherpad, please confirm your presence as it will probably influence on
> this topic.
>
> Here is the though question...
>
> What kind of PTG do you prefer for this one, virtual or on-site in Denver?
>

Virtual makes sense to me.

>
> CC to Kendall Nelson from the foundation if she could help us on this
> though decission, given the small time we have until the PTG both ways have
> some kind of bad consecuencies for both the project and the contributors.
>
> [0] https://etherpad.openstack.org/p/kolla-stein-ptg-planning
> [1] http://eavesdrop.openstack.org/meetings/kolla/2018/kolla.
> 2018-08-15-15.00.log.html#l-13
>
> Regards
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] How to mount NFS volume?

[Ivan Kolodyazhny]

Hi Clay,

Unfortunately, local-attach doesn't support NFS-based volumes due to the
security reasons. We haven't the good solution now for multi-tenant
environments.

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Fri, Aug 17, 2018 at 12:03 PM, Chang, Clay (HPS OE-Linux TDC) <
cl...@hpe.com> wrote:

> Hi,
>
>
>
> I have Cinder configured with NFS backend. On one bare metal node, I can
> use ‘cinder create’ to create the volume with specified size – I saw a
> volume file create on the NFS server, so I suppose the NFS was configured
> correctly.
>
>
>
> My question is, how could I mount the NFS volume on the bare metal node?
>
>
>
> I tried:
>
>
>
> cinder local-attach 3f66c360-e2e1-471e-aa36-57db3fcf3bdb –mountpoint
> /mnt/tmp
>
>
>
> it says:
>
>
>
> “ERROR: Connect to volume via protocol NFS not supported”
>
>
>
> I looked at https://github.com/openstack/python-brick-cinderclient-ext/b
> lob/master/brick_cinderclient_ext/volume_actions.py, found only iSCSI,
> RBD and FIBRE_CHANNEL were supported.
>
>
>
> Wondering if there are ways to mount the NFS volume?
>
>
>
> Thanks,
>
> Clay
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][ptg] Denver PTG on-site or virtual

[Adam Harwell]

As one of the other two in the etherpad, I will say that I was looking
forward to getting together face to face with other contributors for the
first time (as I am new to the project), but I guess the majority won't
actually be there, and I understand that we need to do what is best for the
majority as well.
I know that at least one or maybe two other people from my team were also
planning to attend some Kolla sessions, so I'll see if I can get them to
sign up.
The other projects I'll be focused on are Octavia and Barbican, and I know
both have been successful with a hybrid approach in the past (providing
video of the room and allowing folks to dial in and contribute, while also
having a number of people present physically).
Since the room is already reserved, I don't see a huge point in avoiding
its use either.

   --Adam

On Fri, Aug 17, 2018, 20:27 Mark Goddard  wrote:

> As one of the lucky three kolleagues able to make the PTG, here's my
> position (inline).
>
> On 17 August 2018 at 11:52, Eduardo Gonzalez  wrote:
>
>> Fellow kolleages.
>>
>> In september is Denver PTG, as per the etherpad [0] only 3 contributors
>> confirmed their presence in the PTG, we expected more people to be there as
>> previous PTGs were full of contributors and operators.
>>
>> In the last kolla meeting [1] with discussed if we should make a virtual
>> PTG rather than a on-site one as we will probably reach a bigger number of
>> attendance.
>>
>> This set us in a bad possition as per:
>>
>> If we do an on-site PTG
>>
>> - Small representation for a whole cycle design, being this one larger
>> than usual.
>> - Many people whiling to attend is not able to be there.
>>
>
> I agree that three is too small a number to justify an on-site PTG. I was
> planning to split my time between kolla and ironic, so being able to focus
> on one project would be beneficial to me, assuming the virtual PTG takes
> place at a different time. I could still split my time if the virtual PTG
> occurs at the same time.
>
>
>>
>> If we do a virtual PTG
>>
>> - Some people already spend money to travel for kolla PTG
>>
>
> I would be going anyway.
>
>
>> - PTG rooms are already reserved for kolla session
>>
>
> If the virtual PTG occurs at the same time, we could use the (oversized)
> reserved room to dial into calls.
>
> - No cross project discussion
>>
>
> Happy to attend on behalf of kolla and feed back to the team.
>
>>
>> If there are more people who is going to Denver and haven't signed up at
>> the etherpad, please confirm your presence as it will probably influence on
>> this topic.
>>
>> Here is the though question...
>>
>> What kind of PTG do you prefer for this one, virtual or on-site in Denver?
>>
>
> Virtual makes sense to me.
>
>>
>> CC to Kendall Nelson from the foundation if she could help us on this
>> though decission, given the small time we have until the PTG both ways have
>> some kind of bad consecuencies for both the project and the contributors.
>>
>> [0] https://etherpad.openstack.org/p/kolla-stein-ptg-planning
>> [1]
>> http://eavesdrop.openstack.org/meetings/kolla/2018/kolla.2018-08-15-15.00.log.html#l-13
>>
>> Regards
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][ptg] Denver PTG on-site or virtual

[Mark Goddard]

Whether there is a physical PTG session or not, I'd certainly like to meet
up with other folks who are using and/or contributing to Kolla, let's be
sure to make time for that.
Mark

On 17 August 2018 at 12:54, Adam Harwell  wrote:

> As one of the other two in the etherpad, I will say that I was looking
> forward to getting together face to face with other contributors for the
> first time (as I am new to the project), but I guess the majority won't
> actually be there, and I understand that we need to do what is best for the
> majority as well.
> I know that at least one or maybe two other people from my team were also
> planning to attend some Kolla sessions, so I'll see if I can get them to
> sign up.
> The other projects I'll be focused on are Octavia and Barbican, and I know
> both have been successful with a hybrid approach in the past (providing
> video of the room and allowing folks to dial in and contribute, while also
> having a number of people present physically).
> Since the room is already reserved, I don't see a huge point in avoiding
> its use either.
>
>--Adam
>
>
> On Fri, Aug 17, 2018, 20:27 Mark Goddard  wrote:
>
>> As one of the lucky three kolleagues able to make the PTG, here's my
>> position (inline).
>>
>> On 17 August 2018 at 11:52, Eduardo Gonzalez  wrote:
>>
>>> Fellow kolleages.
>>>
>>> In september is Denver PTG, as per the etherpad [0] only 3 contributors
>>> confirmed their presence in the PTG, we expected more people to be there as
>>> previous PTGs were full of contributors and operators.
>>>
>>> In the last kolla meeting [1] with discussed if we should make a virtual
>>> PTG rather than a on-site one as we will probably reach a bigger number of
>>> attendance.
>>>
>>> This set us in a bad possition as per:
>>>
>>> If we do an on-site PTG
>>>
>>> - Small representation for a whole cycle design, being this one larger
>>> than usual.
>>> - Many people whiling to attend is not able to be there.
>>>
>>
>> I agree that three is too small a number to justify an on-site PTG. I was
>> planning to split my time between kolla and ironic, so being able to focus
>> on one project would be beneficial to me, assuming the virtual PTG takes
>> place at a different time. I could still split my time if the virtual PTG
>> occurs at the same time.
>>
>>
>>>
>>> If we do a virtual PTG
>>>
>>> - Some people already spend money to travel for kolla PTG
>>>
>>
>> I would be going anyway.
>>
>>
>>> - PTG rooms are already reserved for kolla session
>>>
>>
>> If the virtual PTG occurs at the same time, we could use the (oversized)
>> reserved room to dial into calls.
>>
>> - No cross project discussion
>>>
>>
>> Happy to attend on behalf of kolla and feed back to the team.
>>
>>>
>>> If there are more people who is going to Denver and haven't signed up at
>>> the etherpad, please confirm your presence as it will probably influence on
>>> this topic.
>>>
>>> Here is the though question...
>>>
>>> What kind of PTG do you prefer for this one, virtual or on-site in
>>> Denver?
>>>
>>
>> Virtual makes sense to me.
>>
>>>
>>> CC to Kendall Nelson from the foundation if she could help us on this
>>> though decission, given the small time we have until the PTG both ways have
>>> some kind of bad consecuencies for both the project and the contributors.
>>>
>>> [0] https://etherpad.openstack.org/p/kolla-stein-ptg-planning
>>> [1] http://eavesdrop.openstack.org/meetings/kolla/2018/kolla.
>>> 2018-08-15-15.00.log.html#l-13
>>>
>>> Regards
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>>> unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Broken pep8 job

[Slawomir Kaplonski]

Thx,

I just did similar patches for stable/rocky [1] and stable/queens [2] in 
Neutron repo:

[1] https://review.openstack.org/#/c/593075/
[2] https://review.openstack.org/#/c/593078/


> Wiadomość napisana przez Doug Hellmann  w dniu 
> 17.08.2018, o godz. 16:34:
> 
> Excerpts from Slawomir Kaplonski's message of 2018-08-17 10:16:35 +0200:
>> Hi,
>> 
>> It looks that pep8 job in Neutron is currently broken because of new version 
>> of bandit (1.5.0).
>> If You have in Your patch failure of pep8 job with error like [1] please 
>> don’t recheck as it will not help.
>> I did some patch which should fix it [2]. Will let You know when it will be 
>> fixed and You will be able to rebase You patches.
>> 
>> [1] 
>> http://logs.openstack.org/37/382037/67/check/openstack-tox-pep8/e2bbd84/job-output.txt.gz#_2018-08-16_21_45_55_366148
>> [2] https://review.openstack.org/#/c/592884/
>> 
>> — 
>> Slawek Kaplonski
>> Senior software engineer
>> Red Hat
>> 
> 
> We had this problem in oslo.concurrency, too.
> 
> Because bandit is considered to be a linter and different teams may
> want to use different versions, it is not managed through the
> constraints list (there is no co-installability requirement for
> linters). Some of the projects using it do not have it capped, so
> new releases that introduce breaking changes like this can cause
> gate issues.
> 
> In the oslo.concurrency stable branch we capped the version of
> bandit to avoid having to backport changes just to fix the linter
> errors. We made code changes in master to address them and left
> bandit uncapped there, for now.
> 
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] how nova should behave when placement returns consumer generation conflict

[Eric Fried]

gibi-

>> - On migration, when we transfer the allocations in either direction, a
>> conflict means someone managed to resize (or otherwise change
>> allocations?) since the last time we pulled data. Given the global lock
>> in the report client, this should have been tough to do. If it does
>> happen, I would think any retry would need to be done all the way back
>> at the claim, which I imagine is higher up than we should go. So again,
>> I think we should fail the migration and make the user retry.
> 
> Do we want to fail the whole migration or just the migration step (e.g.
> confirm, revert)?
> The later means that failure during confirm or revert would put the
> instance back to VERIFY_RESIZE. While the former would mean that in case
> of conflict at confirm we try an automatic revert. But for a conflict at
> revert we can only put the instance to ERROR state.

This again should be "impossible" to come across. What would the
behavior be if we hit, say, ValueError in this spot?

-efried

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

Re: [openstack-dev] [tripleo][Edge][FEMDC] Edge clouds and controlplane updates

[Jiří Stránský]

On 14.8.2018 15:19, Bogdan Dobrelya wrote:

On 8/13/18 9:47 PM, Giulio Fidente wrote:

Hello,

I'd like to get some feedback regarding the remaining
work for the split controlplane spec implementation [1]

Specifically, while for some services like nova-compute it is not
necessary to update the controlplane nodes after an edge cloud is
deployed, for other services, like cinder (or glance, probably
others), it is necessary to do an update of the config files on the
controlplane when a new edge cloud is deployed.

In fact for services like cinder or glance, which are hosted in the
controlplane, we need to pull data from the edge clouds (for example
the newly deployed ceph cluster keyrings and fsid) to configure cinder
(or glance) with a new backend.

It looks like this demands for some architectural changes to solve the > 
following two:

- how do we trigger/drive updates of the controlplane nodes after the
edge cloud is deployed?


Note, there is also a strict(?) requirement of local management
capabilities for edge clouds temporary disconnected off the central
controlplane. That complicates the updates triggering even more. We'll
need at least a notification-and-triggering system to perform required
state synchronizations, including conflicts resolving. If that's the
case, the architecture changes for TripleO deployment framework are
inevitable AFAICT.


Indeed this would complicate things much, but IIUC the spec [1] that 
Giulio referenced doesn't talk about local management at all.


Within the context of what the spec covers, i.e. 1 stack for Controller 
role and other stack(s) for Compute or *Storage roles, i hope we could 
address updates/upgrades workflow similarly as the deployment workflow 
would be addressed -- working with the stacks one by one.


That would probably mean:

1. `update/upgrade prepare` on Controller stack

2. `update/upgrade prepare` on other stacks (perhaps reusing some 
outputs from Controller stack here)


3. `update/upgrade run` on Controller stack

4. `update/upgrade run` on other stacks

5. (`external-update/external-upgrade run` on other stacks where 
appropriate)


6. `update/upgrade converge` on Controller stack

7. `update/upgrade converge` on other stacks (again maybe reusing 
outputs from Controller stack)


I'm not *sure* such approach would work, but at the moment i don't see a 
reason why it wouldn't :)


Jirka





- how do we scale the controlplane parameters to accomodate for N
backends of the same type?

A very rough approach to the latter could be to use jinja to scale up
the CephClient service so that we can have multiple copies of it in the
controlplane.

Each instance of CephClient should provide the ceph config file and
keyring necessary for each cinder (or glance) backend.

Also note that Ceph is only a particular example but we'd need a similar
workflow for any backend type.

The etherpad for the PTG session [2] touches this, but it'd be good to
start this conversation before then.

1.
https://specs.openstack.org/openstack/tripleo-specs/specs/rocky/split-controlplane.html

2. https://etherpad.openstack.org/p/tripleo-ptg-queens-split-controlplane







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

Re: [openstack-dev] [puppet] migrating to storyboard

[Tom Barron]

On 17/08/18 09:05 -0500, Jay S Bryant wrote:



On 8/16/2018 4:03 PM, Kendall Nelson wrote:


Hello :)

On Thu, Aug 16, 2018 at 12:47 PM Jay S Bryant > wrote:


   Hey,

   Well, the attachments are one of the things holding us up along
   with reduced participation in the project and a number of other
   challenges.  Getting the time to prepare for the move has been
   difficult.


I wouldn't really say we have reduced participation- we've always 
been a small team. In the last year, we've actually seen more 
involvement from new contributors (new and future users of sb) which 
has been awesome :) We even had/have an outreachy intern that has 
been working on making searching and filtering even better.


Prioritizing when to invest time to migrate has been hard for 
several projects so Cinder isn't alone, no worries :)
Sorry, I wasn't clear here.  I was referencing greatly reduced 
participation in Cinder.  I had been hoping to get more time to dig 
into StoryBoard and prepare the team for migration but that has been 
harder given an increased need to do other work in Cinder.


I have noticed that the search in StoryBoard was better so that was 
encouraging.


   I am planning to take some time before the PTG to look at how
   Ironic has been using Storyboard and take this forward to the team
   at the PTG to try and spur the process along.


Glad to hear it! Once I get the SB room on the schedule, you are 
welcome to join the conversations there.  We would love any feedback 
you have on what the 'other challenges' are that you mentioned 
above.
Yeah, I think it would be good to have time at the PTG to get Manila, 
Cinder, Oslo, etc. together to talk about this.  This will give me 
incentive to do some more experimenting before the PTG.  :-)


+1

- Tom Barron  (tbarron)



See you in Denver.  :-)


   Jay Bryant - (jungleboyj)


   On 8/16/2018 2:22 PM, Kendall Nelson wrote:

   Hey :)

   Yes, I know attachments are important to a few projects. They are
   on our todo list and we plan to talk about how to implement them
   at the upcoming PTG[1].

   Unfortunately, we have had other things that are taking priority
   over attachments. We would really love to migrate you all, but if
   attachments is what is really blocking you and there is no other
   workable solution, I'm more than willing to review patches if you
   want to help out to move things along a little faster :)

   -Kendall Nelson (diablo_rojo)

   [1]https://etherpad.openstack.org/p/sb-stein-ptg-planning

   On Wed, Aug 15, 2018 at 1:49 PM Jay S Bryant
   mailto:jungleb...@gmail.com>> wrote:



   On 8/15/2018 11:43 AM, Chris Friesen wrote:
   > On 08/14/2018 10:33 AM, Tobias Urdin wrote:
   >
   >> My goal is that we will be able to swap to Storyboard
   during the
   >> Stein cycle but
   >> considering that we have a low activity on
   >> bugs my opinion is that we could do this swap very easily
   anything
   >> soon as long
   >> as everybody is in favor of it.
   >>
   >> Please let me know what you think about moving to Storyboard?
   >
   > Not a puppet dev, but am currently using Storyboard.
   >
   > One of the things we've run into is that there is no way to
   attach log
   > files for bug reports to a story. There's an open story on
   this[1]
   > but it's not assigned to anyone.
   >
   > Chris
   >
   >
   > [1] https://storyboard.openstack.org/#!/story/2003071
   
   >
   Cinder is planning on holding on any migration, like Manila,
   until the
   file attachment issue is resolved.

   Jay
   >
   
__

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


   
__
   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





Thanks!

- Kendall (diablo_rojo)





__
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 

[openstack-dev] [keystone] Keystone Team Update - Week of 13 August 2018

[Colleen Murphy]

Forgot the [keystone] tag.

On Fri, Aug 17, 2018, at 4:11 PM, Colleen Murphy wrote:
> # Keystone Team Update - Week of 13 Auguest 2018
> 
> ## News
> 
> Relatively quiet week with minimal fires. Prepare for the PTG by adding 
> topics to the etherpad[1].
> 
> [1] https://etherpad.openstack.org/p/keystone-stein-ptg
> 
> ## Recently Merged Changes
> 
> Search query: https://bit.ly/2IACk3F
> 
> We merged 27 changes this week.
> 
> ## Changes that need Attention
> 
> Search query: https://bit.ly/2wv7QLK
> 
> There are 46 changes that are passing CI, not in merge conflict, have no 
> negative reviews and aren't proposed by bots.
> 
> ## Bugs
> 
> This week we opened 2 new bugs and closed 2.
> 
> Bugs opened (2) 
> Bug #1786594 (keystone:Undecided) opened by Egor Panfilov 
> https://bugs.launchpad.net/keystone/+bug/1786594 
> Bug #1787212 (keystone:Undecided) opened by tujiapeng 
> https://bugs.launchpad.net/keystone/+bug/1787212 
> 
> Bugs fixed (2) 
> Bug #1784536 (keystone:Low) fixed by Bi wei 
> https://bugs.launchpad.net/keystone/+bug/1784536 
> Bug #1785898 (ldappool:Undecided) fixed by Nick Wilburn 
> https://bugs.launchpad.net/ldappool/+bug/1785898
> 
> ## Milestone Outlook
> 
> https://releases.openstack.org/rocky/schedule.html
> 
> Next week will be the last week to release another RC if we need to.
> 
> ## Shout-outs
> 
> Congratulations to Nick Wilburn (orange_julius) whose first patch to 
> OpenStack landed this week[2] which fixed a major bug in the ldappool 
> library. Many thanks!
> 
> [2] https://review.openstack.org/591174
> 
> ## Help with this newsletter
> 
> Help contribute to this newsletter by editing the etherpad: 
> https://etherpad.openstack.org/p/keystone-team-newsletter
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [puppet] Puppet weekly recap - week 33

[Tobias Urdin]

Hello all Puppeteers!

Welcome to the weekly Puppet recap for week 33.
This is a weekly overview of what has changed in the Puppet OpenStack 
project the past week.



CHANGES


Changes in all modules
---
* Removed PE requirement from metadata.json
* Prepared Rocky RC1

Aodh
---
* Improved restarting Apache
   Changed so that Apache more accurately restarts services on 
configuration changes.


Glance
-
* Configure access_key and secret_key as secrets
* Fixed glance_image provider
   Stopped working after os_algo, os_hash_value and os_hidden was 
introduced.


Heat
--
* Improved restarting Apache
   Changed so that Apache more accurately restarts services on 
configuration changes.


Horizon
--
* Add wsgi_processes and wsgi_threads to horizon init
* apache wsgi: Exchange defaults for workers and threads
   Default values for Apache WSGI workers and threads changed.

Manila
-
* Support manila-api deployment with Apache WSGI
  You can now deploy manila-api under Apache WSGI

Murano
--
* Deprecated auth_uri option

Nova
---
* Configure access_key and secret_key as secrets

Puppet-OpenStack-Integration
-
* Test bgp-dragent in scenario004
   Now has full testing for the BGP agent provided by 
neutron-dynamic-routing

* Fix configure_facts.sh for RDO mirrors
* Run metadata-json-lint test in lint job
   Now runs metadata-json-lint in puppet-lint jobs if a metadata.json 
file exists.

* Test Sahara API with WSGI
   Sahara is now tested with API running under Apache WSGI

Puppet-OpenStack-Guide
--
* Updated latest RC1 version on release page

Panko

* Restart API also when run with Apache
   Correctly restart Apache on configuration changes

Sahara
--
* Add Sahara API WSGI support
  The Sahara API can now be deployed with Apache WSGI


SPECS

None.


OTHER

* We have submitted a review for releasing RC1 of all modules 
https://review.openstack.org/#/c/592584/

* We have started to take a look at migrating to Storyboard
   I have posted an email on the mailing list, please leave your 
feedback if you have any.


Interested in knowing what's up? Want to help or get help? See our 
etherpad https://etherpad.openstack.org/p/puppet-openstack-rocky
Or maybe you have some awesome ideas for next release? Let us know 
https://etherpad.openstack.org/p/puppet-openstack-stein




Wishing you all a great weekend!

Best regards
Tobias

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

Re: [openstack-dev] [neutron] Broken pep8 job

[Doug Hellmann]

Excerpts from Slawomir Kaplonski's message of 2018-08-17 10:16:35 +0200:
> Hi,
> 
> It looks that pep8 job in Neutron is currently broken because of new version 
> of bandit (1.5.0).
> If You have in Your patch failure of pep8 job with error like [1] please 
> don’t recheck as it will not help.
> I did some patch which should fix it [2]. Will let You know when it will be 
> fixed and You will be able to rebase You patches.
> 
> [1] 
> http://logs.openstack.org/37/382037/67/check/openstack-tox-pep8/e2bbd84/job-output.txt.gz#_2018-08-16_21_45_55_366148
> [2] https://review.openstack.org/#/c/592884/
> 
> — 
> Slawek Kaplonski
> Senior software engineer
> Red Hat
> 

We had this problem in oslo.concurrency, too.

Because bandit is considered to be a linter and different teams may
want to use different versions, it is not managed through the
constraints list (there is no co-installability requirement for
linters). Some of the projects using it do not have it capped, so
new releases that introduce breaking changes like this can cause
gate issues.

In the oslo.concurrency stable branch we capped the version of
bandit to avoid having to backport changes just to fix the linter
errors. We made code changes in master to address them and left
bandit uncapped there, for now.

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] [kolla][ptg] Denver PTG on-site or virtual

[Adam Harwell]

Yeah, definitely! Worst case, we spend some time huddled around a table by
the bar, and that isn't too bad in my book. ;)

   --Adam

On Fri, Aug 17, 2018, 20:59 Mark Goddard  wrote:

> Whether there is a physical PTG session or not, I'd certainly like to meet
> up with other folks who are using and/or contributing to Kolla, let's be
> sure to make time for that.
> Mark
>
> On 17 August 2018 at 12:54, Adam Harwell  wrote:
>
>> As one of the other two in the etherpad, I will say that I was looking
>> forward to getting together face to face with other contributors for the
>> first time (as I am new to the project), but I guess the majority won't
>> actually be there, and I understand that we need to do what is best for the
>> majority as well.
>> I know that at least one or maybe two other people from my team were also
>> planning to attend some Kolla sessions, so I'll see if I can get them to
>> sign up.
>> The other projects I'll be focused on are Octavia and Barbican, and I
>> know both have been successful with a hybrid approach in the past
>> (providing video of the room and allowing folks to dial in and contribute,
>> while also having a number of people present physically).
>> Since the room is already reserved, I don't see a huge point in avoiding
>> its use either.
>>
>>--Adam
>>
>>
>> On Fri, Aug 17, 2018, 20:27 Mark Goddard  wrote:
>>
>>> As one of the lucky three kolleagues able to make the PTG, here's my
>>> position (inline).
>>>
>>> On 17 August 2018 at 11:52, Eduardo Gonzalez  wrote:
>>>
 Fellow kolleages.

 In september is Denver PTG, as per the etherpad [0] only 3 contributors
 confirmed their presence in the PTG, we expected more people to be there as
 previous PTGs were full of contributors and operators.

 In the last kolla meeting [1] with discussed if we should make a
 virtual PTG rather than a on-site one as we will probably reach a bigger
 number of attendance.

 This set us in a bad possition as per:

 If we do an on-site PTG

 - Small representation for a whole cycle design, being this one larger
 than usual.
 - Many people whiling to attend is not able to be there.

>>>
>>> I agree that three is too small a number to justify an on-site PTG. I
>>> was planning to split my time between kolla and ironic, so being able to
>>> focus on one project would be beneficial to me, assuming the virtual PTG
>>> takes place at a different time. I could still split my time if the virtual
>>> PTG occurs at the same time.
>>>
>>>

 If we do a virtual PTG

 - Some people already spend money to travel for kolla PTG

>>>
>>> I would be going anyway.
>>>
>>>
 - PTG rooms are already reserved for kolla session

>>>
>>> If the virtual PTG occurs at the same time, we could use the
>>> (oversized) reserved room to dial into calls.
>>>
>>> - No cross project discussion

>>>
>>> Happy to attend on behalf of kolla and feed back to the team.
>>>

 If there are more people who is going to Denver and haven't signed up
 at the etherpad, please confirm your presence as it will probably influence
 on this topic.

 Here is the though question...

 What kind of PTG do you prefer for this one, virtual or on-site in
 Denver?

>>>
>>> Virtual makes sense to me.
>>>

 CC to Kendall Nelson from the foundation if she could help us on this
 though decission, given the small time we have until the PTG both ways have
 some kind of bad consecuencies for both the project and the contributors.

 [0] https://etherpad.openstack.org/p/kolla-stein-ptg-planning
 [1]
 http://eavesdrop.openstack.org/meetings/kolla/2018/kolla.2018-08-15-15.00.log.html#l-13

 Regards


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


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

Re: [openstack-dev] [Nova] A multi-cell instance-list performance test

[Dan Smith]

> We have tried out the patch:
> https://review.openstack.org/#/c/592698/
> we also applied https://review.openstack.org/#/c/592285/
>
> it turns out that we are able to half the overall time consumption, we
> did try with different sort key and dirs, the results are similar, we
> didn't try out paging yet:

Excellent! Let's continue discussion of the batching approach in that
review. There are some other things to try.

Thanks!

--Dan

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

Re: [openstack-dev] [puppet] migrating to storyboard

[Jay S Bryant]

On 8/16/2018 4:03 PM, Kendall Nelson wrote:


Hello :)

On Thu, Aug 16, 2018 at 12:47 PM Jay S Bryant > wrote:


Hey,

Well, the attachments are one of the things holding us up along
with reduced participation in the project and a number of other
challenges.  Getting the time to prepare for the move has been
difficult.


I wouldn't really say we have reduced participation- we've always been 
a small team. In the last year, we've actually seen more involvement 
from new contributors (new and future users of sb) which has been 
awesome :) We even had/have an outreachy intern that has been working 
on making searching and filtering even better.


Prioritizing when to invest time to migrate has been hard for several 
projects so Cinder isn't alone, no worries :)
Sorry, I wasn't clear here.  I was referencing greatly reduced 
participation in Cinder.  I had been hoping to get more time to dig into 
StoryBoard and prepare the team for migration but that has been harder 
given an increased need to do other work in Cinder.


I have noticed that the search in StoryBoard was better so that was 
encouraging.


I am planning to take some time before the PTG to look at how
Ironic has been using Storyboard and take this forward to the team
at the PTG to try and spur the process along.


Glad to hear it! Once I get the SB room on the schedule, you are 
welcome to join the conversations there.  We would love any feedback 
you have on what the 'other challenges' are that you mentioned above.
Yeah, I think it would be good to have time at the PTG to get Manila, 
Cinder, Oslo, etc. together to talk about this.  This will give me 
incentive to do some more experimenting before the PTG.  :-)


See you in Denver.  :-)


Jay Bryant - (jungleboyj)


On 8/16/2018 2:22 PM, Kendall Nelson wrote:

Hey :)

Yes, I know attachments are important to a few projects. They are
on our todo list and we plan to talk about how to implement them
at the upcoming PTG[1].

Unfortunately, we have had other things that are taking priority
over attachments. We would really love to migrate you all, but if
attachments is what is really blocking you and there is no other
workable solution, I'm more than willing to review patches if you
want to help out to move things along a little faster :)

-Kendall Nelson (diablo_rojo)

[1]https://etherpad.openstack.org/p/sb-stein-ptg-planning

On Wed, Aug 15, 2018 at 1:49 PM Jay S Bryant
mailto:jungleb...@gmail.com>> wrote:



On 8/15/2018 11:43 AM, Chris Friesen wrote:
> On 08/14/2018 10:33 AM, Tobias Urdin wrote:
>
>> My goal is that we will be able to swap to Storyboard
during the
>> Stein cycle but
>> considering that we have a low activity on
>> bugs my opinion is that we could do this swap very easily
anything
>> soon as long
>> as everybody is in favor of it.
>>
>> Please let me know what you think about moving to Storyboard?
>
> Not a puppet dev, but am currently using Storyboard.
>
> One of the things we've run into is that there is no way to
attach log
> files for bug reports to a story. There's an open story on
this[1]
> but it's not assigned to anyone.
>
> Chris
>
>
> [1] https://storyboard.openstack.org/#!/story/2003071

>
Cinder is planning on holding on any migration, like Manila,
until the
file attachment issue is resolved.

Jay
>

__

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

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



__
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





Thanks!

- Kendall (diablo_rojo)


__
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] [goal][python3] more updates to the goal tools

[Doug Hellmann]

I was not able to reproduce the problem. Please test the fix in
https://review.openstack.org/#/c/593068/ to see if that helps.

Which version of Python are you using to run the tools? And on which OS?

Excerpts from Doug Hellmann's message of 2018-08-17 10:30:29 -0400:
> I will work on fixing this today.
> 
> Has the designate team agreed to go ahead with their migration, or
> are you still testing the scripts?
> 
> Doug
> 
> Excerpts from super user's message of 2018-08-17 15:37:03 +0900:
> > Hi Doug,
> > 
> > I'm Nguyen Hai. I proposed the python3-first patch set for
> > designate projects. However, I have met this error to designate and
> > designate-dashboard:
> > 
> > === ../Output/designate/openstack/designate @ master ===
> > 
> > ./tools/python3-first/do_repo.sh ../Output/designate/openstack/designate
> > master 24292
> > 
> > ++ cat ../Output/designate/openstack/designate/.gitreview
> > ++ grep project
> > ++ cut -f2 -d=
> > + actual=openstack/designate.git
> > +++ dirname ../Output/designate/openstack/designate
> > ++ basename ../Output/designate/openstack
> > ++ basename ../Output/designate/openstack/designate
> > + expected=openstack/designate
> > + '[' openstack/designate.git '!=' openstack/designate -a
> > openstack/designate.git '!=' openstack/designate.git ']'
> > + git -C ../Output/designate/openstack/designate review -s
> > Creating a git remote called 'gerrit' that maps to:
> > ssh://
> > nguyentri...@review.openstack.org:29418/openstack/designate.git
> > ++ basename master
> > + new_branch=python3-first-master
> > + git -C ../Output/designate/openstack/designate branch
> > + grep -q python3-first-master
> > + echo 'creating python3-first-master'
> > creating python3-first-master
> > + git -C ../Output/designate/openstack/designate checkout -- .
> > + git -C ../Output/designate/openstack/designate clean -f -d
> > + git -C ../Output/designate/openstack/designate checkout -q origin/master
> > + git -C ../Output/designate/openstack/designate checkout -b
> > python3-first-master
> > Switched to a new branch 'python3-first-master'
> > + python3-first -v --debug jobs update
> > ../Output/designate/openstack/designate
> > determining repository name from .gitreview
> > working on openstack/designate @ master
> > looking for zuul config in
> > ../Output/designate/openstack/designate/.zuul.yaml
> > using zuul config from ../Output/designate/openstack/designate/.zuul.yaml
> > loading project settings from ../project-config/zuul.d/projects.yaml
> > loading project templates from
> > ../openstack-zuul-jobs/zuul.d/project-templates.yaml
> > loading jobs from ../openstack-zuul-jobs/zuul.d/jobs.yaml
> > looking for settings for openstack/designate
> > looking at template 'openstack-python-jobs'
> > looking at template 'openstack-python35-jobs'
> > looking at template 'publish-openstack-sphinx-docs'
> > looking at template 'periodic-stable-jobs'
> > looking at template 'check-requirements'
> > did not find template definition for 'check-requirements'
> > looking at template 'translation-jobs-master-stable'
> > looking at template 'release-notes-jobs'
> > looking at template 'api-ref-jobs'
> > looking at template 'install-guide-jobs'
> > looking at template 'release-openstack-server'
> > filtering on master
> > merging templates
> >   adding openstack-python-jobs
> >   adding openstack-python35-jobs
> >   adding publish-openstack-sphinx-docs
> >   adding periodic-stable-jobs
> >   adding check-requirements
> >   adding release-notes-jobs
> >   adding install-guide-jobs
> > merging pipeline check
> > *unhashable type: 'CommentedMap'*
> > *Traceback (most recent call last):*
> > *  File
> > "/home/stack/python3-first/goal-tools/.tox/venv/lib/python3.6/site-packages/cliff/app.py",
> > line 402, in run_subcommand*
> > *result = cmd.run(parsed_args)*
> > *  File
> > "/home/stack/python3-first/goal-tools/.tox/venv/lib/python3.6/site-packages/cliff/command.py",
> > line 184, in run*
> > *return_code = self.take_action(parsed_args) or 0*
> > *  File
> > "/home/stack/python3-first/goal-tools/goal_tools/python3_first/jobs.py",
> > line 531, in take_action*
> > *entry,*
> > *  File
> > "/home/stack/python3-first/goal-tools/goal_tools/python3_first/jobs.py",
> > line 397, in merge_project_settings*
> > *up.get(pipeline, comments.CommentedMap()),*
> > *  File
> > "/home/stack/python3-first/goal-tools/goal_tools/python3_first/jobs.py",
> > line 362, in merge_pipeline*
> > *if job_name in job_names:*
> > *TypeError: unhashable type: 'CommentedMap'*
> > *Traceback (most recent call last):*
> > *  File "/home/stack/python3-first/goal-tools/.tox/venv/bin/python3-first",
> > line 10, in *
> > *sys.exit(main())*
> > *  File
> > "/home/stack/python3-first/goal-tools/goal_tools/python3_first/main.py",
> > line 42, in main*
> > *return Python3First().run(argv)*
> > *  File
> > "/home/stack/python3-first/goal-tools/.tox/venv/lib/python3.6/site-packages/cliff/app.py",
> > line 281, in run*
> 

Re: [openstack-dev] [goal][python3] more updates to the goal tools

[Doug Hellmann]

I will work on fixing this today.

Has the designate team agreed to go ahead with their migration, or
are you still testing the scripts?

Doug

Excerpts from super user's message of 2018-08-17 15:37:03 +0900:
> Hi Doug,
> 
> I'm Nguyen Hai. I proposed the python3-first patch set for
> designate projects. However, I have met this error to designate and
> designate-dashboard:
> 
> === ../Output/designate/openstack/designate @ master ===
> 
> ./tools/python3-first/do_repo.sh ../Output/designate/openstack/designate
> master 24292
> 
> ++ cat ../Output/designate/openstack/designate/.gitreview
> ++ grep project
> ++ cut -f2 -d=
> + actual=openstack/designate.git
> +++ dirname ../Output/designate/openstack/designate
> ++ basename ../Output/designate/openstack
> ++ basename ../Output/designate/openstack/designate
> + expected=openstack/designate
> + '[' openstack/designate.git '!=' openstack/designate -a
> openstack/designate.git '!=' openstack/designate.git ']'
> + git -C ../Output/designate/openstack/designate review -s
> Creating a git remote called 'gerrit' that maps to:
> ssh://
> nguyentri...@review.openstack.org:29418/openstack/designate.git
> ++ basename master
> + new_branch=python3-first-master
> + git -C ../Output/designate/openstack/designate branch
> + grep -q python3-first-master
> + echo 'creating python3-first-master'
> creating python3-first-master
> + git -C ../Output/designate/openstack/designate checkout -- .
> + git -C ../Output/designate/openstack/designate clean -f -d
> + git -C ../Output/designate/openstack/designate checkout -q origin/master
> + git -C ../Output/designate/openstack/designate checkout -b
> python3-first-master
> Switched to a new branch 'python3-first-master'
> + python3-first -v --debug jobs update
> ../Output/designate/openstack/designate
> determining repository name from .gitreview
> working on openstack/designate @ master
> looking for zuul config in
> ../Output/designate/openstack/designate/.zuul.yaml
> using zuul config from ../Output/designate/openstack/designate/.zuul.yaml
> loading project settings from ../project-config/zuul.d/projects.yaml
> loading project templates from
> ../openstack-zuul-jobs/zuul.d/project-templates.yaml
> loading jobs from ../openstack-zuul-jobs/zuul.d/jobs.yaml
> looking for settings for openstack/designate
> looking at template 'openstack-python-jobs'
> looking at template 'openstack-python35-jobs'
> looking at template 'publish-openstack-sphinx-docs'
> looking at template 'periodic-stable-jobs'
> looking at template 'check-requirements'
> did not find template definition for 'check-requirements'
> looking at template 'translation-jobs-master-stable'
> looking at template 'release-notes-jobs'
> looking at template 'api-ref-jobs'
> looking at template 'install-guide-jobs'
> looking at template 'release-openstack-server'
> filtering on master
> merging templates
>   adding openstack-python-jobs
>   adding openstack-python35-jobs
>   adding publish-openstack-sphinx-docs
>   adding periodic-stable-jobs
>   adding check-requirements
>   adding release-notes-jobs
>   adding install-guide-jobs
> merging pipeline check
> *unhashable type: 'CommentedMap'*
> *Traceback (most recent call last):*
> *  File
> "/home/stack/python3-first/goal-tools/.tox/venv/lib/python3.6/site-packages/cliff/app.py",
> line 402, in run_subcommand*
> *result = cmd.run(parsed_args)*
> *  File
> "/home/stack/python3-first/goal-tools/.tox/venv/lib/python3.6/site-packages/cliff/command.py",
> line 184, in run*
> *return_code = self.take_action(parsed_args) or 0*
> *  File
> "/home/stack/python3-first/goal-tools/goal_tools/python3_first/jobs.py",
> line 531, in take_action*
> *entry,*
> *  File
> "/home/stack/python3-first/goal-tools/goal_tools/python3_first/jobs.py",
> line 397, in merge_project_settings*
> *up.get(pipeline, comments.CommentedMap()),*
> *  File
> "/home/stack/python3-first/goal-tools/goal_tools/python3_first/jobs.py",
> line 362, in merge_pipeline*
> *if job_name in job_names:*
> *TypeError: unhashable type: 'CommentedMap'*
> *Traceback (most recent call last):*
> *  File "/home/stack/python3-first/goal-tools/.tox/venv/bin/python3-first",
> line 10, in *
> *sys.exit(main())*
> *  File
> "/home/stack/python3-first/goal-tools/goal_tools/python3_first/main.py",
> line 42, in main*
> *return Python3First().run(argv)*
> *  File
> "/home/stack/python3-first/goal-tools/.tox/venv/lib/python3.6/site-packages/cliff/app.py",
> line 281, in run*
> *result = self.run_subcommand(remainder)*
> *  File
> "/home/stack/python3-first/goal-tools/.tox/venv/lib/python3.6/site-packages/cliff/app.py",
> line 402, in run_subcommand*
> *result = cmd.run(parsed_args)*
> *  File
> "/home/stack/python3-first/goal-tools/.tox/venv/lib/python3.6/site-packages/cliff/command.py",
> line 184, in run*
> *return_code = self.take_action(parsed_args) or 0*
> *  File
> "/home/stack/python3-first/goal-tools/goal_tools/python3_first/jobs.py",
> line 

[openstack-dev] Keystone Team Update - Week of 13 Auguest 2018

[Colleen Murphy]

# Keystone Team Update - Week of 13 Auguest 2018

## News

Relatively quiet week with minimal fires. Prepare for the PTG by adding topics 
to the etherpad[1].

[1] https://etherpad.openstack.org/p/keystone-stein-ptg

## Recently Merged Changes

Search query: https://bit.ly/2IACk3F

We merged 27 changes this week.

## Changes that need Attention

Search query: https://bit.ly/2wv7QLK

There are 46 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots.

## Bugs

This week we opened 2 new bugs and closed 2.

Bugs opened (2) 
Bug #1786594 (keystone:Undecided) opened by Egor Panfilov 
https://bugs.launchpad.net/keystone/+bug/1786594 
Bug #1787212 (keystone:Undecided) opened by tujiapeng 
https://bugs.launchpad.net/keystone/+bug/1787212 

Bugs fixed (2) 
Bug #1784536 (keystone:Low) fixed by Bi wei 
https://bugs.launchpad.net/keystone/+bug/1784536 
Bug #1785898 (ldappool:Undecided) fixed by Nick Wilburn 
https://bugs.launchpad.net/ldappool/+bug/1785898

## Milestone Outlook

https://releases.openstack.org/rocky/schedule.html

Next week will be the last week to release another RC if we need to.

## Shout-outs

Congratulations to Nick Wilburn (orange_julius) whose first patch to OpenStack 
landed this week[2] which fixed a major bug in the ldappool library. Many 
thanks!

[2] https://review.openstack.org/591174

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter

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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

[melanie witt]

On Fri, 17 Aug 2018 13:37:41 -0500, Sean Mcginnis wrote:

On Fri, Aug 17, 2018 at 12:47:10PM -0500, Ed Leafe wrote:

On Aug 17, 2018, at 12:30 PM, Dan Smith  wrote:


Splitting it out to another repository within the compute umbrella (what
do we call it these days?) satisfies the _technical_ concern of not
being able to use placement without installing the rest of the nova code
and dependency tree. Artificially creating more "perceived" distance
sounds really political to me, so let's be sure we're upfront about the
reasoning for doing that if so :)


Characterizing the proposed separation as “artificial” seems to be quite 
political in itself.



Other than currently having a common set of interested people, is there
something about placement that makes it something that should be under the
compute umbrella?
I explained why I think placement belongs under the compute umbrella for 
now in my reply [1]. My reply might have been missed in the shuffle.


-melanie

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-August/133452.html





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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

[Sean McGinnis]

On Fri, Aug 17, 2018 at 10:59:47AM -0500, Ed Leafe wrote:
> On Aug 17, 2018, at 10:51 AM, Chris Dent  wrote:
> > 
> > One of the questions that has come up on the etherpad is about how
> > placement should be positioned, as a project, after the extraction.
> > The options are:
> > 
> > * A repo within the compute project
> > * Its own project, either:
> >  * working towards being official and governed
> >  * official and governed from the start
> 
> I would like to hear from the Cinder and Neutron teams, especially those who 
> were around when those compute sub-projects were split off into their own 
> projects. Did you feel that being independent of compute helped or hindered 
> you? And to those who are in those projects now, is there any sense that 
> things would be better if you were still part of compute?
> 

I wasn't around at the beginning of the separation, but I don't think Cinder
would be anything like it is today (you can decide if that's a good thing or
not) if it had remained a component of Nova.

> My opinion has been that Placement should have been separate from the start. 
> The longer we keep Placement inside of Nova, the more painful it will be to 
> extract, and hence the likelihood of that every happening is greatly 
> diminished.

I have to agree with this statement.

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

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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

[Tom Barron]

On 17/08/18 11:47 -0500, Jay S Bryant wrote:



On 8/17/2018 10:59 AM, Ed Leafe wrote:

On Aug 17, 2018, at 10:51 AM, Chris Dent  wrote:

One of the questions that has come up on the etherpad is about how
placement should be positioned, as a project, after the extraction.
The options are:

* A repo within the compute project
* Its own project, either:
 * working towards being official and governed
 * official and governed from the start

I would like to hear from the Cinder and Neutron teams, especially those who 
were around when those compute sub-projects were split off into their own 
projects. Did you feel that being independent of compute helped or hindered 
you? And to those who are in those projects now, is there any sense that things 
would be better if you were still part of compute?

Ed,

I started working with Cinder right after the split had taken place.  
I have had several discussions as to how the split took place and why 
over the years since.


In the case of Cinder we split because the pace at which things were 
changing in the Cinder project had exceeded what could be handled by 
the Nova team.  Nova has always been a busy project and the changes 
coming in for Nova Volume were getting lost in the larger Nova 
picture.  So, Nova Volume was broken out to become Cinder so that 
people could focus on the storage aspect of things and get change 
through more quickly.


So, I think, for the most part that it has been something that has 
benefited the project.  The exception would be all the challenges that 
have come working cross project on changes that impact both Cinder and 
Nova but that has improved over time.  Given the good leadership I 
envision for the Placement Service I think that is less of a concern.


For the placement service, I would expect that there will be a greater 
rate of change once more projects are using it.  This would also 
support splitting the service out.

My opinion has been that Placement should have been separate from the start. 
The longer we keep Placement inside of Nova, the more painful it will be to 
extract, and hence the likelihood of that every happening is greatly diminished.


I do agree that pulling the service out sooner than later is probably best.


Has there been a discussion on record of how use of placement by 
cinder would affect "standalone" cinder (or manila) initiatives where 
there is a desire to be able to run cinder by itself (with no-auth) or 
just with keystone (where OpenStack style multi-tenancy is desired)?


Tom Barron (tbarron)


-- Ed Leafe






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



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


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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

[Ed Leafe]

On Aug 17, 2018, at 10:51 AM, Chris Dent  wrote:
> 
> One of the questions that has come up on the etherpad is about how
> placement should be positioned, as a project, after the extraction.
> The options are:
> 
> * A repo within the compute project
> * Its own project, either:
>  * working towards being official and governed
>  * official and governed from the start

I would like to hear from the Cinder and Neutron teams, especially those who 
were around when those compute sub-projects were split off into their own 
projects. Did you feel that being independent of compute helped or hindered 
you? And to those who are in those projects now, is there any sense that things 
would be better if you were still part of compute?

My opinion has been that Placement should have been separate from the start. 
The longer we keep Placement inside of Nova, the more painful it will be to 
extract, and hence the likelihood of that every happening is greatly diminished.


-- Ed Leafe






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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

[Sean McGinnis]

> 
> Has there been a discussion on record of how use of placement by cinder
> would affect "standalone" cinder (or manila) initiatives where there is a
> desire to be able to run cinder by itself (with no-auth) or just with
> keystone (where OpenStack style multi-tenancy is desired)?
> 
> Tom Barron (tbarron)
> 

A little bit. That would be one of the pieces that needs to be done if we were
to adopt it.

Just high level brainstorming, but I think we would need something like we have
now with using tooz where if it is configured for it, it will use etcd for
distributed locking. And for single node installs it just defaults to file
locks.


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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

[Jay S Bryant]

On 8/17/2018 1:34 PM, Sean McGinnis wrote:

Has there been a discussion on record of how use of placement by cinder
would affect "standalone" cinder (or manila) initiatives where there is a
desire to be able to run cinder by itself (with no-auth) or just with
keystone (where OpenStack style multi-tenancy is desired)?

Tom Barron (tbarron)


A little bit. That would be one of the pieces that needs to be done if we were
to adopt it.

Just high level brainstorming, but I think we would need something like we have
now with using tooz where if it is configured for it, it will use etcd for
distributed locking. And for single node installs it just defaults to file
locks.


Sean and Tom,

That brief discussion was in Vancouver: 
https://etherpad.openstack.org/p/YVR-cinder-placement


But as Sean indicated I think the long story short was that we would 
make it so that we could use the placement service if it was available 
but would leave the existing functionality in the case it wasn't there.


Jay

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

[openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

[Chris Dent]

Earlier I posted a message about a planning etherpad for the
extraction of placement

  http://lists.openstack.org/pipermail/openstack-dev/2018-August/133319.html
  https://etherpad.openstack.org/p/placement-extract-stein

One of the goals of doing the planning and having the etherpad was
to be able to get to the PTG with some of the issues resolved so
that what little time we had at the PTG could be devoted to
resolving any difficult technical details we uncovered in the lead
up.

One of the questions that has come up on the etherpad is about how
placement should be positioned, as a project, after the extraction.
The options are:

* A repo within the compute project
* Its own project, either:
  * working towards being official and governed
  * official and governed from the start

The etherpad has some discussion about this, but since that etherpad
is primarily for listing out the technical concerns I thought it
might be useful to bring the discussion out into a wider audience,
in a medium more oriented towards discussion. As placement is a
service targeted to serving the entire OpenStack community, talking
about it widely seems warranted.

The outcome I'd like to see happen is the one that makes sure
placement becomes useful to the most people and is worked on by the
most people, as quickly as possible. If how it is arranged as a
project will impact that, now is a good time to figure that out.

If you have thoughts about this, please share them in response.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Searchlight] Reaching out to the Searchlight core members for Stein

[Trinh Nguyen]

Dear Searchlight team,

As you may know, the Searchlight project has missed several milestones,
especially the Rocky cycle. The TC already has the plan to remove
Searchlight from governance [1] but I volunteer to take over it [2]. But
due to the unresponsive on IRC and launchpad, I send this email to reach
out to all the Searchlight core members to discuss our plan in Stein as
well as re-organize the team. Hopefully, this effort will work well and may
bring Searchlight back to life.

If anyone on the core team sees this email, please reply.

My IRC is dangtrinhnt.

[1] https://review.openstack.org/#/c/588644/
[2] https://review.openstack.org/#/c/590601/

Best regards,

*Trinh Nguyen *| Founder & Chief Architect



*E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz *
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

[Jay S Bryant]

On 8/17/2018 10:59 AM, Ed Leafe wrote:

On Aug 17, 2018, at 10:51 AM, Chris Dent  wrote:

One of the questions that has come up on the etherpad is about how
placement should be positioned, as a project, after the extraction.
The options are:

* A repo within the compute project
* Its own project, either:
  * working towards being official and governed
  * official and governed from the start

I would like to hear from the Cinder and Neutron teams, especially those who 
were around when those compute sub-projects were split off into their own 
projects. Did you feel that being independent of compute helped or hindered 
you? And to those who are in those projects now, is there any sense that things 
would be better if you were still part of compute?

Ed,

I started working with Cinder right after the split had taken place.  I 
have had several discussions as to how the split took place and why over 
the years since.


In the case of Cinder we split because the pace at which things were 
changing in the Cinder project had exceeded what could be handled by the 
Nova team.  Nova has always been a busy project and the changes coming 
in for Nova Volume were getting lost in the larger Nova picture.  So, 
Nova Volume was broken out to become Cinder so that people could focus 
on the storage aspect of things and get change through more quickly.


So, I think, for the most part that it has been something that has 
benefited the project.  The exception would be all the challenges that 
have come working cross project on changes that impact both Cinder and 
Nova but that has improved over time.  Given the good leadership I 
envision for the Placement Service I think that is less of a concern.


For the placement service, I would expect that there will be a greater 
rate of change once more projects are using it.  This would also support 
splitting the service out.

My opinion has been that Placement should have been separate from the start. 
The longer we keep Placement inside of Nova, the more painful it will be to 
extract, and hence the likelihood of that every happening is greatly diminished.


I do agree that pulling the service out sooner than later is probably best.

-- Ed Leafe






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



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

[openstack-dev] [Release][PTL] cycle-with-intermediary reminder

[Sean McGinnis]

Just reminding folks with deliverables following the cycle-with-intermediary
release model that next Thursday is the final deadline to get those out.

There are a handful of deliverables that have not done a release yet in Rocky.
If we do not get a release request from these teams we will need to force a
release so we can have a good point to create a stable/rocky branch.

There are also a few that have done a release this cycle but appear to have
merged more changes since then. For these deliverables, if not requested before
the final deadline, we will need to force the creation of the stable/rocky
branch from the last release.

Finally, we have a large list than I would like to see of tempest plugins that
have not done a release. As a reminder, we need those tagged (but not branched)
to have a record of which version of the plugin was part of which release
cycle. This is to ensure the right plugin can be used based on the version of
tempest used to make sure the plugin interface is compatible.

These plugins do require some steps to get things set up before doing the
release, so please keep that in mind when planning the time you will need. They
need to be registered on pypi and a publish-to-pypi job added in the
project-config repo before we will be able to process a release for them.

Please raise any questions here or in the #openstack-release channel.

Thanks!
Sean


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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

[Sean McGinnis]

On Fri, Aug 17, 2018 at 04:51:10PM +0100, Chris Dent wrote:
> 
> [snip]
>
> One of the questions that has come up on the etherpad is about how
> placement should be positioned, as a project, after the extraction.
> The options are:
> 
> * A repo within the compute project
> * Its own project, either:
>   * working towards being official and governed
>   * official and governed from the start
> 
> [snip]
> 
> The outcome I'd like to see happen is the one that makes sure
> placement becomes useful to the most people and is worked on by the
> most people, as quickly as possible. If how it is arranged as a
> project will impact that, now is a good time to figure that out.
> 
> If you have thoughts about this, please share them in response.
> 

I do think this is important if we want placement to get wider adoption.

The subject of using placement in Cinder has come up, and since then I've had a
few conversations with people in and outside of that team. I really think until
placement is its own project outside of the nova team, there will be resistance
from some to adopt it.

This reluctance on having it part of Nova may be real or just perceived, but
with it within Nova it will likely be an uphill battle for some time convincing
other projects that it is a nicely separated common service that they can use.

Sean

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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

[Dan Smith]

> The subject of using placement in Cinder has come up, and since then I've had 
> a
> few conversations with people in and outside of that team. I really think 
> until
> placement is its own project outside of the nova team, there will be 
> resistance
> from some to adopt it.

I know politics will be involved in this, but this is a really terrible
reason to do a thing, IMHO. After the most recent meeting we had with
the Cinder people on placement adoption, I'm about as convinced as ever
that Cinder won't (and won't need to) _consume_ placement any time
soon. I hope it will _report_ to placement so Nova can make better
decisions, just like Neutron does now, but I think that's the extent
we're likely to see if we're honest.

What other projects are _likely_ to _consume_ placement even if they
don't know they'd want to? What projects already want to use it but
refuse to because it has Nova smeared all over it? We talked about this
a lot in the early justification for placement, but the demand for that
hasn't really materialized, IMHO; maybe it's just me.

> This reluctance on having it part of Nova may be real or just perceived, but
> with it within Nova it will likely be an uphill battle for some time 
> convincing
> other projects that it is a nicely separated common service that they can use.

Splitting it out to another repository within the compute umbrella (what
do we call it these days?) satisfies the _technical_ concern of not
being able to use placement without installing the rest of the nova code
and dependency tree. Artificially creating more "perceived" distance
sounds really political to me, so let's be sure we're upfront about the
reasoning for doing that if so :)

--Dan

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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

[Ed Leafe]

On Aug 17, 2018, at 12:30 PM, Dan Smith  wrote:
> 
> Splitting it out to another repository within the compute umbrella (what
> do we call it these days?) satisfies the _technical_ concern of not
> being able to use placement without installing the rest of the nova code
> and dependency tree. Artificially creating more "perceived" distance
> sounds really political to me, so let's be sure we're upfront about the
> reasoning for doing that if so :)

Characterizing the proposed separation as “artificial” seems to be quite 
political in itself.

Of course there are political factors; it would be naive to think otherwise. 
That’s why I’d like to get input from those people who are not in the middle of 
it, and have no political motivation. I’d like this to be a technical 
discussion, with as little political overtones as possible.

-- Ed Leafe






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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

[Sean McGinnis]

On Fri, Aug 17, 2018 at 12:47:10PM -0500, Ed Leafe wrote:
> On Aug 17, 2018, at 12:30 PM, Dan Smith  wrote:
> > 
> > Splitting it out to another repository within the compute umbrella (what
> > do we call it these days?) satisfies the _technical_ concern of not
> > being able to use placement without installing the rest of the nova code
> > and dependency tree. Artificially creating more "perceived" distance
> > sounds really political to me, so let's be sure we're upfront about the
> > reasoning for doing that if so :)
> 
> Characterizing the proposed separation as “artificial” seems to be quite 
> political in itself.
> 

Other than currently having a common set of interested people, is there
something about placement that makes it something that should be under the
compute umbrella?

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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

[melanie witt]

On Fri, 17 Aug 2018 16:51:10 +0100 (BST), Chris Dent wrote:


Earlier I posted a message about a planning etherpad for the
extraction of placement

http://lists.openstack.org/pipermail/openstack-dev/2018-August/133319.html
https://etherpad.openstack.org/p/placement-extract-stein

One of the goals of doing the planning and having the etherpad was
to be able to get to the PTG with some of the issues resolved so
that what little time we had at the PTG could be devoted to
resolving any difficult technical details we uncovered in the lead
up.

One of the questions that has come up on the etherpad is about how
placement should be positioned, as a project, after the extraction.
The options are:

* A repo within the compute project
* Its own project, either:
* working towards being official and governed
* official and governed from the start

The etherpad has some discussion about this, but since that etherpad
is primarily for listing out the technical concerns I thought it
might be useful to bring the discussion out into a wider audience,
in a medium more oriented towards discussion. As placement is a
service targeted to serving the entire OpenStack community, talking
about it widely seems warranted.

The outcome I'd like to see happen is the one that makes sure
placement becomes useful to the most people and is worked on by the
most people, as quickly as possible. If how it is arranged as a
project will impact that, now is a good time to figure that out.

If you have thoughts about this, please share them in response.


Thanks for kicking off this discussion, Chris.

I'd like to see placement extracted as a repo within the compute 
project, as a start. My thinking is, placement was developed to solve 
several long-standing problems and limitations in Nova (including poor 
filter scheduler performance, parallel scheduling races, resource 
tracker issues, and shared storage accounting, just to name a few).


We've seen exciting progress in finally solving a lot of these issues as 
we've been developing placement. But, there is still a significant 
amount of important work to do in Nova that depends on placement. For 
example, we need to integrate nested resource providers into the virt 
drivers in Nova to leverage it for vGPUs and NUMA modeling. We need 
affinity modeling in placement to properly handle affinity with multiple 
cells. We need shared storage accounting to properly handle disk usage 
for deployments on shared storage.


As we've worked to develop placement and use it in Nova, we've found in 
most cases that we've had to develop the Nova side and the placement 
side together, at the same time, to make things work. This isn't really 
surprising, as with any brand new functionality, it's difficult to 
fulfill a use case completely without integrating things together and 
iterating until everything works. Given that, I'd rather see placement 
stay under compute so we can iterate quickly, as we still need to 
develop new features in placement and exercise them for the first time, 
in Nova. Once the major aforementioned efforts have been figured out and 
landed with close coordination, I think it would make more sense to look 
at placement being outside of the compute project.


Cheers,
-melanie





__
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] Stepping down as coordinator for the Outreachy internships

[Samuel de Medeiros Queiroz]

Hi all,

As someone who cares for this cause and participated twice in this program
as a mentor, I'd like to candidate as program coordinator.

Victoria, thanks for all your lovely work. You are awesome!

Best regards,
Samuel


On Thu, Aug 9, 2018 at 6:51 PM Kendall Nelson  wrote:

> You have done such amazing things with the program! We appreciate
> everything you do :) Enjoy the little extra spare time.
>
> -Kendall (daiblo_rojo)
>
>
> On Tue, Aug 7, 2018 at 4:48 PM Victoria Martínez de la Cruz <
> victo...@vmartinezdelacruz.com> wrote:
>
>> Hi all,
>>
>> I'm reaching you out to let you know that I'll be stepping down as
>> coordinator for OpenStack next round. I had been contributing to this
>> effort for several rounds now and I believe is a good moment for somebody
>> else to take the lead. You all know how important is Outreachy to me and
>> I'm grateful for all the amazing things I've done as part of the Outreachy
>> program and all the great people I've met in the way. I plan to keep
>> involved with the internships but leave the coordination tasks to somebody
>> else.
>>
>> If you are interested in becoming an Outreachy coordinator, let me know
>> and I can share my experience and provide some guidance.
>>
>> Thanks,
>>
>> Victoria
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

[Doug Hellmann]

Excerpts from Dan Smith's message of 2018-08-17 10:30:41 -0700:
> > The subject of using placement in Cinder has come up, and since then I've 
> > had a
> > few conversations with people in and outside of that team. I really think 
> > until
> > placement is its own project outside of the nova team, there will be 
> > resistance
> > from some to adopt it.
> 
> I know politics will be involved in this, but this is a really terrible
> reason to do a thing, IMHO. After the most recent meeting we had with
> the Cinder people on placement adoption, I'm about as convinced as ever
> that Cinder won't (and won't need to) _consume_ placement any time
> soon. I hope it will _report_ to placement so Nova can make better
> decisions, just like Neutron does now, but I think that's the extent
> we're likely to see if we're honest.
> 
> What other projects are _likely_ to _consume_ placement even if they
> don't know they'd want to? What projects already want to use it but
> refuse to because it has Nova smeared all over it? We talked about this
> a lot in the early justification for placement, but the demand for that
> hasn't really materialized, IMHO; maybe it's just me.
> 
> > This reluctance on having it part of Nova may be real or just perceived, but
> > with it within Nova it will likely be an uphill battle for some time 
> > convincing
> > other projects that it is a nicely separated common service that they can 
> > use.
> 
> Splitting it out to another repository within the compute umbrella (what
> do we call it these days?) satisfies the _technical_ concern of not
> being able to use placement without installing the rest of the nova code
> and dependency tree. Artificially creating more "perceived" distance
> sounds really political to me, so let's be sure we're upfront about the
> reasoning for doing that if so :)
> 
> --Dan
> 

If we ignore the political concerns in the short term, are there
other projects actually interested in using placement? With what
technical caveats? Perhaps with modifications of some sort to support
the needs of those projects?

Doug

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

[openstack-dev] [tripleo] fedora28 python3 test environment

[Alex Schultz]

Ahoy folks,

In order to get to a spot where can start evaluate the current status
of TripleO under python3 I've thrown together a set of ansible
playbooks[0] to launch a fedora28 node and build the required
python-tripleoclient (and dependencies)  These playbooks will spawn a
VM on an OpenStack cloud, runs through the the steps from the RDO
etherpad[1] for using the fedora stablized repo and builds all the
currently outstanding python3 package builds[2] for
python-tripleoclient & company.  Once the playblook has completed it
should be at a spot to 'dnf install python3-tripleoclient'.

I believe from here we can focus on getting the undercloud[3] and
standalone[4] processes working correctly under python3.  I think
initially we should use the existing CentOS7 containers we build under
the existing processes to see if we can't get the services deployed as
we work on building out all the required python3 packaging.

Thanks,
-Alex

[0] https://github.com/mwhahaha/tripleo-f28-testbed
[1] https://review.rdoproject.org/etherpad/p/use-fedora-stabilized
[2] 
https://review.rdoproject.org/r/#/q/status:open+owner:%22Alex+Schultz+%253Caschultz%2540next-development.com%253E%22+topic:python3
[3] 
https://docs.openstack.org/tripleo-docs/latest/install/installation/installation.html
[4] 
https://docs.openstack.org/tripleo-docs/latest/install/containers_deployment/standalone.html

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

Re: [openstack-dev] Stepping down as coordinator for the Outreachy internships

[Rodrigo Duarte]

Thanks for everything, Victoria.

On Fri, Aug 17, 2018 at 1:07 PM Victoria Martínez de la Cruz <
victo...@vmartinezdelacruz.com> wrote:

> Thanks everyone for your words!
>
> I really love the OpenStack community and I'm glad I could contribute back
> with this.
>
> Samuel has been a great mentor for Outreachy in several rounds and I
> believe he will excel as coordinator along with Mahati. Thanks for
> volunteer for this Samuel!
>
> All the best,
>
> Victoria
>
> 2018-08-17 14:56 GMT-03:00 Samuel de Medeiros Queiroz  >:
>
>> Hi all,
>>
>> As someone who cares for this cause and participated twice in this
>> program as a mentor, I'd like to candidate as program coordinator.
>>
>> Victoria, thanks for all your lovely work. You are awesome!
>>
>> Best regards,
>> Samuel
>>
>>
>> On Thu, Aug 9, 2018 at 6:51 PM Kendall Nelson 
>> wrote:
>>
>>> You have done such amazing things with the program! We appreciate
>>> everything you do :) Enjoy the little extra spare time.
>>>
>>> -Kendall (daiblo_rojo)
>>>
>>>
>>> On Tue, Aug 7, 2018 at 4:48 PM Victoria Martínez de la Cruz <
>>> victo...@vmartinezdelacruz.com> wrote:
>>>
 Hi all,

 I'm reaching you out to let you know that I'll be stepping down as
 coordinator for OpenStack next round. I had been contributing to this
 effort for several rounds now and I believe is a good moment for somebody
 else to take the lead. You all know how important is Outreachy to me and
 I'm grateful for all the amazing things I've done as part of the Outreachy
 program and all the great people I've met in the way. I plan to keep
 involved with the internships but leave the coordination tasks to somebody
 else.

 If you are interested in becoming an Outreachy coordinator, let me know
 and I can share my experience and provide some guidance.

 Thanks,

 Victoria

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

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


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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

[Tom Barron]

On 17/08/18 14:09 -0500, Jay S Bryant wrote:



On 8/17/2018 1:34 PM, Sean McGinnis wrote:

Has there been a discussion on record of how use of placement by cinder
would affect "standalone" cinder (or manila) initiatives where there is a
desire to be able to run cinder by itself (with no-auth) or just with
keystone (where OpenStack style multi-tenancy is desired)?

Tom Barron (tbarron)


A little bit. That would be one of the pieces that needs to be done if we were
to adopt it.

Just high level brainstorming, but I think we would need something like we have
now with using tooz where if it is configured for it, it will use etcd for
distributed locking. And for single node installs it just defaults to file
locks.


Sean and Tom,

That brief discussion was in Vancouver: 
https://etherpad.openstack.org/p/YVR-cinder-placement


Thanks, Jay.



But as Sean indicated I think the long story short was that we would 
make it so that we could use the placement service if it was available 
but would leave the existing functionality in the case it wasn't 
there.


I think that even standalone if I'm running a scheduler (i.e., not 
doing emberlib version of standalone) then I'm likely to want to run 
them active-active on multiple nodes and will need a solution for the 
current races.  So even standalone we face the question of do we use 
placement to solve that issue or do we introduce some coordination 
among the schedulers themselves to solve it.


-- Tom Barron (tbarron)



Jay

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


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

[openstack-dev] networking-vpp 18.07 for VPP 18.07 is now available

[Naveen Joy (najoy)]

Hello Everyone,

In conjunction with the release of VPP 18.07, we'd like to invite you all to 
try out networking-vpp 18.07 for VPP 18.07.
As many of you may already know, VPP is a fast userspace forwarder based on the 
DPDK toolkit, and uses vector packet processing algorithms to minimize the CPU 
time spent on each packet to maximize throughput.

Networking-vpp is a ML2 mechanism driver that controls VPP on your control and 
compute hosts to provide fast L2 forwarding under Neutron.

This version has the below additional enhancements, along with supporting the 
latest VPP 18.07 APIs:
- Network Trunking
- Tap-as-a-Service (Taas)

Both the above features are experimental in this release.
Along with this, there have been the usual upkeep as Neutron versions and VPP 
APIs change, bug fixes, code and test improvements.

The README [1] explains more about the above features and how you can try out 
VPP using devstack:
the devstack plugin will deploy the mechanism driver and VPP itself and should 
give you a working system with a minimum of hassle.

We will be continuing our development between now and VPP's 18.10 release. 
There are several features we're planning to work on and we will keep you 
updated through our bugs list [2].
We welcome anyone who would like to come help us.

Everyone is welcome to join our biweekly IRC meetings, every other Monday (the 
next one is due this Monday at 0900 PST = 1600 GMT.
--
Ian & Naveen

[1]https://github.com/openstack/networking-vpp/blob/master/README.rst
[2]http://goo.gl/i3TzAt
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Freezer] Reactivate the team

[Trinh Nguyen]

Dear Freezer team,

Since we have appointed a new PTL for the Stein cycle (gengchc2), I suggest
that we should reactivate the team follows these actions:

   1. Have a team meeting to formalize the new leader as well as discuss
   the new direction.
   2. Grant PTL privileges for gengchc2 on Launchpad and Project Gerrit
   repositories.
   3. Reorganize the core team to make sure we have enough active core
   reviewers for new patches.
   4. Clean up bug reports, blueprints on Launchpad, as well as unreviewed
   patched on Gerrit.

I hope that we can revive Freezer.

Best regards,

*Trinh Nguyen *| Founder & Chief Architect



*E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz *
__
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] [goal][python3] more updates to the goal tools

[super user]

The problem was fixed.

Nguyen Hai

On Fri, Aug 17, 2018 at 11:47 PM Doug Hellmann 
wrote:

> I was not able to reproduce the problem. Please test the fix in
> https://review.openstack.org/#/c/593068/ to see if that helps.
>
> Which version of Python are you using to run the tools? And on which OS?
>
> Excerpts from Doug Hellmann's message of 2018-08-17 10:30:29 -0400:
> > I will work on fixing this today.
> >
> > Has the designate team agreed to go ahead with their migration, or
> > are you still testing the scripts?
> >
> > Doug
> >
> > Excerpts from super user's message of 2018-08-17 15:37:03 +0900:
> > > Hi Doug,
> > >
> > > I'm Nguyen Hai. I proposed the python3-first patch set for
> > > designate projects. However, I have met this error to designate and
> > > designate-dashboard:
> > >
> > > === ../Output/designate/openstack/designate @ master ===
> > >
> > > ./tools/python3-first/do_repo.sh
> ../Output/designate/openstack/designate
> > > master 24292
> > >
> > > ++ cat ../Output/designate/openstack/designate/.gitreview
> > > ++ grep project
> > > ++ cut -f2 -d=
> > > + actual=openstack/designate.git
> > > +++ dirname ../Output/designate/openstack/designate
> > > ++ basename ../Output/designate/openstack
> > > ++ basename ../Output/designate/openstack/designate
> > > + expected=openstack/designate
> > > + '[' openstack/designate.git '!=' openstack/designate -a
> > > openstack/designate.git '!=' openstack/designate.git ']'
> > > + git -C ../Output/designate/openstack/designate review -s
> > > Creating a git remote called 'gerrit' that maps to:
> > > ssh://
> > > nguyentri...@review.openstack.org:29418/openstack/designate.git
> > > ++ basename master
> > > + new_branch=python3-first-master
> > > + git -C ../Output/designate/openstack/designate branch
> > > + grep -q python3-first-master
> > > + echo 'creating python3-first-master'
> > > creating python3-first-master
> > > + git -C ../Output/designate/openstack/designate checkout -- .
> > > + git -C ../Output/designate/openstack/designate clean -f -d
> > > + git -C ../Output/designate/openstack/designate checkout -q
> origin/master
> > > + git -C ../Output/designate/openstack/designate checkout -b
> > > python3-first-master
> > > Switched to a new branch 'python3-first-master'
> > > + python3-first -v --debug jobs update
> > > ../Output/designate/openstack/designate
> > > determining repository name from .gitreview
> > > working on openstack/designate @ master
> > > looking for zuul config in
> > > ../Output/designate/openstack/designate/.zuul.yaml
> > > using zuul config from
> ../Output/designate/openstack/designate/.zuul.yaml
> > > loading project settings from ../project-config/zuul.d/projects.yaml
> > > loading project templates from
> > > ../openstack-zuul-jobs/zuul.d/project-templates.yaml
> > > loading jobs from ../openstack-zuul-jobs/zuul.d/jobs.yaml
> > > looking for settings for openstack/designate
> > > looking at template 'openstack-python-jobs'
> > > looking at template 'openstack-python35-jobs'
> > > looking at template 'publish-openstack-sphinx-docs'
> > > looking at template 'periodic-stable-jobs'
> > > looking at template 'check-requirements'
> > > did not find template definition for 'check-requirements'
> > > looking at template 'translation-jobs-master-stable'
> > > looking at template 'release-notes-jobs'
> > > looking at template 'api-ref-jobs'
> > > looking at template 'install-guide-jobs'
> > > looking at template 'release-openstack-server'
> > > filtering on master
> > > merging templates
> > >   adding openstack-python-jobs
> > >   adding openstack-python35-jobs
> > >   adding publish-openstack-sphinx-docs
> > >   adding periodic-stable-jobs
> > >   adding check-requirements
> > >   adding release-notes-jobs
> > >   adding install-guide-jobs
> > > merging pipeline check
> > > *unhashable type: 'CommentedMap'*
> > > *Traceback (most recent call last):*
> > > *  File
> > >
> "/home/stack/python3-first/goal-tools/.tox/venv/lib/python3.6/site-packages/cliff/app.py",
> > > line 402, in run_subcommand*
> > > *result = cmd.run(parsed_args)*
> > > *  File
> > >
> "/home/stack/python3-first/goal-tools/.tox/venv/lib/python3.6/site-packages/cliff/command.py",
> > > line 184, in run*
> > > *return_code = self.take_action(parsed_args) or 0*
> > > *  File
> > >
> "/home/stack/python3-first/goal-tools/goal_tools/python3_first/jobs.py",
> > > line 531, in take_action*
> > > *entry,*
> > > *  File
> > >
> "/home/stack/python3-first/goal-tools/goal_tools/python3_first/jobs.py",
> > > line 397, in merge_project_settings*
> > > *up.get(pipeline, comments.CommentedMap()),*
> > > *  File
> > >
> "/home/stack/python3-first/goal-tools/goal_tools/python3_first/jobs.py",
> > > line 362, in merge_pipeline*
> > > *if job_name in job_names:*
> > > *TypeError: unhashable type: 'CommentedMap'*
> > > *Traceback (most recent call last):*
> > > *  File
> "/home/stack/python3-first/goal-tools/.tox/venv/bin/python3-first",
> > > line 

Re: [openstack-dev] [Openstack] Stepping down as coordinator for the Outreachy internships

[Nisha Yadav]

Hey all,

Victoria you are an inspiration!

Going through your blog when I embarked on the OpenStack journey gave me a
lot of motivation. It was a pleasure working with you. Thanks for all your
support and hard work.

Good luck Samuel, great to hear.

Cheers to Outreachy and OpenStack!

Best regards,
Nisha

On Sat, Aug 18, 2018 at 1:37 AM, Victoria Martínez de la Cruz <
victo...@vmartinezdelacruz.com> wrote:

> Thanks everyone for your words!
>
> I really love the OpenStack community and I'm glad I could contribute back
> with this.
>
> Samuel has been a great mentor for Outreachy in several rounds and I
> believe he will excel as coordinator along with Mahati. Thanks for
> volunteer for this Samuel!
>
> All the best,
>
> Victoria
>
> 2018-08-17 14:56 GMT-03:00 Samuel de Medeiros Queiroz  >:
>
>> Hi all,
>>
>> As someone who cares for this cause and participated twice in this
>> program as a mentor, I'd like to candidate as program coordinator.
>>
>> Victoria, thanks for all your lovely work. You are awesome!
>>
>> Best regards,
>> Samuel
>>
>>
>> On Thu, Aug 9, 2018 at 6:51 PM Kendall Nelson 
>> wrote:
>>
>>> You have done such amazing things with the program! We appreciate
>>> everything you do :) Enjoy the little extra spare time.
>>>
>>> -Kendall (daiblo_rojo)
>>>
>>>
>>> On Tue, Aug 7, 2018 at 4:48 PM Victoria Martínez de la Cruz <
>>> victo...@vmartinezdelacruz.com> wrote:
>>>
 Hi all,

 I'm reaching you out to let you know that I'll be stepping down as
 coordinator for OpenStack next round. I had been contributing to this
 effort for several rounds now and I believe is a good moment for somebody
 else to take the lead. You all know how important is Outreachy to me and
 I'm grateful for all the amazing things I've done as part of the Outreachy
 program and all the great people I've met in the way. I plan to keep
 involved with the internships but leave the coordination tasks to somebody
 else.

 If you are interested in becoming an Outreachy coordinator, let me know
 and I can share my experience and provide some guidance.

 Thanks,

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

>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openst...@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

[Jay S Bryant]

On 8/17/2018 12:30 PM, Dan Smith wrote:

The subject of using placement in Cinder has come up, and since then I've had a
few conversations with people in and outside of that team. I really think until
placement is its own project outside of the nova team, there will be resistance
from some to adopt it.

I know politics will be involved in this, but this is a really terrible
reason to do a thing, IMHO. After the most recent meeting we had with
the Cinder people on placement adoption, I'm about as convinced as ever
that Cinder won't (and won't need to) _consume_ placement any time
soon. I hope it will _report_ to placement so Nova can make better
decisions, just like Neutron does now, but I think that's the extent
we're likely to see if we're honest.

Dan,

I don't know of any reason we wouldn't want to report to placement. Just 
a matter of getting a person to implement it.


Also, from a consumption standpoint we really only have one or two 
people are are opposed at this point.  We have time scheduled at the PTG 
to discuss this further.  The discussions in Vancouver seemed to be 
tilting toward the fact that it might solve other technical issues we 
have been having from an Active/Active HA configuration standpoint.  
Just need to get the right people in the room to talk about it.


Jay

What other projects are _likely_ to _consume_ placement even if they
don't know they'd want to? What projects already want to use it but
refuse to because it has Nova smeared all over it? We talked about this
a lot in the early justification for placement, but the demand for that
hasn't really materialized, IMHO; maybe it's just me.


This reluctance on having it part of Nova may be real or just perceived, but
with it within Nova it will likely be an uphill battle for some time convincing
other projects that it is a nicely separated common service that they can use.

Splitting it out to another repository within the compute umbrella (what
do we call it these days?) satisfies the _technical_ concern of not
being able to use placement without installing the rest of the nova code
and dependency tree. Artificially creating more "perceived" distance
sounds really political to me, so let's be sure we're upfront about the
reasoning for doing that if so :)

--Dan

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



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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

[Tom Barron]

On 17/08/18 13:34 -0500, Sean McGinnis wrote:


Has there been a discussion on record of how use of placement by cinder
would affect "standalone" cinder (or manila) initiatives where there is a
desire to be able to run cinder by itself (with no-auth) or just with
keystone (where OpenStack style multi-tenancy is desired)?

Tom Barron (tbarron)



A little bit. That would be one of the pieces that needs to be done if we were
to adopt it.

Just high level brainstorming, but I think we would need something like we have
now with using tooz where if it is configured for it, it will use etcd for
distributed locking. And for single node installs it just defaults to file
locks.


So I want to understand better what problems placement would solve and 
whether those problems need to be solved even in the cinder/manila 
standalone case.  And if they do have to be solved in both cases, why 
not use the same solution for both cases?


That *might* mean running the placement service even in the standalone 
case if it's sufficiently lightweight and can be run without the rest 
of nova.  (Whether it's "under" nova umbrella doesn't matter for this 
decoupling - nothing I'm saying here is intended to argue against e.g. 
Mel's or Dan's points in this thread.)


-- Tom Barron (tbarron)





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


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

Re: [openstack-dev] Stepping down as coordinator for the Outreachy internships

[Victoria Martínez de la Cruz]

Thanks everyone for your words!

I really love the OpenStack community and I'm glad I could contribute back
with this.

Samuel has been a great mentor for Outreachy in several rounds and I
believe he will excel as coordinator along with Mahati. Thanks for
volunteer for this Samuel!

All the best,

Victoria

2018-08-17 14:56 GMT-03:00 Samuel de Medeiros Queiroz :

> Hi all,
>
> As someone who cares for this cause and participated twice in this program
> as a mentor, I'd like to candidate as program coordinator.
>
> Victoria, thanks for all your lovely work. You are awesome!
>
> Best regards,
> Samuel
>
>
> On Thu, Aug 9, 2018 at 6:51 PM Kendall Nelson 
> wrote:
>
>> You have done such amazing things with the program! We appreciate
>> everything you do :) Enjoy the little extra spare time.
>>
>> -Kendall (daiblo_rojo)
>>
>>
>> On Tue, Aug 7, 2018 at 4:48 PM Victoria Martínez de la Cruz <
>> victo...@vmartinezdelacruz.com> wrote:
>>
>>> Hi all,
>>>
>>> I'm reaching you out to let you know that I'll be stepping down as
>>> coordinator for OpenStack next round. I had been contributing to this
>>> effort for several rounds now and I believe is a good moment for somebody
>>> else to take the lead. You all know how important is Outreachy to me and
>>> I'm grateful for all the amazing things I've done as part of the Outreachy
>>> program and all the great people I've met in the way. I plan to keep
>>> involved with the internships but leave the coordination tasks to somebody
>>> else.
>>>
>>> If you are interested in becoming an Outreachy coordinator, let me know
>>> and I can share my experience and provide some guidance.
>>>
>>> Thanks,
>>>
>>> Victoria
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>>> unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [puppet] migrating to storyboard

[Kendall Nelson]

On Fri, Aug 17, 2018 at 12:15 AM Tobias Urdin 
wrote:

> Hello Kendall,
>
> I went through the list of projects [1] and could only really see two
> things.
>
> 1) puppet-rally and puppet-openstack-guide is missing
>
> I had created the projects, but missed adding them to the group. They
should be there now :)


> 2) We have some support projects which doesn't really need bug tracking,
> where some others do.
> You can remove puppet-openstack-specs and
> puppet-openstack-cookiecutter all others would be
> nice to still have left so we can track bugs. [2]
>
> i can remove them from the group if you want, but I don't think I can
delete the projects entirely.


> Best regards
> Tobias
>
> [1] https://storyboard-dev.openstack.org/#!/project_group/60
> [2] Keeping puppet-openstack-integration (integration testing) and
> puppet-openstack_spec_helper (helper for testing).
>   These two usually has a lot of changes so would be good to be able
> to track them.
>
>
> On 08/16/2018 09:40 PM, Kendall Nelson wrote:
>
> Hey :)
>
> I created all the puppet openstack repos in the storyboard-dev envrionment
> and made a project group[1]. I am struggling a bit with finding all of your
> launchpad projects to perform the migrations through, can you share a list
> of all of them?
>
> -Kendall (diablo_rojo)
>
> [1] https://storyboard-dev.openstack.org/#!/project_group/60
>
> On Wed, Aug 15, 2018 at 12:08 AM Tobias Urdin 
> wrote:
>
>> Hello Kendall,
>>
>> Thanks for your reply, that sounds awesome!
>> We can then dig around and see how everything looks when all project bugs
>> are imported to stories.
>>
>> I see no issues with being able to move to Storyboard anytime soon if the
>> feedback for
>> moving is positive.
>>
>> Best regards
>>
>> Tobias
>>
>>
>> On 08/14/2018 09:06 PM, Kendall Nelson wrote:
>>
>> Hello!
>>
>> The error you hit can be resolved by adding launchpadlib to your tox.ini
>> if I recall correctly..
>>
>> also, if you'd like, I can run a test migration of puppet's launchpad
>> projects into our storyboard-dev db (where I've done a ton of other test
>> migrations) if you want to see how it looks/works with a larger db. Just
>> let me know and I can kick it off.
>>
>> As for a time to migrate, if you all are good with it, we usually
>> schedule for Friday's so there is even less activity. Its a small project
>> config change and then we just need an infra core to kick off the script
>> once the change merges.
>>
>> -Kendall (diablo_rojo)
>>
>> On Tue, Aug 14, 2018 at 9:33 AM Tobias Urdin 
>> wrote:
>>
>>> Hello all incredible Puppeters,
>>>
>>> I've tested setting up an Storyboard instance and test migrated
>>> puppet-ceph and it went without any issues there using the documentation
>>> [1] [2]
>>> with just one minor issue during the SB setup [3].
>>>
>>> My goal is that we will be able to swap to Storyboard during the Stein
>>> cycle but considering that we have a low activity on
>>> bugs my opinion is that we could do this swap very easily anything soon
>>> as long as everybody is in favor of it.
>>>
>>> Please let me know what you think about moving to Storyboard?
>>> If everybody is in favor of it we can request a migration to infra
>>> according to documentation [2].
>>>
>>> I will continue to test the import of all our project while people are
>>> collecting their thoughts and feedback :)
>>>
>>> Best regards
>>> Tobias
>>>
>>> [1] https://docs.openstack.org/infra/storyboard/install/development.html
>>> [2] https://docs.openstack.org/infra/storyboard/migration.html
>>> [3] It failed with an error about launchpadlib not being installed,
>>> solved with `tox -e venv pip install launchpadlib`
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




If that's all good now, I can kick off test migrations but having a
complete list of the launchpad projects you maintain and use would be super
helpful so I don't miss any. Is there somewhere this is documented? Or can
you send me a list?

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