[openstack-dev] [cyborg]Cyborg PTG Schedule

[Zhipeng Huang]

Hi Team,

After some discussion, we have tentatively setup our project specific
schedule for Dublin PTG meeting.

*Meetings:*

In general, Cyborg project gathering will happen on Monday and Tuesday [0].

Due to several meeting conflicts, we divide our gathering meeting into two
parts for each day:

(1) Office Hour: 9:00am - 12:00pm. Cyborg core member will be around our
meeting room to answer questions, devstack setup, and so forth.
(2) Discussion Session: 2:00pm - 6:00pm. Rocky Cycle dev discussion. We
will have ZOOM conference for each topic and thus each topic got 40 mins.

*Team Photo:*

Team photo is Tuesday 11:50 - 12:00 [1]

*Team Interview:*

Team Interview is Tuesday 13:00 [2]

*Team Dinner:*

We will have team dinner on Tuesday night, venue info to be updated later :)

For specific topic arrangement , plze refer to [3]

[0] https://www.openstack.org/ptg/#tab_schedule
[1]
https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
[2]
https://docs.google.com/spreadsheets/d/1MK7rCgYXCQZP1AgQ0RUiuc-cEXIzW5RuRzz5BWhV4nQ/edit#gid=0
[3] https://etherpad.openstack.org/p/cyborg-ptg-rocky

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
OpenStack Development Mailing 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] [monasca][congress] help configuring monasca for gate

[Eric K]

Oops. Nevermind. Looks like it's working now.

On 2/12/18, 5:00 PM, "Eric K"  wrote:

>Hi Monasca folks,
>I'm trying to configure monasca in congress gate [1] and modeled it after
>this monasca playbook [2]. But I get:
>rsync: change_dir "/home/zuul/src/*/openstack/monasca-common" failed: No
>such file or directory (2)
>
>http://logs.openstack.org/22/530522/1/check/congress-devstack-api-mysql/16
>6
>d935/logs/devstack-gate-setup-workspace-new.txt.gz#_2017-12-30_01_53_41_60
>7
>
>
>Any hints on what I need to do differently? Thanks!
>
>[1] https://review.openstack.org/#/c/530522/
>[2] 
>https://github.com/openstack/monasca-api/blob/master/playbooks/legacy/mona
>s
>ca-tempest-base/run.yaml
>
>



__
OpenStack Development Mailing 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][Kingbird][Heat][Glance]Multi-Region Orchestrator

[Goutham Pratapa]

Hi Colleen,

Thanks for writing to us.

Sure, we will definitely try to help as much as we can :).



On Mon, Feb 12, 2018 at 8:44 PM, Colleen Murphy  wrote:

> On Mon, Feb 12, 2018 at 7:44 AM, Goutham Pratapa
>  wrote:
> 
> >
> > OUR USE-CASES QUOTA-MANAGEMENT:
> >
> > 1. Admin must have a global view of all quotas to all tenants across all
> the
> > regions
> > 2. Admin can periodically balance the quotas (we have a formula using
> which
> > we do this balancing ) across regions
> > 3. Admin can update, Delete quotas for tenants
> > 4. Admin can sync quotas for all tenants so that the quotas will be
> updated
> > in all regions.
>
> Global quota management is something we're seeking to solve in
> keystone[1][2][3][4], which would enable admins to do 1, 3, and 4 via
> keystone (though admittedly this is a few cycles out). We expect to
> dive into this at the PTG if you'd like to help shape this work.
>
> [1] http://specs.openstack.org/openstack/keystone-specs/
> specs/keystone/ongoing/unified-limits.html
> [2] http://specs.openstack.org/openstack/keystone-specs/
> specs/keystone/queens/limits-api.html
> [3] https://review.openstack.org/#/c/441203/
> [4] https://review.openstack.org/#/c/540803/
>
> 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
>



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

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

[Naveen Joy (najoy)]

Hello Everyone,

In conjunction with the release of VPP 18.01, we'd like to invite you all to 
try out networking-vpp 18.01 for VPP 18.01.
VPP is a fast userspace forwarder based on the DPDK toolkit, and uses vector 
packet processing algorithms to minimize the CPU time spent on each packet and 
maximize throughput.
networking-vpp is a ML2 mechanism driver that controls VPP on your control and 
compute hosts to provide fast L2 forwarding under Neutron.

This version has a few additional enhancements, along with supporting the VPP 
18.01 APIs:
- L3 HA
- VM Live Migration
- Neutron protocol names in a security group rule

Along with this, there have been the usual upkeep as Neutron versions change, 
bug fixes, code and test improvements.

The README [1] explains how you can try out VPP using devstack: the devstack 
plugin will deploy the mechanism driver and VPP itself and should give you a 
working system with a minimum of hassle.
It will use the etcd version deployed by newer versions of devstack.

We will be continuing our development between now and VPP's 18.04 release in 
April.
There are several features we're planning to work on (you'll find a list in our 
RFE bugs at [2]), and we welcome anyone who would like to come help us.

Everyone is welcome to join our biweekly IRC meetings, every other Monday (the 
next one is due in a week), 0800 PST = 1600 GMT.
--
Naveen & Ian

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

[openstack-dev] [monasca][congress] help configuring monasca for gate

[Eric K]

Hi Monasca folks,
I'm trying to configure monasca in congress gate [1] and modeled it after
this monasca playbook [2]. But I get:
rsync: change_dir "/home/zuul/src/*/openstack/monasca-common" failed: No
such file or directory (2)

http://logs.openstack.org/22/530522/1/check/congress-devstack-api-mysql/166
d935/logs/devstack-gate-setup-workspace-new.txt.gz#_2017-12-30_01_53_41_607


Any hints on what I need to do differently? Thanks!

[1] https://review.openstack.org/#/c/530522/
[2] 
https://github.com/openstack/monasca-api/blob/master/playbooks/legacy/monas
ca-tempest-base/run.yaml



__
OpenStack Development Mailing 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] github.com/openstack/nova-specs mirror temporarily broken

[melanie witt]

> On Feb 12, 2018, at 16:26, melanie witt  wrote:
> 
> Hey Stackers,
> 
> This is just a heads up that the github mirror of the nova-specs repo has 
> been temporarily broken for the past few months and doesn’t have the 
> specs/rocky/ directory in it. Fixing it is on the TODO list for the next 
> scheduled maintenance window, but until then, please git clone the 
> https://git.openstack.org/cgit/openstack/nova-specs version to propose your 
> specs [1] for Rocky.
> 
> Cheers,
> -melanie
> 
> [1] http://specs.openstack.org/openstack/nova-specs/readme.html

s/maintenance/gerrit maintenance/
__
OpenStack Development Mailing 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] github.com/openstack/nova-specs mirror temporarily broken

[melanie witt]

Hey Stackers,

This is just a heads up that the github mirror of the nova-specs repo has been 
temporarily broken for the past few months and doesn’t have the specs/rocky/ 
directory in it. Fixing it is on the TODO list for the next scheduled 
maintenance window, but until then, please git clone the 
https://git.openstack.org/cgit/openstack/nova-specs version to propose your 
specs [1] for Rocky.

Cheers,
-melanie

[1] http://specs.openstack.org/openstack/nova-specs/readme.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] Lunchtime during PTG

[Kendall Nelson]

He Miguel :)

We have lunch scheduled from 12:30-1:30 with the last half hour being
presentations while you eat. For topics, see this thread[1]

Let me know if you have any other questions!

