Re: [openstack-dev] [octavia] Proposing Nir Magnezi as Octavia core reviewer

[Numan Siddique]

Congratulations Nir

On Oct 12, 2017 5:19 AM, "Tong Liu"  wrote:

> Congratulations Nir!
>
> On Tue, Oct 10, 2017 at 1:36 PM, Nir Magnezi  wrote:
>
>> Thanks everyone for your votes :-)
>> I'm really happy to become a member of this great team!
>>
>> Nir
>>
>> On Tue, Oct 10, 2017 at 1:28 AM, Michael Johnson 
>> wrote:
>>
>>> Ok, that is quorum.
>>>
>>> Congratulations Nir!
>>>
>>> Michael
>>>
>>>
>>> On Mon, Oct 9, 2017 at 3:18 PM, Adam Harwell 
>>> wrote:
>>> > +1
>>> >
>>> >
>>> > On Thu, Oct 5, 2017, 05:48 Daniel Mellado 
>>> > wrote:
>>> >>
>>> >> +1
>>> >>
>>> >> Go, Nir, Go!
>>> >>
>>> >> congrats!
>>> >>
>>> >> On 10/05/2017 03:51 AM, German Eichberger wrote:
>>> >> > +1
>>> >> >
>>> >> > Welcome Nir, well earned.
>>> >> >
>>> >> > German
>>> >> >
>>> >> > On 10/4/17, 4:28 PM, "Michael Johnson"  wrote:
>>> >> >
>>> >> > Hello OpenStack folks,
>>> >> >
>>> >> > I would like to propose Nir Magnezi as a core reviewer on the
>>> >> > Octavia project.
>>> >> >
>>> >> > He has been an active contributor to the Octavia projects for a
>>> few
>>> >> > releases and has been providing solid patch review comments. His
>>> >> > review stats are also in line with other core reviewers.
>>> >> >
>>> >> > Octavia cores, please reply to this e-mail with your
>>> >> > agreement/disagreement to this proposal.
>>> >> >
>>> >> > Michael
>>> >> >
>>> >> >
>>> >> > 
>>> __
>>> >> > 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/opensta
>>> ck-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.op
>>> enstack.org?subject:unsubscribe
>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>> >
>>> > 
>>> __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Zuul v3 Rollout Update - devstack-gate issues edition

[Ian Wienand]

There are still significant issues

- logs issues

Should be behind us.  The logs partition ran out of inodes, causing
log upload failures.  Pruning jobs should have rectified this.

- Ubuntu package issues

You may notice a range of issues with Ubuntu packages.  The root cause
is that our mirror is behind due a broken reprepro.  Unfortunately, we
build our daily images against an external upstream mirror, so they
have been built using later packages than our un-updated region
mirrors provide, leading apt to great confusion.  Some debugging notes
on reprepro at [1], but I have to conclude the .db files are corrupt
and I have no idea how to recreate these other than to start again.

I think the most expedient solution here will be to turn /ubuntu on
mirrors into a caching reverse proxy for upstream.  However;

- system-config breakage

The system-config gate is broken due to an old pip pin with [2].
However, despite this merging several hours ago, zuulv2 doesn't seem
to want to reload to pick this up.  I have a suspicion that because it
was merged by zuulv3 maybe zuulv2 missed it?  I'm not sure, and don't
think even turning the jobs -nv will help.

- devstack-gate cache copying

This means the original devstack-gate cache issues [3] remain unmerged
at this point.

[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2017-10-12.log.html#t2017-10-12T04:04:16
[2] https://review.openstack.org/511360
[3] https://review.openstack.org/511260

-i

__
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] IBM z/VM CI asks for reporting permission to Nova changes

[Xiao Mei GZ Zheng]

Hello,

I'm requesting reporting permission (non-voting) to Nova changes for the
IBM z/VM CI. The wiki is on link [1].

We designed the CI using nodepool , zuul and Jenkins. The newly uploaded
patches will receive an initial +/-1 reports from Jenkins only for the nova
project (just comments on patches but not vote on them). Tests completed on
the z/VM Driver CI system check-nova pipeline. For more information see[2].
To recheck it, you just submit a comment with only zvm:recheck in the
comment.

The IBM z/VM CI system has been running for a long time in a stable
fashion. We present all test artifacts on a public link [3] to make
debugging failed tests easier. You can see environment details, openstack
logs and tempest logs.

* Gerrit Account: zvmosci

* Gerrit query on patches where the CI commented: [4]

* Proposal for naming: IBM z/VM CI

For any questions feel free to reach out to me (Laurene) or to Leon!

[1] https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_z/VM_CI

[2] https://wiki.openstack.org/wiki/ZVMDriver/zVM-CI


[3] http://extbasicopstackcilog01.podc.sl.edst.ibm.com/ci_status/


[4] https://review.openstack.org/#/c/410596/

Thanks & Best Regards!

Laurene(Xiao Mei) Zheng

Software developer,  CSTL
IBM China Systems & Technology Lab (CSTL)
__
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] [Zaqar] Nominating gecong for Zaqar core

[王玺源]

+1.

2017-10-12 8:53 GMT+08:00 hao wang :

> +1
> I'm very exciting to hear this. gecong is an great contributor in
> Zaqar project,  hope we can work together to make more awesome
> features done in Zaqar.
>
> 2017-10-11 15:41 GMT+08:00 Thomas Herve :
> > On Tue, Oct 10, 2017 at 11:15 PM, feilong 
> wrote:
> >> Hi team,
> >>
> >> I would like to propose adding Cong Ge(gecong) for the Zaqar core team.
> >> He has been an awesome contributor since joining the Zaqar team. And now
> >> he is currently the most active non-core reviewer on Zaqar projects for
> >> the last 180 days[1]. Cong has great technical expertise and contributed
> >> many high quality patches. I'm sure he would be an excellent addition to
> >> the team. If no one objects, I'll proceed and add him in a week from
> >> now. Thanks.
> >
> > +1!
> >
> > --
> > Thomas
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Can swift leverage os page buffer?

[Clay Gerrard]

On Wed, Oct 11, 2017 at 3:46 PM, Jialin Liu  wrote:

> Hi,
> I'm new to openstack swift, I'm a HPC user, by several days of exploration
> of swift, I have some naive questions:
> 1. Can swift, e.g., PUT, leverage OS' page buffer?;
>

Sure, but perhaps to a limited degree depending on what you're expecting?
We try pretty hard to fsync everything before we return success:

https://github.com/openstack/swift/blob/master/swift/obj/diskfile.py#L1517

^ and just below that is _finalize_put


> Is there a Linux kernel module for swift?
>

No.


> What are the existing optimizations for caching the write in order to gain
> better bandwidth on spin disks?
>

... um ... that's a pretty broad question, swift has been around for quite
a while, it would require some research.  You can read through the diskfile
modules; most of the bits that touch disk at the object layer are in
there.  There's a number of tunables that effect how Swift will treat the
filesystem - and the low-level specifics of what they do are in the code.
Any results of rigorous classifications you perform and want to publish are
always interesting and welcome in the community.  There's been a few
interesting things published over the years - but there's no been no
community effort to collect them into a single home that I'm aware of;
you'd have to track them down - I recall Seagate did some interesting
analysis a while back.  RedHat's performance group is always doing stuff,
Intel did some stuff.  Current community efforts are focused on further
refining erasure code storage - which have a positive impact on medium and
large object uploads both by reducing the total number of backend bytes to
store (compared to replicated object) and also by fanning that object data
+ parity out to larger numbers of spindles on the backend.  On the other
end of the spectrum OVH is leading an effort to further improve performance
for lots of small files.

2. Does swift support asynchronous PUT/Get?
>
>
I don't know what that means, so I'll say no.  I might hazard a guess it
has something to do with a PUT only storing some reduced redundancy unsafe
staged data and then doing something to improve durability after it already
promised the client their write was "safe" - which is not something Swift
does.


>
> Also please let me know if the dev list is good for me to ask this kind of
> questions.
>

The ML is nice in that people can give more detailed responses and the
archives tend to be a bit more searchable - the trade off is a longer
latency on responses.  You can also jump on IRC - swift folks hang out in
#openstack-swift on freenode.

Best Regards,

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

Re: [openstack-dev] [Zaqar] Nominating gecong for Zaqar core

[hao wang]

+1
I'm very exciting to hear this. gecong is an great contributor in
Zaqar project,  hope we can work together to make more awesome
features done in Zaqar.

2017-10-11 15:41 GMT+08:00 Thomas Herve :
> On Tue, Oct 10, 2017 at 11:15 PM, feilong  wrote:
>> Hi team,
>>
>> I would like to propose adding Cong Ge(gecong) for the Zaqar core team.
>> He has been an awesome contributor since joining the Zaqar team. And now
>> he is currently the most active non-core reviewer on Zaqar projects for
>> the last 180 days[1]. Cong has great technical expertise and contributed
>> many high quality patches. I'm sure he would be an excellent addition to
>> the team. If no one objects, I'll proceed and add him in a week from
>> now. Thanks.
>
> +1!
>
> --
> Thomas
>
> __
> 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] [ptls] Sydney Forum Project Onboarding Rooms

[Sam P]

Hi Kendall,
 Thank you..
--- Regards,
Sampath



On Thu, Oct 12, 2017 at 1:57 AM, Kendall Nelson  wrote:
> Hello :)
>
> Congrats! I added you/Masakari to my list.
>
> -Kendall (diablo_rojo)
>
> On Wed, Oct 11, 2017 at 12:28 AM Sam P  wrote:
>>
>> Hi Kendall,
>>
>>  Thank you for info.
>>  If slots are still available, we would like to do an On-boarding
>> session for Masakari [1].
>>  # BTW, got the TC approval yesterday [2]...
>>
>>
>> [1] https://wiki.openstack.org/wiki/Masakari
>> [2] https://review.openstack.org/#/c/500118/
>> --- Regards,
>> Sampath
>>
>>
>>
>> On Wed, Oct 11, 2017 at 5:12 AM, Kendall Nelson 
>> wrote:
>> > Of course :) I added Designate.
>> >
>> > -Kendall Nelson(diablo_rojo)
>> >
>> >
>> > On Tue, Oct 10, 2017 at 1:01 PM Graham Hayes  wrote:
>> >>
>> >> Can I add designate? I will be there to look after the room.
>> >>
>> >> Thanks,
>> >>
>> >> Graham
>> >>
>> >>
>> >> On Tue, 10 Oct 2017, at 20:20, Kendall Nelson wrote:
>> >>
>> >> Added :)
>> >> -Kendall (diablo_rojo)
>> >>
>> >> On Tue, Oct 10, 2017 at 2:11 AM Spyros Trigazis 
>> >> wrote:
>> >>
>> >> Magnum - Spyros Trigazis - 
>> >>
>> >> Thanks!
>> >>
>> >> On 9 October 2017 at 23:24, Kendall Nelson 
>> >> wrote:
>> >> > Wanted to keep this thread towards the top of inboxes for those I
>> >> > haven't
>> >> > heard from yet.
>> >> >
>> >> > About a 1/4 of the way booked, so there are still slots available!
>> >> >
>> >> > -Kendall (diablo_rojo)
>> >> >
>> >> >
>> >> > On Thu, Oct 5, 2017 at 8:50 AM Kendall Nelson 
>> >> > wrote:
>> >> >>
>> >> >> Hello :)
>> >> >>
>> >> >> We have a little over 40 slots available so we should be able to
>> >> >> accommodate almost everyone, but it will be a first response first
>> >> >> serve
>> >> >> basis.
>> >> >>
>> >> >> Logistics: Slots are 40 min long and will have projection set up in
>> >> >> them.
>> >> >> The rooms have a capacity of about 40 people and will be set up
>> >> >> classroom
>> >> >> style.
>> >> >>
>> >> >> If you are interested in reserving a spot, just reply directly to me
>> >> >> and I
>> >> >> will put your project on the list. Please let me know if you want
>> >> >> one
>> >> >> and
>> >> >> also include the names and emails anyone that will be speaking with
>> >> >> you.
>> >> >>
>> >> >> When slots run out, they run out.
>> >> >>
>> >> >> Thanks!
>> >> >>
>> >> >> -Kendall Nelson (diablo_rojo)
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > __
>> >> > OpenStack Development Mailing List (not for usage questions)
>> >> > Unsubscribe:
>> >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >> >
>> >>
>> >>
>> >> __
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >>
>> >> __
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >>
>> >> __
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> 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] [octavia] Proposing Nir Magnezi as Octavia core reviewer

[Tong Liu]

Congratulations Nir!

On Tue, Oct 10, 2017 at 1:36 PM, Nir Magnezi  wrote:

> Thanks everyone for your votes :-)
> I'm really happy to become a member of this great team!
>
> Nir
>
> On Tue, Oct 10, 2017 at 1:28 AM, Michael Johnson 
> wrote:
>
>> Ok, that is quorum.
>>
>> Congratulations Nir!
>>
>> Michael
>>
>>
>> On Mon, Oct 9, 2017 at 3:18 PM, Adam Harwell  wrote:
>> > +1
>> >
>> >
>> > On Thu, Oct 5, 2017, 05:48 Daniel Mellado 
>> > wrote:
>> >>
>> >> +1
>> >>
>> >> Go, Nir, Go!
>> >>
>> >> congrats!
>> >>
>> >> On 10/05/2017 03:51 AM, German Eichberger wrote:
>> >> > +1
>> >> >
>> >> > Welcome Nir, well earned.
>> >> >
>> >> > German
>> >> >
>> >> > On 10/4/17, 4:28 PM, "Michael Johnson"  wrote:
>> >> >
>> >> > Hello OpenStack folks,
>> >> >
>> >> > I would like to propose Nir Magnezi as a core reviewer on the
>> >> > Octavia project.
>> >> >
>> >> > He has been an active contributor to the Octavia projects for a
>> few
>> >> > releases and has been providing solid patch review comments. His
>> >> > review stats are also in line with other core reviewers.
>> >> >
>> >> > Octavia cores, please reply to this e-mail with your
>> >> > agreement/disagreement to this proposal.
>> >> >
>> >> > Michael
>> >> >
>> >> >
>> >> > 
>> __
>> >> > 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/opensta
>> ck-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.op
>> enstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> 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] Can swift leverage os page buffer?

[Jialin Liu]

Hi,
I'm new to openstack swift, I'm a HPC user, by several days of exploration
of swift, I have some naive questions:
1. Can swift, e.g., PUT, leverage OS' page buffer?; Is there a Linux kernel
module for swift? What are the existing optimizations for caching the write
in order to gain better bandwidth on spin disks?
2. Does swift support asynchronous PUT/Get?


Also please let me know if the dev list is good for me to ask this kind of
questions.

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

Re: [openstack-dev] [cinder][nova][castellan] Toward deprecating ConfKeyManager

[Duncan Thomas]

I'm not sure there's a general agreement about removing the fixed key
manager code in future. It serves several purposes, testing being the most
significant one, though it also covers some people's usecase from a
security PoV too where something better might not be worth the complexity
trade off. If this work is a backdoor effort to remove the functionality,
rather than purely a code cleanup effort then it should definitely be
clearly presented as such.

On 11 Oct 2017 9:50 pm, "Alan Bishop"  wrote:

> On Wed, Oct 11, 2017 at 1:17 PM, Dave McCowan (dmccowan)
>  wrote:
> > Hi Alan--
> > Since a fixed-key implementation is not secure, I would prefer not
> > adding it to Castellan.  Our desire is that Castellan can be a
> best-practice
> > project to encourage operators to use key management securely.
> > I'm all for consolidating code and providing good migration paths
> from
> > ConfKeyManager to Castellan.
> > Can we create a new oslo project to facilitate this?  Something like
> > oslo.fixed_key_manager.
> > I would rather keep a fixed_key implementation out of Castellan if
> > possible.
>
> Hi Dave,
>
> While I totally take your point about keeping the "deficient" (I'm being
> charitable) ConfKeyManager code out of Castellan, I view it as a short
> term tactical move. Everyone is looking forward to deprecating the code.
> The key (no pun intended) to getting there is providing a migration path
> for users (there are significant ones) that have existing deployments
> that use the fixed-key.
>
> Because of the circumstances, I feel there would be resistance to the
> idea of creating an entirely new oslo project that; a) consists of code
> that everyone knows to be deficient, and b) will be deprecated soon.
>
> I have another motive for temporarily moving the code into Castellan,
> and it pertains to providing a migration path to Barbican. With everything
> consolidated in Castellan, a wrapper class could provide a seamless way
> of handling KeyManager.get() requests for the all-zeros fixed-key ID,
> even when Barbican is the key manager. This would allow users to switch
> to Barbican, and still have any get() requests for the legacy fixed-key
> be resolved by the ConfKeyManager.
>
> All of this could be implemented wholely within Castellan, and be totally
> transparent to the the user, Nova, Cinder, and the Barbican implementation
> in barbican_key_manager.py.
>
> As a final note, we could add all sorts of warnings any to code added
> to Castellan, perhaps even name the file insecure_key_manager.py ;-)
>
> Alan
>
>
> > --Dave
> >
> > There is an ongoing effort to deprecate the ConfKeyManager, but care
> > must be taken when migrating existing ConfKeyManager deployments to
> > Barbican. The ConfKeyManager's fixed_key secret can be added to Barbican,
> > but the process of switching from one key manager to another will need
> > to be done smoothly to ensure encrypted volumes continue to function
> > during the migration period.
> >
> > One thing that will help the migration process is consolidating the
> > two ConfKeyManager implementations (one in Cinder and one in Nova).
> > The two are functionally identical, as dictated by the need to derive
> > the exact same secret from the fixed_key. While it may seem counter-
> > intuitive, adding a ConfKeyManager implementation to Castellan will
> > facilitate the process of deprecating them in Cinder and Nova.
> >
> > To that end, I identified a series of small steps to get us there:
> >
> > 1) Unify the "fixed_key" oslo_config definitions in Cinder and Nova
> > so they are identical (right now their help texts are slightly
> > different). This step avoids triggering a DuplicateOptError exception
> > in the next step.
> >
> > 2) Add a ConfKeyManager implementation to Castellan. This essentially
> > involves copying in one of the existing implementations (either Cinder's
> > or Nova's).
> >
> > 3) Replace Cinder's and Nova's implementations with references to the
> > one in Castellan. This can be done in a way that retains compatibility
> > with the key_manager "backend" (was "api_class") config options
> > currently used by Cinder and Nova. The code in
> > cinder/keymgr/conf_key_manager.py and nova/keymgr/conf_key_manager.py
> > will collapse down to this:
> >
> >   from castellan.key_manager import conf_key_manager
> >
> >   class ConfKeyManager(conf_key_manager.ConfKeyManager):
> >   pass
> >
> > Having a common ConfKeyManager implementation will make it much
> > easier to support migrating things to Barbican, and that's an important
> > step toward the goal of deprecating the ConfKeyManager entirely.
> >
> > Please let me know your thoughts, as I plan to begin proposing patches.
> >
> > Regards,
> >
> > Alan Bishop
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: 

[openstack-dev] [tripleo] TripleO CI end of sprint status

[Arx Cruz]

Sorry, I forgot to add [tripleo] tag.


Hello,

On October 10 we came to our first end of sprint using our new team
structure [1], and here’s the highlights:

TripleO CI Infra meeting notes:


   -

   Zuul v3 related patch:
   -

  The new Zuul v3 doesn’t have the cirros image cached, so we have a
  patch to change the tempest image to default value, that is download the
  image from cirros website.
  -

 https://review.openstack.org/510839
 -

   Zuul migration
   -

  There will have an outage in order to fix some issues found during
  the Zuul migration to v3
  -

 http://lists.openstack.org/pipermail/openstack-dev/2017-
 October/123337.html
 -

   Job for migration
   -

  We are planning to start moving some jobs rom rh1 cloud to rdo cloud.
  -

   RDO Software Factory outage
   -

  There were an outage on RDO cloud on October 9, some jobs were
  stalled for a long time, now everything is working.


Sprint Review:

The sprint epic was utilizing the DLRN api across TripleO and RDO [2] to
report job status and promotions, and we set several tasks in 20 cards, and
I am glad to report that we were able to complete 19 cards! Some of these
cards generate some tech debts, and after a review, we got 11 card in the
tech debt list, plus 3 new bugs opened and XYZ bugs closed by the Ruck and
Rover.

One can see the results of the sprint via https://tinyurl.com/yblqs5z2

Below the list of new bugs related to the work completed in the sprint:


   -

   https://bugs.launchpad.net/tripleo/+bug/1722552
   -

   https://bugs.launchpad.net/tripleo/+bug/1722554
   -

   https://bugs.launchpad.net/tripleo/+bug/1722558


And here the list of what was done by the Ruck and Rover:

   -

   https://bugs.launchpad.net/tripleo/+bug/1722640
   -

   https://bugs.launchpad.net/tripleo/+bug/1722621
   -

   https://bugs.launchpad.net/tripleo/+bug/1722596
   -

   https://bugs.launchpad.net/tripleo/+bug/1721790
   -

   https://bugs.launchpad.net/tripleo/+bug/1721366
   -

   https://bugs.launchpad.net/tripleo/+bug/1721134
   -

   https://bugs.launchpad.net/tripleo/+bug/1720556
   -

   https://bugs.launchpad.net/tripleo/+bug/1719902
   -

   https://bugs.launchpad.net/tripleo/+bug/1719421



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

[2] https://trello.com/c/5FnfGByl
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] TripleO CI end of sprint status

[Arx Cruz]

Hello,

On October 10 we came to our first end of sprint using our new team
structure [1], and here’s the highlights:

TripleO CI Infra meeting notes:


   -

   Zuul v3 related patch:
   -

  The new Zuul v3 doesn’t have the cirros image cached, so we have a
  patch to change the tempest image to default value, that is download the
  image from cirros website.
  -

 https://review.openstack.org/510839
 -

   Zuul migration
   -

  There will have an outage in order to fix some issues found during
  the Zuul migration to v3
  -


 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123337.html
 -

   Job for migration
   -

  We are planning to start moving some jobs rom rh1 cloud to rdo cloud.
  -

   RDO Software Factory outage
   -

  There were an outage on RDO cloud on October 9, some jobs were
  stalled for a long time, now everything is working.


Sprint Review:

The sprint epic was utilizing the DLRN api across TripleO and RDO [2] to
report job status and promotions, and we set several tasks in 20 cards, and
I am glad to report that we were able to complete 19 cards! Some of these
cards generate some tech debts, and after a review, we got 11 card in the
tech debt list, plus 3 new bugs opened and XYZ bugs closed by the Ruck and
Rover.

One can see the results of the sprint via https://tinyurl.com/yblqs5z2

Below the list of new bugs related to the work completed in the sprint:


   -

   https://bugs.launchpad.net/tripleo/+bug/1722552
   -

   https://bugs.launchpad.net/tripleo/+bug/1722554
   -

   https://bugs.launchpad.net/tripleo/+bug/1722558


And here the list of what was done by the Ruck and Rover:

   -

   https://bugs.launchpad.net/tripleo/+bug/1722640
   -

   https://bugs.launchpad.net/tripleo/+bug/1722621
   -

   https://bugs.launchpad.net/tripleo/+bug/1722596
   -

   https://bugs.launchpad.net/tripleo/+bug/1721790
   -

   https://bugs.launchpad.net/tripleo/+bug/1721366
   -

   https://bugs.launchpad.net/tripleo/+bug/1721134
   -

   https://bugs.launchpad.net/tripleo/+bug/1720556
   -

   https://bugs.launchpad.net/tripleo/+bug/1719902
   -

   https://bugs.launchpad.net/tripleo/+bug/1719421



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

[2] https://trello.com/c/5FnfGByl
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder][nova][castellan] Toward deprecating ConfKeyManager

[Alan Bishop]

On Wed, Oct 11, 2017 at 1:17 PM, Dave McCowan (dmccowan)
 wrote:
> Hi Alan--
> Since a fixed-key implementation is not secure, I would prefer not
> adding it to Castellan.  Our desire is that Castellan can be a best-practice
> project to encourage operators to use key management securely.
> I'm all for consolidating code and providing good migration paths from
> ConfKeyManager to Castellan.
> Can we create a new oslo project to facilitate this?  Something like
> oslo.fixed_key_manager.
> I would rather keep a fixed_key implementation out of Castellan if
> possible.

Hi Dave,

While I totally take your point about keeping the "deficient" (I'm being
charitable) ConfKeyManager code out of Castellan, I view it as a short
term tactical move. Everyone is looking forward to deprecating the code.
The key (no pun intended) to getting there is providing a migration path
for users (there are significant ones) that have existing deployments
that use the fixed-key.

Because of the circumstances, I feel there would be resistance to the
idea of creating an entirely new oslo project that; a) consists of code
that everyone knows to be deficient, and b) will be deprecated soon.

I have another motive for temporarily moving the code into Castellan,
and it pertains to providing a migration path to Barbican. With everything
consolidated in Castellan, a wrapper class could provide a seamless way
of handling KeyManager.get() requests for the all-zeros fixed-key ID,
even when Barbican is the key manager. This would allow users to switch
to Barbican, and still have any get() requests for the legacy fixed-key
be resolved by the ConfKeyManager.

All of this could be implemented wholely within Castellan, and be totally
transparent to the the user, Nova, Cinder, and the Barbican implementation
in barbican_key_manager.py.

As a final note, we could add all sorts of warnings any to code added
to Castellan, perhaps even name the file insecure_key_manager.py ;-)

Alan


