Re: [openstack-dev] [stable/ocata] [nova] [devstack multi-node] nova-conductor complaining about "No cell mapping found for cell0"

[Prashant Shetty]

Appreciate some help on this issue.

Thanks,
Prashant

On Tue, Feb 21, 2017 at 9:08 PM, Prashant Shetty <
prashantshetty1...@gmail.com> wrote:

> Hi Mark,
>
> Thanks for your reply.
>
> I tried "nova-manage cell_v2 discover_hosts" and it returned nothing and
> still I have same issue on the node.
>
> Problem seems be the way devstack is getting configured,
> As code suggest below we create cell0 on node where n-api and n-cpu runs.
> In my case compute is running only n-cpu and controller is running n-api
> service, due to this code there are no cell created in controller or
> compute.
>
> We will not have this  problem in all-in-one-node setup.
> --
> # Do this late because it requires compute hosts to have started
> if is_service_enabled n-api; then
> if is_service_enabled n-cpu; then
> create_cell
> else
> # Some CI systems like Hyper-V build the control plane on
> # Linux, and join in non Linux Computes after setup. This
> # allows them to delay the processing until after their whole
> # environment is up.
> echo_summary "SKIPPING Cell setup because n-cpu is not enabled.
> You will have to do this manually before you have a working environment."
> fi
> fi
> ---
>
> vmware@cntr11:~$ nova-manage cell_v2 discover_hosts
> vmware@cntr11:~$ nova service-list
> ++--+---+--+
> -+---++-+
> | Id | Binary   | Host  | Zone | Status  | State |
> Updated_at | Disabled Reason |
> ++--+---+--+
> -+---++-+
> | 3  | nova-conductor   | cntr11| internal | enabled | up|
> 2017-02-21T15:34:13.00 | -   |
> | 5  | nova-scheduler   | cntr11| internal | enabled | up|
> 2017-02-21T15:34:15.00 | -   |
> | 6  | nova-consoleauth | cntr11| internal | enabled | up|
> 2017-02-21T15:34:11.00 | -   |
> | 7  | nova-compute | esx-ubuntu-02 | nova | enabled | up|
> 2017-02-21T15:34:14.00 | -   |
> | 8  | nova-compute | esx-ubuntu-03 | nova | enabled | up|
> 2017-02-21T15:34:16.00 | -   |
> | 9  | nova-compute | kvm-3 | nova | enabled | up|
> 2017-02-21T15:34:07.00 | -   |
> | 10 | nova-compute | kvm-2 | nova | enabled | up|
> 2017-02-21T15:34:13.00 | -   |
> | 11 | nova-compute | esx-ubuntu-01 | nova | enabled | up|
> 2017-02-21T15:34:14.00 | -   |
> | 12 | nova-compute | kvm-1 | nova | enabled | up|
> 2017-02-21T15:34:09.00 | -   |
> ++--+---+--+
> -+---++-+
> vmware@cntr11:~$
> vmware@cntr11:~$ nova-manage cell_v2 list_cells
> +--+--+
> | Name | UUID |
> +--+--+
> +--+--+
> vmware@cntr11:~$
>
>
> Thanks,
> Prashant
>
> On Tue, Feb 21, 2017 at 1:02 AM, Matt Riedemann 
> wrote:
>
>> On 2/20/2017 10:31 AM, Prashant Shetty wrote:
>>
>>> Thanks Jay for the response. Sorry I missed out on copying right error.
>>>
>>> Here is the log:
>>> 2017-02-20 14:24:06.211 TRACE nova.conductor.manager NoValidHost: No
>>> valid host was found. There are not enough hosts available.
>>> 2017-02-20 14:24:06.211 TRACE nova.conductor.manager
>>> 2017-02-20 14:24:06.211 TRACE nova.conductor.manager
>>> 2017-02-20 14:24:06.217 ERROR nova.conductor.manager
>>> [req-e17fda8d-0d53-4735-922e-dd635d2ab7c0 admin admin] No cell mapping
>>> found for cell0 while trying to record scheduling failure. Setup is
>>> incomplete.
>>>
>>> I tried command you mentioned, still I see same error on conductor.
>>>
>>> As part of stack.sh on controller I see below command was executed
>>> related to "cell". Isn't it devstack should take care of this part
>>> during initial bringup or am I missing any parameters in localrc for
>>> same?.
>>>
>>> NOTE: I have not explicitly enabled n-cell in localrc
>>>
>>> 2017-02-20 14:11:47.510 INFO migrate.versioning.api [-] done
>>> +lib/nova:init_nova:683recreate_database nova
>>> +lib/database:recreate_database:112local db=nova
>>> +lib/database:recreate_database:113recreate_database_mysql nova
>>> +lib/databases/mysql:recreate_database_mysql:56  local db=nova
>>> +lib/databases/mysql:recreate_database_mysql:57  mysql -uroot -pvmware
>>> -h127.0.0.1 -e 'DROP DATABASE IF EXISTS nova;'
>>> +lib/databases/mysql:recreate_database_mysql:58  mysql -uroot -pvmware
>>> -h127.0.0.1 -e 'CREATE DATABASE nova CHARACTER SET utf8;'
>>> +lib/nova:init_nova:684recreate_database nova_cell0
>>> +lib/database:recreate_database:112local db=nova_cell0
>>> +lib/database:recreate_database:113

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

[Claudiu Belu]

Hello,

Our team si currently attending the Atlanta PTG, so this week's meeting is 
cancelled, and we will resume the meetings starting next week. In the 
meanwhile, if you're in Atlanta attending the PTG and want to discuss Hyper-V / 
Windows related topics, feel free to drop an email, and we'll meet at the PTG.

Best regards,

Claudiu Belu
__
OpenStack Development Mailing 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] Atlanta PTG

[Emilien Macchi]

On Tue, Feb 21, 2017 at 11:46 AM, Sai Sindhur Malleni
 wrote:
> Is there a plan to have a google hangouts session or similar to attend
> remotely?

to be honest, mixing face 2 face & remote meetings is very challenging.
But because people want it, we'll give a try on Friday morning during
the CI sessions.

If anyone at PTG volunteers to do the same for the other sessions on
Wednesday or Thursday, feel free to do so.

> On Mon, Jan 23, 2017 at 8:45 AM, John Trowbridge  wrote:
>>
>>
>>
>> On 01/21/2017 05:37 AM, Michele Baldessari wrote:
>> > Hi Emilien,
>> >
>> > while not a design session per se, I would love to propose a short slot
>> > for TripleO CI Q, if we have some time left. In short, I'd like to be
>> > more useful around CI failures, but I lack the understanding of a few
>> > aspects of our current CI (promotion, when do images get built, etc.),
>> > that would benefit quite a bit from a short session where we have a few
>> > CI folks in the room that could answer questions or give some tips.
>> > I know of quite few other people that are in the same boat and maybe
>> > this will help a bit our current issue where only a few folks always
>> > chase CI issues.
>> >
>> > If there is consensus (and some CI folks willing to attend ;) and time
>> > for this, I'll be happy to organize this and prepare a bunch of
>> > questions ideas beforehand.
>> >
>>
>> Great idea. We have a room for three days, so it is not like summit
>> where there is really limited time.
>>
>> > Thoughts?
>> > Michele
>> >
>> > On Wed, Jan 04, 2017 at 07:26:52AM -0500, Emilien Macchi wrote:
>> >> I would like to bring this topic up on your inbox, so we can continue
>> >> to make progress on the agenda. Feel free to follow existing examples
>> >> in the etherpad and propose a design dession.
>> >>
>> >> Thanks,
>> >>
>> >> On Wed, Dec 21, 2016 at 9:06 AM, Emilien Macchi 
>> >> wrote:
>> >>> General infos about PTG: https://www.openstack.org/ptg/
>> >>>
>> >>> Some useful informations about PTG/TripleO:
>> >>>
>> >>> * When? We have a room between Wednesday and Friday included.
>> >>> Important sessions will happen on Wednesday and Thursday. We'll
>> >>> probably have sessions on Friday, but it might be more hands-on and
>> >>> hackfest, where people can enjoy the day to work together.
>> >>>
>> >>> * Let's start to brainstorm our topics:
>> >>> https://etherpad.openstack.org/p/tripleo-ptg-pike
>> >>>   Feel free to add any topic, as soon as you can. We need to know asap
>> >>> which sessions will be share with other projects (eg: tripleo/mistral,
>> >>> tripleo/ironic, tripleo/heat, etc).
>> >>>
>> >>>
>> >>> Please let us know any question or feedback,
>> >>> Looking forward to seeing you there!
>> >>> --
>> >>> Emilien Macchi
>> >>
>> >>
>> >>
>> >> --
>> >> Emilien Macchi
>> >>
>> >>
>> >> __
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Sai Sindhur Malleni
>
> Red Hat Inc.
> 100 East Davie Street
> Raleigh, NC, USA
> Work: (919) 754-4557 | Cell: (919) 985-1055
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Emilien Macchi

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

Re: [openstack-dev] [QA] [ptg] Team photo

[zhu.fanglei]

Who can kindly send me a photo as an mail attachment? I am curious about it but 
I can't open the link ^-^












Original Mail



Sender:  ＜andrea.fritt...@gmail.com＞
To:  ＜openstack-dev@lists.openstack.org＞
Date: 2017/02/22 11:40
Subject: [openstack-dev] [QA] [ptg] Team photo






Here are our team photos: 
https://www.dropbox.com/home/Public/PTG%20Atlanta%20QA%20Team


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

[openstack-dev] [neutron] Enable arp_responder without l2pop

[Anil Venkata]

Hi All

Currently arp_resonder can enabled only if l2pop is enabled.

Can we have arp_responder feature enabled without l2pop(i.e Remove the
dependency between arp_responder and l2_pop)?
Also setup arp_responder on OVS integration bridge(and not on br-tun)?.

To enable arp_responder, we only need port's MAC and IP Address and no
tunnel ip(So no need for l2pop).
Currently agents use l2pop notifications to create ARP entries. With the
new approach, agents can use
port events(create, update and delete) to create ARP entry and without
l2pop notifications.

The advantages with this approach for both linuxbridge and OVS agent -
1) Users can enable arp_responder without l2pop
2) Support ARP for distributed router ports(DVR and HA).
Currently, ARP is not added for these ports.
This is a fix for https://bugs.launchpad.net/neutron/+bug/1661717

As we are not dependent on l2pop, we can  create ARP entries on OVS
integration bridge.

Advantages for OVS agent, if ARP entries are setup on integration
bridge(br-int) rather than on tunneling bridge(br-tun)
1) It enables arp_responder for all network types(vlans, vxlan, etc)
arp_responder based on l2pop is supported for only overlay networks.
2) ARP can be resolved within br-int.
3) ARP packets for local ports(ports connected to same br-int) will be
resolved
   in br-int without broadcasting to actual ports connected to br-int.


Any suggestions?

Also submitted bug [1] for this.

[1] https://bugs.launchpad.net/neutron/+bug/1518392

Thanks
Anil
__
OpenStack Development Mailing 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] [QA] [ptg] Team photo

[Andrea Frittoli]

Here are our team photos:
https://www.dropbox.com/home/Public/PTG%20Atlanta%20QA%20Team

andrea
__
OpenStack Development Mailing 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] Team photo at the PTG

[Matt Riedemann]

I've signed us all up for a team photo at 9:50 on Thursday morning. It's 
outside grand ballroom A on the third floor close to the top of the 
staircase.


--

Thanks,

Matt Riedemann

__
OpenStack Development Mailing 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] Call for upstream training liaison

[Sylvain Bauza]

I can help here even I'm not sure I'll be going to the Summit yet.

Le 21 févr. 2017 14:48, "Matt Riedemann"  a écrit :

> If you haven't seen this yet [1] there is going to be an upstream training
> meeting at the PTG on Wednesday 2/22 at 12ET to talk about upstream
> training and what liaisons from each project can do to help.
>
> This email is a call for anyone that's working on Nova and is interested
> in volunteering to be the team liaison for the upstream training which
> happens the weekend before the Pike summit in Boston.
>
> At a high level, it's my understanding that this involves helping some new
> contributors get comfortable with the various projects and to associate a
> person with each project so when they show up in IRC they know someone and
> can ask questions (similar to mentoring but I believe less involved on an
> ongoing basis).
>
> So if you're going to be at the Boston summit and this is something you're
> interested in, please either speak with me, Ildiko, or show up to the
> meeting to find out more.
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-Febr
> uary/112270.html
>
> --
>
> Thanks,
>
> Matt Riedemann
>
> __
> OpenStack Development Mailing 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] RFC for Intel RDT/CAT Support in Nova for Virtual Machine QoS

[Qiao, Liyong]

Hi Marcelo, 

Reserved size means can’t be allocated to Apps(VMs), it is reserved by host, 
and decided by hardware.

This capabilities only show host’s capabilities, there will be another libvirt 
API to report how many bytes can be allocated to VM per cache bank.
Still working on it.


Best Regards

Eli Qiao(乔立勇）OpenStack Core team OTC Intel.
-- 


On 22/02/2017, 9:07 AM, "Marcelo Tosatti"  wrote:

What reserved means again? 

Some field should include how many bytes are CAT allocatable 
at this time in the L3 socket.

(So libvirtd functions properly with other applications).

This is required.

__
OpenStack Development Mailing 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][ptg] QA Team social evening

[Andrea Frittoli]

we're meeting at the reception in 5min
see you there
andrea

On Tue, 21 Feb 2017, 11:49 a.m. Andrea Frittoli, 
wrote:

> Hello folks,
>
> I booked a table for tonight at 7:30 at Poor Calvin's [0]. It's a 15min
> away from the Sheraton [1], for everyone who's answered yes/maybe for
> Tuesday on the doodle [2].
> If you're not planning to come please let me know so I can update the
> reservation.
>
> See you later!
>
> Andrea
>
> [0] http://www.poorcalvins.com/Home
> [1] https://goo.gl/ADuVlX
> [2] http://doodle.com/poll/yxy8ts8s8te8rwwhsfrnft2i/admin
>
> On Mon, Feb 20, 2017 at 11:18 PM Andrea Frittoli <
> andrea.fritt...@gmail.com> wrote:
>
> Hi folks,
>
> thank you for your vote!
> It looks like the best option is tomorrow (Tuesday) night - there's going
> to be a reception at the Sheraton between 5-7 but we can have dinner after
> that.
> I'll book a place tomorrow morning, if you have any good candidate for
> good restaurant nearby please let me know.
>
> Thanks!
>
> andrea
>
> On Sun, Feb 19, 2017 at 12:35 PM Andrea Frittoli <
> andrea.fritt...@gmail.com> wrote:
>
> Hello,
>
> I'd like to propose a social evening for the folks in the QA sessions.
> I prepared a doodle [0] so if you're interested please vote :)
>
> I added the link to the main QA etherpad [1] as well.
> If you know a good place to go for food or drinks please add it to the
> etherpad as well.
>
> Andrea
>
> [0] http://doodle.com/poll/yxy8ts8s8te8rwwh
> [1] https://etherpad.openstack.org/p/qa-ptg-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][all][designate] The way forward for Designate

