[openstack-dev] [Nova] [Cyborg] Updates to os-acc proposal

[Nadathur, Sundar]

Hi Eric and all,
    With recent discussions [1], we have convergence on how Power and 
other architectures can use Cyborg. Before I update the spec [2], I am 
setting down some key aspects of the updates, so that we are all aligned.


The accelerator - instance attachment has two parts:

 * The connection between the accelerator and a host-visible attach
   handle, such as a PCI function or a mediated device UUID. We call
   this the Device Half of the attach.
 * The connection between the attach handle and the instance. We name
   this the Instance Half of the attach.

I propose two different extensibility mechanisms:

 * Cyborg drivers deal with device-specific aspects, including
   discovery/enumeration of devices and handling the Device Half of the
   attach (preparing devices/accelerators for attach to an instance,
   post-attach cleanup (if any) after successful attach, releasing
   device/accelerator resources on instance termination or failed
   attach, etc.)
 * os-acc plugins deal with hypervisor/system/architecture-specific
   aspects, including handling the Instance Half of the attach (e.g.
   for libvirt with PCI, preparing the XML snippet to be included in
   the domain XML).

When invoked by Nova compute to attach accelerator(s) to an instance, 
os-acc would call the Cyborg driver to prepare a VAN (Virtual 
Accelerator Nexus, which is a handle object for attaching an accelerator 
to an instance, similar to VIFs for networking). Such preparation may 
involve configuring the device in some way, including programming for 
FPGAs. This sets up a VAN object with the necessary data for the attach 
(e.g. PCI VF, Power DRC index, etc.). Then the os-acc would call a 
plugin to do the needful for that hypervisor, using that VAN. Finally 
the os-acc may call the Cyborg driver again to do any post-attach 
cleanup, if needed.


A more detailed workflow is here: 
https://docs.google.com/drawings/d/1cX06edia_Pr7P5nOB08VsSMsgznyrz4Yy2u8nb596sU/edit?usp=sharing 



Thus, the drivers and plugins are expected to be complementary. For 
example, for 2 devices of types T1 and T2, there shall be 2 separate 
Cyborg drivers. Further, we would have separate plugins for, say, 
x86+KVM systems and Power systems. We could then have four different 
deployments -- T1 on x86+KVM, T2 on x86+KVM, T1 on Power, T2 on Power -- 
by suitable combinations of the drivers and plugins.


It is possible that there may be scenarios where the separation of roles 
between the plugins and the drivers are not so clear-cut. That can be 
addressed by allowing the plugins to call into Cyborg drivers in the 
future and/or by other mechanisms.


One secondary detail to note is that Nova compute calls os-acc per 
instance for all accelerators for that instance, not once for each 
accelerator. There are two reasons for that:


 * I think this is how Nova deals with os-vif [3].
 * If some accelerators got allocated/configured, and the next
   accelerator configuration fails, a rollback needs to be done. This
   is better done in os-acc than Nova compute.

Cyborg drivers are invoked both by the Cyborg agent (for 
discovery/enumeration) and by os-acc (for instance attach). Both shall 
use Stevedore to locate and load the drivers. A single Python module may 
implement both sets of interfaces, like this:


+--+ +---+
| Nova Compute | |Cyborg |
++-+ |Agent  |
 |   +---+---+
+v---+   |
| os-acc |   |
++---+   |
 |   |
 | Cyborg driver |
+v+--v---+
|UN/PLUG ACCELERATORS |  DISCOVER|
|FROM INSTANCES   |  ACCELERATORS|
| |  |
|* can_handle()   |  * get_devices() |
|* prepareVAN()   |  |
|* postplug() |  |
|* unprepareVAN() |  |
+-+--+

If there are no objections to the above, I will update the spec [2].

[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-cyborg/%23openstack-cyborg.2018-07-30.log.html#t2018-07-30T16:25:41-2 


[2] https://review.openstack.org/#/c/577438/
[3] 
https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L1529


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

Re: [openstack-dev] [all][Election] Last days for PTL nomination

[Luke Hinds]

On Mon, 30 Jul 2018, 21:19 Jeremy Stanley,  wrote:

> On 2018-07-30 15:23:57 +0700 (+0700), Luke Hinds wrote:
> > Security is a SIG and no longer a project (changed as of rocky cycle).
>
> Technically it's still both at the moment, which is why I proposed
> https://review.openstack.org/586896 yesterday (tried to give you a
> heads up in IRC about that as well). A +1 from the current PTL of
> record on that change would probably be a good idea.
>

I am on PTO for the next two weeks,  is +1 in this email ok? I don't have
my launchpad credentials with me to SSO login to Gerrit.



-- 
> Jeremy Stanley
> __
> 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] [trove] Considering the transfter of the project leadership

[赵超]

Dariusz Krol,

That's great, thanks. Please submit your nomination asap, the deadline is
today(2018-07-31 23:45:00 UTC). For detailed guidance about nomination,
please refer to https://governance.openstack.org/election/.

I think we need some work on https://review.openstack.org/#/c/586528/2, and
we're still in the Feature Freeze, so we also need to wait for the stable
branch created(this should be done in the next week).

On Mon, Jul 30, 2018 at 10:07 PM, Dariusz Krol  wrote:

> Hello Zhao Chao,
>
>
> after some internal discussion, I will do the nomination if you decided
> not to nominate yourself. Thanks for letting know you will be still
> available in the next release cycle.
>
> Regarding commits I would recommend to consider also
> https://review.openstack.org/#/c/586528/2 .
>
>
> Best,
>
> Dariusz Krol
>
> On 07/30/2018 03:26 AM, 赵超 wrote:
>
> Since the new folks are still so new - if this works for you - I would
>> recommend continuing on as the official PTL for one more release, but
>> with the
>> understanding that you would just be around to answer questions and give
>> advice
>> to help the new team get up to speed. That should hopefully be a small
>> time
>> commitment for you while still easing that transition.
>>
>> Then hopefully by the T release it would not be an issue at all for
>> someone
>> else to step up as the new PTL. Or even if things progress well, you
>> could step
>> down as PTL at some point during the Stein cycle if someone is ready to
>> take
>> over for you.
>>
>
> Sean, thanks a lot for these helpful suggestions.  I thought about doing
> it this way before writing this post, and this is also the reason I asked
> the current active team members to nominate theselves.
>
> However, it's sad that the other active team members seems also busy on
> other thing. So I think it may be better Dariusz and his team could do more
> than us on the project in the next cycle. I believe they're experience on
> the project , and all other experiences about the whole OpenStack
> environment could be more familiar in the daily pariticipation of the
> project.
>
> On the other hand, I can also understand the lack of time to be a PTL
>> since it requires probably a lot of time to coordinate all the work.
>
>
> Dariusz, no, the current team is really a small team, so in fact I didn't
> need to do much coordination. The pain is that almost none of the current
> active team member are not focusing Trove, so even thought all of us want
> to do more progress in this cycle, we're not able to. This also the reason
> all of us think it's great to have to team focusing on the project could
> join.
>
> So, we don't have much time on the PTL election now, Dariusz, would you
> please discuss with your team who will do the nomination. And then we'll
> see if everything could work. We could also try to merge one the
> trove-tempest-plugin patches(https://review.openstack.org/#/c/580763/
> could be merged first before we get the CI could test all the cases in the
> repo, sadlly currently we cannot the other patches as they're cannot be
> tested).
>
> However that patch is submitted by Krzysztof, though is authored by
> Dariusz. I don't know whether this could count as an identifiied commit
> when applying PTL nomination.
>
> And last, I want to repeat that, I'll still in the Trove delepoment for
> quit a long time, so I will help the new PTL and new contributor on
> everything I could.
>
> Thanks again for everyone who help me a lot in the last cycle, especially
> Fan Zhang, zhanggang, wangyao, song.jian and Manoj Kumar.
>
> --
> To be free as in freedom.
>
>
>
>
>
>



-- 
To be free as in freedom.
__
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] [adjutant] [PTL] [Election] PTL candidacy for the Stein cycle

[Adrian Turjak]

Hello OpenStackers,

I'm submitting myself as the PTL for the first cycle that Adjutant will
be a part of OpenStack.

As the main developer and project lead until now, I'm the best suited to
continue leading the project at this time and finish the current work
that is needed to bring it to a place where the wider community can
embrace what Adjutant offers and better tweak it to their own needs.

My focus for Stein will be continuing the refactor work that was started
during Queens, and finishing the sub-project management APIs as well as
project termination APIs.

As such the planned work is:
- bringing the codebase to a much nicer state while decoupling certain
elements of our internals, and adding support for async task processing.
- rework the config system or potentially adopt oslo.config if appropriate
- introduce partial policy support rather than relying on hardcoded
decorators.
- rework notifications to be pluggable and how/when they are sent
- finish the long planned support for sub-project management, and the
project (and resource) termination logic

I hope for it to be a productive cycle, with some of that work broken
into smaller pieces that new contributors could potentially help with. :)

Cheers,
Adrian Turjak


__
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] [nova][ptl][election] PTL candidacy for the Stein cycle

[melanie witt]

Hello Stackers,

I'd like to announce my candidacy for PTL of Nova for the Stein cycle. I 
feel like Rocky has been a whirlwind of a cycle with a lot of active 
participation by developers, operators, and users. Thank you all for 
bearing with me for the past cycle as I have learned the ropes of being 
a PTL.


We accomplished a lot in Rocky, with some highlights including:

* Experimented with a new review process, "review runways"
* Began using the new Neutron port binding API to minimize network 
downtime during live migrations
* Completed the placement side of nested resource providers (Nova 
integration work still remains)
* Volume-backed instances will no longer claim root_gb for new instances 
and existing instances will heal during move operations

* Made progress on removing nova-network-specific REST APIs
* Added a  nova-manage command to purge archived shadow table data
* Doing more pre-filtering in placement before we iterate over compute 
host candidates with FilterScheduler filters

* Added the ability to boot instances with trusted virtual functions
* Added the ability to disable a cell in cells v2
* Added a way to mitigate Meltdown/Spectre performance degradation via 
cpu flags


Looking toward Stein, we have more work to do with integrating placement 
nested resource providers into Nova, implementing migration of flat 
resource providers => nested tree-based resource providers in placement, 
adding more resiliency in cells v2 for handling "down" or poorer 
performing cells, removing nova-network, and more to be discussed and 
prioritized at the PTG [1].


It would be my privilege to serve the Nova community for another cycle 
and if elected, I endeavor to do a better job using what I have learned 
during the Rocky cycle. I am always trying to improve, so please feel 
free to share your feedback with me.


Thank you for your consideration.

Best,
-melanie

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

__
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][Election] [Octavia] Stein Octavia PTL candidacy

[Michael Johnson]

My fellow OpenStack community,

I would like to nominate myself for Octavia PTL for Stein. I am currently
the PTL for the Rocky release series and would like to continue helping our
team provide network load balancing services for OpenStack.

In the Rocky release, we were able to add support for provider drivers,
improve the user experience when using Barbican, listener timeouts, dashboard
auto refresh, and creating members designated as "backup" members.

Looking forward to Stein I expect the team to finish out some major new
features, such as Active/Active load balancers and flavors.

Thank you for your support of Octavia during Rocky and your consideration for
Stein,

Michael Johnson (johnsom)

__
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] [release] Github release tarballs broken

[Ben Nemec]

On 07/30/2018 02:04 PM, Sean McGinnis wrote:

On Mon, Jul 30, 2018 at 12:02:50PM -0500, Ben Nemec wrote:

According to https://bugs.launchpad.net/pbr/+bug/1742809 our github release
tarballs don't actually work.  It seems to be a github-specific issue
because I was unable to reproduce the problem with a tarball from
releases.openstack.org.

My best guess is that github's release process differs from ours and doesn't
work with our projects.  I see a couple of options for fixing that.  Either
we figure out how to make Github's release process DTRT for our projects, or
we figure out a way to override Github's release artifacts with our own.
I'm not familiar enough with this to know which is a better (or even
possible) option, so I'm sending this to solicit help.

Thanks.

-Ben



 From what I understand, GitHub will provide zip and tar.gz links for all source
whenever a tag is applied. It is a very basic operation and does not have any
kind of logic for correctly packaging whatever that deliverable is.

They even just label the links as "Source code".

I am not sure if there is any way to disable this behavior. One option I see is
we could link in the tag notes to the official tarballs.openstack.org location.
We could also potentially look at using the GitHub API to upload a copy of
those to the GitHub release page. But there's always a mirroring delay, and
GitHub really is just a mirror of our git repos, so using this as a
distribution point really isn't what we want.


Yeah, I talked a bit more about this with Monty on IRC, and it turns out 
there is already an RFE for Github to hide releases that were 
auto-generated from tags: 
https://github.community/t5/How-to-use-Git-and-GitHub/Tag-without-release/m-p/7906


Apparently from the github side "releases" already aren't created unless 
the project does so explicitly, but they show all tags on the release 
tab anyway so the user-visible difference is pretty much nil.  We 
decided to table this until we find out if Github is going to fix it for 
us.  It doesn't make sense to do a bunch of work and then turn around 
and not need it because Github rationalized their UI while we were 
trying to work around it.


__
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] [release] Github release tarballs broken

[Sean McGinnis]

On Mon, Jul 30, 2018 at 12:02:50PM -0500, Ben Nemec wrote:
> According to https://bugs.launchpad.net/pbr/+bug/1742809 our github release
> tarballs don't actually work.  It seems to be a github-specific issue
> because I was unable to reproduce the problem with a tarball from
> releases.openstack.org.
> 
> My best guess is that github's release process differs from ours and doesn't
> work with our projects.  I see a couple of options for fixing that.  Either
> we figure out how to make Github's release process DTRT for our projects, or
> we figure out a way to override Github's release artifacts with our own.
> I'm not familiar enough with this to know which is a better (or even
> possible) option, so I'm sending this to solicit help.
> 
> Thanks.
> 
> -Ben
> 

From what I understand, GitHub will provide zip and tar.gz links for all source
whenever a tag is applied. It is a very basic operation and does not have any
kind of logic for correctly packaging whatever that deliverable is.

They even just label the links as "Source code".

I am not sure if there is any way to disable this behavior. One option I see is
we could link in the tag notes to the official tarballs.openstack.org location.
We could also potentially look at using the GitHub API to upload a copy of
those to the GitHub release page. But there's always a mirroring delay, and
GitHub really is just a mirror of our git repos, so using this as a
distribution point really isn't what we want.