> --Dave
>
> There is an ongoing effort to deprecate the ConfKeyManager, but care
> must be taken when migrating existing ConfKeyManager deployments to
> Barbican. The ConfKeyManager's fixed_key secret can be added to Barbican,
> but the process of switching from one key manager to another will need
> to be done smoothly to ensure encrypted volumes continue to function
> during the migration period.
>
> One thing that will help the migration process is consolidating the
> two ConfKeyManager implementations (one in Cinder and one in Nova).
> The two are functionally identical, as dictated by the need to derive
> the exact same secret from the fixed_key. While it may seem counter-
> intuitive, adding a ConfKeyManager implementation to Castellan will
> facilitate the process of deprecating them in Cinder and Nova.
>
> To that end, I identified a series of small steps to get us there:
>
> 1) Unify the "fixed_key" oslo_config definitions in Cinder and Nova
> so they are identical (right now their help texts are slightly
> different). This step avoids triggering a DuplicateOptError exception
> in the next step.
>
> 2) Add a ConfKeyManager implementation to Castellan. This essentially
> involves copying in one of the existing implementations (either Cinder's
> or Nova's).
>
> 3) Replace Cinder's and Nova's implementations with references to the
> one in Castellan. This can be done in a way that retains compatibility
> with the key_manager "backend" (was "api_class") config options
> currently used by Cinder and Nova. The code in
> cinder/keymgr/conf_key_manager.py and nova/keymgr/conf_key_manager.py
> will collapse down to this:
>
>   from castellan.key_manager import conf_key_manager
>
>   class ConfKeyManager(conf_key_manager.ConfKeyManager):
>   pass
>
> Having a common ConfKeyManager implementation will make it much
> easier to support migrating things to Barbican, and that's an important
> step toward the goal of deprecating the ConfKeyManager entirely.
>
> Please let me know your thoughts, as I plan to begin proposing patches.
>
> Regards,
>
> Alan Bishop
>
>
> __
> 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] [docs] Flagging deprecated releases

[Jay S Bryant]

On 10/10/2017 2:15 PM, Jimmy McArthur wrote:


Hi all -

I'm following up on the PTG action item to add a CSS banner for older 
releases (e.g. https://releases.openstack.org/newton/index.html).  
Does anyone have specific language they'd like to see here or should I 
just riff it?


I was considering a CSS overlay similar to what you see when you 
scroll down below the nav (e.g. 
https://www.openstack.org/software/security/).  Here's a quick comp: 
https://www.screencast.com/t/Kbz0Sh8uRb7


If you like the direction this is going, I'll send along to people 
that are real designers (not me).


Cheers,
Jimmy

__ 


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

Jimmy,

I like the way the information indicating it is deprecated clings to the 
top as your scroll.  Looks good to me and seems to be the fad lately.


Jay

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

[openstack-dev] PTG videos

[Rich Bowen]

FYI, all of the PTG videos are now online at 
https://www.youtube.com/playlist?list=PLOuHvpVx7kYm2b9tmpUJt8lC75fdDr4zx


Thank you to everyone that participated.

If you're interested in doing an interview but missed me at the PTG, 
look me up in Sydney, where I'll be doing more of the same.


--Rich

--
Rich Bowen: Community Architect
rbo...@redhat.com
@rbowen // @RDOCommunity // @CentOSProject
1 859 351 9166

__
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] TripleO/Ansible PTG session

[Emilien Macchi]

(cross-posting)

James and I created this etherpad:
https://etherpad.openstack.org/p/tripleo-config-download
which tracks work in progress for the config download efforts.

Please let us know any question on that topic,

On Mon, Sep 25, 2017 at 5:28 PM, Dan Prince  wrote:
>
>
> On Thu, Sep 21, 2017 at 8:53 AM, Jiří Stránský  wrote:
>>
>> On 21.9.2017 12:31, Giulio Fidente wrote:
>>>
>>> On 09/20/2017 07:36 PM, James Slagle wrote:

 On Tue, Sep 19, 2017 at 8:37 AM, Giulio Fidente 
 wrote:
>
> On 09/18/2017 05:37 PM, James Slagle wrote:
>>
>> - The entire sequence and flow is driven via Mistral on the Undercloud
>> by default. This preserves the API layer and provides a clean reusable
>> interface for the CLI and GUI.
>
>
> I think it's worth saying that we want to move the deployment steps out
> of heat and in ansible, not in mistral so that mistral will run the
> workflow only once and let ansible go through the steps
>
> I think having the steps in mistral would be a nice option to be able
> to
> rerun easily a particular deployment step from the GUI, versus having
> them in ansible which is instead a better option for CLI users ... but
> it looks like having them in ansible is the only option which permits
> us
> to reuse the same code to deploy an undercloud because having the steps
> in mistral would require the undercloud installation itself to depend
> on
> mistral which we don't want to
>
> James, Dan, please comment on the above if I am wrong


 That's correct. We don't want to require Mistral to install the
 Undercloud. However, I don't think that necessarily means it has to be
 a single call to ansible-playbook. We could have multiple invocations
 of ansible-playbook. Both Mistral and CLI code for installing the
 undercloud could handle that easily.

 You wouldn't be able to interleave an external playbook among the
 deploy steps however. That would have to be done under a single call
 to ansible-playbook (at least how that is written now). We could
 however have hooks that could serve as integration points to call
 external playbooks after each step.
>>>
>>>
>>> the benefits of driving the steps from mistral are that then we could
>>> also interleave the deployment steps and we won't need the
>>> ansible-playbook hook for the "external" services:
>>>
>>> 1) collect the ansible tasks *and* the workflow_tasks (per step) from
>>> heat
>>>
>>> 2) launch the stepN deployment workflow (ansible-playbook)
>>>
>>> 3) execute any workflow_task defined for stepN (like ceph-ansible
>>> playbook)
>>>
>>> 4) repeat 2 and 3 for stepN+1
>>>
>>> I think this would also provide a nice interface for the UI ... but then
>>> we'd need mistral to be able to deploy the undercloud
>>>
>>
>> Alternatively we could do the main step loop in Ansible directly, and have
>> the tasks do whatever they need to get the particular service deployed, from
>> to launching a nested ansible-playbook run if that's what it takes.
>>
>> That way we could run the whole thing end-to-end via ansible-playbook, or
>> if needed one could execute smaller bits by themselves (steps or nested
>> playbook runs) -- that capability is not baked in by default, but i think we
>> could make it so.
>
>
> This was the idea that had the most traction at the PTG when we discussed
> it. Things can still be interleaved across the installers (stepwise) but we
> effectively eliminate the complexity of having multiple tools involved
> within the main deploy step loop as you described it.
>
> I think we should consider making it so that the main Ansible loop can call
> any external installer in a stepwise fashion though. It doesn't have to be
> just Ansible it calls. In this manner we would be supporting calling into
> multiple phases of an external installer.
>
> During the undercloud deployment we get all the benefits of Ansible driving
> our primary deployment loop and can still call into external installers like
> Kubernetes if we want to. On the overcloud we'd still be leveraging the high
> level Mistral workflow to kick off the initial Ansible playbooks... but once
> that happens it would be Ansible driving any external installers directly.
>
> Dan
>
>>
>>
>> Also the interface for services would be clean and simple -- it's always
>> the ansible tasks.
>>
>> And Mistral-less use cases become easier to handle too (= undercloud
>> installation when Mistral isn't present yet, or development envs when you
>> want to tune the playbook directly without being forced to go through
>> Mistral).
>>
>> Logging becomes a bit more unwieldy in this scenario though, as for the
>> nested ansible-playbook execution, all output would go into a task in the
>> outer playbook, which would be harder to follow and the log of the outer
>> playbook could be huge.
>>

[openstack-dev] [tripleo] Reminder about specs for Queens

[Alex Schultz]

Hey folks,

As we approach milestone 1 for Queens, we need to be mindful of the
open specs[0]. Please take some time to review the posted specs. Also
if you need to propose a new spec, please do so as soon as possible.
The goal for this cycle is to close the spec repo at milestone 2.  The
hope is to use the time after milestone 2 for additional stabilization
and hardening so we would like to get as much merged prior to
milestone 2 as possible.

If you have any questions or issues with this plan, please let us
know. We chatted about this a bit the last IRC meeting[1] but we can
certainly review this plan as necessary.

Thanks,
-Alex

[0] https://review.openstack.org/#/q/project:openstack/tripleo-specs+status:open
[1] 
http://eavesdrop.openstack.org/meetings/tripleo/2017/tripleo.2017-10-10-14.00.log.html#l-315

__
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] [policy] AWS IAM session

[Lance Bragstad]

Oh - one note about the doodle [0]. All proposed times are in UTC, so
just keep that in mind when selecting your availability.

Thanks!

[0] https://beta.doodle.com/poll/ntkpzgmcv3k6v5qu

On 10/11/2017 01:44 PM, Lance Bragstad wrote:
> In today's policy meeting we went through and started prepping for the
> session. Relevant information has been captured in the etherpad [0].
>
> We're going to hold the meeting using *Google* *Hangouts*. I'll update
> the etherpad with a link to the hangout once we settle on a date. If
> you plan on attending, please *vote* *for* *available* *times* [1].
> I've proposed a bunch of time slots (4 each day for the next two
> weeks) to try and find a time that works for everyone. People from US,
> AU, and EU will be trying to attended, so we're not going to find a
> perfect time for everyone. Having said that, *we're going to record
> the session*.
>
> Most of what we talked about in the meeting today uncovered the need
> to go over the basics of AWS IAM. That should be something we can do
> with a free account, which I'm going to sign up for. If we need more
> time we can have another session or look at options for upgrading the
> account.
>
>
> [0] https://etherpad.openstack.org/p/analyzing-other-policy-systems
> [1] https://doodle.com/poll/ntkpzgmcv3k6v5qu
>
> On 10/09/2017 04:23 PM, Lance Bragstad wrote:
>> I've put a scheduling session on the books for the next policy
>> meeting [0][1]. Advertising it here since folks who want to be
>> involved have responded to the thread.
>>
>> Let's use this meeting time to iron out account details and figure
>> out what exactly we want to get out of the session.
>>
>>
>> [0] http://eavesdrop.openstack.org/#Keystone_Policy_Meeting
>> [1] https://etherpad.openstack.org/p/keystone-policy-meeting
>>
>> On 10/05/2017 02:24 AM, Colleen Murphy wrote:
>>> On Tue, Oct 3, 2017 at 10:08 PM, Lance Bragstad >> > wrote:
>>>
>>> Hey all,
>>>
>>> It was mentioned in today's keystone meeting [0] that it would
>>> be useful
>>> to go through AWS IAM (or even GKE) as a group. With all the recent
>>> policy discussions and work, it seems useful to get our eyes on
>>> another
>>> system. The idea would be to spend time using a video
>>> conference/screen
>>> share to go through and play with policy together. The end
>>> result should
>>> keep us focused on the implementations we're working on today,
>>> but also
>>> provide clarity for the long-term vision of OpenStack's RBAC system.
>>>
>>> Are you interested in attending? If so, please respond to the
>>> thread.
>>> Once we have some interest, we can gauge when to hold the
>>> meeting, which
>>> tools we can use, and setting up a test IAM account.
>>>
>>> Thanks,
>>>
>>> Lance
>>>
>>> [0]
>>> 
>>> http://eavesdrop.openstack.org/meetings/keystone/2017/keystone.2017-10-03-18.00.log.html#l-119
>>> 
>>> 
>>>
>>> Please count me in.
>>>
>>> Colleen
>>>
>>>
>>> __
>>> 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
>>
>



signature.asc
Description: OpenPGP digital 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] [policy] AWS IAM session

[Lance Bragstad]

In today's policy meeting we went through and started prepping for the
session. Relevant information has been captured in the etherpad [0].

We're going to hold the meeting using *Google* *Hangouts*. I'll update
the etherpad with a link to the hangout once we settle on a date. If you
plan on attending, please *vote* *for* *available* *times* [1]. I've
proposed a bunch of time slots (4 each day for the next two weeks) to
try and find a time that works for everyone. People from US, AU, and EU
will be trying to attended, so we're not going to find a perfect time
for everyone. Having said that, *we're going to record the session*.

Most of what we talked about in the meeting today uncovered the need to
go over the basics of AWS IAM. That should be something we can do with a
free account, which I'm going to sign up for. If we need more time we
can have another session or look at options for upgrading the account.


[0] https://etherpad.openstack.org/p/analyzing-other-policy-systems
[1] https://doodle.com/poll/ntkpzgmcv3k6v5qu

On 10/09/2017 04:23 PM, Lance Bragstad wrote:
> I've put a scheduling session on the books for the next policy meeting
> [0][1]. Advertising it here since folks who want to be involved have
> responded to the thread.
>
> Let's use this meeting time to iron out account details and figure out
> what exactly we want to get out of the session.
>
>
> [0] http://eavesdrop.openstack.org/#Keystone_Policy_Meeting
> [1] https://etherpad.openstack.org/p/keystone-policy-meeting
>
> On 10/05/2017 02:24 AM, Colleen Murphy wrote:
>> On Tue, Oct 3, 2017 at 10:08 PM, Lance Bragstad > > wrote:
>>
>> Hey all,
>>
>> It was mentioned in today's keystone meeting [0] that it would be
>> useful
>> to go through AWS IAM (or even GKE) as a group. With all the recent
>> policy discussions and work, it seems useful to get our eyes on
>> another
>> system. The idea would be to spend time using a video
>> conference/screen
>> share to go through and play with policy together. The end result
>> should
>> keep us focused on the implementations we're working on today,
>> but also
>> provide clarity for the long-term vision of OpenStack's RBAC system.
>>
>> Are you interested in attending? If so, please respond to the thread.
>> Once we have some interest, we can gauge when to hold the
>> meeting, which
>> tools we can use, and setting up a test IAM account.
>>
>> Thanks,
>>
>> Lance
>>
>> [0]
>> 
>> http://eavesdrop.openstack.org/meetings/keystone/2017/keystone.2017-10-03-18.00.log.html#l-119
>> 
>> 
>>
>> Please count me in.
>>
>> Colleen
>>
>>
>> __
>> 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
>