[Fei Long Wang]

It would be nice to record this discussion/summary on an etherpad or
somewhere, because it's not just the problem for Designate, IMHO, many
other big tent projects are facing the same issue. Thanks.



On 22/02/17 09:25, Hayes, Graham wrote:
> For those that are interested, we will have an hour discussion about
> how designate can move forward tomorrow (wed 22nd) at the PTG.
>
> We will be in Savannah 3 @ 11:00 for an hour.
>
> Thanks,
>
> Graham
>
> On 09/02/2017 14:22, Hayes, Graham wrote:
>> The HTML version of this is here:
>> http://graham.hayes.ie/posts/openstack-designate-where-we-are/
>>
>> I have been asked a few times recently "What is the state of the Designate
>> project?", "How is Designate getting on?", and by people who know what is
>> happening "What are you going to do about Designate?".
>>
>> Needless to say, all of this is depressing to me, and the people that I have
>> worked with for the last number of years to make Designate a truly useful,
>> feature rich project.
>>
>> *TL;DR;* for this - Designate is not in a sustainable place.
>>
>> To start out - Designate has always been a small project. DNS does not have
>> massive *cool* appeal - its not shiny, pretty, or something you see on the
>> front page of HackerNews (unless it breaks - then oh boy do people
>> become DNS
>> experts).
>>
>> A line a previous PTL for the project used to use, and I have happily
>> robbed is
>> "DNS is like plumbing, no one cares about it until it breaks, and then
>> you are
>> standing knee deep in $expletive". (As an aside, that was the reason we
>> chose
>> the crocodile as our mascot - its basically a dinosaur, old as dirt, and
>> when
>> it bites it causes some serious complications).
>>
>> Unfortunately that comes over into the development of DNS products
>> sometimes.
>> DNSaaS is a check box on a tender response, an assumption.
>>
>> We were lucky in the beginning - we had 2 large(ish) public clouds that
>> needed
>> DNS services, and nothing currently existed in the eco-system, so we got
>> funding for a team from a few sources.
>>
>> We got a ton done in that period - we moved from a v1 API which was
>> synchronous to a new v2 async API, we massively increased the amount of DNS
>> servers we supported, and added new features.
>>
>> Unfortunately, this didn't last. Internal priorities within companies
>> sponsoring the development changed, and we started to shed contributors,
>> which
>> happens, however disappointing. Usually when this happens if a project is
>> important enough the community will pick up where the previous group
>> left off.
>>
>> We have yet to see many (meaningful) commits from the community though. We
>> have some great deployers who will file bugs, and if they can put up patch
>> sets - but they are (incredibly valuable and appreciated) tactical
>> contributions. A project cannot survive on them, and we are no exception.
>>
>> So where does that leave us? Let have a look at how many actual commits we
>> have had:
>>
>> Commits per cycle
>>
>>  +--+-+
>>  | Havana   | 172 |
>>  +--+-+
>>  | Icehouse | 165 |
>>  +--+-+
>>  | Juno | 254 |
>>  +--+-+
>>  | Kilo | 340 |
>>  +--+-+
>>  | Liberty  | 327 |
>>  +--+-+
>>  | Mitaka   | 246 |
>>  +--+-+
>>  | Newton   | 299 |
>>  +--+-+
>>  | Ocata| 98  |
>>  +--+-+
>>
>> Next cycle, we are going to have 2 community goals:
>>
>> * Control Plane API endpoints deployment via WSGI
>> * Python 3.5 functional testing
>>
>> We would have been actually OK for the tempest one - we were one of the
>> first
>> external repo based plug-ins with `designate-tempest-plugin`_
>>
>> For WSGI based APIs, this will be a chunk of work - due to our internal code
>> structure splitting out the API is going to be ... an issue. (and I think it
>> will be harder than most people expect - anyone using olso.service has
>> eventlet imported - I am not sure how that affects running in a WSGI server)
>>
>> Python 3.5 - I have no idea. We can't even run all our unit tests on python
>> 3.5, so I suspect getting functional testing may be an issue. And,
>> convincing
>> management that re-factoring parts of the code base due to "community goals"
>> or a future potential pay-off can be more difficult than it should.
>>
>>   http://graham.hayes.ie/images/oct-2016-projects-prod.jpg
>>
>> We now have a situation where the largest "non-core" project [1]_ in the
>> tent
>> has a tiny number of developers working on it. 42% of deployers are
>> evaluating
>> Designate, so we should see this start to increase.
>>
>> How did this happen?
>> 
>>
>> Like most situations, there is no single cause.
>>
>> Certainly there may have been fault on 

Re: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday

[Ichihara Hirofumi]

+1

2017-02-17 14:18 GMT-05:00 Kevin Benton :

> Hi all,
>
> I'm organizing a Neutron social event for Thursday evening in Atlanta
> somewhere near the venue for dinner/drinks. If you're interested, please
> reply to this email with a "+1" so I can get a general count for a
> reservation.
>
> Cheers,
> Kevin Benton
>
> __
> OpenStack Development Mailing 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] [Fuel] Nominating Alexander Kislitsky for fuel-web-core

[Булат Гайфуллин]

+1

2017-02-21 17:01 GMT+03:00 Alexey Shtokolov :

> Hey fellow fuelers,
>
> I'd like to nominate Alexander Kislitsky to the fuel-web-core team.
> He's doing thorough review [1], participate in feature developments
> (e.g. Config-DB enhancements, network-manager performance
> improvements) and made an outstanding contribution bug-fixing.
>
> Core reviewers, please reply back with +1/-1.
>
> Thanks,
> Ihor
>
> [1] http://stackalytics.com/?release=ocata=fuel-web
>
> __
> OpenStack Development Mailing 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] [tc][all][designate] The way forward for Designate

[Hayes, Graham]

For those that are interested, we will have an hour discussion about
how designate can move forward tomorrow (wed 22nd) at the PTG.

We will be in Savannah 3 @ 11:00 for an hour.

Thanks,

Graham

On 09/02/2017 14:22, Hayes, Graham wrote:
> The HTML version of this is here:
> http://graham.hayes.ie/posts/openstack-designate-where-we-are/
>
> I have been asked a few times recently "What is the state of the Designate
> project?", "How is Designate getting on?", and by people who know what is
> happening "What are you going to do about Designate?".
>
> Needless to say, all of this is depressing to me, and the people that I have
> worked with for the last number of years to make Designate a truly useful,
> feature rich project.
>
> *TL;DR;* for this - Designate is not in a sustainable place.
>
> To start out - Designate has always been a small project. DNS does not have
> massive *cool* appeal - its not shiny, pretty, or something you see on the
> front page of HackerNews (unless it breaks - then oh boy do people
> become DNS
> experts).
>
> A line a previous PTL for the project used to use, and I have happily
> robbed is
> "DNS is like plumbing, no one cares about it until it breaks, and then
> you are
> standing knee deep in $expletive". (As an aside, that was the reason we
> chose
> the crocodile as our mascot - its basically a dinosaur, old as dirt, and
> when
> it bites it causes some serious complications).
>
> Unfortunately that comes over into the development of DNS products
> sometimes.
> DNSaaS is a check box on a tender response, an assumption.
>
> We were lucky in the beginning - we had 2 large(ish) public clouds that
> needed
> DNS services, and nothing currently existed in the eco-system, so we got
> funding for a team from a few sources.
>
> We got a ton done in that period - we moved from a v1 API which was
> synchronous to a new v2 async API, we massively increased the amount of DNS
> servers we supported, and added new features.
>
> Unfortunately, this didn't last. Internal priorities within companies
> sponsoring the development changed, and we started to shed contributors,
> which
> happens, however disappointing. Usually when this happens if a project is
> important enough the community will pick up where the previous group
> left off.
>
> We have yet to see many (meaningful) commits from the community though. We
> have some great deployers who will file bugs, and if they can put up patch
> sets - but they are (incredibly valuable and appreciated) tactical
> contributions. A project cannot survive on them, and we are no exception.
>
> So where does that leave us? Let have a look at how many actual commits we
> have had:
>
> Commits per cycle
>
>  +--+-+
>  | Havana   | 172 |
>  +--+-+
>  | Icehouse | 165 |
>  +--+-+
>  | Juno | 254 |
>  +--+-+
>  | Kilo | 340 |
>  +--+-+
>  | Liberty  | 327 |
>  +--+-+
>  | Mitaka   | 246 |
>  +--+-+
>  | Newton   | 299 |
>  +--+-+
>  | Ocata| 98  |
>  +--+-+
>
> Next cycle, we are going to have 2 community goals:
>
> * Control Plane API endpoints deployment via WSGI
> * Python 3.5 functional testing
>
> We would have been actually OK for the tempest one - we were one of the
> first
> external repo based plug-ins with `designate-tempest-plugin`_
>
> For WSGI based APIs, this will be a chunk of work - due to our internal code
> structure splitting out the API is going to be ... an issue. (and I think it
> will be harder than most people expect - anyone using olso.service has
> eventlet imported - I am not sure how that affects running in a WSGI server)
>
> Python 3.5 - I have no idea. We can't even run all our unit tests on python
> 3.5, so I suspect getting functional testing may be an issue. And,
> convincing
> management that re-factoring parts of the code base due to "community goals"
> or a future potential pay-off can be more difficult than it should.
>
>   http://graham.hayes.ie/images/oct-2016-projects-prod.jpg
>
> We now have a situation where the largest "non-core" project [1]_ in the
> tent
> has a tiny number of developers working on it. 42% of deployers are
> evaluating
> Designate, so we should see this start to increase.
>
> How did this happen?
> 
>
> Like most situations, there is no single cause.
>
> Certainly there may have been fault on the side of the Designate leadership.
> We had started out as a small team, and had built a huge amount of trust and
> respect based on in person interactions over a few years, which meant that
> there was a fair bit of "tribal knowledge" in the heads of a few people, and
> that new people had a hard time becoming part of the group.
>
> Also, due to volume of work 

Re: [openstack-dev] [qa] Tempest Stable plugin interface change broke gate

[Andrea Frittoli]

Hi Graham,

sorry about that, and good catch.
You are right, that's a stable interface so that change should not have
landed.

andrea

On Tue, Feb 21, 2017 at 2:51 PM Hayes, Graham  wrote:

> Hi.
>
> https://review.openstack.org/#/c/434304/ landed yesterday, which was a
> change to the stable interface for tempest plugins.
>
> It also took out the designate gate.
>
> Is this interface stable? - If so, there should have been at least some
> deprecation cycle, notification, or something.
>
> Revert has been proposed - https://review.openstack.org/#/c/436612/
>
> Can someone clarify what the "stable" in "Stable APIs" listed here [1]
> means?
>
> - Graham
>
> 1 -
>
> https://docs.openstack.org/developer/tempest/plugin.html#stable-tempest-apis-plugins-may-use
>
> __
> OpenStack Development Mailing 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] [qa] Tempest Stable plugin interface change broke gate

[Hayes, Graham]

Hi.

https://review.openstack.org/#/c/434304/ landed yesterday, which was a
change to the stable interface for tempest plugins.

It also took out the designate gate.

Is this interface stable? - If so, there should have been at least some
deprecation cycle, notification, or something.

Revert has been proposed - https://review.openstack.org/#/c/436612/

Can someone clarify what the "stable" in "Stable APIs" listed here [1]
means?

- Graham

1 - 
https://docs.openstack.org/developer/tempest/plugin.html#stable-tempest-apis-plugins-may-use

__
OpenStack Development Mailing 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] Call for upstream training liaison

[Matt Riedemann]

If you haven't seen this yet [1] there is going to be an upstream 
training meeting at the PTG on Wednesday 2/22 at 12ET to talk about 
upstream training and what liaisons from each project can do to help.


This email is a call for anyone that's working on Nova and is interested 
in volunteering to be the team liaison for the upstream training which 
happens the weekend before the Pike summit in Boston.


At a high level, it's my understanding that this involves helping some 
new contributors get comfortable with the various projects and to 
associate a person with each project so when they show up in IRC they 
know someone and can ask questions (similar to mentoring but I believe 
less involved on an ongoing basis).


So if you're going to be at the Boston summit and this is something 
you're interested in, please either speak with me, Ildiko, or show up to 
the meeting to find out more.


[1] 
http://lists.openstack.org/pipermail/openstack-dev/2017-February/112270.html


--

Thanks,

Matt Riedemann

__
OpenStack Development Mailing 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] [acceleration]Pike PTG agenda

[Zhipeng Huang]

Hi team,

Please find the initial ptg agenda on the etherpad
https://etherpad.openstack.org/p/cyborg-ptg-pike , and feel free to add
anything that you want to discuss.

Also look forward to meet you guys who has traveled to Atlanta f2f tomorrow
:)

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct 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] New mascot design

[Heidi Joy Tretheway]

Hi Jay & Ironic-ers, 

No, that’s not out of the question at all. In fact, we already added in the 
sticks as drumsticks, and on our list for revision we’re looking to take out 
the leaf (to make the sticks more drumstick-like) and add back in the Kiss 
makeup since many folks in your community liked it. Right now we’ve pressed 
pause on any new changes until after the PTL to give your team a chance to 
debate options and coalesce around a single direction for the design revision 
(since we’re seeing a lot of conflicting feedback). I’m eager to support your 
team’s requests. :-)