-Kendall (diablo_rojo)

[1]
http://lists.openstack.org/pipermail/openstack-tc/2018-February/001492.html

On Mon, Feb 12, 2018 at 2:35 PM Miguel Lavalle  wrote:

> Hi,
>
> In order to schedule team sessions during the PTG I would like to know the
> time lunch is going to be served. It is not in the schedule:
> https://www.openstack.org/ptg/#tab_schedule
>
> Cheers
>
> Miguel
>
>
> __
> OpenStack Development Mailing 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][cyborg]Dublin PTG Cyborg Nova Interaction Discussion

[Zhipeng Huang]

Let's settle on Tuesday afternoon session then, thanks a lot :)

On Tue, Feb 13, 2018 at 1:43 AM, Ed Leafe  wrote:

> On Feb 12, 2018, at 9:57 AM, Chris Dent  wrote:
> >
> > Tuesday would be best for me as Monday is api-sig day.
>
> Same, for the same reason.
>
>
> -- Ed Leafe
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
OpenStack Development Mailing 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][triploe] support for firmware update

[Stig Telfer]

Hi Moshe - 

It seems a bit risky to automatically apply firmware updates.  For example, 
given a node will probably be rebooted for firmware updates to take effect, if 
other vendors also did this then perhaps the node could reboot unexpectedly in 
the middle of your update.  In theory.

The approach we’ve taken on handling firmware updates[1] has been to create a 
hardware manager for verifying firmware values during node cleaning and raising 
an exception if they do not match.  The consequence is, nodes will drop into 
maintenance mode for manual inspection / intervention.  We’ve then booted the 
node into a custom image to perform the update.

Hope this helps,
Stig

[1] https://github.com/stackhpc/stackhpc-ipa-hardware-managers

> On 8 Feb 2018, at 07:43, Moshe Levi  wrote:
> 
> Hi all,
>  
> I saw that ironic-python-agent support custom hardware manager.
> I would like to support firmware updates (In my case Mellanox nic) and I was 
> wandering how custom hardware manager can be used in such case?
> How it is integrated with ironic-python agent and also is there an 
> integration to tripleO as well.
>  
> The use case for use is just to make sure the correct firmware is installed 
> on the nic and if not update it during the triple deployment.
>  
>  
>   
>  
> [1] - 
> https://docs.openstack.org/ironic-python-agent/pike/contributor/hardware_managers.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

[openstack-dev] [ironic] PTG Planning Etherpad

[Julia Kreger]

Greetings fellow Ironic humanoids!

We have had a planning etherpad [1] up for a couple weeks collecting ideas.

If you plan on attending the Ironic sessions at the PTG, please post
any additional ideas as well as feedback for the other ideas. We also
need an idea of interest for the purposes of prioritization, so a +1
on items you feel is important will help us create an agenda.

If you will not be attending the PTG and have an item that requires
discussion, please feel free to add items and provide feedback. If
there is a particular item that you feel needs the attention of the
Ironic team, make sure that you provide additional context as to why
an item is important, and any references that may help context.

I will rank the items by priority, and generate a reasonable agenda
from the ideas this coming Friday the 16th. Items added after 5 PM UTC
on the Friday the 16th may not make the agenda.

Thanks,

-Julia

[1] https://etherpad.openstack.org/p/ironic-rocky-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] [barbican] barbican 6.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/barbican/

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

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

http://git.openstack.org/cgit/openstack/barbican/log/?h=stable/queens

Release notes for barbican can be found at:

http://docs.openstack.org/releasenotes/barbican/




__
OpenStack Development Mailing 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] [heat] No Meeting This week

[Kaz Shinohara]

Hi Rico,


Hope you and your family have good holidays:)

I have one thing hopefully before your off.
Looks heat-dashboard does not have stable/queens branch yet.
I got an indication about this from Horizon core and they are waiting for
that heat-dashboard will have it.
(we want to drop django <= 1.10 support along with Horizon for Rocky)
Cloud you kindly take care of this issue ?

Your response will be highly appreciated.

Regards,
Kaz (kazsh)


2018-02-12 23:35 GMT+09:00 Rico Lin :

> Hi all
> Good news first! We released queens last week, so well done everyone.
>
> This week is Chinese new year, and Wednesday happen to be new year eve, so
> I will not hosting the meeting this week.
>
> Let's skip this one if no important stuff to talk about.
>
> See you at next meeting
>
>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][lbaas][neutron-lbaas][octavia] Announcing the deprecation of neutron-lbaas and neutron-lbaas-dashboard

[Michael Johnson]

Hi Gary,

All of the answers to your questions are on the FAQ linked in the announcement.

1: If you are already using the Octavia driver or the neutron-lbaas
proxy driver, you are already migrated. We will provide a port
migration tool to migrate the neutron port ownership from
neutron-lbaas if neutron-lbaas was configured to create your VIP ports
for the Octavia driver.  For other drivers we will provide a migration
tool during Rocky. The databases are very similar so migrating from
neutron-lbaas will be fairly straight forward.
2: You are correct that currently there are no vendor drivers for
Octavia.  As you probably know, the new and improved driver interface
specification was merged during Queens (A representative from your
employer contributed to the specification).  We expect over the course
of Rocky vendor drivers will become available. This is part of the
motivation for announcing the start of deprecation.
3: This is in no way like the migration from LBaaS v1 to v2. The
largest reason is the LBaaS v2 API is fully compatible with the
Octavia API (it implements LBaaS v2). We did not change the model. The
current load balancer team can't really talk to the choices made in
the V1 to V2 API migrations.

As I have mentioned in the FAQ and on your patch comments,
neutron-lbaas will be maintained with bug fixes for the duration of
the deprecation cycle, which will be a minimum of two OpenStack
releases.

I am sorry you did not get to participate in the discussions and vote
for the start of the deprecation cycle.  We announced that we were
going to work towards this a year and a half ago in a specification
approved by the neutron cores:
http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html
It has been a major topic at our PTG sessions, summits, and weekly
meetings since then.  The team vote that we are ready to announce was
unanimous at our 1/24/2018 IRC meeting.

I hope you will join us going forward to make this deprecation a
success.  We meet weekly on IRC and will be at the PTG.

Michael

On Mon, Feb 12, 2018 at 4:12 AM, Gary Kotton  wrote:
> Hi,
> I have a number of issues with this:
> 1. I do not think that we should mark this as deprecated until we have a 
> clear and working migration patch. Let me give an example. Say I have a user 
> who is using Pike or Queens and has N LBaaS load balancers up and running. 
> What if we upgrade to T and there is no LBaaS, only Octavia. What is the 
> migration path here? Maybe I have missed this and would be happy to learn how 
> this was done.
> 2. I think that none of the load balancing vendors have code in Octavia and 
> this may be a problem (somewhat related to #1). I guess that there is enough 
> warning but this is still concerning
> 3. The migration from V1 to V2 was not successful. So, I have some concerns 
> about going to a new service completely.
> I prefer that we hold off on this until there is a clear picture.
> Thanks
> Gary
>
> On 2/1/18, 9:22 AM, "Andreas Jaeger"  wrote:
>
> On 2018-01-31 22:58, Akihiro Motoki wrote:
> > I don't think we need to drop translation support NOW (at least for
> > neutron-lbaas-dashboard).
> > There might be fixes which affects translation and/or there might be
> > translation improvements.
> > I don't think a deprecation means no translation fix any more. It
> > sounds too aggressive.
> > Is there any problem to keep translations for them?
>
> Reading the whole FAQ - since bug fixes are planned, translations can
> merge back. So, indeed we can keep translation infrastructure set up.
>
> I recommend to translators to remove neutron-lbaas-dashboard from the
> priority list,
>
> Andreas
>
> > Akihiro
> >
> > 2018-02-01 3:28 GMT+09:00 Andreas Jaeger :
> >> In that case, I suggest to remove translation jobs for these 
> repositories,
> >>
> >> 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
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: 