signature.asc
Description: OpenPGP digital 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] [relmgt] Libraries published to pypi with YYYY.X.Z versions

[Jeremy Stanley]

On 2017-09-29 17:31:10 +0200 (+0200), Thierry Carrez wrote:
> OK, I got individual PTL confirmation that it was OK to remove all of
> those from PyPI:
> 
> mistral-extra 2015.1.0
> mistral-dashboard 2015.1.*
> 
> networking-odl, 2015.1.1  2015.1.dev986
> 
> networking-midonet, 2014.2.2 and various 2015.1.* versions
> (might have been removed by networking-midonet folks by now)
> 
> sahara-image-elements 2014.*.*
> sahara-dashboard 2014.*.*

I finally got around to processing these deletions. And yes as far
as I can tell someone with access to the "midonet" account on PyPI
already took care of the networking-midonet cleanup, but I've
handled the others now.
-- 
Jeremy Stanley


signature.asc
Description: Digital 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] [tc] [kolla] [PTL] who can start the official meeting?

[Davanum Srinivas]

Swapnil,

Dunno if it was malicious or someone just trying to understand how things work.

Worth reaching out to jinke [1]

[1] 
http://git.openstack.org/cgit/openstack/stackalytics/commit/?id=e2593c113d64868b44f27a9fba15a564855236c6

Thanks,
Dims

On Wed, Oct 11, 2017 at 12:35 PM, Swapnil Kulkarni  wrote:
> On Wed, Oct 11, 2017 at 9:52 PM, Michał Jastrzębski  wrote:
>> I haven't seen "malicious" meeting starters yet, let's hope that won't
>> happen:) On the other hand, ad-hoc chair change can, and did, happen,
>> so I agree with fungi - I don't think we need to put restrictions on
>> that.
>>
>> On 11 October 2017 at 09:11, Jeremy Stanley  wrote:
>>> On 2017-10-11 21:35:26 +0530 (+0530), Swapnil Kulkarni wrote:
>>> [...]
 The problem here is if we know who are most likely to chair the
 meeting e.g. [1] we can allow them to start the meeting.
>>> [...]
>>>
>>> I'm pretty certain I wouldn't want to have to propose a patch to
>>> update that every time I needed someone to chair a meeting in my
>>> absence. This doesn't seem like a common enough issue to warrant the
>>> added complexity and red tape of access controls on our meeting
>>> automation.
>>> --
>>> 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
>
> Michal,
>
> I just gave one instance of malicious meeting attempt [1] happened
> today and it happened to be kolla meeting so I noticed its not correct
> timing for the same. I would put it as permission-ed access rather
> than restriction, because as much as we want to keep it open we need
> to maintain the genuineness of meeting. I would not want to stumble
> into a junk log file while I am reading it later looking for
> something.
>
>
> [1] 
> http://eavesdrop.openstack.org/meetings/kolla/2017/kolla.2017-10-11-10.31.log.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [pbr] Migration to Storyboard

[Kendall Nelson]

Glad to see this conversation rolling and fully supported :) If there is
anything we can do to help please feel free to bother us in the #storyboard
channel and we will do what we can.

Also, thanks for the webclient patches :)

-Kendall (diablo_rojo)

On Wed, Oct 11, 2017 at 7:06 AM Stephen Finucane 
wrote:

> The Python packaging ecosystem is shifting under our feet and we have a
> couple
> of things in pbr we need to look at over the next few months (Pipfiles,
> pyenv,
> changes in setuptools setup.cfg, ...). We should probably track these
> somewhere
> and Storyboard [1] seems like a better candidate for doing this than
> Launchpad
> (plus, I get to play with Storyboard).
>
> I can initiate the transfer (it seems pretty easy to do [2]) but I'd like
> to
> make sure there are no objections before doing so.
>
> Speak now or forever hold your tongue.
>
> Stephen
>
> [1] https://docs.openstack.org/infra/storyboard/
> [2] https://docs.openstack.org/infra/storyboard/migration.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder][nova][castellan] Toward deprecating ConfKeyManager

[Dave McCowan (dmccowan)]

Hi Alan--
Since a fixed-key implementation is not secure, I would prefer not adding 
it to Castellan.  Our desire is that Castellan can be a best-practice project 
to encourage operators to use key management securely.
I'm all for consolidating code and providing good migration paths from 
ConfKeyManager to Castellan.
Can we create a new oslo project to facilitate this?  Something like 
oslo.fixed_key_manager.
I would rather keep a fixed_key implementation out of Castellan if possible.
--Dave

There is an ongoing effort to deprecate the ConfKeyManager, but care
must be taken when migrating existing ConfKeyManager deployments to
Barbican. The ConfKeyManager's fixed_key secret can be added to Barbican,
but the process of switching from one key manager to another will need
to be done smoothly to ensure encrypted volumes continue to function
during the migration period.

One thing that will help the migration process is consolidating the
two ConfKeyManager implementations (one in Cinder and one in Nova).
The two are functionally identical, as dictated by the need to derive
the exact same secret from the fixed_key. While it may seem counter-
intuitive, adding a ConfKeyManager implementation to Castellan will
facilitate the process of deprecating them in Cinder and Nova.

To that end, I identified a series of small steps to get us there:

1) Unify the "fixed_key" oslo_config definitions in Cinder and Nova
so they are identical (right now their help texts are slightly
different). This step avoids triggering a DuplicateOptError exception
in the next step.

2) Add a ConfKeyManager implementation to Castellan. This essentially
involves copying in one of the existing implementations (either Cinder's
or Nova's).

3) Replace Cinder's and Nova's implementations with references to the
one in Castellan. This can be done in a way that retains compatibility
with the key_manager "backend" (was "api_class") config options
currently used by Cinder and Nova. The code in
cinder/keymgr/conf_key_manager.py and nova/keymgr/conf_key_manager.py
will collapse down to this:

  from castellan.key_manager import conf_key_manager

  class ConfKeyManager(conf_key_manager.ConfKeyManager):
  pass

Having a common ConfKeyManager implementation will make it much
easier to support migrating things to Barbican, and that's an important
step toward the goal of deprecating the ConfKeyManager entirely.

Please let me know your thoughts, as I plan to begin proposing patches.

Regards,

Alan Bishop

__
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] What logical clock does OpenStack use

[Zane Bitter]

On 11/10/17 02:48, Puneet Jain wrote:

Hi,

I was just curious to know, how the event ordering happens in OpenStack? 


You might have mistaken OpenStack for a distributed system :)


What clock does it use? I mean does it use Lamport Logical Clock?


MySQL

__
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] [ptls] Sydney Forum Project Onboarding Rooms

[Kendall Nelson]

Hello :)

Congrats! I added you/Masakari to my list.

-Kendall (diablo_rojo)

On Wed, Oct 11, 2017 at 12:28 AM Sam P  wrote:

> Hi Kendall,
>
>  Thank you for info.
>  If slots are still available, we would like to do an On-boarding
> session for Masakari [1].
>  # BTW, got the TC approval yesterday [2]...
>
>
> [1] https://wiki.openstack.org/wiki/Masakari
> [2] https://review.openstack.org/#/c/500118/
> --- Regards,
> Sampath
>
>
>
> On Wed, Oct 11, 2017 at 5:12 AM, Kendall Nelson 
> wrote:
> > Of course :) I added Designate.
> >
> > -Kendall Nelson(diablo_rojo)
> >
> >
> > On Tue, Oct 10, 2017 at 1:01 PM Graham Hayes  wrote:
> >>
> >> Can I add designate? I will be there to look after the room.
> >>
> >> Thanks,
> >>
> >> Graham
> >>
> >>
> >> On Tue, 10 Oct 2017, at 20:20, Kendall Nelson wrote:
> >>
> >> Added :)
> >> -Kendall (diablo_rojo)
> >>
> >> On Tue, Oct 10, 2017 at 2:11 AM Spyros Trigazis 
> >> wrote:
> >>
> >> Magnum - Spyros Trigazis - 
> >>
> >> Thanks!
> >>
> >> On 9 October 2017 at 23:24, Kendall Nelson 
> wrote:
> >> > Wanted to keep this thread towards the top of inboxes for those I
> >> > haven't
> >> > heard from yet.
> >> >
> >> > About a 1/4 of the way booked, so there are still slots available!
> >> >
> >> > -Kendall (diablo_rojo)
> >> >
> >> >
> >> > On Thu, Oct 5, 2017 at 8:50 AM Kendall Nelson 
> >> > wrote:
> >> >>
> >> >> Hello :)
> >> >>
> >> >> We have a little over 40 slots available so we should be able to
> >> >> accommodate almost everyone, but it will be a first response first
> >> >> serve
> >> >> basis.
> >> >>
> >> >> Logistics: Slots are 40 min long and will have projection set up in
> >> >> them.
> >> >> The rooms have a capacity of about 40 people and will be set up
> >> >> classroom
> >> >> style.
> >> >>
> >> >> If you are interested in reserving a spot, just reply directly to me
> >> >> and I
> >> >> will put your project on the list. Please let me know if you want one
> >> >> and
> >> >> also include the names and emails anyone that will be speaking with
> >> >> you.
> >> >>
> >> >> When slots run out, they run out.
> >> >>
> >> >> Thanks!
> >> >>
> >> >> -Kendall Nelson (diablo_rojo)
> >> >
> >> >
> >> >
> >> >
> __
> >> > OpenStack Development Mailing List (not for usage questions)
> >> > Unsubscribe:
> >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> 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] [ocata] nova-api error 404 instance not found

[Matt Riedemann]

On 10/11/2017 3:48 AM, Kim-Norman Sahm wrote:

Hi Matt,

i'm using the ubuntu packages v15.0.6
the instances are mapped to the correct cell:

mysql> select * from nova_api.instance_mappings where instance_uuid =
 -> "e564c631-896c-458c-93ab-b1c88f444fff";
+-+-+-+--
+-+--+
| created_at  | updated_at  | id  |
instance_uuid| cell_id |
project_id   |
+-+-+-+--
+-+--+
| 2017-10-10 08:16:32 | 2017-10-10 08:16:32 | 846 | e564c631-896c-458c-
93ab-b1c88f444fff |   6 | 7c1dd7d33037481e81f55d2f5d45bb90 |
+-+-+-+--
+-+--+

I've tried the workaround of this bug:
https://bugs.launchpad.net/nova/+bug/1682423

and its running correctly.

br
Kim


I put some comments in the bug report (starting at comment 16). I don't 
really see how this would be happening unless there is an issue with the 
osapi_compute service version, like if you're running the API with uwsgi 
(which wasn't supported in ocata) or if you're API services are not all 
upgraded yet.


The workaround with the 1 second sleep seems to suggest there is a race 
window where the instance is not mapped to a cell yet but the build 
request is also gone, which shouldn't happen as we create the instance 
in the cell before deleting the build request:


https://github.com/openstack/nova/blob/15.0.0/nova/conductor/manager.py#L914

https://github.com/openstack/nova/blob/15.0.0/nova/conductor/manager.py#L937

So while it's possible for the instance to be created in the cell 
database but the instance mapping record isn't yet updated, we account 
for that when looking up the instance here:


https://github.com/openstack/nova/blob/15.0.0/nova/compute/api.py#L2276

and here:

https://github.com/openstack/nova/blob/15.0.0/nova/compute/api.py#L2289

--

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-dev] [all] Zuul v3 Rollout Update - devstack-gate issues edition

[Monty Taylor]

  But, Mousie, thou art no thy-lane,
  In proving foresight may be vain;
  The best-laid schemes o' mice an' men
  Gang aft agley,
  An' lea'e us nought but grief an' pain,
  For promis'd joy!
- To a Mouse, Rabbie Burns, 1785

We have awoken this fine morning to find ourselves having two different 
devstack-gate issues[1][2] that are related neither to each other, nor 
to Zuul v3 itself (although one of them only surfaces in Zuul v3)


Given the typically long iteration time on working through base 
devstack-gate issues, it seems rather imprudent to flip the v3 switch 
until they are sorted.


Consider the rollout on hold until the devstack-gate issues are sorted. 
We'll follow up when we it's a go again.


Thanks!
Monty

[1] Ownership of the in-image artifact cache. Has a patch working 
through the gate now: https://review.openstack.org/#/c/511260/


[2] Issue with our Ubuntu mirrors being out of sync causing package 
version conflicts between mainline and UCA mirrors. Root cause and 
solutions are being worked.