> On Feb 21, 2017, at 10:24 AM, Jay Faulkner  wrote:
> 
>> 
>> On Feb 15, 2017, at 5:25 PM, Heidi Joy Tretheway  
>> wrote:
>> 
>> Hi Ironic team, 
>> 
>> [TL;DR - we agree to Miles’ proposal for two images (one mascot, one logo) 
>> for different contexts. We’re looking for any final feedback on the stylized 
>> logo for use on the website, while the PixieBoots mascot remains yours for 
>> swag, etc.]
>> 
>> I’m doing my best to reply to all questions on this thread as Lucas 
>> requested: 
>> http://lists.openstack.org/pipermail/openstack-dev/2017-February/112212.html.
>>  
>> Please feel free to drop a note here if I’ve missed anything. I’m 
>> summarizing everything below:
>> 
>> Design issues: 
>> —The bear looked angry in v1
>> Answer: We removed the angry expression and replaced it with a neutral 
>> expression
>> —The metal horns hand gesture is culturally inappropriate (rude in some 
>> countries) (from Ruby)
>> Answer: We removed this feature and replaced it, based on the team’s input, 
>> with the bear holding sticks (as drumsticks)
>> —What about a goat-like horned bear? (Joanna)
>> Answer: We removed horned references due to the cultural reference to 
>> cuckolding as the Ironic team pointed out
>> —The bear looks too much like a Russian meme with two hands up
>> Answer: We have a face-forward bear, not a side-view bear, and only one hand 
>> raised.
>> —The bear’s face decoration looked too much like the band Kiss
>> Answer: While this was intentional by the designer (for a more “metal” 
>> look), we removed this feature and replaced it with basic bear face 
>> coloring. Some folks (including Miles, Dmitry, Sam who added +1s) would like 
>> this back in. We’re happy to do it, we just need the team to agree on one 
>> direction.
>> —Don’t like the style (reminds Lucas of church windows)
>> Answer: The design style for all of the mascots is set. It was shared in 
>> July when we started this project, and unfortunately the feedback window 
>> regarding design style has passed, as 95% of projects have now received 
>> their logos. 
>> —Request to abbreviate the bear so it just shows head/top of torso/hand 
>> holding drumsticks (from Dmitry)
>> Answer: We can revisit that with the designers, however it doesn’t match the 
>> rest of the logo set, which is either face or full body of each mascot. 
>> We’re happy to try this, but as we’ve already been four rounds with the 
>> team, I’m soliciting ANY final feedback on this version before we finalize 
>> it. 
>> 
>> 
> 
> I have a question about the drumsticks — I noticed today at the PTG, that the 
> cloud kitty mascot has a collar and license — that seems like a minimal 
> manmade addition to that logo, similar to what actual drumsticks would be 
> with an Ironic mascot. Is it completely out of the question to revisit adding 
> those back to the logo? As this debate has shown, it’s difficult to transmit 
> the idea of a “metal” bear without some kind of musical tool/instrument 
> involved.
> 
> Thanks,
> Jay Faulkner
> 
>> Outstanding questions: 
>> —Can we use PixieBoots in the future? 
>> Answer: Absolutely. You’re welcome to produce vintage swag like shirts and 
>> stickers with your original logo. Any team can use their old logo in this 
>> way. Put another way, if you’d like to call PixieBoots your mascot, but 
>> refer to the Ironic logo our illustrators have created as merely a logo, 
>> that’s fine. And you don’t have to use this logo if you don’t want to. 
>> —Can we use (1) A stylized logo, matching the guidelines, for use in 
>> “official” settings and anywhere that it will be seen in other projects’ 
>> logos; and (2) Our existing PixieBoots mascot, for use in “official” 
>> settings (laptop stickers, T-shirts, chatbots, webcomic, etc.)? (suggested 
>> by Miles)
>> Answer: Great suggestion! Yes. Together with the answer above, that’s our 
>> intention—we’d like for you to be able to continue to use your beloved 
>> mascot in your own way, and we’d like the Ironic team to select some logo 
>> that is consistent with the rest of the community project logos, that we can 
>> use on official channels such as the website.
>> —What will we see at the PTG?
>> Answer: Out of respect for the team, we did not print stickers or signage 
>> for the Ironic team with any logo on it until the team reaches an agreement. 
>> —What license 

Re: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday

[John Joyce (joycej)]

+1 – thanks for organizing

From: Kevin Benton [mailto:ke...@benton.pub]
Sent: Friday, February 17, 2017 2:19 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday

Hi all,

I'm organizing a Neutron social event for Thursday evening in Atlanta somewhere 
near the venue for dinner/drinks. If you're interested, please reply to this 
email with a "+1" so I can get a general count for a reservation.

Cheers,
Kevin Benton
__
OpenStack Development Mailing 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] Hierarchical quotas at the PTG?

[Matt Riedemann]

On 2/15/2017 6:22 PM, Matt Riedemann wrote:


I have no idea. I'm guessing someone will ping me when the time comes
and I'll mosey on over. For whatever doesn't get covered, or needs to
spill over, Nova is already going to have a block of time to talk about
quota-related things (not just this) so we can pick it up there too
later in the week.



We'll be meeting in the Georgia 4 room (level 1) on Tuesday at 3pm to 
discuss this.


--

Thanks,

Matt Riedemann

__
OpenStack Development Mailing 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] New mascot design

[Jay Faulkner]

> On Feb 15, 2017, at 5:25 PM, Heidi Joy Tretheway  
> wrote:
> 
> Hi Ironic team, 
> 
> [TL;DR - we agree to Miles’ proposal for two images (one mascot, one logo) 
> for different contexts. We’re looking for any final feedback on the stylized 
> logo for use on the website, while the PixieBoots mascot remains yours for 
> swag, etc.]
> 
> I’m doing my best to reply to all questions on this thread as Lucas 
> requested: 
> http://lists.openstack.org/pipermail/openstack-dev/2017-February/112212.html. 
> Please feel free to drop a note here if I’ve missed anything. I’m summarizing 
> everything below:
> 
> Design issues: 
> —The bear looked angry in v1
> Answer: We removed the angry expression and replaced it with a neutral 
> expression
> —The metal horns hand gesture is culturally inappropriate (rude in some 
> countries) (from Ruby)
> Answer: We removed this feature and replaced it, based on the team’s input, 
> with the bear holding sticks (as drumsticks)
> —What about a goat-like horned bear? (Joanna)
> Answer: We removed horned references due to the cultural reference to 
> cuckolding as the Ironic team pointed out
> —The bear looks too much like a Russian meme with two hands up
> Answer: We have a face-forward bear, not a side-view bear, and only one hand 
> raised.
> —The bear’s face decoration looked too much like the band Kiss
> Answer: While this was intentional by the designer (for a more “metal” look), 
> we removed this feature and replaced it with basic bear face coloring. Some 
> folks (including Miles, Dmitry, Sam who added +1s) would like this back in. 
> We’re happy to do it, we just need the team to agree on one direction.
> —Don’t like the style (reminds Lucas of church windows)
> Answer: The design style for all of the mascots is set. It was shared in July 
> when we started this project, and unfortunately the feedback window regarding 
> design style has passed, as 95% of projects have now received their logos. 
> —Request to abbreviate the bear so it just shows head/top of torso/hand 
> holding drumsticks (from Dmitry)
> Answer: We can revisit that with the designers, however it doesn’t match the 
> rest of the logo set, which is either face or full body of each mascot. We’re 
> happy to try this, but as we’ve already been four rounds with the team, I’m 
> soliciting ANY final feedback on this version before we finalize it. 
> 
> 

I have a question about the drumsticks — I noticed today at the PTG, that the 
cloud kitty mascot has a collar and license — that seems like a minimal manmade 
addition to that logo, similar to what actual drumsticks would be with an 
Ironic mascot. Is it completely out of the question to revisit adding those 
back to the logo? As this debate has shown, it’s difficult to transmit the idea 
of a “metal” bear without some kind of musical tool/instrument involved.

Thanks,
Jay Faulkner

> Outstanding questions: 
> —Can we use PixieBoots in the future? 
> Answer: Absolutely. You’re welcome to produce vintage swag like shirts and 
> stickers with your original logo. Any team can use their old logo in this 
> way. Put another way, if you’d like to call PixieBoots your mascot, but refer 
> to the Ironic logo our illustrators have created as merely a logo, that’s 
> fine. And you don’t have to use this logo if you don’t want to. 
> —Can we use (1) A stylized logo, matching the guidelines, for use in 
> “official” settings and anywhere that it will be seen in other projects’ 
> logos; and (2) Our existing PixieBoots mascot, for use in “official” settings 
> (laptop stickers, T-shirts, chatbots, webcomic, etc.)? (suggested by Miles)
> Answer: Great suggestion! Yes. Together with the answer above, that’s our 
> intention—we’d like for you to be able to continue to use your beloved mascot 
> in your own way, and we’d like the Ironic team to select some logo that is 
> consistent with the rest of the community project logos, that we can use on 
> official channels such as the website.
> —What will we see at the PTG?
> Answer: Out of respect for the team, we did not print stickers or signage for 
> the Ironic team with any logo on it until the team reaches an agreement. 
> —What license will the mascot have?
> Answer: It will be CC-BY-ND, which the foundation uses for most of our 
> collateral. That allows you to use it (and we’ve provided ten versions to the 
> PTLs of the projects with finalized mascots so they have a good amount of 
> flexibility in logo use). It prevents, for example, a for-profit company from 
> inserting its commercial logo into an element of the community-use mascots 
> (which was a common request early in the design process). If you would like 
> to make a derivative work, we can definitely find a way to compromise, just 
> send me a note. 
> —What does the foundation want to achieve with this? (from Lucas)
> Answer: We’re trying to communicate, by way of design, that the projects are 
> cohesive and connected, while 

[openstack-dev] [Zun] Choose a project mascot

[Heidi Joy Tretheway]

Hello Zun team, I apologize that your mascot choice was listed wrong on 
openstack.org/project-mascots. It should have shown as (not chosen) but instead 
showed up as Tricircle’s chosen mascot, the panda. The error is entirely my 
fault, and we’ll get it fixed on the website shortly. Thanks for your patience, 
and please carry on with your debate over the best Sun mascot!
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [openstack-docs] [dev] Thursday docs meeting

[Alexandra Settle]

Hi everyone,

The docs team will still be hosting their meeting on Thursday, 23 February at 
2100 UTC in #openstack-meeting-alt. We will not be skipping the meeting in 
favor for the PTG as the docs sessions are on the Mon-Tues and I would love the 
opportunity to immediately report back to people who cannot attend.

For more meeting details, including minutes and the 
agenda:https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting

Thanks,

Alex

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

[openstack-dev] [docs] 101 session

[Alexandra Settle]

Hey everyone,

If anyone is interested, I’ll be helping out a few new contributors getting set 
up with documentation tools tomorrow morning (Wednesday, 22nd February).

I’ll be on level 1, on the couches near the coffee station for anyone who’s 
interested in getting setup and learning a bit about how docs work.

Cheers,

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

Re: [openstack-dev] The end of OpenStack packages in Debian?

[Ritesh Raj Sarraf]

Hello Thomas,

Sad to see this. But with so much free loading trend, these are bound to happen.

For the LIO-fb target in Debian, we've been depending on the rtslib-fb package,
which you've maintained so far. Should we pick it up under the pkg-linux-target
team ?

Ritesh

On Wed, 2017-02-15 at 13:42 +0100, Thomas Goirand wrote:
> Hi there,
> 
> It's been a while since I planed on writing this message. I couldn't
> write it because the situation makes me really sad. At this point, it
> starts to be urgent to post it.
> 
> As for many other folks, Mirantis decided to end its contract with me.
> This happened when I was the most successful doing the job, with all of
> the packaging CI moved to OpenStack infra at the end of the OpenStack
> Newton cycle, after we were able to release Newton this way. I was
> hoping to start packaging on every commit for Ocata. That's yet another
> reason for me to be very frustrated about all of this. Such is life...
> 
> Over the last few months, I hoped for having enough strengths to
> continue my packaging work anyway, and get Ocata packages done. But
> that's not what happened. The biggest reason for this is that I know
> that this needs to be a full time job. And at this point, I still don't
> know what my professional future will be. A company, in Barcelona, told
> me I'd get hired to continue my past work of packaging OpenStack in
> Debian, but so far, I'm still waiting for a definitive answer, so I'm
> looking into some other opportunities.
> 
> All this to say that, unless someone wants to hire me for it (which
> would be the best outcome, but I fear this wont happen), or if someone
> steps in (this seems unlikely at this point), both the packaging-deb and
> the faith of OpenStack packages in Debian are currently compromised.
> 
> I will continue to maintain OpenStack Newton during the lifetime of
> Debian Stretch though, but I don't plan on doing anything more. This
> means that maybe, Newton will be the last release of OpenStack in
> Debian. If things continue this way, I probably will ask for the removal
> of all OpenStack packages from Debian Sid after Stretch gets released
> (unless I know that someone will do the work).
> 
> As a consequence, the following projects wont get packages even in
> Ubuntu (as they were "community maintained", which means done by me and
> later sync into Ubuntu...):
> 
> - congress
> - gnocchi
> - magnum
> - mistral
> - murano
> - sahara
> - senlin
> - watcher
> - zaqar
> 
> Hopefully, Canonical will continue to maintain the other 15 (more
> core...) projects in UCA.
> 
> Thanks for the fish,
> 
> Thomas Goirand (zigo)
> 
> P,S: To the infra folks: please keep the packaging CI as it is, as it
> will be useful for the lifetime of Stretch.
> 
> 
-- 
Given the large number of mailing lists I follow, I request you to CC
me in replies for quicker response

signature.asc
Description: This is a digitally signed message part
__
OpenStack Development Mailing 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] Is 'murano-agent' support optional in an OpenStack Murano Deployment ?

[Serg Melikyan]

Hi Greg,

>Is the Murano-agent functionality truly optional?
Yes, there is even an option in config file to completely disable this
functionality: [engine]\disable_murano_agent.

You can use Heat Software Configuration to configure VM or just
Cloud-Init. Unfortunately I don't have examples under my hand, but
basically you should use LinuxUDInstance or HeatSWConfigLinuxInstance
instead of LinuxMuranoInstance in your application.

>Is there a way to determine whether a Murano Application requires Murano-agent 
>functionality or not
apps.openstack.org doesn't have any indication regarding if
murano-agent functionality is needed or not. There is no way to deduce
this information without looking into the source code.

>Roughly what % of Murano Applications leverage the Murano-agent functionality ?
100% of murano applications published on apps.openstack.org require
murano-agent.

On Tue, Feb 21, 2017 at 5:39 AM, Waines, Greg  wrote:
> A couple of questions about Murano-agent functionality in an OpenStack
> Murano Deployment:
>
>
>
> 1. Is the Murano-agent functionality truly optional ?
>
>
>
>  I believe answer is yes … although wanted to confirm that the
> optionality wasn’t referring to whether Murano-agent was implemented with
> same or separate rabbit server.
>
>
>
>
>
> 2. Assuming Murano-agent functionality is optional,
>
>
>
>  I am surprised that items in the Murano Community Catalog
> (https://apps.openstack.org/#tab=murano-apps )
>  don’t explicitly indicate whether they require Murano-agent
> functionality or not.
>
>
>
>  a) Is there a way to determine whether a Murano Application requires
> Murano-agent functionality or not ?
>
>  b) Roughly what % of Murano Applications leverage the Murano-agent
> functionality ?
>
>
>
>
>
>
>
> 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
>



-- 
Serg Melikyan, Development Manager at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com | +1 (650) 440-8979

__
OpenStack Development Mailing 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] [Sahara][QA] Tests broken after a devstack change

[Luigi Toscano]

On Tuesday, 21 February 2017 11:18:12 CET Sean Dague wrote:
> On 02/21/2017 10:45 AM, Luigi Toscano wrote:
> > Hi team (mostly at the PTG),
> > 
> > you probably noticed that the jobs has been failing since February 17th.
> > The reason can be traced back to this change in devstack:
> > 
> > https://review.openstack.org/#/c/433272/
> > 
> > I tried to revert it and rerun a job after setting the revert and
> > dependency, and indeed both the tempest and the scenario jobs passed
> > (ignore the failure in the cli job, it is unrelated):
> > https://review.openstack.org/#/c/436116/
> > https://review.openstack.org/#/c/436479/
> > 
> > The main error was related to
> > 
> >  EndpointNotFound: adminURL endpoint for compute service not found
> > 
> > so most likely we need to revisit how Sahara uses the endpoints. If you
> > have some time, please squeeze this into the discussions. Or check with
> > the rest of QA/devstack people if it is possible to revert the change.
> > 
> > This is master only (so Pike), Ocata is not affected (as the change landed
> > after that devstack was branched). Still it blocks some merges.
> 
> You can change
> https://github.com/openstack/sahara/blob/af5979e70bd1665abca780bb1d0965e240e
> 9f5e5/devstack/settings#L26 to publicURL as a default, then things will be
> fine.