[openstack-dev] Lunchtime during PTG

[Miguel Lavalle]

Hi,

In order to schedule team sessions during the PTG I would like to know the
time lunch is going to be served. It is not in the schedule:
https://www.openstack.org/ptg/#tab_schedule

Cheers

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

Re: [openstack-dev] [requirements] we are now unfrozen and branched

[Matthew Thode]

On 18-02-12 16:13:30, William M Edmonds wrote:
> I'm not seeing a stable/queens branch for openstack/requirements yet. Is
> that not what you meant? When is that projected?
> 
> Matthew Thode  wrote on 02/12/2018 11:25:44 AM:
> > This means we are back to business as usual.
> >
> > cycle trailing projects have been warned not to merge requirements
> > updates until they branch or get an ack from a requirements core.
> >

It's done now, gate problems delayed it.

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [ironic] team dinner at Dublin PTG?

[Ruby Loo]

On Mon, Feb 5, 2018 at 5:42 PM, Loo, Ruby  wrote:

> Hi ironic-ers,
>
> Planning for the Dublin PTG has started. And what's the most important
> thing (and most fun event) to plan for? You got it, the team dinner! We'd
> like to get an idea of who is interested and what evening works for all or
> most of us.
>
> Please indicate which evenings you are available, at this doodle:
> https://doodle.com/poll/d4ff6m9hxg887n9q
>
> If you're shy or don't want to use doodle, send me an email.
>
> Please respond by Friday, Feb 16 (same deadline as PTG
> topics-for-discussion), so we can find a place and reserve it.
>
> Thanks!
> --ruby
>
>
Reminder to doodle [1] if you haven't done so already. Also, because we're
all so keen to know when and where we're going, we want to decide sooner,
so please respond by tomorrow (Tues, Feb 13). Thanks!

--ruby

[1] https://doodle.com/poll/d4ff6m9hxg887n9q
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements] we are now unfrozen and branched

[William M Edmonds]

I'm not seeing a stable/queens branch for openstack/requirements yet. Is
that not what you meant? When is that projected?

Matthew Thode  wrote on 02/12/2018 11:25:44 AM:
> This means we are back to business as usual.
>
> cycle trailing projects have been warned not to merge requirements
> updates until they branch or get an ack from a requirements core.
>
> --
> Matthew Thode (prometheanfire)
>
__
> OpenStack Development Mailing 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] [osc][python-openstackclient] Consistency of option name

[William M Edmonds]

Graham Hayes  wrote on 02/12/2018 11:17:45 AM:
> On 12/02/18 16:04, William M Edmonds wrote:
> > keystone may have taken "domain", but it didn't take "dns-domain"
>
> No, but the advice at the time was to move to zone, and match DNS
> RFCs, and not namespace objects with the service type.
>

I wasn't trying to criticize or question history but rather to look
forward. IF we change the name, "dns-domain" could be an option. That is
all.
__
OpenStack Development Mailing 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] Notification update week 7

[Matt Riedemann]

On 2/12/2018 11:11 AM, Balázs Gibizer wrote:

Add the user id and project id of the user initiated the instance
action to the notification
-
The bp 
https://blueprints.launchpad.net/nova/+spec/add-action-initiator-to-instance-action-notifications 
was shortly discussed on the last nova weekyl meeting, there was no 
objection but it still pending approval.


This is approved now. We agreed to approve this in the the Feb 8 
meeting, I just forgot to do it.


--

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] [keystone] Queens backports

[Lance Bragstad]

Hey all,

Now that we have a stable/queens branch, I've created a
"queens-backport-potential" bug tag. Feel free to use this if you triage a
bug that needs to be backported.

Thanks,

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

Re: [openstack-dev] [charms] Propose Andrew McLeod for OpenStack Charmers team

[Pete Vander Giessen]

+1 from me, too.

On Mon, Feb 12, 2018 at 12:39 PM Alex Kavanagh 
wrote:

> Positive +1 from me.  Andrew would make a great additiona.
>
> On Mon, Feb 12, 2018 at 5:00 PM, Ryan Beisner 
> wrote:
>
>> Hi All,
>>
>> I'd like to propose Andrew McLeod for the OpenStack Charmers (LP) and
>> charms-core (Gerrit) teams.  Andrew has made many commits and bugfixes to
>> the OpenStack Charms over the past couple of years, and he has general
>> charming knowledge and experience which is wider than just OpenStack.
>>
>> He has actively participated in the last two OpenStack Charms release
>> processes.  He is also the original author and current maintainer of the
>> magpie charm.
>>
>> Cheers,
>>
>> Ryan
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Alex Kavanagh - Software Engineer
> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] this week's priorities and subteam reports

[Yeleswarapu, Ramamani]

Hi,

We are glad to present this week's priorities and subteam report for Ironic. As 
usual, this is pulled directly from the Ironic whiteboard[0] and formatted.

This Week's Priorities (as of the weekly ironic meeting)


Weekly priorities
-
- Fix the multitenant grenade - https://bugs.launchpad.net/ironic/+bug/1744139
- Add tempest job for ironic queens branch  https://review.openstack.org/543555
- CI and docs work for classic drivers deprecation (see status below)
- Required Backports/Nice to haves below
- CRITICAL bugs (must be fixed and backported to queens before the release)
- ironic-inspector: rare crash when ironic port list returns HTTP 400 
https://bugs.launchpad.net/ironic-inspector/+bug/1748893
- the actual bug is that ironic returns 400 on port.list when node 
deletion races with it
- ironic-inspector: broken noauth mode: 
https://bugs.launchpad.net/ironic-inspector/+bug/1748263
- Fix as many bugs as possible

Required Queens Backports
-
- Traits instance_info validation - https://review.openstack.org/#/c/543461/
- mgoddard says it is a nice to have
- Switch to hardware types
- https://review.openstack.org/#/c/537959/

Nice to have backports
--
- Ansible docs - https://review.openstack.org/#/c/525501/
- inspector: do not try passing non-MACs as switch_id: 
https://review.openstack.org/542214

Vendor priorities
-
cisco-ucs:
Patches in works for SDK update, but not posted yet, currently rebuilding 
third party CI infra after a disaster...
idrac:
RFE and first several patches for adding UEFI support will be posted by 
Tuesday, 1/9
ilo:
https://review.openstack.org/#/c/530838/ - OOB Raid spec for iLO5
irmc:
None

oneview:


Subproject priorities
-
bifrost:
ironic-inspector (or its client):

networking-baremetal:

networking-generic-switch:
- initial release note https://review.openstack.org/#/c/534201/ MERGED

sushy and the redfish driver:


Bugs (dtantsur, vdrok, TheJulia)