__
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] [pbr] Migration to Storyboard

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2017-10-11 16:29:31 +:
> On 2017-10-11 12:05:33 -0400 (-0400), Doug Hellmann wrote:
> [...]
> > We have a bunch of open bugs. It would be good to triage those to see
> > which, if any, need to be migrated.
> [...]
> 
> Well, they'll all be migrated (whether open or closed), but closing
> them in LP where possible will reduce the risk that people continue
> trying to update them there later.

Oh, nice, I didn't realize all of the bugs would be copied over.
Triaging will still help clean up the active items, but I don't think
it's a blocker.

> 
> Unfortunately the degree to which bug handling can be disabled in LP
> is somewhat lacking if you want to still have old bugs archived
> there (so that existing links on mailing lists and such continue
> working). You can disable reporting new bugs and hide links to the
> bug tracker from the project page on LP, but bugs can still get
> updated there. We've talked about the possibility for a bug-spammer
> that adds a comment to and closes all LP bugs on a project pointing
> to the corresponding URLs of imported SB stories. However, as you
> know, dealing with API timeouts for LP is sort of un-fun so this
> may be a foolish idea.

Commenting on bugs seems to trigger the timeout less often than
trying to update some of the metadata. At least that's what I think
we've found with the release tools. It's also safe to ignore the
timeout errors in this case, I think.

On the other hand, I think just closing down the tracker is probably
sufficient. It's not like we have lots of people commenting on pbr bugs
right now.

Doug

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

Re: [openstack-dev] [tc] [kolla] [PTL] who can start the official meeting?

[Swapnil Kulkarni]

On Wed, Oct 11, 2017 at 9:52 PM, Michał Jastrzębski  wrote:
> I haven't seen "malicious" meeting starters yet, let's hope that won't
> happen:) On the other hand, ad-hoc chair change can, and did, happen,
> so I agree with fungi - I don't think we need to put restrictions on
> that.
>
> On 11 October 2017 at 09:11, Jeremy Stanley  wrote:
>> On 2017-10-11 21:35:26 +0530 (+0530), Swapnil Kulkarni wrote:
>> [...]
>>> The problem here is if we know who are most likely to chair the
>>> meeting e.g. [1] we can allow them to start the meeting.
>> [...]
>>
>> I'm pretty certain I wouldn't want to have to propose a patch to
>> update that every time I needed someone to chair a meeting in my
>> absence. This doesn't seem like a common enough issue to warrant the
>> added complexity and red tape of access controls on our meeting
>> automation.
>> --
>> 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

Michal,

I just gave one instance of malicious meeting attempt [1] happened
today and it happened to be kolla meeting so I noticed its not correct
timing for the same. I would put it as permission-ed access rather
than restriction, because as much as we want to keep it open we need
to maintain the genuineness of meeting. I would not want to stumble
into a junk log file while I am reading it later looking for
something.


[1] 
http://eavesdrop.openstack.org/meetings/kolla/2017/kolla.2017-10-11-10.31.log.html

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

Re: [openstack-dev] [pbr] Migration to Storyboard

[Jeremy Stanley]

On 2017-10-11 12:05:33 -0400 (-0400), Doug Hellmann wrote:
[...]
> We have a bunch of open bugs. It would be good to triage those to see
> which, if any, need to be migrated.
[...]

Well, they'll all be migrated (whether open or closed), but closing
them in LP where possible will reduce the risk that people continue
trying to update them there later.

Unfortunately the degree to which bug handling can be disabled in LP
is somewhat lacking if you want to still have old bugs archived
there (so that existing links on mailing lists and such continue
working). You can disable reporting new bugs and hide links to the
bug tracker from the project page on LP, but bugs can still get
updated there. We've talked about the possibility for a bug-spammer
that adds a comment to and closes all LP bugs on a project pointing
to the corresponding URLs of imported SB stories. However, as you
know, dealing with API timeouts for LP is sort of un-fun so this
may be a foolish idea.
-- 
Jeremy Stanley


signature.asc
Description: Digital 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] [pbr] Migration to Storyboard

[Davanum Srinivas]

+1

On Wed, Oct 11, 2017 at 12:05 PM, Doug Hellmann  wrote:
> Excerpts from Stephen Finucane's message of 2017-10-11 15:05:50 +0100:
>> The Python packaging ecosystem is shifting under our feet and we have a 
>> couple
>> of things in pbr we need to look at over the next few months (Pipfiles, 
>> pyenv,
>> changes in setuptools setup.cfg, ...). We should probably track these 
>> somewhere
>> and Storyboard [1] seems like a better candidate for doing this than 
>> Launchpad
>> (plus, I get to play with Storyboard).
>>
>> I can initiate the transfer (it seems pretty easy to do [2]) but I'd like to
>> make sure there are no objections before doing so.
>>
>> Speak now or forever hold your tongue.
>>
>> Stephen
>>
>> [1] https://docs.openstack.org/infra/storyboard/
>> [2] https://docs.openstack.org/infra/storyboard/migration.html
>>
>
> We have a bunch of open bugs. It would be good to triage those to see
> which, if any, need to be migrated.
>
> Otherwise I'm +1.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [tc] [kolla] [PTL] who can start the official meeting?

[Michał Jastrzębski]

I haven't seen "malicious" meeting starters yet, let's hope that won't
happen:) On the other hand, ad-hoc chair change can, and did, happen,
so I agree with fungi - I don't think we need to put restrictions on
that.

On 11 October 2017 at 09:11, Jeremy Stanley  wrote:
> On 2017-10-11 21:35:26 +0530 (+0530), Swapnil Kulkarni wrote:
> [...]
>> The problem here is if we know who are most likely to chair the
>> meeting e.g. [1] we can allow them to start the meeting.
> [...]
>
> I'm pretty certain I wouldn't want to have to propose a patch to
> update that every time I needed someone to chair a meeting in my
> absence. This doesn't seem like a common enough issue to warrant the
> added complexity and red tape of access controls on our meeting
> automation.
> --
> 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] [tc] [kolla] [PTL] who can start the official meeting?

[Jeremy Stanley]

On 2017-10-11 21:35:26 +0530 (+0530), Swapnil Kulkarni wrote:
[...]
> The problem here is if we know who are most likely to chair the
> meeting e.g. [1] we can allow them to start the meeting.
[...]

I'm pretty certain I wouldn't want to have to propose a patch to
update that every time I needed someone to chair a meeting in my
absence. This doesn't seem like a common enough issue to warrant the
added complexity and red tape of access controls on our meeting
automation.
-- 
Jeremy Stanley


signature.asc
Description: Digital 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] [tc] [kolla] [PTL] who can start the official meeting?

[Swapnil Kulkarni]

Hi Jeremy, Amrith,

On Wed, Oct 11, 2017 at 7:50 PM, Amrith Kumar  wrote:
> I agree with Jeremy that we shouldn't attempt to implement technical
> solutions for non-technical problems. But to that end, I'd be curious
> to know what the problem was with this. In my experience it has been
> an asset to have the meeting start on time even if the regular chair
> is for some reason delayed.
>

I agree this is a non-technical problem  and if someone else who can
start the meeting in the absence of the chair is always helpful. The
problem here is if we know who are most likely to chair the meeting
e.g. [1] we can allow them to start the meeting.


[1] 
https://github.com/openstack-infra/irc-meetings/blob/master/meetings/requirements-team.yaml#L10

> I've benefited from that in Trove, and on at least one occasion I've
> started the oslo meeting and the regular chair came in and took over a
> while later.
>
> The short log that coolsvap provided doesn't exhibit a problem, as
> best as I can tell; people without bouncers sometimes do lose their
> internet connection :(

This is all the log there is. I don't even know if the person who
started the meeting is contributor to kolla or openstack for that
matter. My only query is people who know about official meetings will
not do it, but can we restrict those who dont? Otherwise there is no
meaning to the official meetings if anyone can start them anytime.

>
> -amrith
>
>
>
> On Wed, Oct 11, 2017 at 9:55 AM, Jeremy Stanley  wrote:
>> On 2017-10-11 17:51:59 +0530 (+0530), Swapnil Kulkarni (coolsvap) wrote:
>>> I was attending the weekly requirements meeting when I noticed
>>> someone started the kolla meeting [1] on openstack-meeting-4
>>> channel. I thought we had the restrictions on the chairs, but
>>> apparently there's not. Can we think about having one such
>>> restriction?
>>
>> We don't implement technical solutions to social problems of this
>> nature. If you have an issue with the person who started the kolla
>> meeting in your absence, please take it up with them.
>> --
>> 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

__
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] [pbr] Migration to Storyboard

[Jay Pipes]

Sounds like a plan to me.

On 10/11/2017 10:05 AM, Stephen Finucane wrote:

The Python packaging ecosystem is shifting under our feet and we have a couple
of things in pbr we need to look at over the next few months (Pipfiles, pyenv,
changes in setuptools setup.cfg, ...). We should probably track these somewhere
and Storyboard [1] seems like a better candidate for doing this than Launchpad
(plus, I get to play with Storyboard).

I can initiate the transfer (it seems pretty easy to do [2]) but I'd like to
make sure there are no objections before doing so.

Speak now or forever hold your tongue.

Stephen

[1] https://docs.openstack.org/infra/storyboard/
[2] https://docs.openstack.org/infra/storyboard/migration.html

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



__
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] [pbr] Migration to Storyboard

[Doug Hellmann]

Excerpts from Stephen Finucane's message of 2017-10-11 15:05:50 +0100:
> The Python packaging ecosystem is shifting under our feet and we have a couple
> of things in pbr we need to look at over the next few months (Pipfiles, pyenv,
> changes in setuptools setup.cfg, ...). We should probably track these 
> somewhere
> and Storyboard [1] seems like a better candidate for doing this than Launchpad
> (plus, I get to play with Storyboard).
> 
> I can initiate the transfer (it seems pretty easy to do [2]) but I'd like to
> make sure there are no objections before doing so.
> 
> Speak now or forever hold your tongue.
> 
> Stephen
> 
> [1] https://docs.openstack.org/infra/storyboard/
> [2] https://docs.openstack.org/infra/storyboard/migration.html
> 

We have a bunch of open bugs. It would be good to triage those to see
which, if any, need to be migrated.

Otherwise I'm +1.

Doug

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

Re: [openstack-dev] [tc][election] TC non-candidacy

[Amrith Kumar]

On Tue, Oct 10, 2017 at 7:40 PM, Monty Taylor  wrote:
> Hey everybody!
>
> I have decided not to seek reelection for the TC.
>
> I have had the honor and privilege of serving you on the TC and it's
> predecessor the PPB since the fall of 2011 (with one six month absence that
> I blame on Jay Pipes)
>
> There are a wealth of amazing people running for the TC this cycle, many of
> whom have a different genetic, cultural or geographic background than I do.
> I look forward to seeing how they shepherd our amazing community.
>

Thank you Monty for all that you've done for OpenStack all these years. It has
been wonderful working with you and I look forward to continuing that.

> I am not going anywhere. We're just getting Zuul v3 rolled out, there's a
> pile of work to do to merge and rationalize shade and openstacksdk and I
> managed to sign myself up to implement application credentials in Keystone.
> I still haven't even managed to convince all of you that Floating IPs are a
> bad idea...
>
> Thank you, from the bottom of my heart, for the trust you have placed in me.
> I look forward to seeing as many of you as I can in Sydney, Vancouver,
> Berlin and who knows where else.
>
> 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 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][elections] TC nomination period is now over

[Emmet Hikory]

Sean McGinnis wrote:

> On Wed, Oct 11, 2017 at 12:18:30AM +, Kendall Nelson wrote:
> > Hello!TC Nomination is now over. The official candidate list is available
> > on the election website[0].We now enter the campaigning period where
> > candidates and electorate may debate their statements.The election will
> > start this Saturday.Thank you,Kendall Nelson (diablo_rojo)
> > [0]: http://governance.openstack.org/election/#pike-tc-candidates
>
> Pike? :)

    We’re also slightly backlogged on development of better documentation 
automation.  Despite the cosmetics being wrong, this does actually link to the 
Queens TC list.

—
Emmet

__
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][elections] TC nomination period is now over

[Sean McGinnis]

On Wed, Oct 11, 2017 at 12:18:30AM +, Kendall Nelson wrote:
> Hello!TC Nomination is now over. The official candidate list is available
> on the election website[0].We now enter the campaigning period where
> candidates and electorate may debate their statements.The election will
> start this Saturday.Thank you,Kendall Nelson (diablo_rojo)
> [0]: http://governance.openstack.org/election/#pike-tc-candidates

Pike? :)

__
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] [tc][election] TC non-candidacy

[Jay Pipes]

On 10/10/2017 07:40 PM, Monty Taylor wrote:

Hey everybody!

I have decided not to seek reelection for the TC.

I have had the honor and privilege of serving you on the TC and it's 
predecessor the PPB since the fall of 2011 (with one six month absence 
that I blame on Jay Pipes)


There are a wealth of amazing people running for the TC this cycle, many 
of whom have a different genetic, cultural or geographic background than 
I do. I look forward to seeing how they shepherd our amazing community.


+1

I am not going anywhere. We're just getting Zuul v3 rolled out, there's 
a pile of work to do to merge and rationalize shade and openstacksdk and 
I managed to sign myself up to implement application credentials in 
Keystone. I still haven't even managed to convince all of you that 
Floating IPs are a bad idea...