Thank you, I submitted https://review.openstack.org/436567 , let's cross 
fingers.


> The explosion of the 3 interfaces is a bit of an anti pattern we are
> trying to claw back, because there is really no different in
> functionality provided by them, it's merely a way to designate different
> network paths. The out of the box devstack is now providing only
> publicURL except when services specifically do something different with
> them, like admin.
Understood, thanks for the explanation.

Ciao
-- 
Luigi

__
OpenStack Development Mailing 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][ptg] QA Team social evening

[Andrea Frittoli]

Hello folks,

I booked a table for tonight at 7:30 at Poor Calvin's [0]. It's a 15min
away from the Sheraton [1], for everyone who's answered yes/maybe for
Tuesday on the doodle [2].
If you're not planning to come please let me know so I can update the
reservation.

See you later!

Andrea

[0] http://www.poorcalvins.com/Home
[1] https://goo.gl/ADuVlX
[2] http://doodle.com/poll/yxy8ts8s8te8rwwhsfrnft2i/admin

On Mon, Feb 20, 2017 at 11:18 PM Andrea Frittoli 
wrote:

Hi folks,

thank you for your vote!
It looks like the best option is tomorrow (Tuesday) night - there's going
to be a reception at the Sheraton between 5-7 but we can have dinner after
that.
I'll book a place tomorrow morning, if you have any good candidate for good
restaurant nearby please let me know.

Thanks!

andrea

On Sun, Feb 19, 2017 at 12:35 PM Andrea Frittoli 
wrote:

Hello,

I'd like to propose a social evening for the folks in the QA sessions.
I prepared a doodle [0] so if you're interested please vote :)

I added the link to the main QA etherpad [1] as well.
If you know a good place to go for food or drinks please add it to the
etherpad as well.

Andrea

[0] http://doodle.com/poll/yxy8ts8s8te8rwwh
[1] https://etherpad.openstack.org/p/qa-ptg-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] [tripleo] Atlanta PTG

[Carlos Camacho Gonzalez]

+1 Sai

On Tue, Feb 21, 2017 at 5:46 PM, Sai Sindhur Malleni 
wrote:

> Is there a plan to have a google hangouts session or similar to attend
> remotely?
>
> On Mon, Jan 23, 2017 at 8:45 AM, John Trowbridge  wrote:
>
>>
>>
>> On 01/21/2017 05:37 AM, Michele Baldessari wrote:
>> > Hi Emilien,
>> >
>> > while not a design session per se, I would love to propose a short slot
>> > for TripleO CI Q, if we have some time left. In short, I'd like to be
>> > more useful around CI failures, but I lack the understanding of a few
>> > aspects of our current CI (promotion, when do images get built, etc.),
>> > that would benefit quite a bit from a short session where we have a few
>> > CI folks in the room that could answer questions or give some tips.
>> > I know of quite few other people that are in the same boat and maybe
>> > this will help a bit our current issue where only a few folks always
>> > chase CI issues.
>> >
>> > If there is consensus (and some CI folks willing to attend ;) and time
>> > for this, I'll be happy to organize this and prepare a bunch of
>> > questions ideas beforehand.
>> >
>>
>> Great idea. We have a room for three days, so it is not like summit
>> where there is really limited time.
>>
>> > Thoughts?
>> > Michele
>> >
>> > On Wed, Jan 04, 2017 at 07:26:52AM -0500, Emilien Macchi wrote:
>> >> I would like to bring this topic up on your inbox, so we can continue
>> >> to make progress on the agenda. Feel free to follow existing examples
>> >> in the etherpad and propose a design dession.
>> >>
>> >> Thanks,
>> >>
>> >> On Wed, Dec 21, 2016 at 9:06 AM, Emilien Macchi 
>> wrote:
>> >>> General infos about PTG: https://www.openstack.org/ptg/
>> >>>
>> >>> Some useful informations about PTG/TripleO:
>> >>>
>> >>> * When? We have a room between Wednesday and Friday included.
>> >>> Important sessions will happen on Wednesday and Thursday. We'll
>> >>> probably have sessions on Friday, but it might be more hands-on and
>> >>> hackfest, where people can enjoy the day to work together.
>> >>>
>> >>> * Let's start to brainstorm our topics:
>> >>> https://etherpad.openstack.org/p/tripleo-ptg-pike
>> >>>   Feel free to add any topic, as soon as you can. We need to know asap
>> >>> which sessions will be share with other projects (eg: tripleo/mistral,
>> >>> tripleo/ironic, tripleo/heat, etc).
>> >>>
>> >>>
>> >>> Please let us know any question or feedback,
>> >>> Looking forward to seeing you there!
>> >>> --
>> >>> Emilien Macchi
>> >>
>> >>
>> >>
>> >> --
>> >> Emilien Macchi
>> >>
>> >> 
>> __
>> >> 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
>>
>
>
>
> --
> Sai Sindhur Malleni
>
> Red Hat Inc.
> 100 East Davie Street
> Raleigh, NC, USA
> Work: (919) 754-4557 | Cell: (919) 985-1055
>
> __
> OpenStack Development Mailing 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] [tripleo] Atlanta PTG

[Sai Sindhur Malleni]

Is there a plan to have a google hangouts session or similar to attend
remotely?

On Mon, Jan 23, 2017 at 8:45 AM, John Trowbridge  wrote:

>
>
> On 01/21/2017 05:37 AM, Michele Baldessari wrote:
> > Hi Emilien,
> >
> > while not a design session per se, I would love to propose a short slot
> > for TripleO CI Q, if we have some time left. In short, I'd like to be
> > more useful around CI failures, but I lack the understanding of a few
> > aspects of our current CI (promotion, when do images get built, etc.),
> > that would benefit quite a bit from a short session where we have a few
> > CI folks in the room that could answer questions or give some tips.
> > I know of quite few other people that are in the same boat and maybe
> > this will help a bit our current issue where only a few folks always
> > chase CI issues.
> >
> > If there is consensus (and some CI folks willing to attend ;) and time
> > for this, I'll be happy to organize this and prepare a bunch of
> > questions ideas beforehand.
> >
>
> Great idea. We have a room for three days, so it is not like summit
> where there is really limited time.
>
> > Thoughts?
> > Michele
> >
> > On Wed, Jan 04, 2017 at 07:26:52AM -0500, Emilien Macchi wrote:
> >> I would like to bring this topic up on your inbox, so we can continue
> >> to make progress on the agenda. Feel free to follow existing examples
> >> in the etherpad and propose a design dession.
> >>
> >> Thanks,
> >>
> >> On Wed, Dec 21, 2016 at 9:06 AM, Emilien Macchi 
> wrote:
> >>> General infos about PTG: https://www.openstack.org/ptg/
> >>>
> >>> Some useful informations about PTG/TripleO:
> >>>
> >>> * When? We have a room between Wednesday and Friday included.
> >>> Important sessions will happen on Wednesday and Thursday. We'll
> >>> probably have sessions on Friday, but it might be more hands-on and
> >>> hackfest, where people can enjoy the day to work together.
> >>>
> >>> * Let's start to brainstorm our topics:
> >>> https://etherpad.openstack.org/p/tripleo-ptg-pike
> >>>   Feel free to add any topic, as soon as you can. We need to know asap
> >>> which sessions will be share with other projects (eg: tripleo/mistral,
> >>> tripleo/ironic, tripleo/heat, etc).
> >>>
> >>>
> >>> Please let us know any question or feedback,
> >>> Looking forward to seeing you there!
> >>> --
> >>> Emilien Macchi
> >>
> >>
> >>
> >> --
> >> Emilien Macchi
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Sai Sindhur Malleni

Red Hat Inc.
100 East Davie Street
Raleigh, NC, USA
Work: (919) 754-4557 | Cell: (919) 985-1055
__
OpenStack Development Mailing 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]Use 'uuid' instead of 'id' as object ident in data model

[Pradeep Singh]

I also agree to use 'uuid' as primary key as that makes more sense as
compared to id.

On Tue, Feb 21, 2017 at 9:40 PM, Hongbin Lu  wrote:

> Gordon & Qiming,
>
> Thanks for your inputs. The only reason Zun was using 'id' is because the
> data model was copied from other projects and those projects are using
> 'id', but I couldn't think of a reason why they were using 'id' at the
> first place. By aggregating the feedback so far, I think it makes sense for
> Zun to switch to 'uuid' since we introduced etcd as an alternative
> datastore and etcd didn't support auto-increment primary key, unless
> someone pointed out a valid reason for stay using 'id'...
>
> Best regards,
> Hongbin
>
> > -Original Message-
> > From: gordon chung [mailto:g...@live.ca]
> > Sent: February-21-17 8:29 AM
> > To: openstack-dev@lists.openstack.org
> > Subject: Re: [openstack-dev] [Zun]Use 'uuid' instead of 'id' as object
> > ident in data model
> >
> >
> >
> > On 21/02/17 01:28 AM, Qiming Teng wrote:
> > >> in mysql[2].
> > > Can someone remind me the benefits we get from Integer over UUID as
> > > primary key? UUID, as its name implies, is meant to be an identifier
> > > for a resource. Why are we generating integer key values?
> >
> > this ^. use UUID please. you can google why auto increment is a
> > probably not a good idea.
> >
> > from a selfish pov, as gnocchi captures data on all resources in
> > openstack, we store everything as a uuid anyways. even if your id
> > doesn't clash in zun, it has a higher chance of clashing when you
> > consider all the other resources from other services.
> >
> > cheers,
> > --
> > gord
> >
> > ___
> > ___
> > OpenStack Development Mailing 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] [Zun] Choose a project mascot

[Hongbin Lu]

Hi all,

It looks someone proposed “panda” as a mascot for the Zun team [1] (although I 
don’t know who proposed it), and I think panda would be an interesting choice. 
Thoughts on this?

[1] https://www.openstack.org/project-mascots/

Best regards,
Hongbin

From: Pradeep Singh [mailto:ps4openst...@gmail.com]
Sent: February-16-17 10:46 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Zun] Choose a project mascot

I was thinking about falcon(light, powerful and fast), or dolphins or tiger.

On Wed, Feb 15, 2017 at 12:29 AM, Hongbin Lu 
> wrote:
Hi Zun team,

OpenStack has a mascot program [1]. Basically, if we like, we can choose a 
mascot to represent our team. The process is as following:
* We choose a mascot from the natural world, which can be an animal (i.e. fish, 
bird), natural feature (i.e. waterfall) or other natural element (i.e. flame).
* Once we choose a mascot, I communicate the choice with OpenStack foundation 
staff.
* Someone will work on a draft based on the style of the family of logos.
* The draft will be sent back to us for approval.

The final mascot will be used to present our team. All, any idea for the mascot 
choice?

[1] https://www.openstack.org/project-mascots/

Best regards,
Hongbin

__
OpenStack Development Mailing 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] [heat][neutron]PTG session about implement Neutron Trunks resource in heat

[Bence Romsics]

The spec proposed can be found here:
https://review.openstack.org/424571

Cheers,
Bence Romsics
__
OpenStack Development Mailing 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] [Sahara][QA] Tests broken after a devstack change

[Sean Dague]

On 02/21/2017 10:45 AM, Luigi Toscano wrote:

Hi team (mostly at the PTG),

you probably noticed that the jobs has been failing since February 17th. The
reason can be traced back to this change in devstack:

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

I tried to revert it and rerun a job after setting the revert and dependency,
and indeed both the tempest and the scenario jobs passed (ignore the failure
in the cli job, it is unrelated):
https://review.openstack.org/#/c/436116/
https://review.openstack.org/#/c/436479/

The main error was related to
 EndpointNotFound: adminURL endpoint for compute service not found

so most likely we need to revisit how Sahara uses the endpoints. If you have
some time, please squeeze this into the discussions. Or check with the rest of
QA/devstack people if it is possible to revert the change.

This is master only (so Pike), Ocata is not affected (as the change landed
after that devstack was branched). Still it blocks some merges.

Ciao


You can change 
https://github.com/openstack/sahara/blob/af5979e70bd1665abca780bb1d0965e240e9f5e5/devstack/settings#L26 
to publicURL as a default, then things will be fine.


The explosion of the 3 interfaces is a bit of an anti pattern we are 
trying to claw back, because there is really no different in 
functionality provided by them, it's merely a way to designate different 
network paths. The out of the box devstack is now providing only 
publicURL except when services specifically do something different with 
them, like admin.


-Sean

--
Sean Dague
http://dague.net

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

[openstack-dev] [Cinder] Team photo at PTG

[Sean McGinnis]

Hey team!

They are giving all teams the opportunity to get a team photo taken at
the PTG. I've signed us up for 9:30am on Thursday.

Please take your weekly shower and join us on the third floor in front
of the grand ballroom.

Sean

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

Re: [openstack-dev] [Zun]Use 'uuid' instead of 'id' as object ident in data model

[Hongbin Lu]

Gordon & Qiming,

Thanks for your inputs. The only reason Zun was using 'id' is because the data 
model was copied from other projects and those projects are using 'id', but I 
couldn't think of a reason why they were using 'id' at the first place. By 
aggregating the feedback so far, I think it makes sense for Zun to switch to 
'uuid' since we introduced etcd as an alternative datastore and etcd didn't 
support auto-increment primary key, unless someone pointed out a valid reason 
for stay using 'id'...

Best regards,
Hongbin

> -Original Message-
> From: gordon chung [mailto:g...@live.ca]
> Sent: February-21-17 8:29 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Zun]Use 'uuid' instead of 'id' as object
> ident in data model
> 
> 
> 
> On 21/02/17 01:28 AM, Qiming Teng wrote:
> >> in mysql[2].
> > Can someone remind me the benefits we get from Integer over UUID as
> > primary key? UUID, as its name implies, is meant to be an identifier
> > for a resource. Why are we generating integer key values?
> 
> this ^. use UUID please. you can google why auto increment is a
> probably not a good idea.
> 
> from a selfish pov, as gnocchi captures data on all resources in
> openstack, we store everything as a uuid anyways. even if your id
> doesn't clash in zun, it has a higher chance of clashing when you
> consider all the other resources from other services.
> 
> cheers,
> --
> gord
> 
> ___
> ___
> OpenStack Development Mailing 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] - approximate schedule for PTG / networking-bgpvpn

[Thomas Morin]

Hi everyone,

I propose to meet and discuss networking-bgpvpn tomorrow (Wed) after the 
Neutron session.
Current and future contributors to the service plugin or to drivers are 
welcome!