__
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] [openstack-helm] PTL non-candidacy for Stein

[MCEUEN, MATT]

Team,

I have decided to bow out as PTL for OpenStack-Helm in the Stein cycle.  My 
work focus is shifting to Airship engineering, so I think it makes sense to 
transition the PTL role to someone who can give OpenStack-Helm their full 
attention.

That said, I plan to remain fully active as an OpenStack-Helm core reviewer and 
developer, and I'll look for opportunities to align Airship to OpenStack-Helm 
and leverage OSH as a consumer.

It's been a privilege to serve such a great team as PTL -- I'm proud of our 
team and the work that we've accomplished during OpenStack-Helm's short time as 
an official project!

Thank you,
Matt McEuen
__
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] [placement] compute nodes use of placement

[Jay Pipes]

ack. will review shortly. thanks, Chris.

On 07/30/2018 02:20 PM, Chris Dent wrote:

On Mon, 30 Jul 2018, Jay Pipes wrote:


On 07/26/2018 12:15 PM, Chris Dent wrote:

The `in_tree` calls happen from the report client method
`_get_providers_in_tree` which is called by
`_ensure_resource_provider` which can be called from multiple
places, but in this case is being called both times from
`get_provider_tree_and_ensure_root`, which is also responsible for
two of the inventory request.

`get_provider_tree_and_ensure_root` is called by `_update` in the
resource tracker.

`_update` is called by both `_init_compute_node` and
`_update_available_resource`. Every single period job iteration.
`_init_compute_node` is called from _update_available_resource`
itself.

That accounts for the overall doubling.


Actually, no. What accounts for the overall doubling is the fact that 
we no longer short-circuit return from _update() when there are no 
known changes in the node's resources.


I think we're basically agreeing on this: I'm describing the current
state of affairs, not attempting to describe why it is that way.
Your insight helps to explain why.

I have a set of change in progress which experiments with what
happens if we don't call placement a second time in the _update
call:

   https://review.openstack.org/#/c/587050/

Just to see what might blow up.



__
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] [nova] [placement] compute nodes use of placement

[Chris Dent]

On Mon, 30 Jul 2018, Jay Pipes wrote:


On 07/26/2018 12:15 PM, Chris Dent wrote:

The `in_tree` calls happen from the report client method
`_get_providers_in_tree` which is called by
`_ensure_resource_provider` which can be called from multiple
places, but in this case is being called both times from
`get_provider_tree_and_ensure_root`, which is also responsible for
two of the inventory request.

`get_provider_tree_and_ensure_root` is called by `_update` in the
resource tracker.

`_update` is called by both `_init_compute_node` and
`_update_available_resource`. Every single period job iteration.
`_init_compute_node` is called from _update_available_resource`
itself.

That accounts for the overall doubling.


Actually, no. What accounts for the overall doubling is the fact that we no 
longer short-circuit return from _update() when there are no known changes in 
the node's resources.


I think we're basically agreeing on this: I'm describing the current
state of affairs, not attempting to describe why it is that way.
Your insight helps to explain why.

I have a set of change in progress which experiments with what
happens if we don't call placement a second time in the _update
call:

  https://review.openstack.org/#/c/587050/

Just to see what might blow up.

--
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

Re: [openstack-dev] [tripleo] The Weekly Owl - 25th Edition

[Jill Rouleau]

On Mon, 2018-07-30 at 11:35 -0400, Pradeep Kilambi wrote:
> 
> 
> On Mon, Jul 30, 2018 at 10:42 AM Alex Schultz 
> wrote:
> > On Mon, Jul 30, 2018 at 8:32 AM, Martin Magr 
> > wrote:
> > >
> > >
> > > On Tue, Jul 17, 2018 at 6:12 PM, Emilien Macchi  > m> wrote:
> > >>
> > >> Your fellow reporter took a break from writing, but is now back
> > on his
> > >> pen.
> > >>
> > >> Welcome to the twenty-fifth edition of a weekly update in TripleO
> > world!
> > >> The goal is to provide a short reading (less than 5 minutes) to
> > learn
> > >> what's new this week.
> > >> Any contributions and feedback are welcome.
> > >> Link to the previous version:
> > >> http://lists.openstack.org/pipermail/openstack-dev/2018-June/1314
> > 26.html
> > >>
> > >> +-+
> > >> | General announcements |
> > >> +-+
> > >>
> > >> +--> Rocky Milestone 3 is next week. After, any feature code will
> > require
> > >> Feature Freeze Exception (FFE), asked on the mailing-list. We'll
> > enter a
> > >> bug-fix only and stabilization period, until we can push the
> > first stable
> > >> version of Rocky.
> > >
> > >
> > > Hey guys,
> > >
> > >   I would like to ask for FFE for backup and restore, where we
> > ended up
> > > deciding where is the best place for the code base for this
> > project (please
> > > see [1] for details). We believe that B support for overcloud
> > control
> > > plane will be good addition to a rocky release, but we started
> > with this
> > > initiative quite late indeed. The final result should the support
> > in
> > > openstack client, where "openstack overcloud (backup|restore)"
> > would work as
> > > a charm. Thanks in advance for considering this feature.
> > >
> > 
> > Was there a blueprint/spec for this effort?  Additionally do we have
> > a
> > list of the outstanding work required for this? If it's just these
> > two
> > playbooks, it might be ok for an FFE. But if there's additional
> > tripleoclient related changes, I wouldn't necessarily feel
> > comfortable
> > with these unless we have a complete list of work.  Just as a side
> > note, I'm not sure putting these in tripleo-common is going to be
> > the
> > ideal place for this.

Was it this review? https://review.openstack.org/#/c/582453/

For Stein we'll have an ansible role[0] and playbook repo[1] where these
types of tasks should live.

[0] https://github.com/openstack/ansible-role-openstack-operations 
[1] https://review.openstack.org/#/c/583415/