- Stats (diff between  5 Feb 2018 and 12 Feb 2018)
- Ironic: 209 bugs (-13) + 247 wishlist items. 2 new (+1), 157 in progress 
(-4), 1 critical, 29 high (-5) and 20 incomplete (-5)
- Inspector: 17 bugs (+3) + 25 wishlist items. 0 new, 14 in progress (+2), 2 
critical (+2), 3 high (+1) and 4 incomplete
- Nova bugs with Ironic tag: 14. 1 new, 0 critical, 0 high
- via http://dashboard-ironic.7e14.starter-us-west-2.openshiftapps.com/
- the dashboard was abruptly deleted and needs a new home :(
- use it locally with `tox -erun` if you need to
- HIGH bugs with patches to review:
- Clean steps are not tested in gate 
https://bugs.launchpad.net/ironic/+bug/1523640: Add manual clean step ironic 
standalone test https://review.openstack.org/#/c/429770/15
- Needs to be reproposed to the ironic tempest plugin repository.
- prepare_instance() is not called for whole disk images with 'agent' deploy 
interface https://bugs.launchpad.net/ironic/+bug/1713916:
- Fix ``agent`` deploy interface to call ``boot.prepare_instance`` 
https://review.openstack.org/#/c/499050/
- (TheJulia) Currently WF-1, as revision is required for deprecation.
- If provisioning network is changed, Ironic conductor does not behave 
correctly https://bugs.launchpad.net/ironic/+bug/1679260: Ironic conductor 
works correctly on changes of networks: https://review.openstack.org/#/c/462931/
- (rloo) needs some direction
- may be fixed as part of https://review.openstack.org/#/c/460564/

CI refactoring and missing test coverage

- not considered a priority, it's a 'do it always' thing
- Standalone CI tests (vsaienk0)
- next patch to be reviewed, needed for 3rd party CI: 
https://review.openstack.org/#/c/429770/
- localboot with partitioned image patches:
- Ironic - add localboot partitioned image test: 
https://review.openstack.org/#/c/502886/
- when previous are merged TODO (vsaienko)
- Upload tinycore partitioned image to tarbals.openstack.org
- Switch ironic to use tinyipa partitioned image by default
- Missing test coverage (all)
- portgroups and attach/detach tempest tests: 
https://review.openstack.org/382476
- adoption: https://review.openstack.org/#/c/344975/
- should probably be changed to use standalone tests
- root device hints: TODO
- node take over
- resource classes integration tests: 
https://review.openstack.org/#/c/443628/
- radosgw (https://bugs.launchpad.net/ironic/+bug/1737957)

Essential Priorities


Ironic client API version negotiation (TheJulia, dtantsur)
--
- RFE https://bugs.launchpad.net/python-ironicclient/+bug/1671145
- Nova bug https://bugs.launchpad.net/nova/+bug/1739440
- gerrit topic: https://rev

[openstack-dev] [mistral][release] Release of openstack/mistral-extra failed

[Sean McGinnis]

Hey Mistral team,

We had a release job failure for mistral-extra. The issue was caused by
something that has already been fixed in master (and stable/queens).

The root cause of the problem is the way that tox is using constraints. This
caused an issue during an attempt to create a source distribution that calls a
command similar to "tox -e venv -vv -- python setup.py sdist", which then fails
pip install due to a constraint being passed in to a local path install.

I have proposed a backport from the fix to master with this:

https://review.openstack.org/543563

Unfortunately, we've now tagged the 5.2.1 release in git, but we are not able
to publish the release artifacts for it. We will need the above patch to land
in stable/pike, then a new 5.2.2 release proposed to get that published.

Please let me know if you have any questions about this.

Thanks!

Sean

- Forwarded message from z...@openstack.org -

Date: Mon, 12 Feb 2018 13:55:35 +
From: z...@openstack.org
To: release-job-failu...@lists.openstack.org
Subject: [Release-job-failures] Release of openstack/mistral-extra failed
Reply-To: openstack-dev@lists.openstack.org

Build failed.

- release-openstack-python 
http://logs.openstack.org/13/13fec4048a3c57d77307f4384b26788227179113/release/release-openstack-python/1dc8c7a/
 : FAILURE in 4m 45s
- announce-release announce-release : SKIPPED
- propose-update-constraints propose-update-constraints : SKIPPED

___
Release-job-failures mailing list
release-job-failu...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures

- End forwarded message -

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

Re: [openstack-dev] [nova][cyborg]Dublin PTG Cyborg Nova Interaction Discussion

[Ed Leafe]

On Feb 12, 2018, at 9:57 AM, Chris Dent  wrote:
> 
> Tuesday would be best for me as Monday is api-sig day.

Same, for the same reason.


-- Ed Leafe






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

Re: [openstack-dev] [charms] Propose Andrew McLeod for OpenStack Charmers team

[Alex Kavanagh]

Positive +1 from me.  Andrew would make a great additiona.

On Mon, Feb 12, 2018 at 5:00 PM, Ryan Beisner 
wrote:

> Hi All,
>
> I'd like to propose Andrew McLeod for the OpenStack Charmers (LP) and
> charms-core (Gerrit) teams.  Andrew has made many commits and bugfixes to
> the OpenStack Charms over the past couple of years, and he has general
> charming knowledge and experience which is wider than just OpenStack.
>
> He has actively participated in the last two OpenStack Charms release
> processes.  He is also the original author and current maintainer of the
> magpie charm.
>
> Cheers,
>
> Ryan
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Alex Kavanagh - Software Engineer
Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Balázs Gibizer]

Hi,

Here is the status update / focus settings mail for w7.

Bugs

No new bugs. No change from last week's bug status.


Versioned notification transformation
-
The rocky bp has been created 
https://blueprints.launchpad.net/nova/+spec/versioned-notification-transformation-rocky
Every open patch needs to be reproposed to this bp as soon as master 
opens for Rocky.


Introduce instance.lock and instance.unlock notifications
-
The bp 
https://blueprints.launchpad.net/nova/+spec/trigger-notifications-when-lock-unlock-instances 
was shortly discussed on the last nova weekly meeting and approved.


Add the user id and project id of the user initiated the instance
action to the notification
-
The bp 
https://blueprints.launchpad.net/nova/+spec/add-action-initiator-to-instance-action-notifications 
was shortly discussed on the last nova weekyl meeting, there was no 
objection but it still pending approval.


Factor out duplicated notification sample
-
https://review.openstack.org/#/q/topic:refactor-notification-samples+status:open
No open patches. We can expect some as soon as master opens for Rocky.

Weekly meeting
--
The next three meetings are cancelled. The next meeting will be help 
after the PTG.


Cheers,
gibi




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

[openstack-dev] [charms] Propose Andrew McLeod for OpenStack Charmers team

[Ryan Beisner]

Hi All,

I'd like to propose Andrew McLeod for the OpenStack Charmers (LP) and
charms-core (Gerrit) teams.  Andrew has made many commits and bugfixes to
the OpenStack Charms over the past couple of years, and he has general
charming knowledge and experience which is wider than just OpenStack.

He has actively participated in the last two OpenStack Charms release
processes.  He is also the original author and current maintainer of the
magpie charm.

Cheers,

Ryan
__
OpenStack Development Mailing 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] Nominating Hironori Shiina for ironic-core

[Shiina, Hironori]

Thank you, everyone! I'm glad to join the team.

Thanks,
Hironori


差出人: Julia Kreger [juliaashleykre...@gmail.com]
送信日時: 2018年2月10日 0:22
宛先: OpenStack Development Mailing List (not for usage questions)
件名: Re: [openstack-dev] [ironic] Nominating Hironori Shiina for ironic-core