-Thomas



Sat Feb 18 2017 15:42:24 GMT-0500 (EST), Kevin Benton:

Hi All,


Here is a rough outline of the order in which I want to cover the 
items: https://etherpad.openstack.org/p/neutron-ptg-pike-final



I've also put together a calendar that has the meeting times as well 
as a few relevant cross project sessions and our team dinner/photo.


I suggest watching the calendar for changes since we will need to make 
adjustments as we go.


ICAL: 
https://calendar.google.com/calendar/ical/khbmhi1mhtthrmgv2gnejtul3o%40group.calendar.google.com/public/basic.ics


HTML page: 
https://calendar.google.com/calendar/embed?src=khbmhi1mhtthrmgv2gnejtul3o%40group.calendar.google.com=America/New_York



If you notice any conflicts or missing items, reply right away so I 
can get it fixed.


Cheers,
Kevin Benton


__
OpenStack Development Mailing 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] [Sahara][QA] Tests broken after a devstack change

[Telles Nobrega]

Thanks Luigi, we will certainly talk about and figure out a way ASAP to get
the the gate working again for us.

On Tue, Feb 21, 2017 at 12:54 PM Luigi Toscano  wrote:

> Hi team (mostly at the PTG),
>
> you probably noticed that the jobs has been failing since February 17th.
> The
> reason can be traced back to this change in devstack:
>
> https://review.openstack.org/#/c/433272/
>
> I tried to revert it and rerun a job after setting the revert and
> dependency,
> and indeed both the tempest and the scenario jobs passed (ignore the
> failure
> in the cli job, it is unrelated):
> https://review.openstack.org/#/c/436116/
> https://review.openstack.org/#/c/436479/
>
> The main error was related to
>  EndpointNotFound: adminURL endpoint for compute service not found
>
> so most likely we need to revisit how Sahara uses the endpoints. If you
> have
> some time, please squeeze this into the discussions. Or check with the
> rest of
> QA/devstack people if it is possible to revert the change.
>
> This is master only (so Pike), Ocata is not affected (as the change landed
> after that devstack was branched). Still it blocks some merges.
>
> Ciao
> --
> Luigi
>
> __
> OpenStack Development Mailing 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] - approximate schedule for PTG

[Thomas Morin]

Hi Kevin, all,

A few things:
- I think it would be useful to discuss the work for L2 extension ovs 
flow management [1] on Thursday aft.

- I'm ready to expose where we are on n8g-bgpvpn on Friday morning
- If time allows, it would be great to take some time to 
discuss/encourage the adoption of push notification by stadium projects 
(such as networking-bgpvpn and networking-sfc, possibly others). Perhaps 
a bootstrap overview of the things that need to be done to adopt this 
model would help.


-Thomas

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


Sat Feb 18 2017 15:42:24 GMT-0500 (EST), Kevin Benton:

Hi All,


Here is a rough outline of the order in which I want to cover the 
items: https://etherpad.openstack.org/p/neutron-ptg-pike-final



I've also put together a calendar that has the meeting times as well 
as a few relevant cross project sessions and our team dinner/photo.


I suggest watching the calendar for changes since we will need to make 
adjustments as we go.


ICAL: 
https://calendar.google.com/calendar/ical/khbmhi1mhtthrmgv2gnejtul3o%40group.calendar.google.com/public/basic.ics


HTML page: 
https://calendar.google.com/calendar/embed?src=khbmhi1mhtthrmgv2gnejtul3o%40group.calendar.google.com=America/New_York



If you notice any conflicts or missing items, reply right away so I 
can get it fixed.


Cheers,
Kevin Benton


__
OpenStack Development Mailing 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] [Sahara][QA] Tests broken after a devstack change

[Luigi Toscano]

Hi team (mostly at the PTG),

you probably noticed that the jobs has been failing since February 17th. The 
reason can be traced back to this change in devstack:

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

I tried to revert it and rerun a job after setting the revert and dependency, 
and indeed both the tempest and the scenario jobs passed (ignore the failure 
in the cli job, it is unrelated):
https://review.openstack.org/#/c/436116/
https://review.openstack.org/#/c/436479/

The main error was related to
 EndpointNotFound: adminURL endpoint for compute service not found

so most likely we need to revisit how Sahara uses the endpoints. If you have 
some time, please squeeze this into the discussions. Or check with the rest of 
QA/devstack people if it is possible to revert the change.

This is master only (so Pike), Ocata is not affected (as the change landed 
after that devstack was branched). Still it blocks some merges.

Ciao
-- 
Luigi

__
OpenStack Development Mailing 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] [stable/ocata] [nova] [devstack multi-node] nova-conductor complaining about "No cell mapping found for cell0"

[Prashant Shetty]

Hi Mark,

Thanks for your reply.

I tried "nova-manage cell_v2 discover_hosts" and it returned nothing and
still I have same issue on the node.

Problem seems be the way devstack is getting configured,
As code suggest below we create cell0 on node where n-api and n-cpu runs.
In my case compute is running only n-cpu and controller is running n-api
service, due to this code there are no cell created in controller or
compute.

We will not have this  problem in all-in-one-node setup.
--
# Do this late because it requires compute hosts to have started
if is_service_enabled n-api; then
if is_service_enabled n-cpu; then
create_cell
else
# Some CI systems like Hyper-V build the control plane on
# Linux, and join in non Linux Computes after setup. This
# allows them to delay the processing until after their whole
# environment is up.
echo_summary "SKIPPING Cell setup because n-cpu is not enabled. You
will have to do this manually before you have a working environment."
fi
fi
---

vmware@cntr11:~$ nova-manage cell_v2 discover_hosts
vmware@cntr11:~$ nova service-list
++--+---+--+-+---++-+
| Id | Binary   | Host  | Zone | Status  | State |
Updated_at | Disabled Reason |
++--+---+--+-+---++-+
| 3  | nova-conductor   | cntr11| internal | enabled | up|
2017-02-21T15:34:13.00 | -   |
| 5  | nova-scheduler   | cntr11| internal | enabled | up|
2017-02-21T15:34:15.00 | -   |
| 6  | nova-consoleauth | cntr11| internal | enabled | up|
2017-02-21T15:34:11.00 | -   |
| 7  | nova-compute | esx-ubuntu-02 | nova | enabled | up|
2017-02-21T15:34:14.00 | -   |
| 8  | nova-compute | esx-ubuntu-03 | nova | enabled | up|
2017-02-21T15:34:16.00 | -   |
| 9  | nova-compute | kvm-3 | nova | enabled | up|
2017-02-21T15:34:07.00 | -   |
| 10 | nova-compute | kvm-2 | nova | enabled | up|
2017-02-21T15:34:13.00 | -   |
| 11 | nova-compute | esx-ubuntu-01 | nova | enabled | up|
2017-02-21T15:34:14.00 | -   |
| 12 | nova-compute | kvm-1 | nova | enabled | up|
2017-02-21T15:34:09.00 | -   |
++--+---+--+-+---++-+
vmware@cntr11:~$
vmware@cntr11:~$ nova-manage cell_v2 list_cells
+--+--+
| Name | UUID |
+--+--+
+--+--+
vmware@cntr11:~$


Thanks,
Prashant

On Tue, Feb 21, 2017 at 1:02 AM, Matt Riedemann  wrote:

> On 2/20/2017 10:31 AM, Prashant Shetty wrote:
>
>> Thanks Jay for the response. Sorry I missed out on copying right error.
>>
>> Here is the log:
>> 2017-02-20 14:24:06.211 TRACE nova.conductor.manager NoValidHost: No
>> valid host was found. There are not enough hosts available.
>> 2017-02-20 14:24:06.211 TRACE nova.conductor.manager
>> 2017-02-20 14:24:06.211 TRACE nova.conductor.manager
>> 2017-02-20 14:24:06.217 ERROR nova.conductor.manager
>> [req-e17fda8d-0d53-4735-922e-dd635d2ab7c0 admin admin] No cell mapping
>> found for cell0 while trying to record scheduling failure. Setup is
>> incomplete.
>>
>> I tried command you mentioned, still I see same error on conductor.
>>
>> As part of stack.sh on controller I see below command was executed
>> related to "cell". Isn't it devstack should take care of this part
>> during initial bringup or am I missing any parameters in localrc for
>> same?.
>>
>> NOTE: I have not explicitly enabled n-cell in localrc
>>
>> 2017-02-20 14:11:47.510 INFO migrate.versioning.api [-] done
>> +lib/nova:init_nova:683recreate_database nova
>> +lib/database:recreate_database:112local db=nova
>> +lib/database:recreate_database:113recreate_database_mysql nova
>> +lib/databases/mysql:recreate_database_mysql:56  local db=nova
>> +lib/databases/mysql:recreate_database_mysql:57  mysql -uroot -pvmware
>> -h127.0.0.1 -e 'DROP DATABASE IF EXISTS nova;'
>> +lib/databases/mysql:recreate_database_mysql:58  mysql -uroot -pvmware
>> -h127.0.0.1 -e 'CREATE DATABASE nova CHARACTER SET utf8;'
>> +lib/nova:init_nova:684recreate_database nova_cell0
>> +lib/database:recreate_database:112local db=nova_cell0
>> +lib/database:recreate_database:113recreate_database_mysql
>> nova_cell0
>> +lib/databases/mysql:recreate_database_mysql:56  local db=nova_cell0
>> +lib/databases/mysql:recreate_database_mysql:57  mysql -uroot -pvmware
>> -h127.0.0.1 -e 'DROP DATABASE IF EXISTS nova_cell0;'
>> +lib/databases/mysql:recreate_database_mysql:58  mysql -uroot -pvmware
>> -h127.0.0.1 -e 

[openstack-dev] [watcher] Meeting on PTF week

[Чадин Александр]

Hello Watcher Team,

We will not have weekly meeting this Wednesday since most of topics will be 
discussed on PTG.

Best regards
_
Alexander Chadin
OpenStack Developer
Servionica LTD
a.cha...@servionica.ru
+7 (916) 693-58-81
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Telles Nobrega]

Hi Saharans,

Since most of the team is at the PTG we won't be having our IRC meeting
this week.

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

[openstack-dev] [Sahara][PTG] Meeting Room

[Telles Nobrega]

For all Sahara folks at the PTG, if you don't already know it, our sessions
will be held at the Room Georgia 6: Level1 on Wednesday and Georgia 9:
Level 1 on Thursday.

Thanks and hope to see you all soon.
__
OpenStack Development Mailing 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] [Fuel] Nominating Alexander Kislitsky for fuel-web-core

[Ilya Kutukov]

+1

Alexander is a great specialist

>Hey fellow fuelers,

>I'd like to nominate Alexander Kislitsky to the fuel-web-core team.>He's doing 
>thorough review [1], participate in feature developments>(e.g. Config-DB 
>enhancements, network-manager performance
improvements) and made an outstanding contribution bug-fixing.>>Core
reviewers, please reply back with +1/-1.>>Thanks,>Ihor>>[1]
http://stackalytics.com/?release=ocata=fuel-web


-- 
С уважением,
Кутуков Илья

+7 962 909 10 35
post.i...@gmail.com
skype: blinkedeye
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron]

[Roua Touihri]

Hello everybody,

How can we interconnect two VMs without using a bridge or a switch as an
intermediate. That is, only via a virtual link (e.g. veth or tap). In fact,
I see that when we create an aditional subnet and two ports of the given
subnet. Then when I attach each port to a running VM, neutron use a bridge
as an intermediate element. I want to create a mesh topology between
several VMs of the same tenant in addition to or without the default
network created by neutron.

If such a configuration were not possible, I must then create new APIs for
doing that. However, I do not know how to get started with this task. I
guess that I should create new classes similarly to the
"neutron.create_port" one and maybe to overload the veth/tap constructor.

Thanks in advance

-- 

​Kindly,


R.T
__
OpenStack Development Mailing 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][bugs] No Bugs Team meeting today (21.02)

[Szankin, Maciej]

The Bugs Team Meeting today is cancelled due to the PTG.
The next meeting will be Tuesday,  March 7, 2017 at 1800UTC  in 
#openstack-meeting-4.

---
Maciej Szankin
irc: macsz

__
OpenStack Development Mailing 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] [kuryr][dragonflow][octavia] layer 7 load balancing discussion

[Antoni Segura Puimedon]

Hi all!

An impromptu conversation started between Omer and I about l4 and l7 load
balancers for serving Kubernetes workloads (both services and ingress
controllers) and we thought it would be nice to have more feedback on the
discussion, particularly from Octavia folks.

Omer kindly offered to have the discussion at 11:00 tomorrow in the
Dragonflow room Savannah 2 (level 2)[0].

Some of the topics to cover will be:

- Generic API for load balancing based on headers versus protocol drivers
- Octavia kubernetes compute driver
- Dragonflow Octavia implementation

We'll keep working on the etherpad leading up to the meeting for topics and
structure of the discussion.

Regards,

Toni

[0] https://etherpad.openstack.org/p/dragonflow-l7lbaas
__
OpenStack Development Mailing 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] [tricircle][all] guide for reading source code

[Vega Cai]

Wow, awesome guide!!

My suggestion will be no matter where we maintain the guide, it will be
better to not just update the original guide directly, to make readers easy
to follow the changes of logic.

BR
Zhiyuan

On Tue, 21 Feb 2017 at 11:00 joehuang  wrote:

> Hello,
>
> For those who are interested in digging into Tricircle source code, it'll
> be good to have a step by step guide. I prepared a wiki page to navigate
> the source code of Tricircle:
>
> https://wiki.openstack.org/wiki/TricircleHowToReadCode
>
> It was linked to the wiki page of Tricircle:
> https://wiki.openstack.org/wiki/Tricircle
>
> And also please feel free to update the wiki to make it being more
> readable and consistent with the code.
>
> Should we include it into the source code repo, and maintain it at the
> same time if we update the code logic?
>
> Best Regards
> Chaoyi Huang (joehuang)
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
BR
Zhiyuan
__
OpenStack Development Mailing 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] PTG Team Photos!

[Kendall Nelson]

To be a little more specific about the location. It's just outside the
Grand ballroom A. Close to the top of the staircase.

- Kendall Nelson (diablo_rojo)

On Wed, Feb 15, 2017, 1:24 PM Kendall Nelson  wrote:

> Hello All!
>
> We are excited to see you next week at the PTG and wanted to share
> that we will be taking team photos! Provided is a google sheet signup for
> the available time slots [1]. We will be providing time on Tuesday Morning/
> Afternoon and Thursday Morning/Afternoon to come as a team to get your
> photo taken. Slots are only ten minutes so its *important that everyone
> be on time*! If you are unable to view/edit the spreadsheet let me know
> and I will try to get you access or can fill in a slot for you.
>
> The location we are taking the photos on the 3rd floor in the prefunction
> space in front of the Grand Ballroom (across the hall from Fandangles).
>
> See you next week!
>
> Thanks,
>
> -Kendall Nelson (diablo_rojo)
>
> [1]
> https://docs.google.com/spreadsheets/d/1bgwMDsUm37JgpksUJszoDWcoBMHciufXcGV3OYe5A-4/edit?usp=sharing
>
>
__
OpenStack Development Mailing 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][neutron]PTG session about implement Neutron Trunks resource in heat