> 
> Thanks Alex. For Rocky, if we can ship the playbooks with relevant
> docs we should be good. We will integrated with client in Stein
> release with restore logic included. Regarding putting tripleo-common, 
> we're open to suggestions. I think Dan just submitted the review so we
> can get some eyes on the playbooks. Where do you suggest is better
> place for these instead?
>  
> > 
> > Thanks,
> > -Alex
> > 
> > > Regards,
> > > Martin
> > >
> > > [1] https://review.openstack.org/#/c/582453/
> > >
> > >>
> > >> +--> Next PTG will be in Denver, please propose topics:
> > >> https://etherpad.openstack.org/p/tripleoci-ptg-stein
> > >> +--> Multiple squads are currently brainstorming a framework to
> > provide
> > >> validations pre/post upgrades - stay in touch!
> > >>
> > >> +--+
> > >> | Continuous Integration |
> > >> +--+
> > >>
> > >> +--> Sprint theme: migration to Zuul v3 (More on
> > >> https://trello.com/c/vyWXcKOB/841-sprint-16-goals)
> > >> +--> Sagi is the rover and Chandan is the ruck. Please tell them
> > any CI
> > >> issue.
> > >> +--> Promotion on master is 4 days, 0 days on Queens and Pike and
> > 1 day on
> > >> Ocata.
> > >> +--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meet
> > ing
> > >>
> > >> +-+
> > >> | Upgrades |
> > >> +-+
> > >>
> > >> +--> Good progress on major upgrades workflow, need reviews!
> > >> +--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad
> > -status
> > >>
> > >> +---+
> > >> | Containers |
> > >> +---+
> > >>
> > >> +--> We switched python-tripleoclient to deploy containerized
> > undercloud
> > >> by default!
> > >> +--> Image prepare via workflow is still work in progress.
> > >> +--> More:
> > >> https://etherpad.openstack.org/p/tripleo-containers-squad-status
> > >>
> > >> +--+
> > >> | config-download |
> > >> +--+
> > >>
> > >> +--> UI integration is almost done (need review)
> > >> +--> Bug with failure listing is being fixed:
> > >> https://bugs.launchpad.net/tripleo/+bug/1779093
> > >> +--> More:
> > >> https://etherpad.openstack.org/p/tripleo-config-download-squad-st
> > atus
> > >>
> > >> +--+
> > >> | Integration |
> > >> +--+
> > >>
> > >> +--> We're enabling decoupled deployment plans e.g for OpenShift,
> > DPDK
> > >> etc:
> > >> 

Re: [openstack-dev] [nova] [placement] compute nodes use of placement

[Jay Pipes]

On 07/26/2018 12:15 PM, Chris Dent wrote:

The `in_tree` calls happen from the report client method
`_get_providers_in_tree` which is called by
`_ensure_resource_provider` which can be called from multiple
places, but in this case is being called both times from
`get_provider_tree_and_ensure_root`, which is also responsible for
two of the inventory request.

`get_provider_tree_and_ensure_root` is called by `_update` in the
resource tracker.

`_update` is called by both `_init_compute_node` and
`_update_available_resource`. Every single period job iteration.
`_init_compute_node` is called from _update_available_resource`
itself.

That accounts for the overall doubling.


Actually, no. What accounts for the overall doubling is the fact that we 
no longer short-circuit return from _update() when there are no known 
changes in the node's resources.


We *used* to do a quick check of whether the resource tracker's local 
cache of resources had been changed, and just exit _update() if no 
changes were detected. However, this patch modified that so that we 
*always* call to get inventory, even if the resource tracker noticed no 
changes in resources:


https://github.com/openstack/nova/commit/e2a18a37190e4c7b7697a8811553d331e208182c

The reason for that change is because the virt driver was tracking vGPU 
resources now and those vGPU resources were not tracked by the resource 
tracker's local cache of resources.


Thus, we now always call the virt driver get_inventory() call (which 
morphed into the virt driver's update_provider_tree() call, but the 
change to update_provider_tree() didn't actually increase the number of 
calls to get inventories. It was the patch above that did that.


Best,
-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

Re: [openstack-dev] [i18n] Edge and Containers whitepapers ready for translation

[Sebastian Marcet]

Hi Frank,
i was double checking pot file and realized that original pot missed some
parts of the original paper (subsections of the paper) apologizes on that
i just re uploaded an updated pot file with missing subsections

regards

On Mon, Jul 30, 2018 at 2:20 PM, Frank Kloeker  wrote:

> Hi Jimmy,
>
> from the GUI I'll get this link:
> https://translate.openstack.org/rest/file/translation/edge-
> computing/pot-translation/de/po?docId=cloud-edge-computing-
> beyond-the-data-center
>
> paper version  are only in container whitepaper:
>
> https://translate.openstack.org/rest/file/translation/levera
> ging-containers-openstack/paper/de/po?docId=leveraging-
> containers-and-openstack
>
> In general there is no group named papers
>
> kind regards
>
> Frank
>
>
> Am 2018-07-30 17:06, schrieb Jimmy McArthur:
>
>> Frank,
>>
>> We're getting a 404 when looking for the pot file on the Zanata API:
>> https://translate.openstack.org/rest/file/translation/papers
>> /papers/de/po?docId=edge-computing
>>
>> As a result, we can't pull the po files.  Any idea what might be
>> happening?
>>
>> Seeing the same thing with both papers...
>>
>> Thank you,
>> Jimmy
>>
>> Frank Kloeker wrote:
>>
>>> Hi Jimmy,
>>>
>>> Korean and German version are now done on the new format. Can you check
>>> publishing?
>>>
>>> thx
>>>
>>> Frank
>>>
>>> Am 2018-07-19 16:47, schrieb Jimmy McArthur:
>>>
 Hi all -

 Follow up on the Edge paper specifically:
 https://translate.openstack.org/iteration/view/edge-computin
 g/pot-translation/documents?dswid=-3192 This is now available. As I
 mentioned on IRC this morning, it should
 be VERY close to the PDF.  Probably just needs a quick review.

 Let me know if I can assist with anything.

 Thank you to i18n team for all of your help!!!

 Cheers,
 Jimmy

 Jimmy McArthur wrote:

> Ian raises some great points :) I'll try to address below...
>
> Ian Y. Choi wrote:
>
>> Hello,
>>
>> When I saw overall translation source strings on container
>> whitepaper, I would infer that new edge computing whitepaper
>> source strings would include HTML markup tags.
>>
> One of the things I discussed with Ian and Frank in Vancouver is the
> expense of recreating PDFs with new translations.  It's prohibitively
> expensive for the Foundation as it requires design resources which we just
> don't have.  As a result, we created the Containers whitepaper in HTML, so
> that it could be easily updated w/o working with outside design
> contractors.  I indicated that we would also be moving the Edge paper to
> HTML so that we could prevent that additional design resource cost.
>
>> On the other hand, the source strings of edge computing whitepaper
>> which I18n team previously translated do not include HTML markup
>> tags, since the source strings are based on just text format.
>>
> The version that Akihiro put together was based on the Edge PDF, which
> we unfortunately didn't have the resources to implement in the same 
> format.
>
>>
>> I really appreciate Akihiro's work on RST-based support on publishing
>> translated edge computing whitepapers, since
>> translators do not have to re-translate all the strings.
>>
> I would like to second this. It took a lot of initiative to work on
> the RST-based translation.  At the moment, it's just not usable for the
> reasons mentioned above.
>
>> On the other hand, it seems that I18n team needs to investigate on
>> translating similar strings of HTML-based edge computing whitepaper
>> source strings, which would discourage translators.
>>
> Can you expand on this? I'm not entirely clear on why the HTML based
> translation is more difficult.
>
>>
>> That's my point of view on translating edge computing whitepaper.
>>
>> For translating container whitepaper, I want to further ask the
>> followings since *I18n-based tools*
>> would mean for translators that translators can test and publish
>> translated whitepapers locally:
>>
>> - How to build translated container whitepaper using original
>> Silverstripe-based repository?
>>   https://docs.openstack.org/i18n/latest/tools.html describes well
>> how to build translated artifacts for RST-based OpenStack repositories
>>   but I could not find the way how to build translated container
>> whitepaper with translated resources on Zanata.
>>
> This is a little tricky.  It's possible to set up a local version of
> the OpenStack website (https://github.com/OpenStackw
> eb/openstack-org/blob/master/installation.md).  However, we have to
> manually ingest the po files as they are completed and then push them out
> to production, so that wouldn't do much to help with your local build.  
> I'm
> open to suggestions on how we can make 

[openstack-dev] [ironic] [FFE] Teach ironic about ppc64le boot requirements

[Michael Turek]

I would like to request a FFE for this RFE 
https://storyboard.openstack.org/#!/story/1749057


The implementation should be complete and is currently passing CI, but 
does need more reviews. I'd also like to test this locally ideally.


pros
---
- Improves ppc64le support

cons
---
- Bumps ironic-lib version for both IPA and Ironic

risk
---
- There are other deployment methods for ppc64le, including wholedisk 
and netboot. However, this feature is desired to improve parity between 
x86 and ppc64le for tripleo. The feature should not affect any current 
working deployment methods, but please review closely.


Please let me know if you'd like more detail on this or have any 
questions! Thanks!


-Mike  Turek


__
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] [election][horizon][ptl] PTL Candidacy for Stein Release

[Ivan Kolodyazhny]

Hello  everyone,

I would like to announce my candidacy for PTL of Horizon for Stein release.


I had the honor to serve PTL role in the Rocky timeframe and I want to
continue work
with such a great team with PTL hat.

During Rocky release cycle we worked mostly on the technical dept. We
improved our
CI with new jobs for Selenium tests. Some work is still in progress on
getting
integration tests working again. We're pretty close to reaching mox to mock
migration community goal. I would like to work on these areas in Stein
release
too.


In addition to this, as PTL I'm going to work on the following areas:

* Finish work on mox to mock migrations and integration tests CI job.

* More cross projects work should be done: cross-project CI jobs for
plugins,
  work closely with projects teams to understand which features should be
  implemented in Horizon.

* We need to help to contributors to get patches merged faster: work closely
  with new contributors, improve documentation to get it friendly both for
  JavaScript and Python developers.


I'm looking forward to working together with all of you on Stein release
and hope
for your help with my efforts.


Thank you,
Ivan Kolodyazhny (e0ne)
__
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] [i18n] Edge and Containers whitepapers ready for translation

[Frank Kloeker]

Hi Jimmy,

from the GUI I'll get this link:
https://translate.openstack.org/rest/file/translation/edge-computing/pot-translation/de/po?docId=cloud-edge-computing-beyond-the-data-center

paper version  are only in container whitepaper:

https://translate.openstack.org/rest/file/translation/leveraging-containers-openstack/paper/de/po?docId=leveraging-containers-and-openstack

In general there is no group named papers

kind regards

Frank

Am 2018-07-30 17:06, schrieb Jimmy McArthur:

Frank,

We're getting a 404 when looking for the pot file on the Zanata API:
https://translate.openstack.org/rest/file/translation/papers/papers/de/po?docId=edge-computing

As a result, we can't pull the po files.  Any idea what might be 
happening?


Seeing the same thing with both papers...

Thank you,
Jimmy

Frank Kloeker wrote:

Hi Jimmy,

Korean and German version are now done on the new format. Can you 
check publishing?


thx

Frank

Am 2018-07-19 16:47, schrieb Jimmy McArthur:

Hi all -

Follow up on the Edge paper specifically:
https://translate.openstack.org/iteration/view/edge-computing/pot-translation/documents?dswid=-3192 
This is now available. As I mentioned on IRC this morning, it should

be VERY close to the PDF.  Probably just needs a quick review.

Let me know if I can assist with anything.

Thank you to i18n team for all of your help!!!

Cheers,
Jimmy

Jimmy McArthur wrote:

Ian raises some great points :) I'll try to address below...

Ian Y. Choi wrote:

Hello,

When I saw overall translation source strings on container 
whitepaper, I would infer that new edge computing whitepaper

source strings would include HTML markup tags.
One of the things I discussed with Ian and Frank in Vancouver is the 
expense of recreating PDFs with new translations.  It's 
prohibitively expensive for the Foundation as it requires design 
resources which we just don't have.  As a result, we created the 
Containers whitepaper in HTML, so that it could be easily updated 
w/o working with outside design contractors.  I indicated that we 
would also be moving the Edge paper to HTML so that we could prevent 
that additional design resource cost.

On the other hand, the source strings of edge computing whitepaper
which I18n team previously translated do not include HTML markup 
tags, since the source strings are based on just text format.
The version that Akihiro put together was based on the Edge PDF, 
which we unfortunately didn't have the resources to implement in the 
same format.


I really appreciate Akihiro's work on RST-based support on 
publishing translated edge computing whitepapers, since

translators do not have to re-translate all the strings.
I would like to second this. It took a lot of initiative to work on 
the RST-based translation.  At the moment, it's just not usable for 
the reasons mentioned above.

On the other hand, it seems that I18n team needs to investigate on
translating similar strings of HTML-based edge computing whitepaper 
source strings, which would discourage translators.
Can you expand on this? I'm not entirely clear on why the HTML based 
translation is more difficult.


That's my point of view on translating edge computing whitepaper.

For translating container whitepaper, I want to further ask the 
followings since *I18n-based tools*
would mean for translators that translators can test and publish 
translated whitepapers locally:


- How to build translated container whitepaper using original 
Silverstripe-based repository?
  https://docs.openstack.org/i18n/latest/tools.html describes well 
how to build translated artifacts for RST-based OpenStack 
repositories
  but I could not find the way how to build translated container 
whitepaper with translated resources on Zanata.
This is a little tricky.  It's possible to set up a local version of 
the OpenStack website 
(https://github.com/OpenStackweb/openstack-org/blob/master/installation.md). 
 However, we have to manually ingest the po files as they are 
completed and then push them out to production, so that wouldn't do 
much to help with your local build.  I'm open to suggestions on how 
we can make this process easier for the i18n team.


Thank you,
Jimmy



With many thanks,

/Ian

Jimmy McArthur wrote on 7/17/2018 11:01 PM:

Frank,

I'm sorry to hear about the displeasure around the Edge paper.  As 
mentioned in a prior thread, the RST format that Akihiro worked 
did not work with the  Zanata process that we have been using with 
our CMS.  Additionally, the existing EDGE page is a PDF, so we had 
to build a new template to work with the new HTML whitepaper 
layout we created for the Containers paper. I outlined this in the 
thread " [OpenStack-I18n] [Edge-computing] [Openstack-sigs] Edge 
Computing Whitepaper Translation" on 6/25/18 and mentioned we 
would be ready with the template around 7/13.


We completed the work on the new whitepaper template and then put 
out the pot files on Zanata so we can get the po language files 
back. If this 

[openstack-dev] [Vitrage][PTL][Election] PTL candidacy for the Stein cycle

[Ifat Afek]

Hi all,

I would like to announce my candidacy to continue as Vitrage PTL for the
Stein
release.

I’ve been the PTL of Vitrage since the day it started. It has been an
amazing
journey, both for Vitrage and for me personally.

During the Rocky cycle, we have significantly enhanced the stability and
usability of Vitrage and we added support for integrating Vitrage with
several
other projects. We also took an active part in the self-healing SIG
discussions, as we believe Vitrage should hold an important role in every
self-healing scenario.

Among the most important tasks we did in Rocky were:

* Fast-failover of vitrage-graph
* Alarm history
* Significant performance improvements
* Kubernetes and Prometheus datasources

In Stein, I would like to continue the effort around Virage usability and
stability. In addition, we should integrate Vitrage with more projects,
to give the user maximum visibility of the state of the system.
On top of all the technical goals, I plan to continue the effort of
enlarging
our community. We are always looking for new contributors!

I look forward to working with you all in the coming cycle.

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

[openstack-dev] [release] Github release tarballs broken

[Ben Nemec]

According to https://bugs.launchpad.net/pbr/+bug/1742809 our github 
release tarballs don't actually work.  It seems to be a github-specific 
issue because I was unable to reproduce the problem with a tarball from 
releases.openstack.org.


My best guess is that github's release process differs from ours and 
doesn't work with our projects.  I see a couple of options for fixing 
that.  Either we figure out how to make Github's release process DTRT 
for our projects, or we figure out a way to override Github's release 
artifacts with our own.  I'm not familiar enough with this to know which 
is a better (or even possible) option, so I'm sending this to solicit help.


Thanks.

-Ben

__
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] [self-healing] [ptg] [monasca] PTG track schedule published

[Adam Spiers]

Hi Witek,

Thanks a lot for the offer!  I've suggested to Thierry that Thursday 
morning probably works best, but if the room logistics don't permit 
that then we might have to accept your kind offer - I'll let you know. 


Cheers!
Adam

Bedyk, Witold  wrote: 

Hi Adam,

if nothing else works, we could probably offer you half-day of Monasca slot on Monday or Tuesday afternoon. I'm afraid though that our room might be too small for you. 


Cheers
Witek


-Original Message-
From: Thierry Carrez 
Sent: Freitag, 20. Juli 2018 18:46
To: Adam Spiers 
Cc: openstack-dev mailing list 
Subject: Re: [openstack-dev] [self-healing] [ptg] PTG track schedule 
published 

Adam Spiers wrote: 
Apologies - I have had to change plans and leave on the Thursday 
evening (old friend is getting married on Saturday morning).  Is there 
any chance of swapping the self-healing slot with one of the others? 


It's tricky, as you asked to avoid conflicts with API SIG, Watcher, Monasca, 
Masakari, and Mistral... Which day would be best for you given the current 
schedule (assuming we don't move anything else as it's too late for that). 


--
Thierry Carrez (ttx) 


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

[openstack-dev] [election][cinder] PTL Candidacy for Stein Release

[Jay S Bryant]

All,

I have submitted a letter announcing my Cinder PTL Candidacy for the 
Stein Release Cycle here:  https://review.openstack.org/587139


I am including a copy of the letter below.

Thank you for your continued support!

Sincerely,

Jay Bryant (jungleboyj)

-

All,

This letter is to indicate my interest in continuing to serve as
the Cinder PTL for the Stein release. This would be my third
release as PTL and am happy to continue leading this great project.

As I look back at the last two releases we have gotten some
good things done.  The implementation of multi-attach has
been a goal of Cinder for quite some time and I am glad to
have been able to help make this happen.  We have also seen
a change from trying to get new features implemented in Cinder
to fixing bugs and making Cinder more user friendly and stable.
During the Rocky release we have continued to improve our
documentation, have worked on improving HA support and removed
a lot of old code that did not need to remain in tree.
I think this is an important evolution in the Cinder project:
to focus on stability, usability and maintainability of our code.

With that said I think the Stein release is going to be a challenging
release for Cinder.  We have the following issues that are going
to need to be addressed:

* Migration to Storyboard
* Dwindling review support
* Making decisions around the Placement Service and Cinder
* Continuing discussion around Cinder as a Stand-alone service

I am hoping that I will be able to use my experience over
the last two releases to move the above issues forward.

Sincerely,
Jay Bryant (jungleboyj)



__
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] deployement fails

[Remo Mattei]

Take it off and check :) 



> On Jul 30, 2018, at 09:46, Samuel Monderer  
> wrote:
> 
> Yes 
> I tried eith 60 and 120
> 
> On Mon, Jul 30, 2018, 19:42 Remo Mattei mailto:r...@rm.ht>> 
> wrote:
> Do you have a timeout set? 
> 
> > On Jul 30, 2018, at 07:48, Samuel Monderer  > > wrote:
> > 
> > Hi,
> > 
> > I'm trying to deploy a small environment with one controller and one 
> > compute but i get a timeout with no specific information in the logs
> > 
> > 2018-07-30 13:19:41Z [overcloud.Controller.0.ControllerConfig]: 
> > CREATE_IN_PROGRESS  state changed
> > 2018-07-30 13:19:41Z [overcloud.Controller.0.ControllerConfig]: 
> > CREATE_COMPLETE  state changed
> > 2018-07-30 14:04:51Z [overcloud.ComputeGammaV3]: CREATE_FAILED  CREATE 
> > aborted (Task create from ResourceGroup "ComputeGammaV3" Stack "overcloud" 
> > [690ee33c-8194-4713-a44f-9c8dcf88359f] Timed out)
> > 2018-07-30 14:04:51Z [overcloud.ComputeGammaV3]: UPDATE_FAILED  Stack 
> > UPDATE cancelled
> > 2018-07-30 14:04:51Z [overcloud]: CREATE_FAILED  Timed out
> > 2018-07-30 14:04:51Z [overcloud.ComputeGammaV3.0]: CREATE_FAILED  Stack 
> > CREATE cancelled
> > 2018-07-30 14:04:51Z [overcloud.Controller]: CREATE_FAILED  CREATE aborted 
> > (Task create from ResourceGroup "Controller" Stack "overcloud" 
> > [690ee33c-8194-4713-a44f-9c8dcf88359f] Timed out)
> > 2018-07-30 14:04:51Z [overcloud]: CREATE_FAILED  Timed out
> > 2018-07-30 14:04:51Z [overcloud.Controller]: UPDATE_FAILED  Stack UPDATE 
> > cancelled
> > 2018-07-30 14:04:51Z [overcloud.Controller.0]: CREATE_FAILED  Stack CREATE 
> > cancelled
> > 2018-07-30 14:04:52Z [overcloud.ComputeGammaV3.0]: CREATE_FAILED  
> > resources[0]: Stack CREATE cancelled
> > 
> >  Stack overcloud CREATE_FAILED 
> > 
> > overcloud.ComputeGammaV3.0:
> >   resource_type: OS::TripleO::ComputeGammaV3
> >   physical_resource_id: 5755d746-7cbf-4f3d-a9e1-d94a713705a7
> >   status: CREATE_FAILED
> >   status_reason: |
> > resources[0]: Stack CREATE cancelled
> > overcloud.Controller.0:
> >   resource_type: OS::TripleO::Controller
> >   physical_resource_id: 4bcf84c1-1d54-45ee-9f81-b6dda780cbd7
> >   status: CREATE_FAILED
> >   status_reason: |
> > resources[0]: Stack CREATE cancelled
> > Not cleaning temporary directory /tmp/tripleoclient-vxGzKo
> > Not cleaning temporary directory /tmp/tripleoclient-vxGzKo
> > Heat Stack create failed.
> > Heat Stack create failed.
> > (undercloud) [stack@staging-director ~]$
> > 
> > It seems that it wasn't able to configure the OVS bridges
> > 
> > (undercloud) [stack@staging-director ~]$ openstack software deployment show 
> > 4b4fc54f-7912-40e2-8ad4-79f6179fe701
> > +---++
> > | Field | Value  |
> > +---++
> > | id| 4b4fc54f-7912-40e2-8ad4-79f6179fe701   |
> > | server_id | 0accb7a3-4869-4497-8f3b-5a3d99f3926b   |
> > | config_id | 2641b4dd-afc7-4bf5-a2e2-481c207e4b7f   |
> > | creation_time | 2018-07-30T13:19:44Z   |
> > | updated_time  ||
> > | status| IN_PROGRESS|
> > | status_reason | Deploy data available  |
> > | input_values  | {u'interface_name': u'nic1', u'bridge_name': u'br-ex'} |
> > | action| CREATE |
> > +---++
> > (undercloud) [stack@staging-director ~]$ openstack software deployment show 
> > a297e8ae-f4c9-41b0-938f-c51f9fe23843
> > +---++
> > | Field | Value  |
> > +---++
> > | id| a297e8ae-f4c9-41b0-938f-c51f9fe23843   |
> > | server_id | 145167da-9b96-4eee-bfe9-399b854c1e84   |
> > | config_id | d1baf0a5-de9b-48f2-b486-9f5d97f7e94f   |
> > | creation_time | 2018-07-30T13:17:29Z   |
> > | updated_time  ||
> > | status| IN_PROGRESS|
> > | status_reason | Deploy data available  |
> > | input_values  | {u'interface_name': u'nic1', u'bridge_name': u'br-ex'} |
> > | action| CREATE |
> > +---++
> > (undercloud) [stack@staging-director ~]$
> > 
> > Regards,
> > Samuel
> > 

Re: [openstack-dev] [tripleo] deployement fails

[Samuel Monderer]

Yes
I tried eith 60 and 120

On Mon, Jul 30, 2018, 19:42 Remo Mattei  wrote:

> Do you have a timeout set?
>
> > On Jul 30, 2018, at 07:48, Samuel Monderer 
> wrote:
> >
> > Hi,
> >
> > I'm trying to deploy a small environment with one controller and one
> compute but i get a timeout with no specific information in the logs
> >
> > 2018-07-30 13:19:41Z [overcloud.Controller.0.ControllerConfig]:
> CREATE_IN_PROGRESS  state changed
> > 2018-07-30 13:19:41Z [overcloud.Controller.0.ControllerConfig]:
> CREATE_COMPLETE  state changed
> > 2018-07-30 14:04:51Z [overcloud.ComputeGammaV3]: CREATE_FAILED  CREATE
> aborted (Task create from ResourceGroup "ComputeGammaV3" Stack "overcloud"
> [690ee33c-8194-4713-a44f-9c8dcf88359f] Timed out)
> > 2018-07-30 14:04:51Z [overcloud.ComputeGammaV3]: UPDATE_FAILED  Stack
> UPDATE cancelled
> > 2018-07-30 14:04:51Z [overcloud]: CREATE_FAILED  Timed out
> > 2018-07-30 14:04:51Z [overcloud.ComputeGammaV3.0]: CREATE_FAILED  Stack
> CREATE cancelled
> > 2018-07-30 14:04:51Z [overcloud.Controller]: CREATE_FAILED  CREATE
> aborted (Task create from ResourceGroup "Controller" Stack "overcloud"
> [690ee33c-8194-4713-a44f-9c8dcf88359f] Timed out)
> > 2018-07-30 14:04:51Z [overcloud]: CREATE_FAILED  Timed out
> > 2018-07-30 14:04:51Z [overcloud.Controller]: UPDATE_FAILED  Stack UPDATE
> cancelled
> > 2018-07-30 14:04:51Z [overcloud.Controller.0]: CREATE_FAILED  Stack
> CREATE cancelled
> > 2018-07-30 14:04:52Z [overcloud.ComputeGammaV3.0]: CREATE_FAILED
> resources[0]: Stack CREATE cancelled
> >
> >  Stack overcloud CREATE_FAILED
> >
> > overcloud.ComputeGammaV3.0:
> >   resource_type: OS::TripleO::ComputeGammaV3
> >   physical_resource_id: 5755d746-7cbf-4f3d-a9e1-d94a713705a7
> >   status: CREATE_FAILED
> >   status_reason: |
> > resources[0]: Stack CREATE cancelled
> > overcloud.Controller.0:
> >   resource_type: OS::TripleO::Controller
> >   physical_resource_id: 4bcf84c1-1d54-45ee-9f81-b6dda780cbd7
> >   status: CREATE_FAILED
> >   status_reason: |
> > resources[0]: Stack CREATE cancelled
> > Not cleaning temporary directory /tmp/tripleoclient-vxGzKo
> > Not cleaning temporary directory /tmp/tripleoclient-vxGzKo
> > Heat Stack create failed.
> > Heat Stack create failed.
> > (undercloud) [stack@staging-director ~]$
> >
> > It seems that it wasn't able to configure the OVS bridges
> >
> > (undercloud) [stack@staging-director ~]$ openstack software deployment
> show 4b4fc54f-7912-40e2-8ad4-79f6179fe701
> >
> +---++
> > | Field | Value
> |
> >
> +---++
> > | id| 4b4fc54f-7912-40e2-8ad4-79f6179fe701
>  |
> > | server_id | 0accb7a3-4869-4497-8f3b-5a3d99f3926b
>  |
> > | config_id | 2641b4dd-afc7-4bf5-a2e2-481c207e4b7f
>  |
> > | creation_time | 2018-07-30T13:19:44Z
>  |
> > | updated_time  |
> |
> > | status| IN_PROGRESS
> |
> > | status_reason | Deploy data available
> |
> > | input_values  | {u'interface_name': u'nic1', u'bridge_name': u'br-ex'}
> |
> > | action| CREATE
>  |
> >
> +---++
> > (undercloud) [stack@staging-director ~]$ openstack software deployment
> show a297e8ae-f4c9-41b0-938f-c51f9fe23843
> >
> +---++
> > | Field | Value
> |
> >
> +---++
> > | id| a297e8ae-f4c9-41b0-938f-c51f9fe23843
>  |
> > | server_id | 145167da-9b96-4eee-bfe9-399b854c1e84
>  |
> > | config_id | d1baf0a5-de9b-48f2-b486-9f5d97f7e94f
>  |
> > | creation_time | 2018-07-30T13:17:29Z
>  |
> > | updated_time  |
> |
> > | status| IN_PROGRESS
> |
> > | status_reason | Deploy data available
> |
> > | input_values  | {u'interface_name': u'nic1', u'bridge_name': u'br-ex'}
> |
> > | action| CREATE
>  |
> >
> +---++
> > (undercloud) [stack@staging-director ~]$
> >
> > Regards,
> > Samuel
> >
> __
> > 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] [tripleo] deployement fails

[Remo Mattei]

Do you have a timeout set? 

> On Jul 30, 2018, at 07:48, Samuel Monderer  
> wrote:
> 
> Hi,
> 
> I'm trying to deploy a small environment with one controller and one compute 
> but i get a timeout with no specific information in the logs
> 
> 2018-07-30 13:19:41Z [overcloud.Controller.0.ControllerConfig]: 
> CREATE_IN_PROGRESS  state changed
> 2018-07-30 13:19:41Z [overcloud.Controller.0.ControllerConfig]: 
> CREATE_COMPLETE  state changed
> 2018-07-30 14:04:51Z [overcloud.ComputeGammaV3]: CREATE_FAILED  CREATE 
> aborted (Task create from ResourceGroup "ComputeGammaV3" Stack "overcloud" 
> [690ee33c-8194-4713-a44f-9c8dcf88359f] Timed out)
> 2018-07-30 14:04:51Z [overcloud.ComputeGammaV3]: UPDATE_FAILED  Stack UPDATE 
> cancelled
> 2018-07-30 14:04:51Z [overcloud]: CREATE_FAILED  Timed out
> 2018-07-30 14:04:51Z [overcloud.ComputeGammaV3.0]: CREATE_FAILED  Stack 
> CREATE cancelled
> 2018-07-30 14:04:51Z [overcloud.Controller]: CREATE_FAILED  CREATE aborted 
> (Task create from ResourceGroup "Controller" Stack "overcloud" 
> [690ee33c-8194-4713-a44f-9c8dcf88359f] Timed out)
> 2018-07-30 14:04:51Z [overcloud]: CREATE_FAILED  Timed out
> 2018-07-30 14:04:51Z [overcloud.Controller]: UPDATE_FAILED  Stack UPDATE 
> cancelled
> 2018-07-30 14:04:51Z [overcloud.Controller.0]: CREATE_FAILED  Stack CREATE 
> cancelled
> 2018-07-30 14:04:52Z [overcloud.ComputeGammaV3.0]: CREATE_FAILED  
> resources[0]: Stack CREATE cancelled
> 
>  Stack overcloud CREATE_FAILED 
> 
> overcloud.ComputeGammaV3.0:
>   resource_type: OS::TripleO::ComputeGammaV3
>   physical_resource_id: 5755d746-7cbf-4f3d-a9e1-d94a713705a7
>   status: CREATE_FAILED
>   status_reason: |
> resources[0]: Stack CREATE cancelled
> overcloud.Controller.0:
>   resource_type: OS::TripleO::Controller
>   physical_resource_id: 4bcf84c1-1d54-45ee-9f81-b6dda780cbd7
>   status: CREATE_FAILED
>   status_reason: |
> resources[0]: Stack CREATE cancelled
> Not cleaning temporary directory /tmp/tripleoclient-vxGzKo
> Not cleaning temporary directory /tmp/tripleoclient-vxGzKo
> Heat Stack create failed.
> Heat Stack create failed.
> (undercloud) [stack@staging-director ~]$
> 
> It seems that it wasn't able to configure the OVS bridges
> 
> (undercloud) [stack@staging-director ~]$ openstack software deployment show 
> 4b4fc54f-7912-40e2-8ad4-79f6179fe701
> +---++
> | Field | Value  |
> +---++
> | id| 4b4fc54f-7912-40e2-8ad4-79f6179fe701   |
> | server_id | 0accb7a3-4869-4497-8f3b-5a3d99f3926b   |
> | config_id | 2641b4dd-afc7-4bf5-a2e2-481c207e4b7f   |
> | creation_time | 2018-07-30T13:19:44Z   |
> | updated_time  ||
> | status| IN_PROGRESS|
> | status_reason | Deploy data available  |
> | input_values  | {u'interface_name': u'nic1', u'bridge_name': u'br-ex'} |
> | action| CREATE |
> +---++
> (undercloud) [stack@staging-director ~]$ openstack software deployment show 
> a297e8ae-f4c9-41b0-938f-c51f9fe23843
> +---++
> | Field | Value  |
> +---++
> | id| a297e8ae-f4c9-41b0-938f-c51f9fe23843   |
> | server_id | 145167da-9b96-4eee-bfe9-399b854c1e84   |
> | config_id | d1baf0a5-de9b-48f2-b486-9f5d97f7e94f   |
> | creation_time | 2018-07-30T13:17:29Z   |
> | updated_time  ||
> | status| IN_PROGRESS|
> | status_reason | Deploy data available  |
> | input_values  | {u'interface_name': u'nic1', u'bridge_name': u'br-ex'} |
> | action| CREATE |
> +---++
> (undercloud) [stack@staging-director ~]$
> 
> Regards,
> Samuel
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [openstack-ansible] Proposing Jonathan Rosser as core reviewer

[Guilherme Steinmüller]

+1 nice guy to be a core!

On Mon, Jul 30, 2018, 13:08 Mohammed Naser  wrote:

> On Mon, Jul 30, 2018 at 11:59 AM, Jesse Pretorius
>  wrote:
> >>On 7/30/18, 9:19 AM, "jean-phili...@evrard.me" 
> wrote:
> >>
> >>I'd like to propose Jonathan Rosser (jrosser) as core reviewer for
> OpenStack-Ansible.
> >>The BBC team [1] has been very active recently across the board, but
> worked heavily in our ops repo, making sure the experience is complete for
> operators.
> >
> > I most certainly welcome this. Jonathan (and his team) are insightful
> and provide very valuable operator input and they're always ready to help
> when they can. +2 from me
> >
> >
> I echo those thoughts, +2. :)
> >
> >
> > 
> > Rackspace Limited is a company registered in England & Wales (company
> registered number 03897010) whose registered office is at 5 Millington
> Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy
> can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail
> message may contain confidential or privileged information intended for the
> recipient. Any dissemination, distribution or copying of the enclosed
> material is prohibited. If you receive this transmission in error, please
> notify us immediately by e-mail at ab...@rackspace.com and delete the
> original message. Your cooperation is appreciated.
> >
> __
> > 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
>
>
>
> --
> Mohammed Naser — vexxhost
> -
> D. 514-316-8872
> D. 800-910-1726 ext. 200
> E. mna...@vexxhost.com
> W. http://vexxhost.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
>
__
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-ansible] Proposing Jonathan Rosser as core reviewer

[Mohammed Naser]

On Mon, Jul 30, 2018 at 11:59 AM, Jesse Pretorius
 wrote:
>>On 7/30/18, 9:19 AM, "jean-phili...@evrard.me"  
>>wrote:
>>
>>I'd like to propose Jonathan Rosser (jrosser) as core reviewer for 
>> OpenStack-Ansible.
>>The BBC team [1] has been very active recently across the board, but 
>> worked heavily in our ops repo, making sure the experience is complete for 
>> operators.
>
> I most certainly welcome this. Jonathan (and his team) are insightful and 
> provide very valuable operator input and they're always ready to help when 
> they can. +2 from me
>
>
I echo those thoughts, +2. :)
>
>
> 
> Rackspace Limited is a company registered in England & Wales (company 
> registered number 03897010) whose registered office is at 5 Millington Road, 
> Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
> viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
> contain confidential or privileged information intended for the recipient. 
> Any dissemination, distribution or copying of the enclosed material is 
> prohibited. If you receive this transmission in error, please notify us 
> immediately by e-mail at ab...@rackspace.com and delete the original message. 
> Your cooperation is appreciated.
> __
> 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



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.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

[openstack-dev] [oslo] PTL candidacy

[Ben Nemec]

You can find my statement at 
https://review.openstack.org/#/c/587096/1/candidates/stein/Oslo/openstack%2540nemebean.com


That's certainly not an exhaustive list of what I plan to do next cycle, 
but given the size of our team I thought my time was better spent doing 
those things than writing a flowery campaign speech that nobody would 
ever read. ;-)


-Ben

__
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-ansible] Proposing Jonathan Rosser as core reviewer

[Jesse Pretorius]

>On 7/30/18, 9:19 AM, "jean-phili...@evrard.me"  wrote:
>
>I'd like to propose Jonathan Rosser (jrosser) as core reviewer for 
> OpenStack-Ansible.
>The BBC team [1] has been very active recently across the board, but 
> worked heavily in our ops repo, making sure the experience is complete for 
> operators.

I most certainly welcome this. Jonathan (and his team) are insightful and 
provide very valuable operator input and they're always ready to help when they 
can. +2 from me





Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
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] The Weekly Owl - 25th Edition

[Pradeep Kilambi]

On Mon, Jul 30, 2018 at 10:42 AM Alex Schultz  wrote:

> On Mon, Jul 30, 2018 at 8:32 AM, Martin Magr  wrote:
> >
> >
> > On Tue, Jul 17, 2018 at 6:12 PM, Emilien Macchi 
> wrote:
> >>
> >> Your fellow reporter took a break from writing, but is now back on his
> >> pen.
> >>
> >> Welcome to the twenty-fifth edition of a weekly update in TripleO world!
> >> The goal is to provide a short reading (less than 5 minutes) to learn
> >> what's new this week.
> >> Any contributions and feedback are welcome.
> >> Link to the previous version:
> >>
> http://lists.openstack.org/pipermail/openstack-dev/2018-June/131426.html
> >>
> >> +-+
> >> | General announcements |
> >> +-+
> >>
> >> +--> Rocky Milestone 3 is next week. After, any feature code will
> require
> >> Feature Freeze Exception (FFE), asked on the mailing-list. We'll enter a
> >> bug-fix only and stabilization period, until we can push the first
> stable
> >> version of Rocky.
> >
> >
> > Hey guys,
> >
> >   I would like to ask for FFE for backup and restore, where we ended up
> > deciding where is the best place for the code base for this project
> (please
> > see [1] for details). We believe that B support for overcloud control
> > plane will be good addition to a rocky release, but we started with this
> > initiative quite late indeed. The final result should the support in
> > openstack client, where "openstack overcloud (backup|restore)" would
> work as
> > a charm. Thanks in advance for considering this feature.
> >
>
> Was there a blueprint/spec for this effort?  Additionally do we have a
> list of the outstanding work required for this? If it's just these two
> playbooks, it might be ok for an FFE. But if there's additional
> tripleoclient related changes, I wouldn't necessarily feel comfortable
> with these unless we have a complete list of work.  Just as a side
> note, I'm not sure putting these in tripleo-common is going to be the
> ideal place for this.
>


Thanks Alex. For Rocky, if we can ship the playbooks with relevant docs we
should be good. We will integrated with client in Stein release with
restore logic included. Regarding putting tripleo-common, we're open to
suggestions. I think Dan just submitted the review so we can get some eyes
on the playbooks. Where do you suggest is better place for these instead?


>
> Thanks,
> -Alex
>
> > Regards,
> > Martin
> >
> > [1] https://review.openstack.org/#/c/582453/
> >
> >>
> >> +--> Next PTG will be in Denver, please propose topics:
> >> https://etherpad.openstack.org/p/tripleoci-ptg-stein
> >> +--> Multiple squads are currently brainstorming a framework to provide
> >> validations pre/post upgrades - stay in touch!
> >>
> >> +--+
> >> | Continuous Integration |
> >> +--+
> >>
> >> +--> Sprint theme: migration to Zuul v3 (More on
> >> https://trello.com/c/vyWXcKOB/841-sprint-16-goals)
> >> +--> Sagi is the rover and Chandan is the ruck. Please tell them any CI
> >> issue.
> >> +--> Promotion on master is 4 days, 0 days on Queens and Pike and 1 day
> on
> >> Ocata.
> >> +--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting
> >>
> >> +-+
> >> | Upgrades |
> >> +-+
> >>
> >> +--> Good progress on major upgrades workflow, need reviews!
> >> +--> More:
> https://etherpad.openstack.org/p/tripleo-upgrade-squad-status
> >>
> >> +---+
> >> | Containers |
> >> +---+
> >>
> >> +--> We switched python-tripleoclient to deploy containerized undercloud
> >> by default!
> >> +--> Image prepare via workflow is still work in progress.
> >> +--> More:
> >> https://etherpad.openstack.org/p/tripleo-containers-squad-status
> >>
> >> +--+
> >> | config-download |
> >> +--+
> >>
> >> +--> UI integration is almost done (need review)
> >> +--> Bug with failure listing is being fixed:
> >> https://bugs.launchpad.net/tripleo/+bug/1779093
> >> +--> More:
> >> https://etherpad.openstack.org/p/tripleo-config-download-squad-status
> >>
> >> +--+
> >> | Integration |
> >> +--+
> >>
> >> +--> We're enabling decoupled deployment plans e.g for OpenShift, DPDK
> >> etc:
> >>
> https://review.openstack.org/#/q/topic:alternate_plans+(status:open+OR+status:merged)
> >> (need reviews).
> >> +--> More:
> >> https://etherpad.openstack.org/p/tripleo-integration-squad-status
> >>
> >> +-+
> >> | UI/CLI |
> >> +-+
> >>
> >> +--> Good progress on network configuration via UI
> >> +--> Config-download patches are being reviewed and a lot of testing is
> >> going on.
> >> +--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status
> >>
> >> +---+
> >> | Validations |
> >> +---+
> >>
> >> +--> Working on OpenShift validations, need reviews.
> >> +--> More:
> >> https://etherpad.openstack.org/p/tripleo-validations-squad-status
> >>
> >> 

Re: [openstack-dev] [openstack-ansible] Proposing Jonathan Rosser as core reviewer

[Amy Marrich]

+2 from me!

Amy (spotz)

On Mon, Jul 30, 2018 at 3:16 AM, jean-phili...@evrard.me <
jean-phili...@evrard.me> wrote:

> Hello everyone,
>
> I'd like to propose Jonathan Rosser (jrosser) as core reviewer for
> OpenStack-Ansible.
> The BBC team [1] has been very active recently across the board, but
> worked heavily in our ops repo, making sure the experience is complete for
> operators.
>
> I value Jonathan's opinion (I remember the storage backend conversations
> for lxc/systemd-nspawn!), and I'd like this positive trend to continue. On
> top of it Jonathan has been recently reviewing quite a series of patches,
> and is involved into some of our important work: bringing the Bionic
> support.
>
> Best regards,
> Jean-Philippe Evrard (evrardjp)
>
> [1]: http://stackalytics.com/?project_type=openstack;
> release=rocky=commits=BBC
>
>
> __
> 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] [requirements][release] FFE for openstacksdk 0.17.1

[Matthew Thode]

On 18-07-30 08:33:32, Monty Taylor wrote:
> Heya,
> 
> I'd like to request a FFE to release 0.17.1 of openstacksdk from
> stable/rocky. The current rocky release, 0.17.0, added a feature (being able
> to pass data directly to an object upload rather that requiring a file or
> file-like object) - but it is broken if you pass an interator because it
> (senselessly) tries to run len() on the data parameter.
> 
> The new feature is not used anywhere in OpenStack yet. The first consumer
> (and requestor of the feature) is Infra, who are looking at using it as part
> of our efforts to start uploading build log files to swift.
> 
> We should not need a g-r bump - since nothing in OpenStack uses the feature
> yet, none of the OpenStack projects need their depends changed. OTOH,
> openstacksdk is a thing we expect end-users to use, and once they see the
> shiny new feature they might use it - and then be sad that it's half broken.
> 

As long as it's only a UC bump you have my ack.

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [i18n] Edge and Containers whitepapers ready for translation

[Jimmy McArthur]

Frank,

We're getting a 404 when looking for the pot file on the Zanata API: 
https://translate.openstack.org/rest/file/translation/papers/papers/de/po?docId=edge-computing


As a result, we can't pull the po files.  Any idea what might be happening?

Seeing the same thing with both papers...

Thank you,
Jimmy

Frank Kloeker wrote:

Hi Jimmy,

Korean and German version are now done on the new format. Can you 
check publishing?


thx

Frank

Am 2018-07-19 16:47, schrieb Jimmy McArthur:

Hi all -

Follow up on the Edge paper specifically:
https://translate.openstack.org/iteration/view/edge-computing/pot-translation/documents?dswid=-3192 



This is now available. As I mentioned on IRC this morning, it should
be VERY close to the PDF.  Probably just needs a quick review.

Let me know if I can assist with anything.

Thank you to i18n team for all of your help!!!

Cheers,
Jimmy

Jimmy McArthur wrote:

Ian raises some great points :) I'll try to address below...

Ian Y. Choi wrote:

Hello,

When I saw overall translation source strings on container 
whitepaper, I would infer that new edge computing whitepaper

source strings would include HTML markup tags.
One of the things I discussed with Ian and Frank in Vancouver is the 
expense of recreating PDFs with new translations.  It's 
prohibitively expensive for the Foundation as it requires design 
resources which we just don't have.  As a result, we created the 
Containers whitepaper in HTML, so that it could be easily updated 
w/o working with outside design contractors.  I indicated that we 
would also be moving the Edge paper to HTML so that we could prevent 
that additional design resource cost.

On the other hand, the source strings of edge computing whitepaper
which I18n team previously translated do not include HTML markup 
tags, since the source strings are based on just text format.
The version that Akihiro put together was based on the Edge PDF, 
which we unfortunately didn't have the resources to implement in the 
same format.


I really appreciate Akihiro's work on RST-based support on 
publishing translated edge computing whitepapers, since

translators do not have to re-translate all the strings.
I would like to second this. It took a lot of initiative to work on 
the RST-based translation.  At the moment, it's just not usable for 
the reasons mentioned above.

On the other hand, it seems that I18n team needs to investigate on
translating similar strings of HTML-based edge computing whitepaper 
source strings, which would discourage translators.
Can you expand on this? I'm not entirely clear on why the HTML based 
translation is more difficult.


That's my point of view on translating edge computing whitepaper.

For translating container whitepaper, I want to further ask the 
followings since *I18n-based tools*
would mean for translators that translators can test and publish 
translated whitepapers locally:


- How to build translated container whitepaper using original 
Silverstripe-based repository?
  https://docs.openstack.org/i18n/latest/tools.html describes well 
how to build translated artifacts for RST-based OpenStack repositories
  but I could not find the way how to build translated container 
whitepaper with translated resources on Zanata.
This is a little tricky.  It's possible to set up a local version of 
the OpenStack website 
(https://github.com/OpenStackweb/openstack-org/blob/master/installation.md). 
 However, we have to manually ingest the po files as they are 
completed and then push them out to production, so that wouldn't do 
much to help with your local build.  I'm open to suggestions on how 
we can make this process easier for the i18n team.


Thank you,
Jimmy



With many thanks,

/Ian

Jimmy McArthur wrote on 7/17/2018 11:01 PM:

Frank,

I'm sorry to hear about the displeasure around the Edge paper.  As 
mentioned in a prior thread, the RST format that Akihiro worked 
did not work with the  Zanata process that we have been using with 
our CMS.  Additionally, the existing EDGE page is a PDF, so we had 
to build a new template to work with the new HTML whitepaper 
layout we created for the Containers paper. I outlined this in the 
thread " [OpenStack-I18n] [Edge-computing] [Openstack-sigs] Edge 
Computing Whitepaper Translation" on 6/25/18 and mentioned we 
would be ready with the template around 7/13.


We completed the work on the new whitepaper template and then put 
out the pot files on Zanata so we can get the po language files 
back. If this process is too cumbersome for the translation team, 
I'm open to discussion, but right now our entire translation 
process is based on the official OpenStack Docs translation 
process outlined by the i18n team: 
https://docs.openstack.org/i18n/latest/en_GB/tools.html


Again, I realize Akihiro put in some work on his own proposing the 
new translation type. If the i18n team is moving to this format 
instead, we can work on redoing our process.


Please let me know if I can clarify 

[openstack-dev] [tripleo] deployement fails

[Samuel Monderer]

Hi,

I'm trying to deploy a small environment with one controller and one
compute but i get a timeout with no specific information in the logs

2018-07-30 13:19:41Z [overcloud.Controller.0.ControllerConfig]:
CREATE_IN_PROGRESS  state changed
2018-07-30 13:19:41Z [overcloud.Controller.0.ControllerConfig]:
CREATE_COMPLETE  state changed
2018-07-30 14:04:51Z [overcloud.ComputeGammaV3]: CREATE_FAILED  CREATE
aborted (Task create from ResourceGroup "ComputeGammaV3" Stack "overcloud"
[690ee33c-8194-4713-a44f-9c8dcf88359f] Timed out)
2018-07-30 14:04:51Z [overcloud.ComputeGammaV3]: UPDATE_FAILED  Stack
UPDATE cancelled
2018-07-30 14:04:51Z [overcloud]: CREATE_FAILED  Timed out
2018-07-30 14:04:51Z [overcloud.ComputeGammaV3.0]: CREATE_FAILED  Stack
CREATE cancelled
2018-07-30 14:04:51Z [overcloud.Controller]: CREATE_FAILED  CREATE aborted
(Task create from ResourceGroup "Controller" Stack "overcloud"
[690ee33c-8194-4713-a44f-9c8dcf88359f] Timed out)
2018-07-30 14:04:51Z [overcloud]: CREATE_FAILED  Timed out
2018-07-30 14:04:51Z [overcloud.Controller]: UPDATE_FAILED  Stack UPDATE
cancelled
2018-07-30 14:04:51Z [overcloud.Controller.0]: CREATE_FAILED  Stack CREATE
cancelled
2018-07-30 14:04:52Z [overcloud.ComputeGammaV3.0]: CREATE_FAILED
resources[0]: Stack CREATE cancelled

 Stack overcloud CREATE_FAILED

overcloud.ComputeGammaV3.0:
  resource_type: OS::TripleO::ComputeGammaV3
  physical_resource_id: 5755d746-7cbf-4f3d-a9e1-d94a713705a7
  status: CREATE_FAILED
  status_reason: |
resources[0]: Stack CREATE cancelled
overcloud.Controller.0:
  resource_type: OS::TripleO::Controller
  physical_resource_id: 4bcf84c1-1d54-45ee-9f81-b6dda780cbd7
  status: CREATE_FAILED
  status_reason: |
resources[0]: Stack CREATE cancelled
Not cleaning temporary directory /tmp/tripleoclient-vxGzKo
Not cleaning temporary directory /tmp/tripleoclient-vxGzKo
Heat Stack create failed.
Heat Stack create failed.
(undercloud) [stack@staging-director ~]$

It seems that it wasn't able to configure the OVS bridges

(undercloud) [stack@staging-director ~]$ openstack software deployment show
4b4fc54f-7912-40e2-8ad4-79f6179fe701
+---++
| Field | Value  |
+---++
| id| 4b4fc54f-7912-40e2-8ad4-79f6179fe701   |
| server_id | 0accb7a3-4869-4497-8f3b-5a3d99f3926b   |
| config_id | 2641b4dd-afc7-4bf5-a2e2-481c207e4b7f   |
| creation_time | 2018-07-30T13:19:44Z   |
| updated_time  ||
| status| IN_PROGRESS|
| status_reason | Deploy data available  |
| input_values  | {u'interface_name': u'nic1', u'bridge_name': u'br-ex'} |
| action| CREATE |
+---++
(undercloud) [stack@staging-director ~]$ openstack software deployment show
a297e8ae-f4c9-41b0-938f-c51f9fe23843
+---++
| Field | Value  |
+---++
| id| a297e8ae-f4c9-41b0-938f-c51f9fe23843   |
| server_id | 145167da-9b96-4eee-bfe9-399b854c1e84   |
| config_id | d1baf0a5-de9b-48f2-b486-9f5d97f7e94f   |
| creation_time | 2018-07-30T13:17:29Z   |
| updated_time  ||
| status| IN_PROGRESS|
| status_reason | Deploy data available  |
| input_values  | {u'interface_name': u'nic1', u'bridge_name': u'br-ex'} |
| action| CREATE |
+---++
(undercloud) [stack@staging-director ~]$

Regards,
Samuel
__
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] [charms] PTL candidacy for Stein cycle

[David Ames]

On Sat, Jul 28, 2018 at 8:25 AM, Frode Nordahl
 wrote:
> Hello all,
>
> I hereby announce my candidacy for PTL of the OpenStack Charms project [0].
>
> Through the course of the past two years I have made many contributions to
> the Charms projects and I have had the privilege of becoming a Core
> developer.
>
> Prior to focusing on the Charms project I have made upstream contributions
> in
> other OpenStack projects and I have followed the unfolding and development
> of
> the OpenStack community with great interest.
>
> We live in exciting times and I believe great things are afoot for OpenStack
> as a stable, versatile and solid contender in the cloud space.  It would be
> my privilege to be able to help further that along as PTL for the Charms
> project.
>
> Our project has a strong and disperse group of contributors and we are
> blessed
> with motivated and assertive people taking interest in maintaining existing
> code as well as developing new features.
>
> The most important aspect of my job as PTL will be to make sure we maintain
> room for the diversity of contributions without losing velocity and
> direction.
> Maintaining and developing our connection with the broader OpenStack
> community
> will also be of great importance.
>
> Some key areas of focus for Stein cycle:
> - Python 3 migration
>   - The clock is ticking for Python 2 and we need to continue the drive
> towards
> porting all our code to Python 3
> - Continue modernization of test framework
>   - Sustained software quality is only as good as you can prove through the
> quality of your unit and functional tests.
>   - Great progress has been made this past cycle in developing and extending
> functionality of a new framework for our functional tests and we need to
> continue this work.
>   - Continue to build test driven development culture, and export this
> culture
> to contributors outside the core team.
> - [Multi-cycle] Explore possibilities and methodologies for Classic ->
> layered
>   Reactive Charm migrations
>   - A lot of effort has been put into the Reactive Charm framework and the
> reality of writing a new Charm today is quite different from what it was
> just a few years ago.
>   - The time and effort needed to maintain a layered Reactive Charm is also
> far
> less than what it takes to maintain a classic Charm.
>   - There are many hard and difficult topics surrounding such a migration
> but I
> think it is worth spending some time exploring our options of how we
> could
> get there.
> - Evaluate use of upstream release tools
>   - The OpenStack release team has put together some great tools that might
> make our release duties easier.  Let us evaluate adopting some of them
> for
> our project.
>
> 0: https://review.openstack.org/#/c/586821/
>
> --
> Frode Nordahl (IRC: fnordahl)


+1

I am certain Frode will work tirelessly as the Chrams PTL.

--
David Ames

__
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] The Weekly Owl - 25th Edition

[Alex Schultz]

On Mon, Jul 30, 2018 at 8:32 AM, Martin Magr  wrote:
>
>
> On Tue, Jul 17, 2018 at 6:12 PM, Emilien Macchi  wrote:
>>
>> Your fellow reporter took a break from writing, but is now back on his
>> pen.
>>
>> Welcome to the twenty-fifth edition of a weekly update in TripleO world!
>> The goal is to provide a short reading (less than 5 minutes) to learn
>> what's new this week.
>> Any contributions and feedback are welcome.
>> Link to the previous version:
>> http://lists.openstack.org/pipermail/openstack-dev/2018-June/131426.html
>>
>> +-+
>> | General announcements |
>> +-+
>>
>> +--> Rocky Milestone 3 is next week. After, any feature code will require
>> Feature Freeze Exception (FFE), asked on the mailing-list. We'll enter a
>> bug-fix only and stabilization period, until we can push the first stable
>> version of Rocky.
>
>
> Hey guys,
>
>   I would like to ask for FFE for backup and restore, where we ended up
> deciding where is the best place for the code base for this project (please
> see [1] for details). We believe that B support for overcloud control
> plane will be good addition to a rocky release, but we started with this
> initiative quite late indeed. The final result should the support in
> openstack client, where "openstack overcloud (backup|restore)" would work as
> a charm. Thanks in advance for considering this feature.
>

Was there a blueprint/spec for this effort?  Additionally do we have a
list of the outstanding work required for this? If it's just these two
playbooks, it might be ok for an FFE. But if there's additional
tripleoclient related changes, I wouldn't necessarily feel comfortable
with these unless we have a complete list of work.  Just as a side
note, I'm not sure putting these in tripleo-common is going to be the
ideal place for this.

Thanks,
-Alex

> Regards,
> Martin
>
> [1] https://review.openstack.org/#/c/582453/
>
>>
>> +--> Next PTG will be in Denver, please propose topics:
>> https://etherpad.openstack.org/p/tripleoci-ptg-stein
>> +--> Multiple squads are currently brainstorming a framework to provide
>> validations pre/post upgrades - stay in touch!
>>
>> +--+
>> | Continuous Integration |
>> +--+
>>
>> +--> Sprint theme: migration to Zuul v3 (More on
>> https://trello.com/c/vyWXcKOB/841-sprint-16-goals)
>> +--> Sagi is the rover and Chandan is the ruck. Please tell them any CI
>> issue.
>> +--> Promotion on master is 4 days, 0 days on Queens and Pike and 1 day on
>> Ocata.
>> +--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting
>>
>> +-+
>> | Upgrades |
>> +-+
>>
>> +--> Good progress on major upgrades workflow, need reviews!
>> +--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad-status
>>
>> +---+
>> | Containers |
>> +---+
>>
>> +--> We switched python-tripleoclient to deploy containerized undercloud
>> by default!
>> +--> Image prepare via workflow is still work in progress.
>> +--> More:
>> https://etherpad.openstack.org/p/tripleo-containers-squad-status
>>
>> +--+
>> | config-download |
>> +--+
>>
>> +--> UI integration is almost done (need review)
>> +--> Bug with failure listing is being fixed:
>> https://bugs.launchpad.net/tripleo/+bug/1779093
>> +--> More:
>> https://etherpad.openstack.org/p/tripleo-config-download-squad-status
>>
>> +--+
>> | Integration |
>> +--+
>>
>> +--> We're enabling decoupled deployment plans e.g for OpenShift, DPDK
>> etc:
>> https://review.openstack.org/#/q/topic:alternate_plans+(status:open+OR+status:merged)
>> (need reviews).
>> +--> More:
>> https://etherpad.openstack.org/p/tripleo-integration-squad-status
>>
>> +-+
>> | UI/CLI |
>> +-+
>>
>> +--> Good progress on network configuration via UI
>> +--> Config-download patches are being reviewed and a lot of testing is
>> going on.
>> +--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status
>>
>> +---+
>> | Validations |
>> +---+
>>
>> +--> Working on OpenShift validations, need reviews.
>> +--> More:
>> https://etherpad.openstack.org/p/tripleo-validations-squad-status
>>
>> +---+
>> | Networking |
>> +---+
>>
>> +--> No updates this week.
>> +--> More:
>> https://etherpad.openstack.org/p/tripleo-networking-squad-status
>>
>> +--+
>> | Workflows |
>> +--+
>>
>> +--> No updates this week.
>> +--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status
>>
>> +---+
>> | Security |
>> +---+
>>
>> +--> Working on Secrets management and Limit TripleO users efforts
>> +--> More: https://etherpad.openstack.org/p/tripleo-security-squad
>>
>> ++
>> | Owl fact  |
>> ++
>> Elf owls live in a cacti. They are the smallest owls, and live in the
>> southwestern United States and 

Re: [openstack-dev] [tripleo] The Weekly Owl - 25th Edition

[Martin Magr]

On Tue, Jul 17, 2018 at 6:12 PM, Emilien Macchi  wrote:

> Your fellow reporter took a break from writing, but is now back on his pen.
>
> Welcome to the twenty-fifth edition of a weekly update in TripleO world!
> The goal is to provide a short reading (less than 5 minutes) to learn
> what's new this week.
> Any contributions and feedback are welcome.
> Link to the previous version:
> http://lists.openstack.org/pipermail/openstack-dev/2018-June/131426.html
>
> +-+
> | General announcements |
> +-+
>
> +--> Rocky Milestone 3 is next week. After, any feature code will require
> Feature Freeze Exception (FFE), asked on the mailing-list. We'll enter a
> bug-fix only and stabilization period, until we can push the first stable
> version of Rocky.
>

Hey guys,

  I would like to ask for FFE for backup and restore, where we ended up
deciding where is the best place for the code base for this project (please
see [1] for details). We believe that B support for overcloud control
plane will be good addition to a rocky release, but we started with this
initiative quite late indeed. The final result should the support in
openstack client, where "openstack overcloud (backup|restore)" would work
as a charm. Thanks in advance for considering this feature.

Regards,
Martin

[1] https://review.openstack.org/#/c/582453/


> +--> Next PTG will be in Denver, please propose topics:
> https://etherpad.openstack.org/p/tripleoci-ptg-stein
> +--> Multiple squads are currently brainstorming a framework to provide
> validations pre/post upgrades - stay in touch!
>
> +--+
> | Continuous Integration |
> +--+
>
> +--> Sprint theme: migration to Zuul v3 (More on
> https://trello.com/c/vyWXcKOB/841-sprint-16-goals)
> +--> Sagi is the rover and Chandan is the ruck. Please tell them any CI
> issue.
> +--> Promotion on master is 4 days, 0 days on Queens and Pike and 1 day on
> Ocata.
> +--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting
>
> +-+
> | Upgrades |
> +-+
>
> +--> Good progress on major upgrades workflow, need reviews!
> +--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad-status
>
> +---+
> | Containers |
> +---+
>
> +--> We switched python-tripleoclient to deploy containerized undercloud
> by default!
> +--> Image prepare via workflow is still work in progress.
> +--> More: https://etherpad.openstack.org/p/tripleo-containers-squad-st
> atus
>
> +--+
> | config-download |
> +--+
>
> +--> UI integration is almost done (need review)
> +--> Bug with failure listing is being fixed: https://bugs.launchpad.
> net/tripleo/+bug/1779093
> +--> More: https://etherpad.openstack.org/p/tripleo-config-download-squ
> ad-status
>
> +--+
> | Integration |
> +--+
>
> +--> We're enabling decoupled deployment plans e.g for OpenShift, DPDK
> etc: https://review.openstack.org/#/q/topic:alternate_plans+
> (status:open+OR+status:merged) (need reviews).
> +--> More: https://etherpad.openstack.org/p/tripleo-integration-squad-s
> tatus
>
> +-+
> | UI/CLI |
> +-+
>
> +--> Good progress on network configuration via UI
> +--> Config-download patches are being reviewed and a lot of testing is
> going on.
> +--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status
>
> +---+
> | Validations |
> +---+
>
> +--> Working on OpenShift validations, need reviews.
> +--> More: https://etherpad.openstack.org/p/tripleo-validations-squad-s
> tatus
>
> +---+
> | Networking |
> +---+
>
> +--> No updates this week.
> +--> More: https://etherpad.openstack.org/p/tripleo-networking-squad-st
> atus
>
> +--+
> | Workflows |
> +--+
>
> +--> No updates this week.
> +--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status
>
> +---+
> | Security |
> +---+
>
> +--> Working on Secrets management and Limit TripleO users efforts
> +--> More: https://etherpad.openstack.org/p/tripleo-security-squad
>
> ++
> | Owl fact  |
> ++
> Elf owls live in a cacti. They are the smallest owls, and live in the
> southwestern United States and Mexico. It will sometimes make its home in
> the giant saguaro cactus, nesting in holes made by other animals. However,
> the elf owl isn’t picky and will also live in trees or on telephone poles.
>
> Source: http://mentalfloss.com/article/68473/15-mysterious-facts-abo
> ut-owls
>
> Thank you all for reading and stay tuned!
> --
> Your fellow reporter, Emilien Macchi
>
> __
> 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][nova] - Barbican w/Live Migration in DevStack Multinode

[Walsh, Helen]

Hi OpenStack Community,

I am having some issues with key management in a multinode devstack (from 
master branch 27th July '18) environment where Barbican is the configured 
key_manager.  I have followed setup instructions from the following pages:

  *   https://docs.openstack.org/barbican/latest/contributor/devstack.html 
(manual configuration)
  *   
https://docs.openstack.org/cinder/latest/configuration/block-storage/volume-encryption.html

So far:

  *   Unencrypted block volumes can be attached to instances on any compute node
  *   Instances with unencrypted volumes can also be live migrated to other 
compute node
  *   Encrypted bootable volumes created successfully
  *   Instances can be launched using these encrypted volumes when the instance 
is spawned on demo_machine1 (controller & compute node)
  *   Instances cannot be launched using encrypted volumes when the instance is 
spawned on demo_machine2 or demo_machine3 (compute only), the same failure can 
be seen in nova logs from both compute nodes:

Jul 30 14:35:18 demo_machine2 nova-compute[25686]: DEBUG cinderclient.v3.client 
[None req-3c977faa-a64c-4536-82c8-d1dbaf856b99 admin admin] GET call to 
cinderv3 for 
http://10.0.0.63/volume/v3/3f22a0262a7b4832a08c24ac0295cbd9/volumes/296148bf-edb8-4c9f-88c2-44464907f7e7/encryption
 used request id req-71fa7f20-c0bc-46c3-9f07-5866344d31a1 {{(pid=25686) request 
/usr/local/lib/python2.7/dist-packages/keystoneauth1/session.py:844}}

Jul 30 14:35:18 demo_machine2 nova-compute[25686]: DEBUG os_brick.encryptors 
[None req-3c977faa-a64c-4536-82c8-d1dbaf856b99 admin admin] Using volume 
encryption metadata '{u'cipher': u'aes-xts-plain64', u'encryption_key_id': 
u'da7ee21c-67ff-4d74-95a0-18ee6c25d85a', u'provider': u'luks', u'key_size': 
256, u'control_location': u'front-end'}' for connection: {'status': 
u'attaching', 'detached_at': u'', u'volume_id': 
u'296148bf-edb8-4c9f-88c2-44464907f7e7', 'attach_mode': u'null', 
'driver_volume_type': u'iscsi', 'instance': 
u'e0dc6eac-09bb-4232-bea7-7b8b161cfa31', 'attached_at': 
u'2018-07-30T13:35:17.00', 'serial': 
u'296148bf-edb8-4c9f-88c2-44464907f7e7', 'data': {'device_path': 
'/dev/disk/by-id/scsi-SEMC_SYMMETRIX_900049_wy000', u'target_discovered': True, 
u'encrypted': True, u'qos_specs': None, u'target_iqn': 
u'iqn.1992-04.com.emc:69700bcbb7112504018f', u'target_portal': 
u'192.168.0.60:3260', u'volume_id': u'296148bf-edb8-4c9f-88c2-44464907f7e7', 
u'target_lun': 1, u'access_mode': u'rw'}} {{(pid=25686) get_encryption_metadata 
/usr/local/lib/python2.7/dist-packages/os_brick/encryptors/__init__.py:125}}

Jul 30 14:35:18 demo_machine2 nova-compute[25686]: WARNING 
keystoneauth.identity.generic.base [None 
req-3c977faa-a64c-4536-82c8-d1dbaf856b99 admin admin] Failed to discover 
available identity versions when contacting http://localhost/identity/v3. 
Attempting to parse version from URL.: NotFound: Not Found (HTTP 404)

Jul 30 14:35:18 demo_machine2 nova-compute[25686]: ERROR 
castellan.key_manager.barbican_key_manager [None 
req-3c977faa-a64c-4536-82c8-d1dbaf856b99 admin admin] Error creating Barbican 
client: Could not find versioned identity endpoints when attempting to 
authenticate. Please check that your auth_url is correct. Not Found (HTTP 404): 
DiscoveryFailure: Could not find versioned identity endpoints when attempting 
to authenticate. Please check that your auth_url is correct. Not Found (HTTP 
404)

All instance of Nova have [key_manager] configured as follows:
[key_manager]
backend = barbican
auth_url = http://10.0.0.63/identity/
### Tried with and without the below config options, same result
# auth_type = password
# password = devstack
# username = barbican

Any assistance here would be greatly appreciated, I have spent a lot of time 
looking for some additional information for the use of Barbican in multinode 
devstack environments or with live migration but there is nothing out there, 
everything is for all-in-one environments and I'm not having any issues when 
everything is on one node. I am wondering if at this point there is something I 
am missing in terms of services in a multinode devstack environment, 
qualification of barbican in a multinode environment is outside of the 
recommended test config but following the docs it looks very straight forward.

Some information on the three nodes in my environment are below, if there is 
any other information I can provide let me know, thanks for the help!

Node & Service Breakdown
Node 1 (Controller & Compute)
stack@demo_machine1:~$ openstack service list
+--+-++
| ID   | Name| Type   |
+--+-++
| 43a1334c755c4c81969565097cc9c30c | cinder  | volume |
| 52a8927c09154e33900f24c7c95a9f8b | cinderv2| volumev2   |
| 5427a9dff3b6477197062e1747843c4d | nova_legacy | compute_legacy |
| 

Re: [openstack-dev] [all][Election] Last days for PTL nomination

[Jeremy Stanley]

On 2018-07-30 15:23:57 +0700 (+0700), Luke Hinds wrote:
> Security is a SIG and no longer a project (changed as of rocky cycle).

Technically it's still both at the moment, which is why I proposed
https://review.openstack.org/586896 yesterday (tried to give you a
heads up in IRC about that as well). A +1 from the current PTL of
record on that change would probably be a good idea.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [trove] Considering the transfter of the project leadership

[Dariusz Krol]

Hello Zhao Chao,


after some internal discussion, I will do the nomination if you decided 
not to nominate yourself. Thanks for letting know you will be still 
available in the next release cycle.

Regarding commits I would recommend to consider also 
https://review.openstack.org/#/c/586528/2 .


Best,

Dariusz Krol


On 07/30/2018 03:26 AM, 赵超 wrote:
>
> Since the new folks are still so new - if this works for you - I would
> recommend continuing on as the official PTL for one more release,
> but with the
> understanding that you would just be around to answer questions
> and give advice
> to help the new team get up to speed. That should hopefully be a
> small time
> commitment for you while still easing that transition.
>
> Then hopefully by the T release it would not be an issue at all
> for someone
> else to step up as the new PTL. Or even if things progress well,
> you could step
> down as PTL at some point during the Stein cycle if someone is
> ready to take
> over for you.
>
>
> Sean, thanks a lot for these helpful suggestions.  I thought about 
> doing it this way before writing this post, and this is also the 
> reason I asked the current active team members to nominate theselves.
>
> However, it's sad that the other active team members seems also busy 
> on other thing. So I think it may be better Dariusz and his team could 
> do more than us on the project in the next cycle. I believe they're 
> experience on the project , and all other experiences about the whole 
> OpenStack environment could be more familiar in the daily 
> pariticipation of the project.
>
> On the other hand, I can also understand the lack of time to be a
> PTL since it requires probably a lot of time to coordinate all the
> work. 
>
>
> Dariusz, no, the current team is really a small team, so in fact I 
> didn't need to do much coordination. The pain is that almost none of 
> the current active team member are not focusing Trove, so even thought 
> all of us want to do more progress in this cycle, we're not able to. 
> This also the reason all of us think it's great to have to team 
> focusing on the project could join.
>
> So, we don't have much time on the PTL election now, Dariusz, would 
> you please discuss with your team who will do the nomination. And then 
> we'll see if everything could work. We could also try to merge one the 
> trove-tempest-plugin patches(https://review.openstack.org/#/c/580763/ 
> could be merged first before we get the CI could test all the cases in 
> the repo, sadlly currently we cannot the other patches as they're 
> cannot be tested).
>
> However that patch is submitted by Krzysztof, though is authored by 
> Dariusz. I don't know whether this could count as an identifiied 
> commit when applying PTL nomination.
>
> And last, I want to repeat that, I'll still in the Trove delepoment 
> for quit a long time, so I will help the new PTL and new contributor 
> on everything I could.
>
> Thanks again for everyone who help me a lot in the last cycle, 
> especially Fan Zhang, zhanggang, wangyao, song.jian and Manoj Kumar.
>
> -- 
> To be free as in freedom.

__
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] [Sahara][PTL][Elections] Candidacy for Sahara PTL

[Telles Nobrega]

Hi Saharans, I would like to nominate myself to act as PTL for Sahara
during the Stein cycle.

I've been acting as PTL for the last three cycles (Pike, Queens and Rocky)
and I believe that we had good results and the project improved well during
this time.

Moving forward I plan to continue working on the direction of stabilization
of the project and improvements of user experience.

* Bug triaging:

We need to clean up our bug list. This has been a goal on all last cycles
and we need to continue this work.

* Documentation:

Improvements on documentation is always needed and we had some new features
introduced and we have to make sure that we keep documentation up to date
and user friendly.

* Final APIv2 work

Sadly we didn't finish this in Rocky and for sure we will have to finish in
Stein.

* Modularity

One of the main features planned for Stein is the split of the plugins from
the Sahara code. This will easy the installment and maintenance of Sahara
by deployers.

I hope that I can continue leading the team and help improve Sahara as much
as we can.


-- 

TELLES NOBREGA

SOFTWARE ENGINEER

Red Hat Brasil  

Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo

tenob...@redhat.com

TRIED. TESTED. TRUSTED. 
 Red Hat é reconhecida entre as melhores empresas para trabalhar no Brasil
pelo Great Place to Work.
__
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] Reminder: User Committee @ 1800 UTC

[Melvin Hillsman]

Hi everyone,

UC meeting today in #openstack-uc
Agenda: https://wiki.openstack.org/wiki/Governance/Foundation/UserCommittee

-- 

Kind regards,

Melvin Hillsman

mrhills...@gmail.com
mobile: (832) 264-2646
__
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] [requirements][release] FFE for openstacksdk 0.17.1

[Monty Taylor]

Heya,

I'd like to request a FFE to release 0.17.1 of openstacksdk from 
stable/rocky. The current rocky release, 0.17.0, added a feature (being 
able to pass data directly to an object upload rather that requiring a 
file or file-like object) - but it is broken if you pass an interator 
because it (senselessly) tries to run len() on the data parameter.


The new feature is not used anywhere in OpenStack yet. The first 
consumer (and requestor of the feature) is Infra, who are looking at 
using it as part of our efforts to start uploading build log files to swift.


We should not need a g-r bump - since nothing in OpenStack uses the 
feature yet, none of the OpenStack projects need their depends changed. 
OTOH, openstacksdk is a thing we expect end-users to use, and once they 
see the shiny new feature they might use it - and then be sad that it's 
half broken.


Thanks!
Monty

__
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] non-candidacy for stein

[Mohammed Naser]

Hi everyone,

Unfortunately, I've gotten busy with a few other projects over time
and I won't be able to run PTL for the upcoming Stein cycle.

I'd like to personally thank all of the current Puppet team due to
their help in on-boarding and helping me take on one of my first
leadership experiences inside OpenStack, I'm extremely grateful for
all of it.

I'll continue to be able to do reviews however!

Thank you,
Mohammed

__
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] [election] [openstack-ansible] Candidacy for OpenStack Ansible

[Mohammed Naser]

Hi everyone:

I would like to submit my candidacy to become PTL for the OpenStack Ansible
project for the upcoming Stein cycle.

I have been personally involved in the deployment of OpenStack for many years
now, using all sorts of different deployment tools.  Ansible seems like a
great choice for deployment OpenStack and I've been using OpenStack Ansible
for quite a while now.

As PTL, I hope that I can work with the team to focus on the following:

# CI
- Improve stability of CI for both roles and integrated repo. by using more
  mirrors.
- Start leveraging the integrated repo playbooks inside the role test jobs in
  order to avoid the duplication and test the OpenStack Ansible path
- Once jobs are stable, add integrated jobs to all roles in order to be sure
  that we don't break the integrated repo with role changes.

# Deployment
- Continue to work and finalize the addition of distro installation for all
  distributions.
- Aim to start integrating the `systemd` roles and look into seeing the
  possibility of enabling nspawn and avoiding lxc on CentOS.

There's much more to be done, but those are some of the aspects that would
help in the stability of this project which is what I feel we need to focus
a bit more on.   As a deployment project with a limited scope of the operating
systems needing to exist, there doesn't seem to be much we can come up with
and taking a cycle just to catch up on all the debt, improve stability and
make the maintenance of the project easier is extremely useful.

I hope to work with the team for the upcoming cycle.

Regards,
Mohammed

-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.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

[openstack-dev] [nova]Notification update week 31

[Balázs Gibizer]

Hi,

Here is the latest notification subteam update.

Bugs

No RC potential notification bug is tracked.
No new bug since last week.

Features


We hit FeatureFreeze. Every tracked bp is merged before FF except 
verioned notification transformation. That will be re-proposed to Stein 
to finish up the remaining 7 workitem that is left on the board 
http://burndown.peermore.com/nova-notification/


Weekly meeting
--
The next meeting is planned to be held on 31th of July on 
#openstack-meeting-4

https://www.timeanddate.com/worldclock/fixedtime.html?iso=20180731T17


Cheers,
gibi




__
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] [ironic][pt][election] Announcing candidacy for Ironic PTL

[Julia Kreger]

Greetings!

I have been truly amazed by our accomplishments of the last six months and
I wish to continue this momentum. As such I am announcing my candidacy and
self nomination for the position of Ironic PTL.

I promise to continue the application of irony. This past cycle has been
very eye opening for me and has taught me a lot about the community at large
and the challenges they face. My passion has not wavered and I wish to
continue enhancing ironic's capabilities.

Operators are central to our community, and we need to continue
enhancements that help operators but at the same time we need to
revisit our old ideas and plans.

In a sense we have already started to do this and we need to continue it.
Efforts such as splitting iPXE out of PXE make lots of sense and better
enables mixed hardware and even architecture fleets to co-exist.

My vision for this next cycle is to setup ironic to become the the
defacto API driven hardware provisioning toolkit. This will naturally
mean some more work and we will need to continue with our momentum and focus
on enablement and performance enhancements to improve the user experience.

Thank you for your consideration.

Julia Kreger (TheJulia)

__
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] [neutron] Bug deputy report

[Takashi Yamamoto]

hi,

Here's a report of my week.
I will not attend the neutron meeting due to an overlapping schedule. (sorry!)

Issues I failed to triage.  Needs a help from someone familiar with DVR.
https://bugs.launchpad.net/neutron/+bug/1783470 get_subnet_for_dvr
returns SNAT mac instead of gateway in subnet_info
https://bugs.launchpad.net/neutron/+bug/1783654 DVR process flow not
installed on physical bridge for shared tenant network

Critical
none

High
https://bugs.launchpad.net/neutron/+bug/1783306 Invalid auth url

Medium
https://bugs.launchpad.net/neutron/+bug/1782421
https://bugs.launchpad.net/neutron/+bug/1782421
https://bugs.launchpad.net/neutron/+bug/1780453 openvswitch-agent
doesn't try to rebind "binding_failed" ports on startup anymore
https://bugs.launchpad.net/neutron/+bug/1783908 dnsmasq does not
remove leases for deleted VMs - leases and host files point to
different MACS
https://bugs.launchpad.net/neutron/+bug/1783965 Openvswtich agent
break the existing data plane as not stable server
https://bugs.launchpad.net/neutron/+bug/1783968 ovs agent failed to
continue to process devices if one of them are failed
https://bugs.launchpad.net/neutron/+bug/1783378 Following protocol 73
name change , neutron constants have to be updated too
https://bugs.launchpad.net/neutron/+bug/1780883 FWAAS V1： Add or
remove firewall rules, caused the status of associated firewall
becomes "PENDING_UPDATE"
https://bugs.launchpad.net/neutron/+bug/1784006 Instances miss neutron
QoS on their ports after unrescue and soft reboot

Incomplete
https://bugs.launchpad.net/neutron/+bug/1781372 Neutron security group
resource logging presents in ovs-agent.log
https://bugs.launchpad.net/neutron/+bug/1783261
Neutron-LBaaS v2: create loadbalance of 5 listeners, and add members
to each pool, cost about 1 hour
https://bugs.launchpad.net/neutron/+bug/1779334 neutron-vpnaas doesn't
support local tox targets
https://bugs.launchpad.net/neutron/+bug/1779194 neutron-lbaas haproxy
agent, when configured with allow_automatic_lbaas_agent_failover =
True, after failover, when the failed agent restarts or reconnects to
RabbitMQ, it tries to unplug the vif port without checking if it is
used by other agent
https://bugs.launchpad.net/neutron/+bug/1778735 floatingip not found
404 PecanNotFound
https://bugs.launchpad.net/neutron/+bug/1783330 Logging - Error
message is not correct in creating network log with incorrect
'resource_type'
https://bugs.launchpad.net/neutron/+bug/1780407 There are some errors
in neutron_l3_agent and neutron_dhcp_agent after restarting open
vswitch with dpdk
https://bugs.launchpad.net/neutron/+bug/1784342 AttributeError:
'Subnet' object has no attribute '_obj_network_id'

Duplicate
https://bugs.launchpad.net/neutron/+bug/1783534 Install and configure
OpenStack Neutron for Ubuntu

For those who read this boring mail up to here:
https://review.openstack.org/#/c/586488/ Bug deputy routines for dummies

__
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] keypair quota usage info for user

[Ghanshyam Mann]

  On Sat, 28 Jul 2018 04:21:53 +0900 Matt Riedemann  
wrote  
 > On 7/27/2018 2:14 PM, Matt Riedemann wrote:
 > >>  From checking the history and review discussion on [3], it seems that 
 > >> it was like that from staring. key_pair quota is being counted when 
 > >> actually creating the keypair but it is not shown in API 'in_use' field.
 > > 
 > > Just so I'm clear which API we're talking about, you mean there is no 
 > > totalKeypairsUsed entry in 
 > > https://developer.openstack.org/api-ref/compute/#show-rate-and-absolute-limits
 > >  
 > > correct?
 > 
 > Nevermind I see it now:
 > 
 > https://developer.openstack.org/api-ref/compute/#show-the-detail-of-quota

Yeah, 'is_use' field under 'keypair' of this API. 

 > 
 > We have too many quota-related APIs.
 > 
 > -- 
 > 
 > Thanks,
 > 
 > Matt
 > 
 > __
 > 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-dev] [trove] Considering the transfter of the project leadership

[Thierry Carrez]

Dariusz Krol wrote:

[...]
On the other hand, I can also understand the lack of time to be a PTL 
since it requires probably a lot of time to coordinate all the work.


Let’s wait for Chao Zhao to give his opinion on the topic :)


If the PTL delegates the most time-intensive work (release liaison, 
meeting chair...) then it should not be too much extra work.


PTLs are responsible by default for a lot of things in their projects, 
but all of those things can be delegated to others.


--
Thierry Carrez (ttx)

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

[openstack-dev] [all][Election] candidacy for Tricircle PTL Stein cycle

[linghucongsong]

Hi all!

I would like to announce myself nomination for the PTL candidacy in
Tricircle Stein cycle. My name is Baisen Song, and my IRC handle is
songbaisen. I am currently the Core Member of Tricircle for Rocky cycle and have
been the most actively participating in the development of this project since
last year. I and my team have finished the most BluePrints in Tricircle.

During the Rocky cycle, we begin to bring enable mutable configuration to
Tricircle, network deletion reliability, reuse the deleted port after the
vm have been deleted and recreated in another region, add service function
chain support. We also start to implement the new l3 networking model.

For the coming Stein cycle, here are some works we can focus on:

* Driver based implementation of Trunk, current implementation is plugin-based.
* Implement the new cross-Neutron L3 networking model that doesn't
  depend on host routes.
* Improvement the Tricircle work with nova cell2.
* Add more unit and smoke test cases.
* Make Trio2o and Tricircle work more close together.

Thank you for taking the time to consider me for Stein PTL.

Hope everyone will enjoy joining the Tricircle.__
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][Election] Last days for PTL nomination

[Luke Hinds]

Hi,

Security is a SIG and no longer a project (changed as of rocky cycle).

Regards

Luke

On Mon, 30 Jul 2018, 08:36 Tony Breeds,  wrote:

> Hello all,
>
> A quick reminder that we are in the last hours for PTL candidate
> nominations.
>
> If you want to stand for PTL, don't delay, follow the instructions
> at [1] to make sure the community knows your intentions.
>
> Make sure your nomination has been submitted to the openstack/election
> repository and approved by election officials.
>
> Election statistics[2]:
> Nominations started   @ 2018-07-24 23:45:00 UTC
> Nominations end   @ 2018-07-31 23:45:00 UTC
> Nominations duration  : 7 days, 0:00:00
> Nominations remaining : 1 day, 22:12:07
> Nominations progress  :  72.50%
> ---
> Projects[2]   :65
> Projects with candidates  :29 ( 44.62%)
> Projects with election: 0 (  0.00%)
> ---
> Need election : 0 ()
> Need appointment  : 36 (Adjutant Blazar Cinder Designate
> Documentation Dragonflow Freezer Horizon
> Ironic Kolla Loci Manila Masakari
> Monasca Nova Octavia OpenStackAnsible
> OpenStackClient OpenStack_Helm Oslo
> Packaging_Rpm Puppet_OpenStack Qinling
> Rally RefStack Sahara Searchlight
> Security Solum Storlets Trove Vitrage
> Watcher Winstackers Zaqar Zun)
> ===
> Stats gathered@ 2018-07-30 01:32:53 UTC
>
>
> This means that with approximately 2 days left, 39 projects will
> be deemed leaderless.  In this case the TC will oversee PTL selection as
> described by [3].
>
> Thank you,
>
> [1] http://governance.openstack.org/election/#how-to-submit-your-candidacy
> [2] Assuming the open reviews below are validated
> https://review.openstack.org/#/q/is:open+project:openstack/election
> Which ATM includes:
> Magnum Tacker OpenStack_Charms Neutron Manilla Tripleo Barbican
> Murano
> [3]
> http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html
>
> Yours Tony.
> __
> 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] [openstack-ansible] Proposing Jonathan Rosser as core reviewer

[jean-philippe]

Hello everyone,

I'd like to propose Jonathan Rosser (jrosser) as core reviewer for 
OpenStack-Ansible.
The BBC team [1] has been very active recently across the board, but worked 
heavily in our ops repo, making sure the experience is complete for operators.

I value Jonathan's opinion (I remember the storage backend conversations for 
lxc/systemd-nspawn!), and I'd like this positive trend to continue. On top of 
it Jonathan has been recently reviewing quite a series of patches, and is 
involved into some of our important work: bringing the Bionic support.

Best regards,
Jean-Philippe Evrard (evrardjp)

[1]: 
http://stackalytics.com/?project_type=openstack=rocky=commits=BBC


__
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] [openstack-ansible] Using jmespath more

[jean-philippe]

Hello,

According to the readability test here [1], contributors prefer reading a task 
like the following:

- name: Fail if service was deployed using a different installation method
  fail:
msg: "Switching installation methods for OpenStack services is not 
supported"
  when:
- ansible_local is defined
- ansible_local.openstack_ansible is defined
- ansible_local.openstack_ansible.aodh is defined
- ansible_local.openstack_ansible.aodh.install_method is defined
- ansible_local.openstack_ansible.aodh.install_method != aodh_install_method

as:

- name: Fail if service was deployed using a different installation method
  fail:
msg: "Switching installation methods for OpenStack services is not 
supported"
  when:
- (ansible_local | json_query("openstack_ansible.aodh.install_method")) is 
not ""
- ansible_local.openstack_ansible.aodh.install_method != aodh_install_method

(Short explanation, json_query returns an empty string if path is not found, 
instead of having
an ansible failure, which is very welcomed. In the case above, if everything is 
defined, there will
be no empty string, and we can compare the string contents with the second when 
condition).

Another example avoiding the "is defined" dance:
Checking if install_method IS equal to "source" in the local facts could be 
simplified to:
when:
  - (ansible_local | json_query("openstack_ansible.aodh.install_method")) == 
'source'

I hope this will inspire people to refactor some tedious to read tasks into 
more readable ones.
Thanks for your contributions!

Best regards,
Jean-Philippe Evrard (evrardjp)

[1]: https://etherpad.openstack.org/p/osa-readability-test


__
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] [i18n] Edge and Containers whitepapers ready for translation

[Frank Kloeker]

Hi Jimmy,

Korean and German version are now done on the new format. Can you check 
publishing?


thx

Frank

Am 2018-07-19 16:47, schrieb Jimmy McArthur:

Hi all -

Follow up on the Edge paper specifically:
https://translate.openstack.org/iteration/view/edge-computing/pot-translation/documents?dswid=-3192

This is now available. As I mentioned on IRC this morning, it should
be VERY close to the PDF.  Probably just needs a quick review.

Let me know if I can assist with anything.

Thank you to i18n team for all of your help!!!

Cheers,
Jimmy

Jimmy McArthur wrote:

Ian raises some great points :) I'll try to address below...

Ian Y. Choi wrote:

Hello,

When I saw overall translation source strings on container 
whitepaper, I would infer that new edge computing whitepaper

source strings would include HTML markup tags.
One of the things I discussed with Ian and Frank in Vancouver is the 
expense of recreating PDFs with new translations.  It's prohibitively 
expensive for the Foundation as it requires design resources which we 
just don't have.  As a result, we created the Containers whitepaper in 
HTML, so that it could be easily updated w/o working with outside 
design contractors.  I indicated that we would also be moving the Edge 
paper to HTML so that we could prevent that additional design resource 
cost.

On the other hand, the source strings of edge computing whitepaper
which I18n team previously translated do not include HTML markup 
tags, since the source strings are based on just text format.
The version that Akihiro put together was based on the Edge PDF, which 
we unfortunately didn't have the resources to implement in the same 
format.


I really appreciate Akihiro's work on RST-based support on publishing 
translated edge computing whitepapers, since

translators do not have to re-translate all the strings.
I would like to second this. It took a lot of initiative to work on 
the RST-based translation.  At the moment, it's just not usable for 
the reasons mentioned above.

On the other hand, it seems that I18n team needs to investigate on
translating similar strings of HTML-based edge computing whitepaper 
source strings, which would discourage translators.
Can you expand on this? I'm not entirely clear on why the HTML based 
translation is more difficult.


That's my point of view on translating edge computing whitepaper.

For translating container whitepaper, I want to further ask the 
followings since *I18n-based tools*
would mean for translators that translators can test and publish 
translated whitepapers locally:


- How to build translated container whitepaper using original 
Silverstripe-based repository?
  https://docs.openstack.org/i18n/latest/tools.html describes well 
how to build translated artifacts for RST-based OpenStack 
repositories
  but I could not find the way how to build translated container 
whitepaper with translated resources on Zanata.
This is a little tricky.  It's possible to set up a local version of 
the OpenStack website 
(https://github.com/OpenStackweb/openstack-org/blob/master/installation.md). 
 However, we have to manually ingest the po files as they are 
completed and then push them out to production, so that wouldn't do 
much to help with your local build.  I'm open to suggestions on how we 
can make this process easier for the i18n team.


Thank you,
Jimmy



With many thanks,

/Ian

Jimmy McArthur wrote on 7/17/2018 11:01 PM:

Frank,

I'm sorry to hear about the displeasure around the Edge paper.  As 
mentioned in a prior thread, the RST format that Akihiro worked did 
not work with the  Zanata process that we have been using with our 
CMS.  Additionally, the existing EDGE page is a PDF, so we had to 
build a new template to work with the new HTML whitepaper layout we 
created for the Containers paper. I outlined this in the thread " 
[OpenStack-I18n] [Edge-computing] [Openstack-sigs] Edge Computing 
Whitepaper Translation" on 6/25/18 and mentioned we would be ready 
with the template around 7/13.


We completed the work on the new whitepaper template and then put 
out the pot files on Zanata so we can get the po language files 
back. If this process is too cumbersome for the translation team, 
I'm open to discussion, but right now our entire translation process 
is based on the official OpenStack Docs translation process outlined 
by the i18n team: 
https://docs.openstack.org/i18n/latest/en_GB/tools.html


Again, I realize Akihiro put in some work on his own proposing the 
new translation type. If the i18n team is moving to this format 
instead, we can work on redoing our process.


Please let me know if I can clarify further.

Thanks,
Jimmy

Frank Kloeker wrote:

Hi Jimmy,

permission was added for you and Sebastian. The Container 
Whitepaper is on the Zanata frontpage now. But we removed Edge 
Computing whitepaper last week because there is a kind of 
displeasure in the team since the results of translation are still 
not published beside Chinese 

[openstack-dev] [watcher] PTL on vacation

[Чадин Александр Сергеевич]

Hi all,

I'll be on vacation until  August 10th and am 
available for emails.

P.S. My candidacy for Stein cycle will be submitted this evening.

Best wishes

Alex
__
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][Election] candidacy for Zaqar PTL Stein cycle

[hao wang]

Hi all,

This is my self-nomination to continue running as Zaqar PTL for the Stein cycle.

We did a great job in Rocky. Supported the different format of client id to be
more suitable for more use cases. We also introduced the function to query
queues filtered by name and metadata in mongodb backend.

For Stein release, I want to finish the list of jobs below.

1. Refactoring
   We want to remove useless pool group totally in Stein and make the model of
   pool and flavor more clear.

2. Scalability
   We will continue our work to improve Zaqar's performance under the different
   cases of load increasing:
   1) number of publishers
   2) number of subscribers
   3) rate of messages published or consumed
   4) number of messages
   5) number of queues
   6) size of messages

3. Usability
   We still have some works that inherit from Rocky. Those tasks contain very
   useful features:
   1) Introduce a new resource for queue's metadata
   2) Introduce topic resource for notification
   3) Delete message with claim ID
   4) Send Email subscription by Zaqar

Thanks for your consideration!

__
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