Since all of our ironic cores have replied and nobody has stated any
objections, I guess it is time to welcome Hironori to the team! I will
make the changes in gerrit after coffee.

Thanks everyone!

-Julia

On Fri, Feb 9, 2018 at 7:13 AM, Sam Betts (sambetts)  wrote:
> +1
>
>

__
OpenStack Development Mailing 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] [requirements] we are now unfrozen and branched

[Matthew Thode]

This means we are back to business as usual.

cycle trailing projects have been warned not to merge requirements
updates until they branch or get an ack from a requirements core.

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [osc][python-openstackclient] Consistency of option name

[Graham Hayes]

On 12/02/18 16:04, William M Edmonds wrote:
> keystone may have taken "domain", but it didn't take "dns-domain"

No, but the advice at the time was to move to zone, and match DNS
RFCs, and not namespace objects with the service type.

We moved from "domain" -> "zone" and "records" -> "recordsets" in
both the CLI and in our V2 API (in Aug 2013, so the time for change
has long passed).

The point of my initial email was that if we were moving some of the
inconsistent naming for availability zones to something, that
moving it to "availability-zone" would be better than "zone". I think
that point has been made, so lets leave it at that.

- Graham

> 
> Dean Troyer  wrote on 02/12/2018 10:24:05 AM:
>>
>> On Mon, Feb 12, 2018 at 9:13 AM, Graham Hayes  wrote:
>> > OSC only predates Designate by 5 months ...
>>
>> My bad, I didn't check dates.
>>
>> > "Zone" was what we were recommend to use by the OSC devs at the time we
>> > wrote our OSC plugin, and at the time we were also *not* supposed to
>> > name space commands inside service parent (e.g. openstack zone create vs
>> > openstack dns zone create).
>>
>> Namespacing commands and naming options are totally separate things.
>> It is likely I suggested --zone at the time, and in the context of DNS
>> commands it is very clear.  Also, in the context of Compute commands,
>> --zone meaning availability zone is also clear.
>>
>> > For command flags --dns-zone seems like a good idea - but having a plain
>> > --zone is confusing when we have a top level "zone" object in the CLI,
>> > when the type of object that "--zone" refers to is different to
>> > "openstack zone "
>>
>> Again, if there is confusion, things should be more specifically named
>> to remove the confusion.  Maybe allowing "zone" to be assumed to be a
>> DNS zone was a mistake, I've made plenty of those in OSC already, so
>> there is precedent, but it seemed reasonable at the time and we (OSC
>> team) do not control what external plugins do.
>>
>> For example, I really resist using abbreviations in OSC, but in some
>> places to not do so is to buck trends that any semi-experienced user
>> in the field would expect.  The last discussion of this was last week
>> regarding "MTU" in Network commands.
>>
>> These are not hard rules, but strong guidelines that can and should be
>> interpreted in the context that they will be applied.  And in the end,
>> the result should be one that is understandable, clear and even
>> expected by the users.
>>
>> dt
>>
>> --
>>
>> Dean Troyer
>> dtro...@gmail.com
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> https://urldefense.proofpoint.com/v2/url?
>>
> u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-
>>
> siA1ZOg&r=uPMq7DJxi29v-9CkM5RT0pxLlwteWvldJgmFhLURdvg&m=Fr9TF_mDZVJgACWKoyXcnphs-6rMDWufyRhpQEtUask&s=m5wXNx8okCgs7CbNoMhHEQev0xJCFIq61pcmnWBugSs&e=
>>
> 
> 
> 
> __
> OpenStack Development Mailing 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] [osc][python-openstackclient] Consistency of option name

[William M Edmonds]

keystone may have taken "domain", but it didn't take "dns-domain"


Dean Troyer  wrote on 02/12/2018 10:24:05 AM:
>
> On Mon, Feb 12, 2018 at 9:13 AM, Graham Hayes  wrote:
> > OSC only predates Designate by 5 months ...
>
> My bad, I didn't check dates.
>
> > "Zone" was what we were recommend to use by the OSC devs at the time we
> > wrote our OSC plugin, and at the time we were also *not* supposed to
> > name space commands inside service parent (e.g. openstack zone create
vs
> > openstack dns zone create).
>
> Namespacing commands and naming options are totally separate things.
> It is likely I suggested --zone at the time, and in the context of DNS
> commands it is very clear.  Also, in the context of Compute commands,
> --zone meaning availability zone is also clear.
>
> > For command flags --dns-zone seems like a good idea - but having a
plain
> > --zone is confusing when we have a top level "zone" object in the CLI,
> > when the type of object that "--zone" refers to is different to
> > "openstack zone "
>
> Again, if there is confusion, things should be more specifically named
> to remove the confusion.  Maybe allowing "zone" to be assumed to be a
> DNS zone was a mistake, I've made plenty of those in OSC already, so
> there is precedent, but it seemed reasonable at the time and we (OSC
> team) do not control what external plugins do.
>
> For example, I really resist using abbreviations in OSC, but in some
> places to not do so is to buck trends that any semi-experienced user
> in the field would expect.  The last discussion of this was last week
> regarding "MTU" in Network commands.
>
> These are not hard rules, but strong guidelines that can and should be
> interpreted in the context that they will be applied.  And in the end,
> the result should be one that is understandable, clear and even
> expected by the users.
>
> dt
>
> --
>
> Dean Troyer
> dtro...@gmail.com
>
>
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> https://urldefense.proofpoint.com/v2/url?
>
u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-

>
siA1ZOg&r=uPMq7DJxi29v-9CkM5RT0pxLlwteWvldJgmFhLURdvg&m=Fr9TF_mDZVJgACWKoyXcnphs-6rMDWufyRhpQEtUask&s=m5wXNx8okCgs7CbNoMhHEQev0xJCFIq61pcmnWBugSs&e=

>
__
OpenStack Development Mailing 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] Reminder about stable/queens backports

[Matt Riedemann]

I'm going through the proposed stable/queens backports and marking them 
as -Workflow if they are not fixing a regression introduced in queens 
itself or required for a queens-rc2 tag.


If we have a need for a queens-rc2 tag then we can assess if any of 
these other backports should be included, otherwise they'll go into the 
first release after the queens GA.


--

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

Re: [openstack-dev] [nova][cyborg]Dublin PTG Cyborg Nova Interaction Discussion

[Chris Dent]

On Mon, 12 Feb 2018, Jay Pipes wrote:


On 02/12/2018 10:27 AM, Eric Fried wrote:

I'm interested.  No date/time preference so far as long as it sticks to
Monday/Tuesday.


Same for me.


Tuesday would be best for me as Monday is api-sig day.

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

Re: [openstack-dev] [nova][cyborg]Dublin PTG Cyborg Nova Interaction Discussion

[Jay Pipes]

On 02/12/2018 10:27 AM, Eric Fried wrote:

I'm interested.  No date/time preference so far as long as it sticks to
Monday/Tuesday.


Same for me.

-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] Feedback on the Dev Digest

[Mike Perez]

Hey all,

I setup a two question survey asking about your frequency with the Dev Digest,
and how it can be improved:

https://openstackfoundation.formstack.com/forms/openstack_developer_digest_feedback

In case you're not familiar, the Dev Digest tries to provide summaries of the
OpenStack Dev mailing list, for people who might not have time to read every
message and thread on the list. The hope is for people to be informed on
discussions they would've otherwise missed, and be able to get caught up to 
chime in if necessary. This is a community effort worked on via etherpad:

https://etherpad.openstack.org/p/devdigest