[Rico Lin]

Dear Neutorn team

We have a session about implement Neutron Trunks resource in heat.
Would like some joint discussion from Neutron team member in this session.
We have to figure out why we should have this resource and how we going to
integrate it with other resources (like Nova instance resource).

The session is at 9:00-9:30 on Friday morning in Heat's PTG room.
Feel free to join

-- 
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] [keystone][heat][all]Cross-project: Trust and Federate session on Thrusday morning

[Rico Lin]

Dear all
Just reminding that we will have a cross-project session about Cross about
Trust and Federate session 9:00 am on Thursday morning in Savannah room.
Feel free to attend if that issue also affects your project.

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

Re: [openstack-dev] [heat][tripleo][mistral][all]PTG: Cross-Project: OpenStack Orchestration Integration

[Renat Akhmerov]

Ok, thanks.

Renat Akhmerov
@Nokia

> On 21 Feb 2017, at 09:17, Rico Lin  wrote:
> 
> Dear all
> Just reminding the Cross-Project session: OpenStack Orchestration Integration
> Will take place at 11:00 on Thursday in `Macon` room.
> 
> 2017-02-14 21:49 GMT+08:00 John Fulton  >:
> Thanks Rico and Renat. This applies to two specs [1][2] I'm involved in so 
> I'll be sure to be there. --John
> 
> [1] https://review.openstack.org/#/c/387631/ 
> 
> [2] https://review.openstack.org/#/c/423304/ 
> 
> 
> 
> - Original Message -
> From: "Renat Akhmerov"  >
> To: "OpenStack Development Mailing List (not for usage questions)" 
> >
> Sent: Tuesday, February 14, 2017 12:59:09 AM
> Subject: [openstack-dev] [heat][tripleo][mistral][all]PTG: Cross-Project: 
> OpenStack Orchestration Integration
> 
> Ok, thanks Rico. Keep us updated on the schedule changes. I’m currently 
> finalizing the schedule for Mistral, for now I’ll leave Thursday 11.00-12.00 
> blank.
> 
> Renat Akhmerov
> @Nokia
> 
> 
> 
> 
> On 14 Feb 2017, at 10:49, Rico Lin < rico.lin.gua...@gmail.com 
>  > wrote:
> 
> Let's move the schedule toThursday morning 11:00 am to 12:00 pm in the same 
> room. Hope that schedule work for all:)
> 
> Also, I will ask if Mon - Tue is available or not, but there might be more 
> cross-project sessions we have to not to conflict with them.
> 
> 2017-02-14 10:02 GMT+08:00 Renat Akhmerov < renat.akhme...@gmail.com 
>  > :
> 
> 
> 
> 
> 
> 
> On 13 Feb 2017, at 19:30, Emilien Macchi < emil...@redhat.com 
>  > wrote:
> 
> 
> 
> On Mon, Feb 13, 2017 at 4:48 AM, Rico Lin < rico.lin.gua...@gmail.com 
>  > wrote:
> 
> 
> 
> Dear all
> 
> PTG is approaching, we have few ideas around TripleO team ([1] and [2]) about 
> use case like using Mistral through Heat. It seems some great OpenStacker 
> already start thing about how the Orchestration services (Heat, Mistral, and 
> some other projects) could use together for a better developer or operator 
> experiences. First, of curse,
> we will arrange a fishbowl design session on Wednesday morning.
> Let's settle with 10:00 am to 10:50 am at Macon (on level2) for now.
> Could teams kindly help to make sure they can attend this cross project 
> session or need it reschedule?
> 
> Can we reschedule it? It seems like the only slot where we have sessions 
> organized is on Wednesday morning, for our container work:
> https://etherpad.openstack.org/p/tripleo-ptg-pike 
> 
> 
> Wednesday 9:00 Cross-Teams talk about containers and networking
> Wednesday 10:00: TripleO Containers status update and path forward
> 
> So I suggest Wednesday afternoon or Thursday or Friday morning. At your 
> convenience.
> 
> Thursday morning would work for me.
> 
> 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 
> 
> 
> 
> 
> 
> --
> May The Force of Open Stack 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 
> 
> 
> __
> OpenStack Development Mailing 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][magnum][murano][sahara][tripleo][mistral][all]PTG: Cross-Project:Orchestration feedback and announcement

[Rico Lin]

Dear all
Just reminding the Cross-Project session: Orchestration feedback and
announcement
Will take place at 11:00 on Wednesday in `Macon` room.

2017-02-14 11:35 GMT+08:00 Rico Lin :

>
>> Aren’t we supposed to have all cross-project sessions on Mon-Tue?
>>
>
> That is an interesting way to do it, althrough the cross project effort
> mentioned by PTG is refering to release goals, Architecture workgroup, any
> other workgroups. I will ask if those time is available for this kind of
> cross projects.
>
>
>> The time slot you mentioned is kind of ok, I can be there (although
>> earlier would be better) but starting Wed we all have time dedicated to
>> specific project discussions.
>>
>
> Thanks for the confirms
>
>
>> Renat Akhmerov
>> @Nokia
>>
>> On 13 Feb 2017, at 17:38, Rico Lin  wrote:
>>
>> Dear all
>>
>> We would like to have a Cross Project fishbowl session
>> about Orchestration feedback and announcement.
>> We would like to help on any improvement that will potentially help other
>> projects.
>> That's why we need your feedback.
>> Heat has landed some cool improvement like reduce 60% of memory usage in
>> the last cycle, stable convergence engine, etc. Therefore, we would like to
>> check with teams if those nice features can be integrated and enabled
>> within their project. If not, which goal we still required to make it
>> happen?
>>
>>
>> *Let's schedule this session in Macon(on level2) at 11:00 am - 12:00 pm
>> on Wednesday Morning for now.*
>> Could teams kindly help to make sure they can attend this cross project
>> session or need it reschedule?
>> Hopefully, all schedule for teams does not conflict with this schedule.
>> If the schedule is a perfect fit for all teams and you feel like this is
>> part of your concerns, then we hope to see you all there:)
>>
>> --
>> 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: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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>


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

Re: [openstack-dev] [heat][tripleo][mistral][all]PTG: Cross-Project: OpenStack Orchestration Integration

[Rico Lin]

Dear all
Just reminding the Cross-Project session: OpenStack Orchestration
Integration
Will take place at 11:00 on Thursday in `Macon` room.

2017-02-14 21:49 GMT+08:00 John Fulton :

> Thanks Rico and Renat. This applies to two specs [1][2] I'm involved in so
> I'll be sure to be there. --John
>
> [1] https://review.openstack.org/#/c/387631/
> [2] https://review.openstack.org/#/c/423304/
>
>
> - Original Message -
> From: "Renat Akhmerov" 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Sent: Tuesday, February 14, 2017 12:59:09 AM
> Subject: [openstack-dev] [heat][tripleo][mistral][all]PTG: Cross-Project:
> OpenStack Orchestration Integration
>
> Ok, thanks Rico. Keep us updated on the schedule changes. I’m currently
> finalizing the schedule for Mistral, for now I’ll leave Thursday
> 11.00-12.00 blank.
>
> Renat Akhmerov
> @Nokia
>
>
>
>
> On 14 Feb 2017, at 10:49, Rico Lin < rico.lin.gua...@gmail.com > wrote:
>
> Let's move the schedule toThursday morning 11:00 am to 12:00 pm in the
> same room. Hope that schedule work for all:)
>
> Also, I will ask if Mon - Tue is available or not, but there might be more
> cross-project sessions we have to not to conflict with them.
>
> 2017-02-14 10:02 GMT+08:00 Renat Akhmerov < renat.akhme...@gmail.com > :
>
>
>
>
>
>
> On 13 Feb 2017, at 19:30, Emilien Macchi < emil...@redhat.com > wrote:
>
>
>
> On Mon, Feb 13, 2017 at 4:48 AM, Rico Lin < rico.lin.gua...@gmail.com >
> wrote:
>
>
>
> Dear all
>
> PTG is approaching, we have few ideas around TripleO team ([1] and [2])
> about use case like using Mistral through Heat. It seems some great
> OpenStacker already start thing about how the Orchestration services (Heat,
> Mistral, and some other projects) could use together for a better developer
> or operator experiences. First, of curse,
> we will arrange a fishbowl design session on Wednesday morning.
> Let's settle with 10:00 am to 10:50 am at Macon (on level2) for now.
> Could teams kindly help to make sure they can attend this cross project
> session or need it reschedule?
>
> Can we reschedule it? It seems like the only slot where we have sessions
> organized is on Wednesday morning, for our container work:
> https://etherpad.openstack.org/p/tripleo-ptg-pike
>
> Wednesday 9:00 Cross-Teams talk about containers and networking
> Wednesday 10:00: TripleO Containers status update and path forward
>
> So I suggest Wednesday afternoon or Thursday or Friday morning. At your
> convenience.
>
> Thursday morning would work for me.
>
> 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
>
>
>
>
> --
> May The Force of Open Stack 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
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
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] [all][meteos]Announcement of Meteos virtual PTG

[Hiroyuki Eguchi]

Hi All and Meteos Team,

We would like to hold a virtual PTG of Meteos Project like weekly irc-meeting.
Please see below for the details.
Meteos is a new project which provides Machine Learning as a service launched 
at 10/2016.

We have a favor for you all.

If you are interested in Machine Learning,
Would you please answer the questionnaire in here ?
https://etherpad.openstack.org/p/meteos-ptg-questionnaire

Meteos is very young project, so we very welcome for your comments.

We are going to discuss about future prospective and development plan for next 
Pike release.
Your comments are very helpful to us to understand the current situation of 
Machine Learning as a Service.

[Scheduled date and time]
Friday,   Feb 24 at 05:00 - 07:00 UTC
Thursday, Feb 23 at 21:00 - 23:00 PST
Friday,   Feb 24 at 10:30 - 12:30 IST
Friday,   Feb 24 at 14:00 - 16:00 JST

Sorry for inconvenience time schedule.

[Place]
#openstack-meteos (IRC webclient)
http://webchat.freenode.net/?channels=openstack-meteos
(we have not had irc-meetings channel yet. now preparing.)

[Agenda](TBD)
https://etherpad.openstack.org/p/meteos-ptg

Thank you.

--
Hiroyuki Eguchi
__
OpenStack Development Mailing 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] Upstream Training Team meeting at PTG - Are you coming?

[Ildiko Vancsa]

Hi All,

A quick reminder that we will have our face to face gathering on __Wednesday 
(tomorrow) at lunch time (12pm ET)__.

I booked Savannah 3 on the second floor (Lobby level). Please grab a lunch box 
after the morning sessions and join us for lunch if you would like to get 
involved with the Upstream Training and/or new contributor on boarding 
activities.

Thanks and Best Regards,
Ildikó
IRC: ildikov


> On 2017. Feb 15., at 13:16, Ildiko Vancsa  wrote:
> 
> Hi,
> 
> We are forming a virtual upstream collaboration training team including 
> everyone who’s either helping us out with maintaining and improving the 
> training material and/or who are attending the course as coaches or mentors.
> 
> We are planning to meet at the PTG in person next week on Wednesday at lunch 
> time. We picked this slot as our first face to face gathering as all of us 
> have project related assignments to drive and sessions to attend that makes 
> scheduling a meeting even more challenging.
> 
> If you are interested in what we are doing and how we are trying to make the 
> on boarding process for new contributors a pleasant experience and would like 
> to join our activities meet us there!
> 
> The meeting time is __Wednesday (February 22) lunch time__. I will share the 
> meeting point next week before the meeting.
> 
> If you would like to have a mail reminder prior to the meeting next week 
> please reach out to me.
> 
> Thanks and Best Regards,
> Ildikó
> IRC: ildikov


__
OpenStack Development Mailing 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]PKI token VS Fernet token

[Dolph Mathews]

It appears that you don't have caching enabled, then. Without enabling
caching, Fernet performance is well known to be terrible, which would
explain your benchmark results. If you run a similar benchmark with
caching, I'd be eager to see the new configuration and benchmark results.

On Fri, Feb 17, 2017 at 8:16 AM 王玺源  wrote:

> Hi Dolph:
>
> We made the keystone.conf same with the example.
>
> [token]
>
> provider = fernet
>
>
>
> [fernet_tokens]   //all configuration is default
>
> #
>
> # From keystone
>
> #
>
>
>
> # Directory containing Fernet token keys. (string value)
>
> #key_repository = /etc/keystone/fernet-keys/
>
>
>
> # This controls how many keys are held in rotation by keystone-manage
>
> # fernet_rotate before they are discarded. The default value of 3 means
> that
>
> # keystone will maintain one staged key, one primary key, and one secondary
>
> # key. Increasing this value means that additional secondary keys will be
> kept
>
> # in the rotation. (integer value)
>
> # max_active_keys = 3
> Dolph Mathews 于2017年2月17日 周五上午7:22写道：
>
> Thank you for the data and your test scripts! As Lance and Stanek already
> alluded, Fernet performance is very sensitive to keystone's configuration.
> Can your share your keystone.conf as well?
>
> I'll also be in Atlanta and would love to talk Fernet performance, even if
> we don't have a formal time slot on the schedule.
>
> On Wed, Feb 15, 2017 at 9:08 AM Lance Bragstad 
> wrote:
>
> In addition to what David said, have you played around with caching in
> keystone [0]? After the initial implementation of fernet landed, we
> attempted to make it the default token provider. We ended up reverting the
> default back to uuid because we hit several issues. Around the Liberty and
> Mitaka timeframe, we reworked the caching implementation to fix those
> issues and improve overall performance of all token formats, especially
> fernet.
>
> We have a few different performance perspectives available, too. Some were
> run nearly 2 years ago [1] and some are run today [2]. Since the Newton
> release, we've made drastic improvements to the overall structure of the
> token provider [3] [4] [5]. At the very least, it should make understanding
> keystone's approach to tokens easier. Maintaining out-of-tree token
> providers should also be easier since we cleaned up a lot of the interfaces
> that affect developers maintaining their own providers.
>
> We can try and set something up at the PTG. We are getting pretty tight
> for time slots, but I'm sure we can find some time to work through the
> issues you're seeing (also, feel free to hop into #openstack-keystone on
> freenode if you want to visit prior to the PTG).
>
>
> [0]
> https://docs.openstack.org/developer/keystone/configuration.html#caching-layer
> [1] http://dolphm.com/benchmarking-openstack-keystone-token-formats/
> [2] https://github.com/lbragstad/keystone-performance
> [3]
> https://review.openstack.org/#/q/status:merged+project:openstack/keystone+branch:master+topic:make-fernet-default
> [4]
> https://review.openstack.org/#/q/status:merged+project:openstack/keystone+branch:master+topic:cleanup-token-provider
> [5]
> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ocata/token-provider-cleanup.html
>
> On Wed, Feb 15, 2017 at 8:44 AM, David Stanek  wrote:
>
> On 15-Feb 18:16, 王玺源 wrote:
> > Hello everyone,
> >   PKI/PKIZ token has been removed from keystone in Ocata. But recently
> our
> > production team did some test about PKI and Fernet token (With Keystone
> > Mitaka). They found that in large-scale production environment, Fernet
> > token's performance is not as good as PKI. Here is the test data:
> >
> >
> https://docs.google.com/document/d/12cL9bq9EARjZw9IS3YxVmYsGfdauM25NzZcdzPE0fvY/edit?usp=sharing
>
> This is nice to see. Thanks.
>
>
> >
> > From the data, we can see that:
> > 1. In large-scale concurrency test, PKI is much faster than Fernet.
> > 2. PKI token revoke can't immediately make the token invalid. So it has
> the
> > revoke issue.  https://wiki.openstack.org/wiki/OSSN/OSSN-0062
> >
> > But in our production team's opinion, the revoke issue is a small
> problem,
> > and can be avoided by some periphery ways. (More detail solution could be
> > explained by them in the follow email).
> > They think that the performance issue is the most important thing. Maybe
> > you can see that in some production environment, performance is the first
> > thing to be considered.
>
> I'd like to hear solutions to this if you have already come up with
> them. This issue, however, isn't the only one that led us to remove PKI
> tokens.
>
> >
> > So here I'd like to ask you, especially the keystone experts:
> > 1. Is there any chance to bring PKI/PKIZ back to Keystone?
>
> I would guess that, at least in the immediate future, we would not want
> to put it back into keystone until someone can fix the 