Thank you, from the bottom of my heart, for the trust you have placed in 
me. I look forward to seeing as many of you as I can in Sydney, 
Vancouver, Berlin and who knows where else.


And thank YOU, Monty, for the work you put in to building software and 
leveling up the community every day.


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] [zun] Client long description on PyPi

[Hongbin Lu]

Hi Zigo,

According to https://github.com/pypa/warehouse/issues/2170 , it is impossible 
to update the description manually. I will release a new version of 
python-zunclient to get the description updated.

Best regards,
Hongbin 

> -Original Message-
> From: Thomas Goirand [mailto:z...@debian.org]
> Sent: October-11-17 4:50 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [zun] Client long description on PyPi
> 
> Hi,
> 
> Could someone write something relevant, instead of the current
> placeholder? See here:
> 
> https://pypi.python.org/pypi/python-zunclient
> 
> and see that "this is a hard requirement".
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 
> ___
> ___
> 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] [murano] Support for http_proxy environment variable in NEWTON

[Rong Zhu]

Hi, Greg

You can try with this commit: https://review.openstack.org/#/c/85014/

Thanks,
Rong Zhu



On Tue, Oct 10, 2017 at 8:03 PM, Waines, Greg  wrote:
> Is this a known issue in NEWTON ?
>
>
>
> i.e. it does NOT appear that murano client uses the http_proxy environment
> variable defined in /etc/environment
>
>
>
> e.g.   murano package-import 
>
>   will NOT work behind a proxy server, even if http_proxy is
> defined in /etc/environment
>
>
>
> Is this fixed in OCATA or PIKE ?
>
>
>
> Greg.
>
>
> __
> 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] [tc] [kolla] [PTL] who can start the official meeting?

[Amrith Kumar]

I agree with Jeremy that we shouldn't attempt to implement technical
solutions for non-technical problems. But to that end, I'd be curious
to know what the problem was with this. In my experience it has been
an asset to have the meeting start on time even if the regular chair
is for some reason delayed.

I've benefited from that in Trove, and on at least one occasion I've
started the oslo meeting and the regular chair came in and took over a
while later.

The short log that coolsvap provided doesn't exhibit a problem, as
best as I can tell; people without bouncers sometimes do lose their
internet connection :(

-amrith



On Wed, Oct 11, 2017 at 9:55 AM, Jeremy Stanley  wrote:
> On 2017-10-11 17:51:59 +0530 (+0530), Swapnil Kulkarni (coolsvap) wrote:
>> I was attending the weekly requirements meeting when I noticed
>> someone started the kolla meeting [1] on openstack-meeting-4
>> channel. I thought we had the restrictions on the chairs, but
>> apparently there's not. Can we think about having one such
>> restriction?
>
> We don't implement technical solutions to social problems of this
> nature. If you have an issue with the person who started the kolla
> meeting in your absence, please take it up with them.
> --
> 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] [keystone][middleware]: Use encrypted password in the service conf file

[Lance Bragstad]

This sounds like something that was discussed during the PTG. The oslo
team was exploring ways to implement this, which would be consumable to
keystonemiddleware as a library [0].

[0] https://etherpad.openstack.org/p/oslo-ptg-queens

On 10/11/2017 07:43 AM, pnkk wrote:
> Hi,
>
> We have our API server(based on pyramid) integrated with keystone for
> AuthN/AuthZ.
> So our service has a *.conf file which has [keystone_authtoken]
> section that defines all the stuff needed for registering to keystone.
>
> WSGI pipeline will first get filtered with keystone auth token and
> then get into our application functionality.
>
> Now as part of hardening, we want to save an encrypted password(admin
> password) in the conf file.
> Where should I put the decryption logic so it gets passed to the
> middleware in the needed format?
>
> Appreciate your help!
>
> Thanks,
> Kanthi
>
>
> __
> 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



signature.asc
Description: OpenPGP digital 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

[openstack-dev] [pbr] Migration to Storyboard

[Stephen Finucane]

The Python packaging ecosystem is shifting under our feet and we have a couple
of things in pbr we need to look at over the next few months (Pipfiles, pyenv,
changes in setuptools setup.cfg, ...). We should probably track these somewhere
and Storyboard [1] seems like a better candidate for doing this than Launchpad
(plus, I get to play with Storyboard).

I can initiate the transfer (it seems pretty easy to do [2]) but I'd like to
make sure there are no objections before doing so.

Speak now or forever hold your tongue.

Stephen

[1] https://docs.openstack.org/infra/storyboard/
[2] https://docs.openstack.org/infra/storyboard/migration.html

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

Re: [openstack-dev] [tc] [kolla] [PTL] who can start the official meeting?

[Jeremy Stanley]

On 2017-10-11 17:51:59 +0530 (+0530), Swapnil Kulkarni (coolsvap) wrote:
> I was attending the weekly requirements meeting when I noticed
> someone started the kolla meeting [1] on openstack-meeting-4
> channel. I thought we had the restrictions on the chairs, but
> apparently there's not. Can we think about having one such
> restriction?

We don't implement technical solutions to social problems of this
nature. If you have an issue with the person who started the kolla
meeting in your absence, please take it up with them.
-- 
Jeremy Stanley


signature.asc
Description: Digital 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] Update on Zuul v3 Migration - and what to do about issues

[Jeremy Stanley]

On 2017-10-11 08:13:44 -0400 (-0400), David Shrewsbury wrote:
[...]
> On Wed, Oct 11, 2017 at 1:31 AM, Rikimaru Honjo wrote:
[...]
> > 1) Is there the information about differences of configuration
> > between nodepool for zuul v2 and v3? Or, can I configure
> > feature/zuulv3 basically same as lower version?
> 
> We don't document the differences between versions, but all of the
> v3 config options are documented in the nodepool docs (you can
> generate them from the source repo with the command: tox -e docs).
[...]

It also bears mentioning that Zuul v3 has not officially reached
release yet, and the plan is to work on documentation for CI
operators upgrading from v2 to v3 after we've been able to
successfully use v3 ourselves upstream. The unfortunate lack of
documentation around migration is still expected at this stage.
-- 
Jeremy Stanley


signature.asc
Description: Digital 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

[openstack-dev] [keystone][middleware]: Use encrypted password in the service conf file

[pnkk]

Hi,

We have our API server(based on pyramid) integrated with keystone for
AuthN/AuthZ.
So our service has a *.conf file which has [keystone_authtoken] section
that defines all the stuff needed for registering to keystone.

WSGI pipeline will first get filtered with keystone auth token and then get
into our application functionality.

Now as part of hardening, we want to save an encrypted password(admin
password) in the conf file.
Where should I put the decryption logic so it gets passed to the middleware
in the needed format?

Appreciate your help!

Thanks,
Kanthi
__
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] Contributor Portal PTG Recap

[Petr Kovar]

Hi all,

Just a quick update on how the contributor portal project will be
organized.

We created a new subteam under the Documentation Project.
This subteam (specialty team), led by Mike, will maintain the
portal repo openstack/contributor-guide.

Patches addressing this have been merged:

https://review.openstack.org/#/q/Ib8062210854e1979aa1f56bd7c0f5af8e578decc

Thanks,
pk


On Fri, 22 Sep 2017 11:13:46 -0700
Mike Perez  wrote:

> # Contributor Portal Next Steps
> 
> ## Landing Page Mock ups
> * Current mock up:
> https://drive.google.com/file/d/0BxMh9oiou2xMLVRvRWRFVklHa2c/view
> * Limited click through mock up:
> https://invis.io/CSDEZTBDJ#/252645774_Landing
> 
> ## Todo
> - [ ] thingee: A proposal for the *second level* of what the landing page
> shows.
> - [ ] thingee: Follow up with the Wes and Jimmy at the OpenStack Foundation
> for design assistance.
> 
> ## Communication To The Community
> * [Initial
> email](http://lists.openstack.org/pipermail/openstack-dev/2017-June/118877.html)
> * [Initial full
> thread](http://lists.openstack.org/pipermail/openstack-dev/2017-June/thread.html#118877)
> 
> ## Highlights from PTG session
> [OpenStack Etherpad](https://etherpad.openstack.org/p/contributor-portal)
> 
> ### TLDR (big changes from discussion)
> * Instead of all team on-boarding documentation living in a central
> repository, it will still remain with the individual teams to maintain in
> their own repository. General documentation (e.g. git, creating accounts,
> gerrit setup, etc) will still live in this central repo. If you choose to
> contribute by code for example and you pick a project, it will take you
> through our general documentation, then the project’s specific documentation.
> * This could lead to inconsistencies in documentation design? Confusion
> for the reader being sent to different pages?
> 
> ### General
> * We can’t go based off services. Not everything people are contributing
> to is a service, so they won't have anything corresponding in the
> [service type authority
> repo](http://git.openstack.org/cgit/openstack/service-types-authority/tree/service-types.yaml).
> There might be a field in projects.yaml that can help with this.
> * Remind Thierry on the service type authority repo for
> grouping/mapping project.
> * Videos were considered, but they’re hard to keep up-to-date.
> Previous Documentation PTL Alexandra Settle expressed that even
> screenshots can get out of date real fast. 
> * Generate some kind of crash-course / cheatsheet content for people
> who are used to GitHub but not familiar with Gerrit. Aspiers
> volunteered for this and made this first pass [ethercalc
> sheet](https://ethercalc.openstack.org/github-gerrit).
> * Translation team needs to be included
> * Provide documentation with how to edit the landing page, since the
> source is being hosted on github (there are transition discussions in
> place with the infra team and Jimmy)
> * Help projects with creating their own contributor guides if they
> need to. Think of something like Cookie cutter for setting up the
> scaffolding for a new OpenStack project, but getting projects
> contributor guides going.
> 
> ### Upstream Institute
> Attendees of the session we’re more in favor of projects keeping
> their specific documentation owned in their repositories. As learned
> from the centralize documentation problem
> [1](http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html)
> [2](https://doughellmann.com/blog/2017/08/24/stop-working-so-hard-scaling-open-source-community-practices/)
> [3](https://governance.openstack.org/tc/reference/top-5-help-wanted.html#documentation-owners),
> this is a good move. Upstream institute would then use whatever
> general documentation is provided. If people get past that, we could
> even suggest on-boarding to one of the [top 5 most wanted
> help](https://governance.openstack.org/tc/reference/top-5-help-wanted.html)!
> 
> ### User Committee
> Lauren Sell worked with Melvin and others from the user committee to get their
> requirements and perspective on the project. Here's an ether pad:
> https://etherpad.openstack.org/p/contributor-portal-user-section
> 
> ### Mock Up Feedback
> * Having the service types is great, but on the next level it would
> be good to express the code name with a description of what the
> project does.
> * Combine in events OpenStack day, meetups, forum, ptg, etc.
> (emphasize on in person thing)
> 
> ### Bikeshed
> * A word that combines code and documentation ("team(s)" was already
> rejected)
> 
> -- 
> Mike Perez

__
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] [tc] [kolla] [PTL] who can start the official meeting?

[Swapnil Kulkarni (coolsvap)]

I was attending the weekly requirements meeting when I noticed someone
started the kolla meeting [1] on openstack-meeting-4 channel. I thought we
had the restrictions on the chairs, but apparently there's not. Can we
think about having one such restriction?

[1]
http://eavesdrop.openstack.org/meetings/kolla/2017/kolla.2017-10-11-10.31.html

Best Regards,
Swapnil
__
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] Update on Zuul v3 Migration - and what to do about issues

[David Shrewsbury]

Hi.

Your questions about setting up nodepool are a bit off topic for this email
thread, but I'll try to answer them for you below:


On Wed, Oct 11, 2017 at 1:31 AM, Rikimaru Honjo <
honjo.rikim...@po.ntt-tx.co.jp> wrote:

> Hello,
>
> I'm trying to install & configure nodepool for Zuul v3 in my CI
> environment now.
> I use feature/zuulv3 branch.(ver. 0.4.1.dev430)
>
> I referred nodepool documents and infra/project-config tree.
> And I have some questions about this version of nodepool.
>
> 1)Is there the information about differences of configuration between
> nodepool for zuul v2 and v3?
>   Or, can I configure feature/zuulv3 basically same as lower version?
>

We don't document the differences between versions, but all of the v3
config options are
documented in the nodepool docs (you can generate them from the source repo
with the
command: tox -e docs).

For example configs, you can look at tools/fake.yaml, or in
devstack/plugin.sh which writes
a nodepool.yaml used in our testing environment. Or look at the configs we
use in infra (see
link below).



> 2)Below suggestion is wrote in README.rst.
>   But such file is not contained in the infra/system-config tree now.
>   Where is the file?
>
> Create or adapt a nodepool yaml file. You can adapt an infra/system-config
>> one, or fake.yaml as desired. Note that fake.yaml's settings won't Just
>> Work - consult ./modules/openstack_project/te
>> mplates/nodepool/nodepool.yaml.erb in the infra/system-config tree to
>> see a production config.
>>
>
>
We need to update the README (thanks for pointing this out). The infra
nodepool configs are
in project-config now. Example:


https://git.openstack.org/cgit/openstack-infra/project-config/tree/nodepool/nl01.openstack.org.yaml




> 3)Can I use "images" key in "providers"?
>   I used "images" in nodepool ver.0.3.1, but below sample file doesn't use
> the key.
>
>   https://github.com/openstack-infra/nodepool/blob/feature/zuu
> lv3/tools/fake.yaml
>
>
This has been renamed to 'labels' for the latest version.

If you have more questions, feel free to visit us in #zuul on IRC.



> Best regards,
>
> On 2017/09/29 23:58, Monty Taylor wrote:
>
>> Hey everybody!
>>
>> tl;dr - If you're having issues with your jobs, check the FAQ, this email
>> and followups on this thread for mentions of them. If it's an issue with
>> your job and you can spot it (bad config) just submit a patch with topic
>> 'zuulv3'. If it's bigger/weirder/you don't know - we'd like to ask that you
>> send a follow up email to this thread so that we can ensure we've got them
>> all and so that others can see it too.
>>
>> ** Zuul v3 Migration Status **
>>
>> If you haven't noticed the Zuul v3 migration - awesome, that means it's
>> working perfectly for you.
>>
>> If you have - sorry for the disruption. It turns out we have a REALLY
>> complicated array of job content you've all created. Hopefully the pain of
>> the moment will be offset by the ability for you to all take direct
>> ownership of your awesome content... so bear with us, your patience is
>> appreciated.
>>
>> If you find yourself with some extra time on your hands while you wait on
>> something, you may find it helpful to read:
>>
>>https://docs.openstack.org/infra/manual/zuulv3.html
>>
>> We're adding content to it as issues arise. Unfortunately, one of the
>> issues is that the infra manual publication job stopped working.
>>
>> While the infra manual publication is being fixed, we're collecting FAQ
>> content for it in an etherpad:
>>
>>https://etherpad.openstack.org/p/zuulv3-migration-faq
>>
>> If you have a job issue, check it first to see if we've got an entry for
>> it. Once manual publication is fixed, we'll update the etherpad to point to
>> the FAQ section of the manual.
>>
>> ** Global Issues **
>>
>> There are a number of outstanding issues that are being worked. As of
>> right now, there are a few major/systemic ones that we're looking in to
>> that are worth noting:
>>
>> * Zuul Stalls
>>
>> If you say to yourself "zuul doesn't seem to be doing anything, did I do
>> something wrong?", we're having an issue that jeblair and Shrews are
>> currently tracking down with intermittent connection issues in the backend
>> plumbing.
>>
>> When it happens it's an across the board issue, so fixing it is our
>> number one priority.
>>
>> * Incorrect node type
>>
>> We've got reports of things running on trusty that should be running on
>> xenial. The job definitions look correct, so this is also under
>> investigation.
>>
>> * Multinode jobs having POST FAILURE
>>
>> There is a bug in the log collection trying to collect from all nodes
>> while the old jobs were designed to only collect from the 'primary'.
>> Patches are up to fix this and should be fixed soon.
>>
>> * Branch Exclusions being ignored
>>
>> This has been reported and its cause is currently unknown.
>>
>> Thank you all again for your patience! This is a giant rollout with a
>> bunch of changes in it, so we 

[openstack-dev] [vitrage] Question about vitrage workings.

[Paul Vaduva]

Hi Vitrage team,

I have a question about vitrage workings. We use vitrage 1.3.1 with openstack 
newton release.
We have a NFV use case scenario where we get faults to compute nodes or 
openstack services (e.g. nova) that makes virtual machines running on that host 
to get lost / removed. We use a combination of alarms and Tacker to respawn a 
VM but sometimes (e. g. nova-compute service is faulted) we lose contact with 
the old vm and cannot delete it. When this happens somehow openstack is aware 
that vm is not in existence anymore (by means of "openstack server list" I 
mean) but Vitrage is still showing that vm as running.
My question is if there is a way to resynchronize VM state in Vitrage with the 
state from openstack.

Best Regards,
Paul Vaduva

__
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] [packaging][all] Sample Config Files in setup.cfg

[Jesse Pretorius]

On 10/10/17, 9:26 PM, "Doug Hellmann"  wrote:

> I still think we should just be looking at these files as sample
> data and not active configuration files when we put them into the sdist
> or wheel.

There is agreement from all distributions bar one on this approach so far, so 
I’d like to dig into this approach more to see if we can find a solution that 
works for everyone.

Thomas, do I understand the problem correctly that if we considered these 
sample files then the complexity for Debian appears to be that it would not 
want the sample config files in, for example, /usr/share/nova but instead in 
/usr/share/nova-common ? Is the use of the –common directory something that’s 
Debian specific, or do any other distributions do it?




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

[openstack-dev] [vitrage] No IRC meeting this week

[Paul Vaduva]

Hi Vitrage team,

I have a question about vitrage workings. We use vitrage 1.3.1 with openstack 
newton release.
We have a NFV use case scenario where we get faults to compute nodes or 
openstack services (e.g. nova) that makes virtual machines running on that host 
to get lost / removed. We use a combination of alarms and Tacker to respawn a 
VM but sometimes (e. g. nova-compute service is faulted) we lose contact with 
the old vm and cannot delete it. When this happens somehow openstack is aware 
that vm is not in existence anymore (by means of "openstack server list" I 
mean) but Vitrage is still showing that vm as running.
My question is if there is a way to resynchronize VM state in Vitrage with the 
state from openstack.

Best Regards,
Paul Vaduva
__
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] [qa][all] QA Office Hours

[Andrea Frittoli]

Dear all,

a kind reminder that tomorrow at 9:00 UTC we'll start office hours for the
QA team in the #openstack-qa channel.
Please join us with any question / comment you may have.

We'll triage bugs for QA projects from the past 7 days and then extend the
time frame if there is time left.

Kind regards

Andrea Frittoli (andreaf)

On Fri, Oct 6, 2017 at 12:09 PM Andrea Frittoli 
wrote:

> Dear all,
>
> Staring next week the QA team will start running office hours be-weekly
> (every send week) on Thursdays at 9:00 UTC.
> Office hours will happen in the #openstack-qa channel, and we'll use
> meetbot there to record info, action and generate dedicated logs.
>
> Several core developers from the QA program will be available, so please
> join us in the #openstack-qa channel to ask any question related QA
> projects.
>
> Faithfully,
>
> Andrea Frittoli (andreaf)
>
__
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] [ironic][inspector] Virtual Queens PTG

[milanisko k]

Folks,

I'd like to announce the end-of-poll with the leading option being:
*   Monday the 16th of October 14:00--15:30UTC[1]*

which essentially means 3 hours before our regular Ironic meeting (I hope I
have that right). The connection details are going to be announced on the
PTG Etherpad[2].

Thanks for Your votes and looking forward to see You there!
milan

[1] https://beta.doodle.com/poll/q7m4mnvv3h7k8eae#table
[2] https://etherpad.openstack.org/p/inspector-queens-virtual-ptg


po 9. 10. 2017 v 11:59 odesílatel milanisko k  napsal:

> Folks,
>
> I'd like to gently remind You about the poll and to thank to those who
> already voted!
> Also I'd like to set the end-of-poll date to tomorrow, EOB.
> In case You know someone who might like to join but is currently on PTO,
> please let me know.
>
> Cheers,
> milan
>
> pá 6. 10. 2017 v 13:40 odesílatel milanisko k  napsal:
>
>> Folks,
>>
>> as there have been multiple questions about Inspector that I couldn't
>> answer due to my PTG absence, I've decided to make it up to You and
>> organise a virtual inspector-focused PTG call (over some BlueJeans or TBD).
>>
>> The other Inspector Cores gracefully agreed to. I've selected the times
>> all of us were most comfortable with and would like to ask You to do the
>> same[1].
>>
>> As far as the program is concerned, I've created an Etherpad with some
>> bullets to base our discussion on[2], TL;DR of it being *current
>> Inspector status on HA filtering and plan on Ironic--Inspector merge*
>> and picking action items.
>>
>> I'd like to kindly invite You, the Community, to participate.
>>
>> Best Regards,
>> milan
>>
>> [1] https://doodle.com/poll/q7m4mnvv3h7k8eae
>> [2] https://etherpad.openstack.org/p/inspector-queens-virtual-ptg
>>
>>
__
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] overhead_pin_set option

[Sahid Orentino Ferdjaoui]

Some workloads require to have hypervisor overheads to be isolated
from the set of pCPUs running guest vCPUs threads.

For libvirt driver we have introduced the emulator threads placements
which provides an option to reserve an additional host CPU per guest
to pin the emulator threads on [0].

To extend the flexibility and address use-cases where resources on
hosts are limited. We are introducing 'overhead_pin_set' option on
compute node. Operators will have ability to reserve host CPUs for
hypervisor overhead.

For case of libvirt driver we are extending the flavor property
hw:emulator_threads_policy to accept 'host' value, meaning that the
guests configured to use hw:emulator_threads_policy=host will have
their emulator threads running on the set of pCPUs configured with
'overhead_pin_set' option.

The blueprint [1] on launchpad.net, patches [2] and spec updated [3]

[0] 
https://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/libvirt-emulator-threads-policy.html
[1] https://blueprints.launchpad.net/nova/+spec/overhead-pin-set
[2] https://review.openstack.org/#/c/510897/
[3] https://review.openstack.org/#/c/511188/

__
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] [tc][election] TC non-candidacy

[Thierry Carrez]

Monty Taylor wrote:
> I have decided not to seek reelection for the TC.

Thanks for all your insights and guidance during all those years. Please
continue to scream and let us know whenever we are doing anything crazy!

-- 
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] [zun] Client long description on PyPi

[Thomas Goirand]

Hi,

Could someone write something relevant, instead of the current
placeholder? See here:

https://pypi.python.org/pypi/python-zunclient

and see that "this is a hard requirement".

Cheers,

Thomas Goirand (zigo)

__
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] [ocata] nova-api error 404 instance not found

[Kim-Norman Sahm]

Hi Matt,

i'm using the ubuntu packages v15.0.6
the instances are mapped to the correct cell:

mysql> select * from nova_api.instance_mappings where instance_uuid =
-> "e564c631-896c-458c-93ab-b1c88f444fff";
+-+-+-+--
+-+--+
| created_at  | updated_at  | id  |
instance_uuid| cell_id |
project_id   |
+-+-+-+--
+-+--+
| 2017-10-10 08:16:32 | 2017-10-10 08:16:32 | 846 | e564c631-896c-458c-
93ab-b1c88f444fff |   6 | 7c1dd7d33037481e81f55d2f5d45bb90 |
+-+-+-+--
+-+--+

I've tried the workaround of this bug:
https://bugs.launchpad.net/nova/+bug/1682423

and its running correctly.

br
Kim



Am Dienstag, den 10.10.2017, 09:08 -0500 schrieb Matt Riedemann:
> On 10/10/2017 3:53 AM, Kim-Norman Sahm wrote:
> >
> > Hi,
> >
> > i've upgraded from newton to ocata and i my last problem (i hope
> > so) is
> > in the nova-api.
> > if i try to create a new instance (horizon or cli) i get an "404
> > instance no found" error but is instance is created and started as
> > well.
> >
> > nova-api.log:
> >
> > 2017-10-10 08:16:31.682 6 DEBUG nova.compute.api [req-4d354485-
> > cfe9-
> > 40f2-8507-a48e02db0af0 db88dca6f68c4ab2b82dbad7476bb122
> > 7c1dd7d33037481e81f55d2f5d45bb90 - default default] [instance:
> > e564c631-896c-458c-93ab-b1c88f444fff] Fetching instance by UUID get
> > /usr/lib/python2.7/dist-packages/nova/compute/api.py:2360
> > 2017-10-10 08:16:31.785 6 INFO nova.api.openstack.wsgi [req-
> > 4d354485-
> > cfe9-40f2-8507-a48e02db0af0 db88dca6f68c4ab2b82dbad7476bb122
> > 7c1dd7d33037481e81f55d2f5d45bb90 - default default] HTTP exception
> > thrown: Instance e564c631-896c-458c-93ab-b1c88f444fff could not be
> > found.
> > 2017-10-10 08:16:31.787 6 DEBUG nova.api.openstack.wsgi [req-
> > 4d354485-
> > cfe9-40f2-8507-a48e02db0af0 db88dca6f68c4ab2b82dbad7476bb122
> > 7c1dd7d33037481e81f55d2f5d45bb90 - default default] Returning 404
> > to
> > user: Instance e564c631-896c-458c-93ab-b1c88f444fff could not be
> > found.
> > __call__ /usr/lib/python2.7/dist-
> > packages/nova/api/openstack/wsgi.py:1039
> >
> > Does anybody know whats the problem?
> >
> > Best regards
> > Kim
> >
> >
> > Kim-Norman Sahm
> > Cloud & Infrastructure(OCI)
> > noris network AG
> > Thomas-Mann-Straße 16-20
> > 90471 Nürnberg
> > Deutschland
> > Tel +49 911 9352 1433
> > Fax +49 911 9352 100
> >
> > kim-norman.s...@noris.de
> > https://www.noris.de - Mehr Leistung als Standard
> > Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel
> > Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB
> > 17689
> >
> >
> >
> >
> >
> >
> > ___
> > ___
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
> > bscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> Do you have all of the latest fixes for Ocata? You should be at
> version
> 15.0.7 if you're on the latest Ocata fix release.
>
> Is the instance properly mapped to a cell? Try querying the nova_api
> database:
>
> select * from nova_api.instance_mappings where instance_uuid =
> "e564c631-896c-458c-93ab-b1c88f444fff";
>
> Did the instance go to ACTIVE state or did it fail to schedule? If
> it
> failed to schedule, it would be in the nova_cell0 database and should
> be
> in ERROR state. You could query the cell0 database with:
>
> select * from nova_cell0.instances where uuid =
> "e564c631-896c-458c-93ab-b1c88f444fff";
>
> Otherwise see #3 in the Cells FAQs page here:
>
> https://docs.openstack.org/nova/latest/user/cells#faqs
>