The content on Fridays is posted to the Dev list in plaintext, LWN, Twitter and
the OpenStack blog:

https://www.openstack.org/blog/

Thank you!

-- 
Mike Perez (thingee)


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

Re: [openstack-dev] [ptg] Lightning talks

[Mike Perez]

On 11:25 Feb 08, Mike Perez wrote:
> Hey all!
> 
> I'm looking for six 5-minute lightning talks for the PTG in Dublin. This will
> be on Friday March 2nd at 13:00-13:30 local time.
> 
> Appropriate 5 minute talk examples:
> * Neat features in libraries like oslo that we should consider adopting in our
>   community wide goals.
> * Features and tricks in your favorite editor that makes doing work easier.
> * Infra tools that maybe not a lot of people know about yet. Zuul v3 explained
>   in five minutes anyone?
> * Some potential API specification from the API SIG that we should adopt as
>   a community wide goal.
> 
> Please email me DIRECTLY the following information:
> 
> Title:
> Speaker(s) full name:
> Abstract:
> Link to presentation or attachment if you have it already. Laptop on stage 
> will
> be loaded with your presentation already. I'll have open office available so
> odp, odg, otp, pdf, limited ppt format support.
> 
> Submission deadline is February 16 00:00 UTC, and then I'll send confirmation
> emails to speakers requesting for slides. Thank you, looking forward to 
> hearing
> some great talks from our community!

Hey all,

Just a reminder that lightning talk proposals for the PTG in Dublin is due
February 16 at 00:00 utc. We're building up a nice line up already. Details
quoted above, Thanks!

-- 
Mike Perez (thingee)


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

Re: [openstack-dev] [nova][cyborg]Dublin PTG Cyborg Nova Interaction Discussion

[Eric Fried]

I'm interested.  No date/time preference so far as long as it sticks to
Monday/Tuesday.

efried

On 02/12/2018 09:13 AM, Zhipeng Huang wrote:
> Hi Nova team,
> 
> Cyborg will have ptg sessions on Mon and Tue from 2:00pm to 6:00pm, and
> we would love to invite any of you guys who is interested in nova-cyborg
> interaction to join the discussion. The discussion will mainly focus on:
> 
> (1) Cyborg team recap on the resource provider features that are
> implemented in Queens.
> (2) Joint discussion on what will be the impact on Nova side and future
> collaboration areas.
> 
> The session is planned for 40 mins long.
> 
> If you are interested plz feedback which date best suit for your
> arrangement so that we could arrange the topic accordingly :)
> 
> Thank you very much.
> 
> 
> 
> -- 
> Zhipeng (Howard) Huang
> 
> Standard Engineer
> IT Standard & Patent/IT Product Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com 
> Office: Huawei Industrial Base, Longgang, Shenzhen
> 
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu 
> Office: Calit2 Building Room 2402
> 
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
> 
> 
> __
> OpenStack Development Mailing 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] [osc][python-openstackclient] Consistency of option name

[Dean Troyer]

On Mon, Feb 12, 2018 at 9:13 AM, Graham Hayes  wrote:
> OSC only predates Designate by 5 months ...

My bad, I didn't check dates.

> "Zone" was what we were recommend to use by the OSC devs at the time we
> wrote our OSC plugin, and at the time we were also *not* supposed to
> name space commands inside service parent (e.g. openstack zone create vs
> openstack dns zone create).

Namespacing commands and naming options are totally separate things.
It is likely I suggested --zone at the time, and in the context of DNS
commands it is very clear.  Also, in the context of Compute commands,
--zone meaning availability zone is also clear.

> For command flags --dns-zone seems like a good idea - but having a plain
> --zone is confusing when we have a top level "zone" object in the CLI,
> when the type of object that "--zone" refers to is different to
> "openstack zone "

Again, if there is confusion, things should be more specifically named
to remove the confusion.  Maybe allowing "zone" to be assumed to be a
DNS zone was a mistake, I've made plenty of those in OSC already, so
there is precedent, but it seemed reasonable at the time and we (OSC
team) do not control what external plugins do.

For example, I really resist using abbreviations in OSC, but in some
places to not do so is to buck trends that any semi-experienced user
in the field would expect.  The last discussion of this was last week
regarding "MTU" in Network commands.

These are not hard rules, but strong guidelines that can and should be
interpreted in the context that they will be applied.  And in the end,
the result should be one that is understandable, clear and even
expected by the users.

dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [openstack-dev] [all][Kingbird][Heat][Glance]Multi-Region Orchestrator

[Colleen Murphy]

On Mon, Feb 12, 2018 at 7:44 AM, Goutham Pratapa
 wrote:

>
> OUR USE-CASES QUOTA-MANAGEMENT:
>
> 1. Admin must have a global view of all quotas to all tenants across all the
> regions
> 2. Admin can periodically balance the quotas (we have a formula using which
> we do this balancing ) across regions
> 3. Admin can update, Delete quotas for tenants
> 4. Admin can sync quotas for all tenants so that the quotas will be updated
> in all regions.

Global quota management is something we're seeking to solve in
keystone[1][2][3][4], which would enable admins to do 1, 3, and 4 via
keystone (though admittedly this is a few cycles out). We expect to
dive into this at the PTG if you'd like to help shape this work.

[1] 
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/unified-limits.html
[2] 
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/limits-api.html
[3] https://review.openstack.org/#/c/441203/
[4] https://review.openstack.org/#/c/540803/

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

[openstack-dev] [nova][cyborg]Dublin PTG Cyborg Nova Interaction Discussion

[Zhipeng Huang]

Hi Nova team,

Cyborg will have ptg sessions on Mon and Tue from 2:00pm to 6:00pm, and we
would love to invite any of you guys who is interested in nova-cyborg
interaction to join the discussion. The discussion will mainly focus on:

(1) Cyborg team recap on the resource provider features that are
implemented in Queens.
(2) Joint discussion on what will be the impact on Nova side and future
collaboration areas.

The session is planned for 40 mins long.

If you are interested plz feedback which date best suit for your
arrangement so that we could arrange the topic accordingly :)

Thank you very much.



-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
OpenStack Development Mailing 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] [osc][python-openstackclient] Consistency of option name

[Graham Hayes]

On 12/02/18 14:51, Dean Troyer wrote:
> On Mon, Feb 12, 2018 at 7:50 AM, Graham Hayes  wrote:
>> Please please move to `availability-zone` - zone is a DNS zone (seen as
>> Keystone took Domain :) ) within OSC.
> 
> As stated in another message, changing the Compute usage of --zone
> makes sense for OSC 4.  Two additional things here:
> 
> * Command option names have a lesser bar to clear (compared to
> resource names which must be unique) for uniqueness, as they are by
> definition context-sensitive.  Like trademarks, the primary objective
> is to reduce user confusion.
> 
> * --zone is really generic and I would suggest that DNS should also be
> using something to qualify it.  The use of --zone in the Compute
> commands pre-dates the existence of Designate by at least a coupe of
> years.

OSC only predates Designate by 5 months ...

> Also, the Network commands use "--dns-*" to refer to anything
> specifically DNS related, so for consistency, "--dns-zone" is a better
> fit.

"Zone" was what we were recommend to use by the OSC devs at the time we
wrote our OSC plugin, and at the time we were also *not* supposed to
name space commands inside service parent (e.g. openstack zone create vs
openstack dns zone create).