[openstack-dev] [Murano] Is 'murano-agent' support optional in an OpenStack Murano Deployment ?

[Waines, Greg]

A couple of questions about Murano-agent functionality in an OpenStack Murano 
Deployment:

1. Is the Murano-agent functionality truly optional ?

 I believe answer is yes … although wanted to confirm that the optionality 
wasn’t referring to whether Murano-agent was implemented with same or separate 
rabbit server.


2. Assuming Murano-agent functionality is optional,

 I am surprised that items in the Murano Community Catalog 
(https://apps.openstack.org/#tab=murano-apps )
 don’t explicitly indicate whether they require Murano-agent functionality 
or not.

 a) Is there a way to determine whether a Murano Application requires 
Murano-agent functionality or not ?

 b) Roughly what % of Murano Applications leverage the Murano-agent 
functionality ?



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

Re: [openstack-dev] [Zun]Use 'uuid' instead of 'id' as object ident in data model

[gordon chung]

On 21/02/17 01:28 AM, Qiming Teng wrote:
>> in mysql[2].
> Can someone remind me the benefits we get from Integer over UUID as
> primary key? UUID, as its name implies, is meant to be an identifier for
> a resource. Why are we generating integer key values?

this ^. use UUID please. you can google why auto increment is a probably 
not a good idea.

from a selfish pov, as gnocchi captures data on all resources in 
openstack, we store everything as a uuid anyways. even if your id 
doesn't clash in zun, it has a higher chance of clashing when you 
consider all the other resources from other services.

cheers,
-- 
gord

__
OpenStack Development Mailing 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] [Telemetry] Feedback from the User Survey

[gordon chung]

On 21/02/17 03:55 AM, Julien Danjou wrote:
> - Legacy MongoDB: 56 (60.2% of users, 40.5% of choices)
> - Gnocchi: 44 (47.3% of users, 31.8 % of choices)
> - HTTP: 8 (8.6% of users, 5.8% of choices)
> - Legacy MySQL: 8 (8.6% of users, 5.8% of choices)
> - Other: 8 (8.6% of users, 5.8% of choices)
> - File dispatcher: 7 (7.5% of users, 5% of choices)
> - Kafka: 4 (4.3% of users, 2.9% of choices)
> - Legacy PostgreSQL: 3 (3.2% of users, 2.1% of choices)

i'm shocked and happy about Gnocchi... and then even more shocked about 
file because i was under impression that was broken.lol

thanks for the details! i completely forgot we even asked this question.

-- 
gord

__
OpenStack Development Mailing 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] [architecture][nova][neutron][cinder][ceilometer][ironic] PTG stuff -- Arch-WG nova-compute-api fact-gathering session Tuesday 10:30 Macon

[gordon chung]

On 17/02/17 01:16 PM, Clint Byrum wrote:
> From that, as a group we'll produce a detailed analysis of all the ways
> nova-compute is interacted with today, and ongoing efforts to change
> them. If you are interested in this please do raise your hand and come
> to our meetings[2] as my time to work on this is limited, and the idea
> for the Arch-WG isn't "Arch-WG solves OpenStack" but "Arch-WG provides
> a structure by which teams can raise understanding of architecture."

the telemetry team isn't at the PTG so i'll add some notes. you can also 
reach us/me on irc. i guess cdent can also chime in if he's there based 
on how much/little he remembers from his ceilometer days

cheers,

-- 
gord

__
OpenStack Development Mailing 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] [governance] Where is project:type documented?

[Jeremy Stanley]

On 2017-02-20 21:12:58 -0600 (-0600), Ian Cordasco wrote:
> In openstack/releases in the deliverables directory
[...]

Which was recently moved from the governance repo, so maybe the
referring documents could use more clarity now. I can see how that
may have been overlooked in some places.
-- 
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

Re: [openstack-dev] [keystone]PKI token VS Fernet token

[王玺源]

Ok, the advice of central database seems feasible, and we have an discuss
about it, but the delay between different region are pullback for this
advise, because it is far away between the two region. The slow sync decide
only the relatively static business can happen between the different
regions.

Lance Bragstad 于2017年2月17日 周五下午1:10写道：

> On Fri, Feb 17, 2017 at 11:22 AM, Clint Byrum  wrote:
>
> Excerpts from 王玺源's message of 2017-02-17 14:08:30 +:
> > Hi David:
> >
> > We have not find the perfect solution to solve the fernet performance
> > issue, we will try the different crypt strength setting with fernet in
> > future.
> >
>
> One important thing: did you try throwing more hardware at Keystone?
> Keystone instances are almost entirely immutable (the fernet keys
> are the only mutable part), which makes it pretty easy to scale them
> horizontally as-needed. Your test has a static 3 nodes, but you didn't
> include system status, so we don't know if the CPUs were overwhelmed,
> or how many database nodes you had, what its level of activity was, etc.
>
>
> +1
>
> Several folks in the community have tested token performance using a
> variety of hardware and configurations. Sharing your specific setup might
> draw similarities to other environments people have used. If not, then we
> at least have an environment description that we can use to experience the
> issues you're seeing first-hand.
>
>
>
> >
> >
> > There are multiple customers have more than 6-region cascade, how to
> > synchronous keystone data between these region disturbed us a lot. It
> does
> > not need to synchronize these data while using pki token, because the pki
> > token including the roles information.
> >
>
> The amount of mutable data to synchronize between datacenters with Fernet
> is the fernet keys. If you set up region-local caches, you should be
> able to ship queries back to a central database cluster and not have to
> worry about a painful global database cluster, since you'll only feel
> the latency of those cross-region queries when your caches are cold.
>
> However, I believe work was done to allow local read queries to be sent
> to local slaves, so you can use traditional MySQL replication if the
> cold-cache latency is too painful.
>
> Replication lag becomes a problem if you get a ton of revocation events,
> but this lag's consequences are pretty low, with the worst effect being a
> larger window for stolen, revoked tokens to be used. Caching also keeps
> that window open longer, so it becomes a game of tuning that window
> against desired API latency.
>
>
> Good point, Clint. We also merged a patch in Ocata that helped improve
> token validation performance, which was not proposed as a stable backport:
>
>
> https://github.com/openstack/keystone/commit/9e84371461831880ce5736e9888c7d9648e3a77b
>
>
> >
> >
> > The pki token has been verified that can support such large-scale
> > production environment, which even the uuid token has performance issue
> in
> > too.
> >
>
> As others have said, the other problems stacked on top of the critical
> security problems in PKI made it very undesirable for the community to
> support. There is, however, nothing preventing you from maintaining it
> out of tree, though I'd hope you would instead collaborate with the
> community to perhaps address those problems and come up with a "PKIv2"
> provider that has the qualities you want for your scale.
>
>
> +1
>
> Having personally maintained a token provider out-of-tree prior to the
> refactoring done last release [0], I think the improvements made are
> extremely beneficial for cases like this. But, again re-iterating what
> Clint said, I would only suggest that if for some reason we couldn't find a
> way to get a supported token provider to suit your needs.
>
> We typically have a session dedicated to performance at the PTG, and I
> have that tentatively scheduled for Friday morning (11:30 - 12:00) [1].
> Otherwise it's usually a topic that comes up during our operator feedback
> session, which is scheduled for Wednesday afternoon (1:30 - 2:20). Both are
> going to be in the dedicated keystone room (which I'll be advertising when
> I know exactly which room that is).
>
>
> [0]
> https://review.openstack.org/#/q/status:merged+project:openstack/keystone+branch:master+topic:cleanup-token-provider
> [1] https://etherpad.openstack.org/p/keystone-pike-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 Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

Re: [openstack-dev] [Fuel] Nominating Alexander Kislitsky for fuel-web-core

[Julia Aranovich]

+1

On Tue, Feb 21, 2017 at 4:32 PM Aleksey Kasatkin 
wrote:

> +1
>
>
> Aleksey Kasatkin
>
>
> On Tue, Feb 21, 2017 at 2:25 PM, Ihor Kalnytskyi 
> wrote:
>
> Hey fellow fuelers,
>
> I'd like to nominate Alexander Kislitsky to the fuel-web-core team.
> He's doing thorough review [1], participate in feature developments
> (e.g. Config-DB enhancements, network-manager performance
> improvements) and made an outstanding contribution bug-fixing.
>
> Core reviewers, please reply back with +1/-1.
>
> Thanks,
> Ihor
>
> [1] http://stackalytics.com/?release=ocata=fuel-web
>
> __
> OpenStack Development Mailing 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] [Fuel] Nominating Alexander Kislitsky for fuel-web-core

[Aleksey Kasatkin]

+1


Aleksey Kasatkin


On Tue, Feb 21, 2017 at 2:25 PM, Ihor Kalnytskyi 
wrote:

> Hey fellow fuelers,
>
> I'd like to nominate Alexander Kislitsky to the fuel-web-core team.
> He's doing thorough review [1], participate in feature developments
> (e.g. Config-DB enhancements, network-manager performance
> improvements) and made an outstanding contribution bug-fixing.
>
> Core reviewers, please reply back with +1/-1.
>
> Thanks,
> Ihor
>
> [1] http://stackalytics.com/?release=ocata=fuel-web
>
> __
> OpenStack Development Mailing 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] [Fuel] Nominating Alexander Kislitsky for fuel-web-core

[Ihor Kalnytskyi]

Hey fellow fuelers,

I'd like to nominate Alexander Kislitsky to the fuel-web-core team.
He's doing thorough review [1], participate in feature developments
(e.g. Config-DB enhancements, network-manager performance
improvements) and made an outstanding contribution bug-fixing.

Core reviewers, please reply back with +1/-1.

Thanks,
Ihor

[1] http://stackalytics.com/?release=ocata=fuel-web

__
OpenStack Development Mailing 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] CI Squad Meeting Summary (week 7)

[Attila Darazs]

On 02/17/2017 07:18 PM, Paul Belanger wrote:

On Fri, Feb 17, 2017 at 03:39:44PM +0100, Attila Darazs wrote:

As always, if these topics interest you and you want to contribute to the
discussion, feel free to join the next meeting:

Time: Thursdays, 15:30-16:30 UTC
Place: https://bluejeans.com/4113567798/

Full minutes: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting


Was this meeting recorded in some manner? I see you are using bluejeans, but
don't see any recordings of the discussion.

Additionally, I am a little sad IRC is not being used for these meetings. Some
of the things tripleo is doing is of interest of me, but I find it difficult to
join a video session for 1hour just to listen.  With IRC, it is easier for me to
multi task into other things, then come back and review what has been discussed.


We are not recording it for now, sorry. We are tying to keep good 
minutes & this summary to bridge the gap for the lack of recording or 
IRC meeting.


We voted about it a few weeks ago and video meeting won. We did agree 
about revisiting the IRC option after the transition is done as the bulk 
of the meetings are mostly chats about possible technical solutions for 
the quickstart transition rather than classic meeting where we decide 
stuff. We're bringing those to the weekly TripleO IRC meetings.



* We discussed about the state of the Quickstart based update/upgrade jobs
upstream. matbu is working on them and the changes for the jobs are under
review. Sagi will help with adding project definitions upstream when the
changes are merged.

* John started to draft out the details of the CI related PTG sessions[1].

* A couple of us brought up reviews that they wanted merged. We discussed
the reasons, and agreed that sometimes an encouraging email to the mailing
list has the best effect to move important or slow-to-merge changes moving
forward.

* We talked quite a lot about log collection upstream. Currently Quickstart
doesn't collect logs exactly as upstream, and that might be okay, as we
collect more, and hopefully in a more easy to digest format.

* However we might collect too much, and finding the way around the logs is
not that easy. So John suggested to create an entry page in html for the
jobs that point to different possible places to find debug output.


Yes, logging was something of an issue this week.  We are still purging data on
logs.o.o, but it does look like quickstart is too aggressive with log
collection. We currently only have 12TB of HDD space for logs.o.o and our
retention policy has dropped from 6 months to 6 weeks.

I believe we are going have a discussion at the PTG about this for
openstack-infra and implement some changes (caps) for jobs in the coming future.
If you are planning on attending the PTG, I encourage you to attend the
discussions.


I won't be on the PTG this time, but maybe Emilien or John can join.

With regards to space, we're going to comb through the logging and make 
sure we're a bit more selective about what we gather.


Attila