Kim-Norman Sahm
Cloud & Infrastructure(OCI)
noris network AG
Thomas-Mann-Straße 16-20
90471 Nürnberg
Deutschland
Tel +49 911 9352 1433
Fax +49 911 9352 100

kim-norman.s...@noris.de
https://www.noris.de - Mehr Leistung als Standard
Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel
Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689






smime.p7s
Description: S/MIME cryptographic 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] [packaging][all] Sample Config Files in setup.cfg

[Thomas Bechtold]

Hi,

On 10.10.2017 13:04, Jesse Pretorius wrote:

On 9/29/17, 7:18 AM, "Thomas Bechtold"  wrote:


This will still install the files into usr/etc :



$ python setup.py install --skip-build --root /tmp/sahara-install > 
/dev/null
$ ls /tmp/sahara-install/usr/
bin  etc  lib



It's not nice but packagers can workaround that.


I gave this a try this morning:

$ python setup.py install --skip-build --root /tmp/keystone --install-data /
$ find /tmp/keystone -maxdepth 6 -type d
/tmp/keystone
/tmp/keystone/usr
/tmp/keystone/usr/local
/tmp/keystone/usr/local/bin
/tmp/keystone/usr/local/lib
/tmp/keystone/usr/local/lib/python2.7
/tmp/keystone/usr/local/lib/python2.7/dist-packages
/tmp/keystone/usr/local/lib/python2.7/dist-packages/keystone-12.0.0.0rc2.dev101.egg-info
/tmp/keystone/usr/local/lib/python2.7/dist-packages/keystone
/tmp/keystone/etc
/tmp/keystone/etc/keystone

Is this perhaps useful?


Now the python files are in usr/local which is wrong for distros. It 
should be usr/


Tom

__
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] [Zaqar] Nominating gecong for Zaqar core

[Thomas Herve]

On Tue, Oct 10, 2017 at 11:15 PM, feilong  wrote:
> Hi team,
>
> I would like to propose adding Cong Ge(gecong) for the Zaqar core team.
> He has been an awesome contributor since joining the Zaqar team. And now
> he is currently the most active non-core reviewer on Zaqar projects for
> the last 180 days[1]. Cong has great technical expertise and contributed
> many high quality patches. I'm sure he would be an excellent addition to
> the team. If no one objects, I'll proceed and add him in a week from
> now. Thanks.

+1!

-- 
Thomas

__
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] [ptls] Sydney Forum Project Onboarding Rooms

[Sam P]

Hi Kendall,

 Thank you for info.
 If slots are still available, we would like to do an On-boarding
session for Masakari [1].
 # BTW, got the TC approval yesterday [2]...


[1] https://wiki.openstack.org/wiki/Masakari
[2] https://review.openstack.org/#/c/500118/
--- Regards,
Sampath



On Wed, Oct 11, 2017 at 5:12 AM, Kendall Nelson  wrote:
> Of course :) I added Designate.
>
> -Kendall Nelson(diablo_rojo)
>
>
> On Tue, Oct 10, 2017 at 1:01 PM Graham Hayes  wrote:
>>
>> Can I add designate? I will be there to look after the room.
>>
>> Thanks,
>>
>> Graham
>>
>>
>> On Tue, 10 Oct 2017, at 20:20, Kendall Nelson wrote:
>>
>> Added :)
>> -Kendall (diablo_rojo)
>>
>> On Tue, Oct 10, 2017 at 2:11 AM Spyros Trigazis 
>> wrote:
>>
>> Magnum - Spyros Trigazis - 
>>
>> Thanks!
>>
>> On 9 October 2017 at 23:24, Kendall Nelson  wrote:
>> > Wanted to keep this thread towards the top of inboxes for those I
>> > haven't
>> > heard from yet.
>> >
>> > About a 1/4 of the way booked, so there are still slots available!
>> >
>> > -Kendall (diablo_rojo)
>> >
>> >
>> > On Thu, Oct 5, 2017 at 8:50 AM Kendall Nelson 
>> > wrote:
>> >>
>> >> Hello :)
>> >>
>> >> We have a little over 40 slots available so we should be able to
>> >> accommodate almost everyone, but it will be a first response first
>> >> serve
>> >> basis.
>> >>
>> >> Logistics: Slots are 40 min long and will have projection set up in
>> >> them.
>> >> The rooms have a capacity of about 40 people and will be set up
>> >> classroom
>> >> style.
>> >>
>> >> If you are interested in reserving a spot, just reply directly to me
>> >> and I
>> >> will put your project on the list. Please let me know if you want one
>> >> and
>> >> also include the names and emails anyone that will be speaking with
>> >> you.
>> >>
>> >> When slots run out, they run out.
>> >>
>> >> Thanks!
>> >>
>> >> -Kendall Nelson (diablo_rojo)
>> >
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
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] [Blazar] Team mascot idea

[Sylvain Bauza]

FWIW, the original name for Blazar was "Climate" so what about a weather
frog ? :-)

-Sylvain

2017-10-11 7:29 GMT+02:00 Masahito MUROI :

> Hi Blazar folks,
>
> As we discussed the topic in the last meeting, we're gathering an idea for
> the project mascot[1].
>
> Current ideas are following fours. If you have or come into mind another
> idea, please replay this mail.  We'll decided the candidacy at the next
> meeting.
>
> - house mouse
> - squirrel
> - shrike
> - blazar
>
>
> 1. https://www.openstack.org/project-mascots
>
> best regards,
> Masahito
>
>
> __
> 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] Update on Zuul v3 Migration - and what to do about issues

[Andreas Jaeger]

On 2017-10-11 09:21, milanisko k wrote:
> Hi,
> 
> without any deeper investigation (yet) I'd like to share this patch
> status https://review.openstack.org/#/c/468712/
> Seems Zuul voted -1 even though all jobs were green...

If you hit the "Toggle CI" button, you see:

legacy-grenade-dsvm-ironic-inspector
finger://ze01.openstack.org/9c9f80b5b54b4b1e9d6689314818d437 : ABORTED
in 1h 44m 45s

So, a job was aborted - and looking at timing, this might be due to our
restart of Zuul v3,

The -1 is for this one,
Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] Update on Zuul v3 Migration - and what to do about issues

[milanisko k]

Hi,

without any deeper investigation (yet) I'd like to share this patch status
https://review.openstack.org/#/c/468712/
Seems Zuul voted -1 even though all jobs were green...

Cheers,
milan

2017-10-11 7:31 GMT+02:00 Rikimaru Honjo :

> Hello,
>
> I'm trying to install & configure nodepool for Zuul v3 in my CI
> environment now.
> I use feature/zuulv3 branch.(ver. 0.4.1.dev430)
>
> I referred nodepool documents and infra/project-config tree.
> And I have some questions about this version of nodepool.
>
> 1)Is there the information about differences of configuration between
> nodepool for zuul v2 and v3?
>   Or, can I configure feature/zuulv3 basically same as lower version?
>
> 2)Below suggestion is wrote in README.rst.
>   But such file is not contained in the infra/system-config tree now.
>   Where is the file?
>
> Create or adapt a nodepool yaml file. You can adapt an infra/system-config
>> one, or fake.yaml as desired. Note that fake.yaml's settings won't Just
>> Work - consult ./modules/openstack_project/te
>> mplates/nodepool/nodepool.yaml.erb in the infra/system-config tree to
>> see a production config.
>>
>
> 3)Can I use "images" key in "providers"?
>   I used "images" in nodepool ver.0.3.1, but below sample file doesn't use
> the key.
>
>   https://github.com/openstack-infra/nodepool/blob/feature/zuu
> lv3/tools/fake.yaml
>
> Best regards,
>
> On 2017/09/29 23:58, Monty Taylor wrote:
>
>> Hey everybody!
>>
>> tl;dr - If you're having issues with your jobs, check the FAQ, this email
>> and followups on this thread for mentions of them. If it's an issue with
>> your job and you can spot it (bad config) just submit a patch with topic
>> 'zuulv3'. If it's bigger/weirder/you don't know - we'd like to ask that you
>> send a follow up email to this thread so that we can ensure we've got them
>> all and so that others can see it too.
>>
>> ** Zuul v3 Migration Status **
>>
>> If you haven't noticed the Zuul v3 migration - awesome, that means it's
>> working perfectly for you.
>>
>> If you have - sorry for the disruption. It turns out we have a REALLY
>> complicated array of job content you've all created. Hopefully the pain of
>> the moment will be offset by the ability for you to all take direct
>> ownership of your awesome content... so bear with us, your patience is
>> appreciated.
>>
>> If you find yourself with some extra time on your hands while you wait on
>> something, you may find it helpful to read:
>>
>>https://docs.openstack.org/infra/manual/zuulv3.html
>>
>> We're adding content to it as issues arise. Unfortunately, one of the
>> issues is that the infra manual publication job stopped working.
>>
>> While the infra manual publication is being fixed, we're collecting FAQ
>> content for it in an etherpad:
>>
>>https://etherpad.openstack.org/p/zuulv3-migration-faq
>>
>> If you have a job issue, check it first to see if we've got an entry for
>> it. Once manual publication is fixed, we'll update the etherpad to point to
>> the FAQ section of the manual.
>>
>> ** Global Issues **
>>
>> There are a number of outstanding issues that are being worked. As of
>> right now, there are a few major/systemic ones that we're looking in to
>> that are worth noting:
>>
>> * Zuul Stalls
>>
>> If you say to yourself "zuul doesn't seem to be doing anything, did I do
>> something wrong?", we're having an issue that jeblair and Shrews are
>> currently tracking down with intermittent connection issues in the backend
>> plumbing.
>>
>> When it happens it's an across the board issue, so fixing it is our
>> number one priority.
>>
>> * Incorrect node type
>>
>> We've got reports of things running on trusty that should be running on
>> xenial. The job definitions look correct, so this is also under
>> investigation.
>>
>> * Multinode jobs having POST FAILURE
>>
>> There is a bug in the log collection trying to collect from all nodes
>> while the old jobs were designed to only collect from the 'primary'.
>> Patches are up to fix this and should be fixed soon.
>>
>> * Branch Exclusions being ignored
>>
>> This has been reported and its cause is currently unknown.
>>
>> Thank you all again for your patience! This is a giant rollout with a
>> bunch of changes in it, so we really do appreciate everyone's understanding
>> as we work through it all.
>>
>> Monty
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
> --
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> Rikimaru Honjo
> E-mail:honjo.rikim...@po.ntt-tx.co.jp
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 

Re: [openstack-dev] Thanks for all the fish

[Jean-Philippe Evrard]

On Wed, Oct 11, 2017 at 1:34 AM, Lana Brindley
 wrote:
> Hi everyone,
>
> As most of you know, I was caught up in the Rackspace layoffs that happened 
> earlier this year, and have been looking for work (in between knee surgery) 
> since then. Well, in good news for my bank account, I have now secured a new 
> job with a startup based here in Brisbane. The bad news is that, while it's 
> working on cool stuff and is likely to be at least partially open sourced at 
> some point, there's currently no scope for me to continue working on 
> OpenStack. Sadly, an OpenStack related position just did not come my way, 
> despite my best efforts.
>
> So, this is goodbye for now. I'm going to unsubscribe from the OpenStack 
> mailing lists, and resign my core positions, but you can still email me at 
> this address if you want to. Feel free to hit me up on LinkedIn or Twitter, 
> if that's your thing.
>
> I'm going to miss being part of the community we built here, and all the 
> fabulous people I've met over my OpenStack years. Keep being awesome, I'll be 
> cheering from the sidelines.
>
> Keep on Doc'ing :)
>
> Lana
>
> --
> Lana Brindley
> Technical Writer
> http://lanabrindley.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
>

Congratulations on the new job.

You'll be missed, for sure! Thanks for the work done.

Best regards,
Jean-Philippe Evrard (evrardjp)

__
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] What logical clock does OpenStack use

[Puneet Jain]

Hi,

I was just curious to know, how the event ordering happens in OpenStack?
What clock does it use? I mean does it use Lamport Logical Clock?

-- 
Best
Regards,
Puneet Jain


__
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