For command flags --dns-zone seems like a good idea - but having a plain
--zone is confusing when we have a top level "zone" object in the CLI,
when the type of object that "--zone" refers to is different to
"openstack zone "

- Graham

> 
> dt
> 



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] [freezer] PTG planning Etherpad

[Adam Heczko]

Hello Saad, I think you missed link to the [1] etherpad.

On Mon, Feb 12, 2018 at 3:05 PM, Saad Zaher  wrote:

> Hello everyone,
>
> Please, if anyone is going to attend the next PTG in dublin check ehterpad
> [1] for discussion agenda.
>
> Feel free to add or comment on topics you want to discuss in this PTG.
>
> Please make sure to add your irc or name to participants section.
>
>
> Best Regards,
> Saad!
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Adam Heczko
Security Engineer @ Mirantis Inc.
__
OpenStack Development Mailing 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] [osc][python-openstackclient] Consistency of option name

[Dean Troyer]

On Mon, Feb 12, 2018 at 7:50 AM, Graham Hayes  wrote:
> Please please move to `availability-zone` - zone is a DNS zone (seen as
> Keystone took Domain :) ) within OSC.

As stated in another message, changing the Compute usage of --zone
makes sense for OSC 4.  Two additional things here:

* Command option names have a lesser bar to clear (compared to
resource names which must be unique) for uniqueness, as they are by
definition context-sensitive.  Like trademarks, the primary objective
is to reduce user confusion.

* --zone is really generic and I would suggest that DNS should also be
using something to qualify it.  The use of --zone in the Compute
commands pre-dates the existence of Designate by at least a coupe of
years.  Also, the Network commands use "--dns-*" to refer to anything
specifically DNS related, so for consistency, "--dns-zone" is a better
fit.

dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [openstack-dev] [osc][python-openstackclient] Consistency of option name

[Dean Troyer]

On Sun, Feb 11, 2018 at 10:18 PM, Hongbin Lu  wrote:
> I was working on the OSC plugin of my project and trying to choose a CLI
> option to represent the availability zone of the container. When I came
> across the existing commands, I saw some inconsistencies on the naming. Some
> commands use the syntax '--zone ', while others use the syntax
> '--availability-zone '. For example:
>
> * openstack host list ... [--zone ]
> * openstack aggregate create ... [--zone ]

These likely date back to the original command mapping I did and in
retrospect should have been --availability-zone.  However they have
been there since day 1 or 2.

> * openstack volume create ... [--availability-zone ]
> * openstack consistency group create ... [--availability-zone
> ]
>
> I wonder if it makes sense to address this inconsistency. Is it possible
> have all commands using one syntax?

This is the sort of thing that should be addressed in the long-overdue
OSC 4 release where we will make small breaking changes like this.
Of course, the old option will be properly deprecated and silently
supported for some time.

dt

-- 

Dean Troyer
dtro...@gmail.com

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

[openstack-dev] [heat] No Meeting This week

[Rico Lin]

Hi all
Good news first! We released queens last week, so well done everyone.

This week is Chinese new year, and Wednesday happen to be new year eve, so
I will not hosting the meeting this week.

Let's skip this one if no important stuff to talk about.

See you at next meeting


-- 
May The Force of OpenStack Be With You,

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

[openstack-dev] [freezer] PTG planning Etherpad

[Saad Zaher]

Hello everyone,

Please, if anyone is going to attend the next PTG in dublin check ehterpad
[1] for discussion agenda.

Feel free to add or comment on topics you want to discuss in this PTG.

Please make sure to add your irc or name to participants section.


Best Regards,
Saad!
__
OpenStack Development Mailing 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] [osc][python-openstackclient] Consistency of option name

[Graham Hayes]

On 12/02/18 04:18, Hongbin Lu wrote:
> Hi all,
> 
> I was working on the OSC plugin of my project and trying to choose a CLI
> option to represent the availability zone of the container. When I came
> across the existing commands, I saw some inconsistencies on the naming.
> Some commands use the syntax '--zone ', while others use the syntax
> '--availability-zone '. For example:
> 
> * openstack host list ... [--zone ]
> * openstack aggregate create ... [--zone ]
> * openstack volume create ... [--availability-zone ]
> * openstack consistency group create ... [--availability-zone
> ]
> 
> I wonder if it makes sense to address this inconsistency. Is it possible
> have all commands using one syntax?
> 
> Best regards,
> Hongbin
> 

Please please move to `availability-zone` - zone is a DNS zone (seen as
Keystone took Domain :) ) within OSC.

> 
> __
> OpenStack Development Mailing 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] [neutron][lbaas][neutron-lbaas][octavia] Announcing the deprecation of neutron-lbaas and neutron-lbaas-dashboard

[Gary Kotton]

Hi,
I have a number of issues with this:
1. I do not think that we should mark this as deprecated until we have a clear 
and working migration patch. Let me give an example. Say I have a user who is 
using Pike or Queens and has N LBaaS load balancers up and running. What if we 
upgrade to T and there is no LBaaS, only Octavia. What is the migration path 
here? Maybe I have missed this and would be happy to learn how this was done.
2. I think that none of the load balancing vendors have code in Octavia and 
this may be a problem (somewhat related to #1). I guess that there is enough 
warning but this is still concerning
3. The migration from V1 to V2 was not successful. So, I have some concerns 
about going to a new service completely.
I prefer that we hold off on this until there is a clear picture. 
Thanks
Gary

On 2/1/18, 9:22 AM, "Andreas Jaeger"  wrote:

On 2018-01-31 22:58, Akihiro Motoki wrote:
> I don't think we need to drop translation support NOW (at least for
> neutron-lbaas-dashboard).
> There might be fixes which affects translation and/or there might be
> translation improvements.
> I don't think a deprecation means no translation fix any more. It
> sounds too aggressive.
> Is there any problem to keep translations for them?

Reading the whole FAQ - since bug fixes are planned, translations can
merge back. So, indeed we can keep translation infrastructure set up.

I recommend to translators to remove neutron-lbaas-dashboard from the
priority list,

Andreas

> Akihiro
> 
> 2018-02-01 3:28 GMT+09:00 Andreas Jaeger :
>> In that case, I suggest to remove translation jobs for these 
repositories,
>>
>> 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
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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


__
OpenStack Development Mailing 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] [reno] an alternative approach to known issues

[Gabriele Cerami]

On 09 Feb, Thierry Carrez wrote:
> Doug Hellmann wrote:
> > What makes reno a good fit for this task? It seems like updating a
> > regular documentation page in the source tree would work just as well,
> > since presumably these technical debt descriptions don't need to be
> > backported to stable branches.
> 
> Yeah it feels like reno would add complexity for little benefit in that
> process... Better track debt in a TODO document, or a proper task tracker ?

The regular document was my first thought too, but then if we want to
create a report on the active TDs, or automate a little the design note
creation, mangle and analyze them a little, we will need to build proper
tooling from scratch. Also most of this work would probably deprecate the
known issue field in the release note.

Any new tool that would need to be created, I still imagine it to be
pretty similar to reno, at least regarding the process of adding
something new: One file per note, together with the code, created from a
template, able to be modified over time, and a command to create a
report

__
OpenStack Development Mailing 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] [mistral] Proposing time slots for Mistral office hours

[Adriano Petrich]

I'm good for helping with the Monday and Friday time slots


Cheers,
   Adriano

On Mon, Feb 5, 2018 at 3:23 PM, Dougal Matthews  wrote:

>
>
> On 5 February 2018 at 07:48, Renat Akhmerov 
> wrote:
>
>> Hi,
>>
>> Not so long ago we decided to stop holding weekly meetings in one of the
>> general IRC channel (it was #openstack-meeting-3 for the last several
>> months). The main reason was that we usually didn’t have a good
>> representation of the team there because the team is distributed across the
>> world. We tried to find a time slot several times that would work well for
>> all the team members but failed to. Another reason is that we didn’t always
>> have a clear reason to gather because everyone was just focused on their
>> tasks and a discussion wasn’t much needed so a meeting was even a
>> distraction.
>>
>> However, despite all this we still would like channels to communicate,
>> the team members and people who have user questions and/or would like to
>> start contributing.
>>
>> Similarly to other teams in OpenStack we’d like to try the “Office hours”
>> concept. If we follow it we’re supposed to have team members, for whom the
>> time slot is OK, available in our channel #openstack-mistral during certain
>> hours. These hours can be used for discussing our development stuff between
>> team members from different time zones and people outside the team would
>> know when they can come and talk to us.
>>
>> Just to start the discussion on what the office hours time slots could be
>> I’m proposing the following time slots:
>>
>>1. Mon 16.00 UTC (it used to be our time of weekly meetings)
>>2. Wed 3.00 UTC
>>3. Fri 8.00 UTC
>>
>>
> These sounds good to me. I should be able to regularly attend the Monday
> and Friday slots.
>
> I think we should ask Mistral cores to try and attend at least one of
> these a week.
>
>
>
>>
>>
>> Each slot is one hour.
>>
>> Assumingly, #1 would be suitable for people in Europe and America. #2 for
>> people in Asia and America. And #3 for people living in Europe and Asia. At
>> least that was my thinking when I was wondering what the time slots should
>> be.
>>
>> Please share your thoughts on this. The idea itself and whether the time
>> slots look ok.
>>
>> Thanks
>>
>> Renat Akhmerov
>> @Nokia
>>
>> 
>> __
>> 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] [mistral] PTG planning on Friday “office hours” session

[Renat Akhmerov]

Hi,

This Friday at 8.00 UTC we’ll have our first “Office hours” session according 
to the time slots earlier proposed in this email thread. It will be devoted to 
the Dublin PTG planning so please join us at #openstack-mistral if you want to 
participate (bring your items, get to know things going on etc.)

And I’m still hoping that more people will give their feedback on the proposal 
itself.

Just to remind what the proposed time slots for office hours are:

1. Mon 16.00 UTC (it used to be our time of weekly meetings)
2. Wed 3.00 UTC
3. Fri 8.00 UTC


Thanks

Renat Akhmerov
@Nokia
__
OpenStack Development Mailing 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] [security] Security PTG Planning, x-project request for topics.

[Luke Hinds]

On Sun, Feb 11, 2018 at 4:01 PM, Pino de Candia  wrote:

> I uploaded the demo video (https://youtu.be/y6ICCPO08d8) and linked it
> from the slides.
>

Thanks Pino , i added these to the agenda:

https://etherpad.openstack.org/p/security-ptg-rocky

Please let me know before the PTG, if it will be your colleague or if we
need to find a projector to conference you in.


> On Fri, Feb 9, 2018 at 5:51 PM, Pino de Candia <
> giuseppe.decan...@gmail.com> wrote:
>
>> Hi Folks,
>>
>> here are the slides for the Tatu presentation: https://docs.goo
>> gle.com/presentation/d/1HI5RR3SNUu1If-A5Zi4EMvjl-3TKsBW20xEUyYHapfM
>>
>> I meant to record the demo video as well but I haven't gotten around to
>> editing all the bits. Please stay tuned.
>>
>> thanks,
>> Pino
>>
>>
>> On Tue, Feb 6, 2018 at 10:52 AM, Giuseppe de Candia <
>> giuseppe.decan...@gmail.com> wrote:
>>
>>> Hi Luke,
>>>
>>> Fantastic! An hour would be great if the schedule allows - there are
>>> lots of different aspects we can dive into and potential future directions
>>> the project can take.
>>>
>>> thanks!
>>> Pino
>>>
>>>
>>>
>>> On Tue, Feb 6, 2018 at 10:36 AM, Luke Hinds  wrote:
>>>


 On Tue, Feb 6, 2018 at 4:21 PM, Giuseppe de Candia <
 giuseppe.decan...@gmail.com> wrote:

> Hi Folks,
>
> I know the request is very late, but I wasn't aware of this SIG until
> recently. Would it be possible to present a new project to the Security 
> SIG
> at the PTG? I need about 30 minutes. I'm hoping to drum up interest in the
> project, sign on users and contributors and get feedback.
>
> For the past few months I have been working on a new project - Tatu
> [1]- to automate the management of SSH certificates (for both users and
> hosts) in OpenStack. Tatu allows users to generate SSH certificates with
> principals based on their Project role assignments, and VMs automatically
> set up their SSH host certificate (and related config) via Nova vendor
> data. The project also manages bastions and DNS entries so that users 
> don't
> have to assign Floating IPs for SSH nor remember IP addresses.
>
> I have a working demo (including Horizon panels [2] and OpenStack CLI
> [3]), but am still working on the devstack script and patches [4] to get
> Tatu's repositories into OpenStack's GitHub and Gerrit. I'll try to post a
> demo video in the next few days.
>
> best regards,
> Pino
>
>
> References:
>
>1. https://github.com/pinodeca/tatu (Please note this is still
>very much a work in progress, lots of TODOs in the code, very little
>testing and documentation doesn't reflect the latest design).
>2. https://github.com/pinodeca/tatu-dashboard
>3. https://github.com/pinodeca/python-tatuclient
>4. https://review.openstack.org/#/q/tatu
>
>
>
>
 Hi Giuseppe, of course you can! I will add you to the agenda. We could
 get your an hour if it allows more time for presenting and post discussion?

 We will be meeting in an allocated room on Monday (details to follow).

 https://etherpad.openstack.org/p/security-ptg-rocky

 Luke




>
>
> On Wed, Jan 31, 2018 at 12:03 PM, Luke Hinds 
> wrote:
>
>>
>> On Mon, Jan 29, 2018 at 2:29 PM, Adam Young 
>> wrote:
>>
>>> Bug 968696 and System Roles.   Needs to be addressed across the
>>> Service catalog.
>>>
>>
>> Thanks Adam, will add it to the list. I see it's been open since 2012!
>>
>>
>>>
>>> On Mon, Jan 29, 2018 at 7:38 AM, Luke Hinds 
>>> wrote:
>>>
 Just a reminder as we have not had many uptakes yet..

 Are there any projects (new and old) that would like to make use of
 the security SIG for either gaining another perspective on security
 challenges / blueprints etc or for help gaining some cross project
 collaboration?

 On Thu, Jan 11, 2018 at 3:33 PM, Luke Hinds 
 wrote:

> Hello All,
>
> I am seeking topics for the PTG from all projects, as this will be
> where we try out are new form of being a SIG.
>
> For this PTG, we hope to facilitate more cross project
> collaboration topics now that we are a SIG, so if your project has a
> security need / problem / proposal than please do use the security 
> SIG room
> where a larger audience may be present to help solve problems and gain
> x-project consensus.
>
> Please see our PTG planning pad [0] where I encourage you to add
> to the topics.
>
> [0] https://etherpad.openstack.org/p/security-ptg-rocky
>
> --
> Luke Hinds
> Security Project PTL
>


 _