* We also discussed adding back debug output to elastic search, as the
current console output doesn't contain everything, we log a lot of
deployment output in seperate log files in undercloud/home/stack/*.log

* Migration to the new Quickstart jobs will happen at or close to 10th of
March, in the beginning of the Pike cycle when the gates are still stable.

That was all for this week.

Best regards,
Attila

[1] https://etherpad.openstack.org/p/tripleo-ci-roadmap

__
OpenStack Development Mailing 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] The end of OpenStack packages in Debian?

[Clint Byrum]

Excerpts from Thomas Goirand's message of 2017-02-21 00:50:35 +0100:
> On 02/19/2017 08:43 PM, Clint Byrum wrote:
> > Excerpts from Thomas Goirand's message of 2017-02-19 00:58:01 +0100:
> >> On 02/18/2017 07:59 AM, Clint Byrum wrote:
> >>> Indeed, DPMT uses all the worst choices for maintaining most of the
> >>> python module packages in Debian. However, something will need to be
> >>> done to spread the load of maintaining the essential libraries, and the
> >>> usual answer to that for Python libraries is DPMT.
> >>
> >> I wish the Python team was more like the Perl one, who really is a well
> >> functioning with a strong team spirit and commitment, with a sense of
> >> collective responsibility. It's far from being the case in the DPMT.
> >>
> >> Moving packages to the DPMT will not magically get you new maintainers.
> >> Even within the team, there's unfortunately *a lot* of strong package
> >> ownership.
> >>
> > 
> > Whatever the issues are with that team, there's a _mountain_ of packages
> > to maintain, and only one team whose charter is to maintain python
> > modules. So we're going to have to deal with the shortcomings of that
> > relationship, or find more OpenStack specific maintainers.
> 
> I think there's a misunderstanding here. What I wrote is that the DPMT
> will *not* maintain packages just because they are pushed to the team,
> you will need to find maintainers for them. So that's the last option of
> your last sentence above that would work. The only issue is, nobody
> cared so far...
> 

I believe your experience is not typical, and the DPMT will in fact
assist with some of the more boring aspects of maintaining those
packages. Are they going to chase new upstream versions? No. But they'll
help with transitions, policy updates, RC bugs, etc.

> > It's also important that the generic libraries
> > we maintain, like stevedore, remain up to date in Debian so they don't
> > fall out of favor with users. Nothing kills a library like old versions
> > breaking apps.
> 
> Stevedore is a very good example. It build-depends on oslotest (to run
> unit tests), which itself needs os-client-config, oslo.config, which
> itself ... no need to continue, once you need oslo.config, you need
> everything else. So to continue to package something like Stevedore, we
> need nearly the full stack. That's equivalent to maintaining all of
> OpenStack (as I wrote: the cherry on top of the cake is the services,
> the bulk work is the Python modules).
> 

We may have to agree to disagree on that. The libraries and clients
should be an order of magnitude simpler than the services to maintain.

__
OpenStack Development Mailing 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] RFC for Intel RDT/CAT Support in Nova for Virtual Machine QoS

[Qiao, Liyong]

Hi folks:

Seeking community input on an initial design for Intel Resource Director 
Technology (RDT), in particular for Cache Allocation Technology in OpenStack 
Nova to protect workloads from co-resident noisy neighbors, to ensure quality 
of service (QoS).

1. What is Cache Allocation Technology (CAT)?
Intel’s RDT(Resource Director Technology) [1]  is a umbrella of hardware 
support to facilitate the monitoring and reservation of shared resources such 
as cache, memory and network bandwidth towards obtaining Quality of Service. 
RDT will enable fine grain control of resources which in particular is valuable 
in cloud environments to meet Service Level Agreements while increasing 
resource utilization through sharing. CAT is a part of RDT and concerns itself 
with reserving for a process(es) a portion of last level cache with further 
fine grain control as to how much for code versus data. The below figure shows 
a single processor composed of 4 cores and the cache hierarchy. The L1 cache is 
split into Instruction and Data, the L2 cache is next in speed to L1. The L1 
and L2 caches are per core. The Last Level Cache (LLC) is shared among all 
cores. With CAT on the currently available hardware the LLC can be partitioned 
on a per process (virtual machine, container, or normal application) or process 
group basis.


Libvirt and OpenStack [2] already support monitoring cache (CMT) and memory 
bandwidth usage local to a processor socket (MBM_local) and total memory 
bandwidth usage across all processor sockets (MBM_total) for a process or 
process group.


2. How CAT works
To learn more about CAT please refer to the Intel Processor Soft Developer's 
Manual
  volume 3b, chapters 17.16 and 17.17 [3]. Linux kernel support for the same is 
expected in release 4.10 and documented at [4]


3. Libvirt Interface

Libvirt support for CAT is underway with the patch at reversion 7

Interface changes of libvirt:

3.1 The capabilities xml has been extended to reveal cache information


 
   
 
 
   
 


The new `cache` xml element shows that the host has two banks of type L3 or 
Last Level Cache (LLC), one per processor socket. The cache type is l3 cache, 
its size 56320 KiB, and the cpus attribute indicates the physical CPUs 
associated with the same, here ‘0-21’, ‘44-65’ respectively.

The control tag shows that bank belongs to scope L3, with a minimum possible 
allocation of 2816 KiB and still has 2816 KiB need to be reserved.

If the host enabled CDP (Code and Data Prioritization) , l3 cache will be 
divided as code  (L3CODE)and data (L3Data).

Control tag will be extended to:
...
 
 
…

The scope of L3CODE and L3DATA show that we can allocate cache for code/data 
usage respectively, they share same amount of l3 cache.

3.2 Domain xml extended to include new CacheTune element


   
   
   
   
   
...


This means the guest will be have vcpus 0, 1 running on host’s socket 0, with 
2816 KiB cache exclusively allocated to it and vcpus 2, 3 running on host’s 
socket 0, with 2816 KiB cache exclusively allocated to it.

Here we need to make sure vcpus 0, 1 are pinned to the pcpus of socket 0, refer 
capabilities
 :

Here we need to make sure vcpus 2, 3 are pinned to the pcpus of socket 1, refer 
capabilities
 :.

3.3 Libvirt work flow for CAT


  1.  Create qemu process and get it’s PIDs
  2.  Define a new resource control domain also known as Class-of-Service 
(CLOS) under /sys/fs/resctrl and set the desired Cache Bit Mask(CBM) in the 
libvirt domain xml file in addition to updating the default schemata of the host

4. Proposed Nova Changes


  1.  Get host capabilities from libvirt and extend compute node’ filed
  2.  Add new scheduler filter and weight to help schedule host for requested 
guest.
  3.  Extend flavor’s (and image meta) extra spec fields:

We need to specify  numa setting for NUMA hosts if we want to enable CAT, see 
[5] to learn more about NUMA.
In flavor, we can have:

vcpus=8
mem=4
hw:numa_nodes=2 - numa of NUMA nodes to expose to the guest.
hw:numa_cpus.0=0,1,2,3,4,5
hw:numa_cpus.1=6,7
hw:numa_mem.0=3072
hw:numa_mem.1=1024
//  new added in the proposal
hw:cache_banks=2   //cache banks to be allocated to a  guest, (can be less than 
the number of NUMA nodes)
hw:cache_type.0=l3  //cache bank type, could be l3, l3data + l3code
hw:cache_type.1=l3_c+d  //cache bank type, could be l3, l3data + l3code
hw:cache_vcpus.0=0,1  //vcpu list on cache banks, can be none
hw:cache_vcpus.1=6,7
hw:cache_l3.0=2816  //cache size in KiB.
hw:cache_l3_code.1=2816
hw:cache_l3_data.1=2816

Here, user can clear about which vcpus will benefit cache allocation, about 
cache bank, it’s should be co-work with numa cell, it will allocate cache on a 
physical CPU socket, but here cache bank is a logic concept. Cache bank will 
allocate cache for a vcpu list, all vcpu list should group

Re: [openstack-dev] [watcher] Nominating Hidekazu Nakamura as Watcher Core

[David TARDIVEL]

+1

Envoy? de mon iPhone

Le 21 f?vr. 2017 ? 09:17, ? ? 
> a ?crit :

+1

Best Regards,
_
Alexander Chadin
OpenStack Developer
Servionica LTD
a.cha...@servionica.ru
+7 (916) 693-58-81

On 20 Feb 2017, at 11:25, Vincent FRAN?OISE 
> wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Team,

Hidekazu Nakamura has made many contributions[1] to Watcher since the
Barcelona summit when we first met. I would like to nominate him to be
part of the Watcher Core Team. I really think he will provide many
valuable contributions to the project and his inputs (such as [2])
will most certainly help us substantially improve Watcher as a whole.

It's now time to vote :)

[1] http://stackalytics.com/report/contribution/watcher/120
[2] https://wiki.openstack.org/wiki/Zone_migration
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJYqqgNAAoJEEb+XENQ/jVSf+kH/1+BLL907SrocIM87AlOdMAn
IuB0Xk+y7fAijrs4X7FqknEb2f8Ns4EN3f97SQGFF6WUqSxTMoyMkCZNBEaTWi0P
0D+g2KLTgOhOG8UGdV26CQD0qj455Q+GsQztatcip3zBRalO3QYcF8WUNkCs3GY3
yMDoCnK9L3JE+aihGf93UklAeYij856LlY4zj1Nxnm5MCdUNLnYpz+VpyjOtpE2w
QX3AH0jPs6b2coYC7O0CggpbMF0xFJzpaLiiRaabSzvuLT8vh1ICaCyUpH9IgXIv
M8i1b7aIvLRyxo1ZylFdBNu3J74Ayv5BZKudEtA5yqGn0bExL+yPiSJgv20WcrY=
=4frW
-END 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

__
OpenStack Development Mailing 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] [Telemetry] Feedback from the User Survey

[Julien Danjou]

Hi,

If you recall, we asked a custom question during the user survey, and
the preliminary results are there, thanks to Heidi.

I've compiled them and here's what it boils down to on 93 answers made
of 138 choices:

- Legacy MongoDB: 56 (60.2% of users, 40.5% of choices)
- Gnocchi: 44 (47.3% of users, 31.8 % of choices)
- HTTP: 8 (8.6% of users, 5.8% of choices)
- Legacy MySQL: 8 (8.6% of users, 5.8% of choices)
- Other: 8 (8.6% of users, 5.8% of choices)
- File dispatcher: 7 (7.5% of users, 5% of choices)
- Kafka: 4 (4.3% of users, 2.9% of choices)
- Legacy PostgreSQL: 3 (3.2% of users, 2.1% of choices)


Note that:
- some of the "Others" are actually "Kafka"
- the percentage overs users not sum to 100% since some people checked
  several choices, I also included the percent over the number of
  choices which sums up to 100%

It _seems_ to me that everyone is starting to move away from MongoDB to
Gnocchi slowly but surely. Hurrah?

Raw data


Which dispatcher are you using or planning to use with Ceilometer?

File dispatcher
File dispatcher
Gnocchi
Gnocchi
Gnocchi
Gnocchi
Gnocchi
Gnocchi
Gnocchi
Gnocchi
Gnocchi
Gnocchi
Gnocchi
Gnocchi
Gnocchi
Gnocchi
Gnocchi
Gnocchi
Gnocchi
Gnocchi
Gnocchi
Gnocchi
Gnocchi
Gnocchi|Legacy Ceilometer database with MongoDB
Gnocchi|Legacy Ceilometer database with MongoDB
Gnocchi|Legacy Ceilometer database with MongoDB
Gnocchi|Legacy Ceilometer database with MongoDB
Gnocchi|Legacy Ceilometer database with MongoDB
Gnocchi|Legacy Ceilometer database with MongoDB
Gnocchi|Legacy Ceilometer database with MongoDB
Gnocchi|Legacy Ceilometer database with MongoDB
Gnocchi|Legacy Ceilometer database with MongoDB
Gnocchi|Legacy Ceilometer database with MongoDB
Gnocchi|Legacy Ceilometer database with MongoDB
Gnocchi|Legacy Ceilometer database with MongoDB
Gnocchi|Legacy Ceilometer database with MongoDB
Gnocchi|Legacy Ceilometer database with MongoDB
Gnocchi|Legacy Ceilometer database with MongoDB
Gnocchi|Legacy Ceilometer database with MongoDB
Gnocchi|Legacy Ceilometer database with MongoDB
Gnocchi|Legacy Ceilometer database with MongoDB
Gnocchi|Legacy Ceilometer database with MongoDB|Legacy Ceilometer database with 
MySQL|HTTP dispatcher
Gnocchi|Legacy Ceilometer database with MongoDB|Other
Gnocchi|Legacy Ceilometer database with PostgreSQL|HTTP dispatcher
Gnocchi|Other
HTTP dispatcher
HTTP dispatcher
HTTP dispatcher|File dispatcher
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB
Legacy Ceilometer database with MongoDB|HTTP dispatcher|File dispatcher
Legacy Ceilometer database with MongoDB|Legacy Ceilometer database with MySQL
Legacy Ceilometer database with MongoDB|Legacy Ceilometer database with MySQL
Legacy Ceilometer database with MongoDB|Legacy Ceilometer database with 
MySQL|HTTP dispatcher|File dispatcher
Legacy Ceilometer database with MongoDB|Other
Legacy Ceilometer database with MongoDB|Other
Legacy Ceilometer database with MySQL
Legacy Ceilometer database with MySQL
Legacy Ceilometer database with MySQL|File dispatcher
Legacy Ceilometer database with MySQL|Other
Legacy Ceilometer database with PostgreSQL
Legacy Ceilometer database with PostgreSQL|HTTP dispatcher|File dispatcher
Other
Other
Other

Other: 
Custom built.
Kafka
Kafka
Kafka
not yet specified
We only run the notification agent to republish notifications from RMQ to Kafka
would like to use gnocchi but it isn't stable in this version. looking forward 
to it being fixed in the next version.

-- 
Julien Danjou
// Free Software hacker
// https://julien.danjou.info


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] [watcher] Nominating Hidekazu Nakamura as Watcher Core

[Чадин Александр]

+1

Best Regards,
_
Alexander Chadin
OpenStack Developer
Servionica LTD
a.cha...@servionica.ru
+7 (916) 693-58-81

On 20 Feb 2017, at 11:25, Vincent FRANÇOISE 
> wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Team,

Hidekazu Nakamura has made many contributions[1] to Watcher since the
Barcelona summit when we first met. I would like to nominate him to be
part of the Watcher Core Team. I really think he will provide many
valuable contributions to the project and his inputs (such as [2])
will most certainly help us substantially improve Watcher as a whole.

It's now time to vote :)

[1] http://stackalytics.com/report/contribution/watcher/120
[2] https://wiki.openstack.org/wiki/Zone_migration
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJYqqgNAAoJEEb+XENQ/jVSf+kH/1+BLL907SrocIM87AlOdMAn
IuB0Xk+y7fAijrs4X7FqknEb2f8Ns4EN3f97SQGFF6WUqSxTMoyMkCZNBEaTWi0P
0D+g2KLTgOhOG8UGdV26CQD0qj455Q+GsQztatcip3zBRalO3QYcF8WUNkCs3GY3
yMDoCnK9L3JE+aihGf93UklAeYij856LlY4zj1Nxnm5MCdUNLnYpz+VpyjOtpE2w
QX3AH0jPs6b2coYC7O0CggpbMF0xFJzpaLiiRaabSzvuLT8vh1ICaCyUpH9IgXIv
M8i1b7aIvLRyxo1ZylFdBNu3J74Ayv5BZKudEtA5yqGn0bExL+yPiSJgv20WcrY=
=4frW
-END 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

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

[openstack-dev] [neutron][fwaas] No FWaaS Meeting this week.

[Sridar Kandaswamy (skandasw)]

Hi All:

Skipping this weeks FWaaS IRC meeting with some members at/traveling to PTG.

We will resume next week as usual.

Thanks

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