[openstack-dev] [heat] Team dinner at PTG

[Rico Lin]

Hi guys

As usual, we will have a team dinner (and beer session) during PTG.
Feel free to join us!
And please vote for any preferred schedule here:
https://framadate.org/DiYtBWG2VqTRxMs5

We will find some place later.


-- 
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] [Horizon] Weekly wrap-up

[Richard Jones]

Hi folks,

A quiet week this week as folks gear up for Pike and the PTG next week.

We did get Ocata RC2 out the door this week with those final few bug
fixes and the wonderful translations from the i18n team! Thanks to
everyone who helped make Ocata Horizon happen :-)

If you're going to the PTG, or have something you'd like discussed
there, please get your thoughts about Pike planning into the
etherpad[1].


Cheers, and signing off to hand over to Rob for Pike,

Richard

[1] https://etherpad.openstack.org/p/horizon-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

[openstack-dev] [Blazar] Project Team Gathering for Pike

[Hiroaki Kobayashi]

Hi all,

Blazar team will unofficially gather on next Thursday at PTG.
Please join us if you are interested in the Reservation as a
Service for OpenStack!

Here are schedule and topics:
https://etherpad.openstack.org/p/blazar-ptg-pike

The Blazar project (previously known as Climate) has recently
been revived but still small and needs more contributors.
We are very happy if you could join us!

More about Blazar:
https://wiki.openstack.org/wiki/Blazar

Best regards,
Hiroaki



__
OpenStack Development Mailing 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] nova 15.0.0.0rc2 (ocata)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/nova/

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

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

http://git.openstack.org/cgit/openstack/nova/log/?h=stable/ocata

Release notes for nova can be found at:

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



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

[openstack-dev] [oslo] PTG schedule

[ChangBo Guo]

*folks,*
I made a draft schedule for Oslo team at PTG. In summary, we have one and
half days, there are two bug smash event at the end of each day.  Maybe we
need make some adjustments to avoid conflicts with other sessions, please
let me know if we have any. Please check out
https://etherpad.openstack.org/p/oslo-ptg-pike for details.

*Agenda*

Monday, February 20
10:00  AM - 10:40 AM

   - use the same configuration names across the different drivers that
   implement the same feature


   - Room: Dedicated Oslo room

11:00 AM - 12:00 PM

   - Oslo - Messaging Experiences towards hybrid backends


   - Room Savannah 3


   - slides:

12:00 PM - 1:30 PM

   - Lunch


   - Room: South Capital Ballroom (1st floor)

1:30 PM - 2:20 PM

   - How to make oslo work done in efficient way


   - Room: Dedicated Oslo room

2:30 PM - 5:00 PM

   - Bug Smash


   - Room: Dedicated Oslo room


Tuesday, February 21st
1:30 PM - 2:20 PM

   - Feature updates & collect ideas


   - Room: Dedicated Oslo room

2:30 PM - 5:00 PM

   - Bug Smash


   - Room: Dedicated Oslo room




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

Re: [openstack-dev] [OpenStack-Infra] [all][stable][ptls] Tagging liberty as EOL

[Joshua Hesketh]

On Wed, Feb 15, 2017 at 4:20 PM, Tony Breeds 
wrote:

> On Wed, Feb 08, 2017 at 09:55:41AM -0800, Ihar Hrachyshka wrote:
> > Has the liberty-eol cleanup happened? Because I still see
> > stable/liberty branch in openstack/neutron repo, which gets in the way
> > of some logic around proactive backports:
> > https://review.openstack.org/#/c/427936/4/bugs-fixed-since.py@75, and
> > I see backports proposed for the branch that is no longer supported
> > and has broken gate setup.
>
> It seems I setup the second wave and then neglected to ask the infra team
> to process them.
>
> Infra tema (*cough* Josh *cough*) can you remove the branches marke Please
> EOL in
>
> https://gist.githubusercontent.com/tbreeds/93cd346c37aa46269456f56649f0a4
> ac/raw/4f781426270cb2030f978f47b1f46dae6f5aecb4/liberty_eol_data.txt
>
>
Hey,

I have processed these retirements. Let me know if there are any more or
any problems etc.

Cheers,
Josh


> Once that's done I can do a final pass for jobs that may break and we can
> drop
> the devstack, devstack-gate and requirements branches.
>
> Tony.
>
> ___
> OpenStack-Infra mailing list
> openstack-in...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
__
OpenStack Development Mailing 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] [manila] manila 4.0.0.0rc2 (ocata)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/manila/

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

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

http://git.openstack.org/cgit/openstack/manila/log/?h=stable/ocata

Release notes for manila can be found at:

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



__
OpenStack Development Mailing 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] cinder 10.0.0.0rc2 (ocata)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/cinder/

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

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

http://git.openstack.org/cgit/openstack/cinder/log/?h=stable/ocata

Release notes for cinder can be found at:

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



__
OpenStack Development Mailing 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] neutron 10.0.0.0rc2 (ocata)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/neutron/

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

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

http://git.openstack.org/cgit/openstack/neutron/log/?h=stable/ocata

Release notes for neutron can be found at:

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



__
OpenStack Development Mailing 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] neutron-fwaas 10.0.0.0rc2 (ocata)

[no-reply]

Hello everyone,

A new release candidate for neutron-fwaas for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/neutron-fwaas/

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

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

http://git.openstack.org/cgit/openstack/neutron-fwaas/log/?h=stable/ocata

Release notes for neutron-fwaas can be found at:

http://docs.openstack.org/releasenotes/neutron-fwaas/



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

[openstack-dev] [glance] priorities for the coming week (02/17-02/23)

[Brian Rosmaita]

Hello Glancers,

Here are the weekly priorities:

1. RC-1 Testing
It's still looking like RC-1 is going to be the real thing.  If you have
some free time, give it a workout.

2. PTG
Here are some key URLs for your convenience:
- https://etherpad.openstack.org/p/glance-pike-ptg-planning
- https://etherpad.openstack.org/p/glance-pike-ptg-schedule
-
https://specs.openstack.org/openstack/glance-specs/specs/mitaka/approved/image-import/image-import-refactor.html

I'm not sure what the remote participation possibilities will be, but
put a shout in #openstack-glance and we'll see what we can do.


There will be no Glance weekly meeting on Thursday, February 23.

cheers,
brian

__
OpenStack Development Mailing 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] artifacts code removed from the glance codebase in Pike

[Brian Rosmaita]

If you've never deployed, packaged, or used the Artifacts API supplied
by Glance or Glare, you can safely disregard this message.

There's a patch up [0] to remove the legacy EXPERIMENTAL Artifacts API
code from the Glance code repository.  (This is an entirely separate
issue from the question of whether the Glare *project* should be
independent or part of Glance, which we'll be discussing at the PTG next
week [1].)  I would like the patch to merge as soon as possible, but I
also wanted to give people a heads-up in case anyone would be impacted
by this change.

The situation is explained in detail in the releasenotes [2] included on
the patch.  Please let me know immediately if there is a reason why we
should hold off merging this patch.  Otherwise, I'd like to merge it
before the post-PTG burst of code changes begins.

thanks,
brian

[0] https://review.openstack.org/427535
[1] "Macon" room, 9:30-10:30 on Thursday
[2]
https://review.openstack.org/#/c/427535/14/releasenotes/notes/glare-ectomy-72a1f80f306f2e3b.yaml

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

Re: [openstack-dev] [tripleo] Fwd: TripleO mascot - how can I help your team?

[John Dickinson]

On 16 Feb 2017, at 15:01, Chris Dent wrote:

> On Thu, 16 Feb 2017, Dan Prince wrote:
>
>> And yes. We are all OpenStack developers in a sense. We want to align
>> things in the technical arena. But I think you'll also find that most
>> people more closely associate themselves to a team within OpenStack
>> than they perhaps do with the larger project. Many of us in TripleO
>> feel that way I think. This is a healthy thing, being part of a team.
>> Don't make us feel bad because of it by suggesting that uber OpenStack
>> graphics styling takes precedent.
>
> I'd very much like to have a more clear picture of the number of
> people who think of themselves primarily as "OpenStack developers"
> or primarily as "$PROJECT developers".
>
> I've always assumed that most people in the community™ thought of
> themselves as the former but I'm realizing (in part because of what
> Dan's said here) that's bias or solipsism on my part and I really
> have no clue what the situation is.
>
> Anyone have a clue?

Without resorting to anecdote, two things from the foundation are interesting 
to me on this topic.

First, the foundation is making individual project logos for each project, thus 
promoting the individual project, and has said they will factor in to future 
OpenStack marketing.

Second, the foundation messaging around the PTG emphasizes per-project 
developers. From https://www.openstack.org/ptg/

The event is not optimized for non-contributors or people who can’t relate to a 
specific project team. Each team is given a single room and attendees are 
expected to spend all their time with their project team. Attendees who can’t 
pick a specific team to work with are encouraged to skip the event in favor of 
attending the OpenStack Summit, where a broader range of topics is discussed.




--John




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


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

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

[Lance Bragstad]

On Thu, Feb 16, 2017 at 5:20 PM, Dolph Mathews 
wrote:

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

++ Our schedule is coming together and this is what we have so far [0]. If
there is an open time slot that works for your schedule, don't hesitate to
let me know.


[0] https://etherpad.openstack.org/p/keystone-pike-ptg


>
> 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/12cL9bq9EARjZw9IS3YxVmYsGfdauM
>> 25NzZcdzPE0fvY/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 issues. Also
>> ideally running the token provider in production.
>>
>>
>> > 2. Has Fernet token improved the performance during these releases? Or
>> any
>> > road map so that we can make sure Fernet is better than PKI in all side.
>> > Otherwise, I don't think that remove PKI in Ocata is the right way. Or
>> > even, we can keep the PKI token in Keystone for more one or two cycles,
>> > then remove it once Fernet is stable enough.
>> > 3. Since I'll be in Atalanta next week, if it is possible, I'd like to
>> > bring this topic to Keystone PTG. can I?
>>
>> Sure. We have a pretty packed calendar, but I'm sure you could steal a
>> few minutes somewhere.
>>
>>
>> >
>> > It is a real production problem and I really need 

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

[Matt Riedemann]

On 2/16/2017 5:26 PM, Thomas Goirand wrote:


Also, the approach to give-up the packaging of "non-important" project
(ie: not-core, like the ones in the list I gave...) in the hope it will
save so much time is IMO simply wrong. What eats all of the package
maintenance time is *not* final projects (trove, watcher, etc.) but all
the OpenStack dependencies. Maybe 90% of my time have been spent on
packaging oslo libraries, clients, and 3rd parties, and making sure they
integrate well with the rest of the distro (python 3 compat, Django
1.10, latest SQLA, etc.). So giving-up on that last extra mile of work
to put the cherry on top of the cake isn't the good approach.



FWIW, +1 to that. When I was doing OpenStack packaging for IBM's distro 
on a daily basis a few years ago the brunt of my time was spent on 
currency on the daily changes in the multitude of dependent package 
version changes. We had spit-balled some ideas on automating some of 
that, but just never found the time.


--

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

[Thomas Goirand]

On 02/16/2017 05:55 PM, Clint Byrum wrote:
> Excerpts from Thomas Goirand's message of 2017-02-15 13:43:46 +0100:
>> 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).
>>
> 
> Thomas, thanks for all your hard work. I hope you can return to it soon
> and that this serves as a notice that we need more investment to keep
> OpenStack viable in Debian and Ubuntu.

Yeah, thanks!

> 
> Can I propose that we start to move some of the libraries and things
> like OpenStack Client into DPMT/DPAT?  They don't require constant
> attention, and it will be helpful to have a larger team assisting in
> the packaging where it doesn't require anything OpenStack specific to
> keep moving forward.

3rd party libs, maybe. Things like OpenStack client and such may not be
good candidates, as they interact too much with oslo stuff. Also,
pushing these packages to a different team wont give you more
contributors. Last, DPMT/DPAT insist in using git-dpm which is horrible,
while I've successfully pushed all of the packaging into the OpenStack
CI, which checks the build on every commit. I consider it a way safer
and nicer than just the "stupid" Git on Alioth. If you want packages to
go back to Alioth, at least someone has to setup a Jenkins the way I
used to do, so that packages are build on git push. I don't have such an
infrastructure anymore at my disposal, Mirantis even is destroying the
server I used to work on (at this point in time, the FTP data may even
already be lost for the older releases...).

Cheers,

Thomas Goirand (zigo)


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

[openstack-dev] [tricircle]Ocata released and Pike meetup

[joehuang]

Hello,

Thanks for your great contribution, Tricircle 3.0.0 (Ocata release) has been 
released after the patch[1] was approved, the release notes could be found at 
[2].

A meetup for Pike will be held: Feb.17, UTC 1:00~8:00( UTC+8: 9:00 am~4:00 pm), 
Block G, Huawei Industrial Base, Shenzhen. Etherpad [3]:

[1] https://review.openstack.org/#/c/432166/
[2] https://docs.openstack.org/releasenotes/tricircle/
[3] https://etherpad.openstack.org/p/tricircle-pike-design-topics


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

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

[Thomas Goirand]

On 02/16/2017 12:20 PM, Ondrej Novy wrote:
> Hi,
> 
> 2017-02-16 0:45 GMT+01:00 Thomas Goirand  >:
> 
> Yes, you've done some work, and many thanks for it, it has been very
> useful. However the reality is: since I stopped after the Newton
> release, absolutely no work has been done to package Ocata in Debian. At
> this point in the OpenStack dev cycle, normally it should have been
> fully uploaded *AND* tested against tempest.
> 
> 
> yep, because there are no branches for it. And because I don't know how
> to create them (in infra which I hate for deb packaging) i can't
> continue my work on Ocata.

1/ Let give you the technical answer

Creating a new debian/ocata branch is just one click away. For example,
if you want to do a debian/ocata branch for Nova, just go here:

https://review.openstack.org/#/admin/projects/openstack/deb-nova,branches

type the name of the branch, the sha or simply debian/newton as a ref,
and you're done. That's really super easy, and you even have the ACLs to
do it!

Though the issue here is that you should first get an Ocata repository
created with reprepro. This, only the OpenStack infra team can do. I
investigated quickly, and it seems it should be a "reprepro pull"
command. You'd have to check for it first though, and make sure all
packages gets imported from the Newton pool.

Once that is done, the first package to fix is openstack-pkg-tools, so
that the debian/ocata branch builds and push in the ocata repository.
That's trivial to do, IMO. Just maybe, the pickup job from the infra
team (ie: when a patch is merged) may need to be fixed to push to the
correct place as well.

In any case, the infra team should be able to help, they've been really
helpful.

2/ The social answer

I really wish somebody takes over the work, if I there's no company is
willing to sponsor mine.

But the fact that none (including you) attempted to get in touch with me
to do it over the course of many months, up to the very end of this
Ocata release isn't a good sign. I still don't believe it will happen. I
hope I'll be proven wrong, but I also don't believe it can realistically
happen with just a few volunteers not working on it full time: someone
must get enough commitment to have a global view of what work remains to
be done, do the tests, write patches. That's not something you just do a
few hours on your week-ends. If someone pretends something else, then
this may imply a drastic drop in packaging quality as well, which I'm
*not* willing to put my name on. Otherwise, I would probably have continued.

Also, the approach to give-up the packaging of "non-important" project
(ie: not-core, like the ones in the list I gave...) in the hope it will
save so much time is IMO simply wrong. What eats all of the package
maintenance time is *not* final projects (trove, watcher, etc.) but all
the OpenStack dependencies. Maybe 90% of my time have been spent on
packaging oslo libraries, clients, and 3rd parties, and making sure they
integrate well with the rest of the distro (python 3 compat, Django
1.10, latest SQLA, etc.). So giving-up on that last extra mile of work
to put the cherry on top of the cake isn't the good approach.

Hoping the above helps, though I'm really not sure it does,
Cheers,

Thomas Goirand (zigo)


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

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

[Dolph Mathews]

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 issues. Also
> ideally running the token provider in production.
>
>
> > 2. Has Fernet token improved the performance during these releases? Or
> any
> > road map so that we can make sure Fernet is better than PKI in all side.
> > Otherwise, I don't think that remove PKI in Ocata is the right way. Or
> > even, we can keep the PKI token in Keystone for more one or two cycles,
> > then remove it once Fernet is stable enough.
> > 3. Since I'll be in Atalanta next week, if it is possible, I'd like to
> > bring this topic to Keystone PTG. can I?
>
> Sure. We have a pretty packed calendar, but I'm sure you could steal a
> few minutes somewhere.
>
>
> >
> > It is a real production problem and I really need your feedback.
> >
>
> Have you tried playing with the crypt_strength[1]? If the slowness is
> the crypto (which it was in the past) then you can tune it a little bit.
> Another option might be to keep the same token flow and find a faster
> method for hashing a token.
>
> 1.
> http://git.openstack.org/cgit/openstack/keystone/tree/etc/keystone.conf.sample#n67
>
>
> --
> david stanek
> web: https://dstanek.com
> twitter: 

Re: [openstack-dev] [tripleo] Fwd: TripleO mascot - how can I help your team?

[Chris Dent]

On Thu, 16 Feb 2017, Dan Prince wrote:


And yes. We are all OpenStack developers in a sense. We want to align
things in the technical arena. But I think you'll also find that most
people more closely associate themselves to a team within OpenStack
than they perhaps do with the larger project. Many of us in TripleO
feel that way I think. This is a healthy thing, being part of a team.
Don't make us feel bad because of it by suggesting that uber OpenStack
graphics styling takes precedent.


I'd very much like to have a more clear picture of the number of
people who think of themselves primarily as "OpenStack developers"
or primarily as "$PROJECT developers".

I've always assumed that most people in the community™ thought of
themselves as the former but I'm realizing (in part because of what
Dan's said here) that's bias or solipsism on my part and I really
have no clue what the situation is.

Anyone have a clue?

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

[openstack-dev] [horizon] horizon 11.0.0.0rc2 (ocata)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/horizon/

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

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

http://git.openstack.org/cgit/openstack/horizon/log/?h=stable/ocata

Release notes for horizon can be found at:

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



__
OpenStack Development Mailing 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] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

[Fox, Kevin M]

Yeah, but if the deployment tools have to implement support for every project, 
it becomes combinatorial to support all the projects in all the deployment 
tools. let alone document it for each deployment project. If there was a 
foundational infrastructure that the other big tent projects could rely on 
always being there, then the big tent projects could themselves work on the 
deployment tooling and do it only once. The idea is not to deprecate the big 
tent projects, but deprecate deploying them with so many different tools. 
Deploy the base openstack parts using chef, ansible, etc and then use the 
common tooling to deploy the rest. Just a thought.

Thanks,
Kevin


From: Tim Bell [tim.b...@cern.ch]
Sent: Thursday, February 16, 2017 11:28 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [chef] Making the Kitchen Great Again: A 
Retrospective on OpenStack & Chef


On 16 Feb 2017, at 19:42, Fox, Kevin M 
> wrote:

+1. The assumption was market forces will cause the best OpenStack deployment 
tools to win. But the sad reality is, market forces are causing people to look 
for non OpenStack solutions instead as the pain is still too high.

While k8s has a few different deployment tools currently, they are focused on 
getting the small bit of underlying plumbing deployed. Then you use the common 
k8s itself to deploy the rest. Adding a dashboard, dns, ingress, sdn, other 
component is easy in that world.

IMO, OpenStack needs to do something similar. Standardize a small core and get 
that easily deployable, then make it easy to deploy/upgrade the rest of the big 
tent projects on top of that, not next to it as currently is being done.

Thanks,
Kevin

Unfortunately, the more operators and end users question the viability of a 
specific project, the less likely it is to be adopted.
It is a very very difficult discussion with an end user to explain that 
function X is no longer available because the latest OpenStack upgrade had to 
be done for security/functional/stability reasons and this project/function is 
not available.
The availability of a function may also have been one of the positives for the 
OpenStack selection so finding a release or two later that it is no longer in 
the portfolio is difficult.
The deprecation policy really helps so we can give a good notice but this 
assumes an equivalent function is available. For example, the built in Nova EC2 
to EC2 project was an example where we had enough notice to test the new 
solution in parallel and then move with minimum disruption.  Moving an entire 
data centre from Chef to Puppet or running a parallel toolchain, for example, 
has a high cost.
Given the massive functionality increase in other clouds, It will be tough to 
limit the OpenStack offering to the small core. However, expanding with 
unsustainable projects is also not attractive.
Tim


From: Joshua Harlow [harlo...@fastmail.com]
Sent: Thursday, February 16, 2017 10:24 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [chef] Making the Kitchen Great Again: A 
Retrospective on OpenStack & Chef

Alex Schultz wrote:
On Thu, Feb 16, 2017 at 9:12 AM, Ed 
Leafe>  wrote:
On Feb 16, 2017, at 10:07 AM, Doug 
Hellmann>  wrote:

When we signed off on the Big Tent changes we said competition
between projects was desirable, and that deployers and contributors
would make choices based on the work being done in those competing
projects. Basically, the market would decide on the "optimal"
solution. It's a hard message to hear, but that seems to be what
is happening.
This.

We got much better at adding new things to OpenStack. We need to get better at 
letting go of old things.

-- Ed Leafe




I agree that the market will dictate what continues to survive, but if
you're not careful you may be speeding up the decline as the end user
(deployer/operator/cloud consumer) will switch completely to something
else because it becomes to difficult to continue to consume via what
used to be there and no longer is.  I thought the whole point was to
not have vendor lock-in.  Honestly I think the focus is too much on
the development and not enough on the consumption of the development
output.  What are the point of all these features if no one can
actually consume them.


+1 to that.

I've been in the boat of development and consumption of it for my
*whole* journey in openstack land and I can say the product as a whole
seems 'underbaked' with regards to the way people consume the
development output. It seems we have focused on how to do the dev. stuff
nicely and a nice process there, but sort of forgotten about all that
being quite useless if no one can consume them (without going through
much 

Re: [openstack-dev] [neutron] Some findings while profiling instances boot

[Kevin Benton]

Note that neutron no longer relies on giant join conditions so heavily due
to explosions in result sizes with the various many to one relationships as
of about a week ago[1].

We switched to subqueries for the one to many relationships to prevent the
result size explosions, so now we issue a lot more queries for an
individual retrieval. I'm not sure if that is better or worse WRT the
sqlalchemy performance but I thought it was important to bring up before we
spend time optimizing the old way of massive joins.

The subqueries make it that much more important that we bulk up requests to
retrieve ports, etc since we now pay a higher constant query cost.

1. https://bugs.launchpad.net/neutron/+bug/1649317

On Feb 16, 2017 8:38 AM, "Mike Bayer"  wrote:

>
>
> On 02/15/2017 12:46 PM, Daniel Alvarez Sanchez wrote:
>
>> Also, while having a look at server profiling, around the 33% of the
>> time was spent building SQL queries [1]. Mike Bayer went through this
>> and suggested having a look at baked queries and also submitted a sketch
>> of his proposal [2].
>>
>
> Neutron relies heavily on a big JOIN query that returns just one row. In
> the profiling, it seemed like joined eager loading overhead is
> significant.  Someone independently opened an upstream issue at
> https://bitbucket.org/zzzeek/sqlalchemy/issues/3915/performa
> nce-degradation-on-version-10xx#comment-34442856 with similar comments.
>
> While the "baked" query thing is the ultimate hammer for "ORM SQL
> building" overhead, it's a very heavy hammer to swing as folks will note in
> the gerrit that shows roughly how it would look, it's involved and not that
> easy to work with.
>
> Fortunately, the joined eager load codepaths here have never been
> optimized for the "many short queries" use case, and a large portion of the
> overhead is all rolled up into some SQL alias objects that can be memoized
> so that most of the work they do happens once, instead of thousands of
> times.
>
> In https://gerrit.sqlalchemy.org/311  (note this is SQLAlchemy's gerrit,
> not openstack's) I have a patch that reduces the overhead associated
> specifically with joined eager loaded entities by around 270% for a
> worst-case scenario (which Neutron seems to be close to).  If those folks
> running the load tests can please try this revision out and see if it makes
> a dent, that would be helpful.
>
> Note that SQLAlchemy 1.1 has been out for about five months now, and it's
> time that Openstack move up to 1.1 series - that's where the performance
> enhancement will be.
>
>
>
>
>> I wanted to share these findings with you (probably most of you knew but
>> I'm quite new to OpenStack so It's been a really nice exercise for me to
>> better understand how things work) and gather your feedback about how
>> things can be improved. Also, I'll be happy to share the results and
>> discuss further if you think it's worth during the PTG next week.
>>
>> Thanks a lot for reading and apologies for such a long email!
>>
>> Cheers,
>> Daniel
>> IRC: dalvarez
>>
>> [0] http://imgur.com/WQqaiYQ
>> [1] http://imgur.com/6KrfJUC
>> [2] https://review.openstack.org/430973
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Some findings while profiling instances boot

[Kevin Benton]

We could potentially make that call async on the agent, but the agent has
very little to do without the information in the response that comes back.

As we switch over to push notifications, this method of data retrieval will
be completely gone so we probably don't want to spend much time redesigning
that workflow anyway.

The baked queries thing is interesting, I'll reply on Mike's email with
more details.

On Feb 16, 2017 7:07 AM, "Daniel Alvarez Sanchez" 
wrote:

> Awesome work, Kevin!
>
> For the DHCP notification, in my profiling I got only 10% of the CPU time
> [0] without taking the waiting times into account which it's probably what
> you also measured.
> Your patch seems like a neat and great optimization :)
>
> Also, since "get_devices_details_list_and_failed_devices()" takes quite a
> long time, does it make sense to trigger this request asynchronously (same
> approach you took for OVO notifier) and continue executing the iteration?
> This would not result in a huge improvement but, in the case I showed in
> the diagram, both 'get_device_details' can be issued at the same time
> instead of one after another and, probably, freeing the iteration for
> further processing on the agent side. Thoughts on this?
>
> Regarding, the time of SQL queries, it looks like the server spends a
> significant amount of time building those and reducing that time will
> result in a nice improvement. Mike's outstanding analysis looks promising
> and maybe it's worth to discuss it.
>
> [0] http://imgur.com/lDikZ0I
>
>
>
> On Thu, Feb 16, 2017 at 8:23 AM, Kevin Benton  wrote:
>
>> Thanks for the stats and the nice diagram. I did some profiling and I'm
>> sure it's the RPC handler on the Neutron server-side behaving like garbage.
>>
>> There are several causes that I have a string of patches up to address
>> that mainly stem from the fact that l2pop requires multiple port status
>> updates to function correctly:
>>
>> * The DHCP notifier will trigger a notification to the DHCP agents on the
>> network on a port status update. This wouldn't be too problematic on it's
>> own, but it does several queries for networks and segments to determine
>> which agents it should talk to. Patch to address it here:
>> https://review.openstack.org/#/c/434677/
>>
>> * The OVO notifier will also generate a notification on any port data
>> model change, including the status. This is ultimately the desired
>> behavior, but until we eliminate the frivolous status flipping, it's going
>> to incur a performance hit. Patch here to put it asynced into the
>> background so it doesn't block the port update process:
>> https://review.openstack.org/#/c/434678/
>>
>> * A wasteful DB query in the ML2 PortContext: https://review.op
>> enstack.org/#/c/434679/
>>
>> * More unnecessary  queries for the status update case in the ML2
>> PortContext: https://review.openstack.org/#/c/434680/
>>
>> * Bulking up the DB queries rather than retrieving port details one by
>> one.
>> https://review.openstack.org/#/c/434681/ https://review.open
>> stack.org/#/c/434682/
>>
>> The top two accounted for more than 60% of the overhead in my profiling
>> and they are pretty simple, so we may be able to get them into Ocata for RC
>> depending on how other cores feel. If not, they should be good candidates
>> for back-porting later. Some of the others start to get more invasive so we
>> may be stuck.
>>
>> Cheers,
>> Kevin Benton
>>
>> On Wed, Feb 15, 2017 at 12:25 PM, Jay Pipes  wrote:
>>
>>> On 02/15/2017 12:46 PM, Daniel Alvarez Sanchez wrote:
>>>
 Hi there,

 We're trying to figure out why, sometimes, rpc_loop takes over 10
 seconds to process an iteration when booting instances. So we deployed
 devstack on a 8GB, 4vCPU VM and did some profiling on the following
 command:

 nova boot --flavor m1.nano --image cirros-0.3.4-x86_64-uec --nic
 net-name=private --min-count 8 instance

>>>
>>> Hi Daniel, thanks for posting the information here. Quick request of
>>> you, though... can you try re-running the test but doing 8 separate calls
>>> to nova boot instead of using the --min-count 8 parameter? I'm curious to
>>> see if you notice any difference in contention/performance.
>>>
>>> Best,
>>> -jay
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> 

[openstack-dev] [trove] trove 7.0.0.0rc2 (ocata)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/trove/

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

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

http://git.openstack.org/cgit/openstack/trove/log/?h=stable/ocata

Release notes for trove can be found at:

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



__
OpenStack Development Mailing 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] Fwd: TripleO mascot - how can I help your team?

[Jeremy Stanley]

On 2017-02-16 15:20:11 -0500 (-0500), Dan Prince wrote:
[...]
> And there is that rub again. There is implied along with this pressure
> to adopt the new logo. If you don't you'll get a blank space as a sort
> of punishment for going your own way. As Monty said directly... they
> want conformance and cohesion over team identity.

There's also an easy out. Pick something, let them use that, and
move on continuing to use whatever other art you want yourself.
That's more or less the direction I took with the Infra team's
"mascot." There was no strong opinion from the team that we even
needed a mascot, and none of the ideas or symbols we'd used in the
past (for which there is existing art) would have met the stated
requirements. So we ran a poll of the various suggestions among our
PTL electorate, and told the foundation to use whatever came up as
the top choice. When they came out with draft artwork, we said go
with it. In the future we very well may still continue to use a gear
or something else on our own; we're not required to brand ourselves
forever as a red velvet ant. That's just something that gets used on
foundation material as far as I'm concerned.

> Read the initial replies on this thread. Almost every single person
> besides (Flavio and Monty) preferred to keep the original TripleO
> mascot. Same thing on the Ironic thread as far as I can tell (those
> devs almost all initially preferred the old mascot before they were
> talked out of it.). And then you wore them down. Keep asking the same
> question again and again and I guess over time people stop caring.

I hope I didn't personally wear anyone down. I'm just attempting to
present impartial facts so that this thread doesn't go entirely off
the rails with conspiracies and blamethrowing.

> Its all just silliness really. Why the foundation got involved in this
> mascot business to begin with and didn't just leave it to the
> individual projects.
[...]

Sure, I felt the same way to a great extent. I just kept in mind
that this came about for a specific purpose, that some people wanted
ideas for art to use on a particular Web site under some pretty
tight design constraints, but that they were attempting to involve
the developer community in that process rather than do it on their
own in a corner somewhere.
-- 
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] [tripleo] Fwd: TripleO mascot - how can I help your team?

[Emilien Macchi]

On Thu, Feb 16, 2017 at 3:20 PM, Dan Prince  wrote:
> On Thu, 2017-02-16 at 19:54 +, Jeremy Stanley wrote:
>> On 2017-02-16 14:09:53 -0500 (-0500), Dan Prince wrote:
>> [...]
>> > This isn't about aligning anything. It is about artistic control.
>> > The
>> > foundation wants to have icons their way playing the "community
>> > card"
>> > to make those who had icons they like conform. It is clear you buy
>> > into
>> > this.
>> >
>> > Each team will have its own mascot anyway so does it really matter
>> > if
>> > there is some deviation in the mix? I think not. We have a mascot
>> > we
>> > like. It even fits the general requirements for OpenStack mascots
>> > so
>> > all we are arguing about here is artistic style really. I say let
>> > the
>> > developers have some leverage in this category... what is the harm
>> > really?
>>
>> [...]
>>
>> You're really reading far too much conspiracy into this. Keep in
>> mind that this was coming from the foundation's marketing team, and
>> while they've been very eager to interface with the community on
>> this effort they may have failed to some degree in explaining their
>> reasons (which as we all know leaves a vacuum where conspiracy
>> theories proliferate).
>>
>> As I understand things there are some pages on the
>> foundation-controlled www.openstack.org site where they want to
>> refer to various projects/teams and having a set of icons
>> representing them was a desire of the designers for that site, to
>> make it more navigable and easier to digest. They place significant
>> importance on consistency and aesthetics, and while that doesn't
>> necessarily match my personal utilitarian nature I can at least
>> understand their position on the matter. Rather than just words or
>> meaningless symbols as icons they thought it would be compelling to
>> base those icons on mascots, but to maintain the aesthetic of the
>> site the specific renderings needed to follow some basic guidelines.
>> They could have picked mascots at random out of the aether to use
>> there, but instead wanted to solicit input from the teams whose work
>> these would represent so that they might have some additional
>> special meaning to the community at large.
>>
>> As I said earlier in the thread, if you have existing art you like
>> then use that in your documentation, in the wiki, on team tee-shirts
>> you make, et cetera. The goal is not to take those away. This is a
>> simple need for the marketing team and foundation Web site designers
>> to have art they can use for their own purposes which meets their
>> relatively strict design aesthetics... and if that art is also
>> something the community wants to use, then all the better but it's
>> in no way mandatory. The foundation has no direct control over
>> community members' choices here, nor have they attempted to pretend
>> otherwise that I've seen.
>
> And there is that rub again. There is implied along with this pressure
> to adopt the new logo. If you don't you'll get a blank space as a sort
> of punishment for going your own way. As Monty said directly... they
> want conformance and cohesion over team identity.
>
> Read the initial replies on this thread. Almost every single person
> besides (Flavio and Monty) preferred to keep the original TripleO
> mascot. Same thing on the Ironic thread as far as I can tell (those
> devs almost all initially preferred the old mascot before they were
> talked out of it.). And then you wore them down. Keep asking the same
> question again and again and I guess over time people stop caring.
>
> Its all just silliness really. Why the foundation got involved in this
> mascot business to begin with and didn't just leave it to the
> individual projects.
>
> And again. Not a great time to be talking about any of this. My sense
> of urgency is largely based on the fact that Emilien sent out an
> official team stance on this. I wasn't part of that... so apologies for
> being late to this conversation.
>
> Dan

Dan, I'm sorry if you were offline during our last weekly meeting on Tuesday.
However, I don't feel that I took the decision on my own, and if I did
it (here or anywhere else in TripleO), please tell me right now
because it has never been my intent. Being a PTL is not always easy
and decisions have to be made, but I hope we can always make it as a
team.

Because I like to think we live in a democracy where we take decisions
as a team, I propose to run this simple poll:
https://goo.gl/forms/ERN7i2dcudqMmRLN2

The question is simple: do you accept a logo change or not.

We'll let the poll open 2 weeks, making sure anyone can vote.

Thank you,
-- 
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] [tripleo] Fwd: TripleO mascot - how can I help your team?

[Jay Faulkner]

> On Feb 16, 2017, at 12:20 PM, Dan Prince  wrote:
> 
> On Thu, 2017-02-16 at 19:54 +, Jeremy Stanley wrote:
>> On 2017-02-16 14:09:53 -0500 (-0500), Dan Prince wrote:
>> [...]
>>> This isn't about aligning anything. It is about artistic control.
>>> The
>>> foundation wants to have icons their way playing the "community
>>> card"
>>> to make those who had icons they like conform. It is clear you buy
>>> into
>>> this.
>>> 
>>> Each team will have its own mascot anyway so does it really matter
>>> if
>>> there is some deviation in the mix? I think not. We have a mascot
>>> we
>>> like. It even fits the general requirements for OpenStack mascots
>>> so
>>> all we are arguing about here is artistic style really. I say let
>>> the
>>> developers have some leverage in this category... what is the harm
>>> really?
>> 
>> [...]
>> 
>> You're really reading far too much conspiracy into this. Keep in
>> mind that this was coming from the foundation's marketing team, and
>> while they've been very eager to interface with the community on
>> this effort they may have failed to some degree in explaining their
>> reasons (which as we all know leaves a vacuum where conspiracy
>> theories proliferate).
>> 
>> As I understand things there are some pages on the
>> foundation-controlled www.openstack.org site where they want to
>> refer to various projects/teams and having a set of icons
>> representing them was a desire of the designers for that site, to
>> make it more navigable and easier to digest. They place significant
>> importance on consistency and aesthetics, and while that doesn't
>> necessarily match my personal utilitarian nature I can at least
>> understand their position on the matter. Rather than just words or
>> meaningless symbols as icons they thought it would be compelling to
>> base those icons on mascots, but to maintain the aesthetic of the
>> site the specific renderings needed to follow some basic guidelines.
>> They could have picked mascots at random out of the aether to use
>> there, but instead wanted to solicit input from the teams whose work
>> these would represent so that they might have some additional
>> special meaning to the community at large.
>> 
>> As I said earlier in the thread, if you have existing art you like
>> then use that in your documentation, in the wiki, on team tee-shirts
>> you make, et cetera. The goal is not to take those away. This is a
>> simple need for the marketing team and foundation Web site designers
>> to have art they can use for their own purposes which meets their
>> relatively strict design aesthetics... and if that art is also
>> something the community wants to use, then all the better but it's
>> in no way mandatory. The foundation has no direct control over
>> community members' choices here, nor have they attempted to pretend
>> otherwise that I've seen.
> 
> And there is that rub again. There is implied along with this pressure
> to adopt the new logo. If you don't you'll get a blank space as a sort
> of punishment for going your own way. As Monty said directly... they
> want conformance and cohesion over team identity.
> 
> Read the initial replies on this thread. Almost every single person
> besides (Flavio and Monty) preferred to keep the original TripleO
> mascot. Same thing on the Ironic thread as far as I can tell (those
> devs almost all initially preferred the old mascot before they were
> talked out of it.). And then you wore them down. Keep asking the same
> question again and again and I guess over time people stop caring.
> 

FWIW, I think we all still prefer the older mascot, and will use it for our 
normal contexts. I changed my vote on the logo because I think we have more 
important things to bike shed over other than logo designs :).

-Jay

> Its all just silliness really. Why the foundation got involved in this
> mascot business to begin with and didn't just leave it to the
> individual projects.
> 
> And again. Not a great time to be talking about any of this. My sense
> of urgency is largely based on the fact that Emilien sent out an
> official team stance on this. I wasn't part of that... so apologies for
> being late to this conversation.
> 
> Dan 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

[Adam Heczko]

Personally I'd prefer OpenStack to follow some of K8s deployment patterns.
OpenStack has grown to an enormous size and it really painful to operate it
at scale. My suggestion would be to focus on improvement of consumption
models. 'Dockerization' of the release artifacts would be very useful. Also
current approach to configuration management relying on tens *conf files
distributed in hundreds directories is difficult to understand and maintain
in the longer term. Why don't move all config to etcd or MySQL? Do we need
all these *conf files? This is operator's pain point and leads
Puppet/Chef/Ansible/Saltstack folks spending hundreds of hours in a
suboptimal way.

On Thu, Feb 16, 2017 at 8:28 PM, Tim Bell  wrote:

>
> On 16 Feb 2017, at 19:42, Fox, Kevin M  wrote:
>
> +1. The assumption was market forces will cause the best OpenStack
> deployment tools to win. But the sad reality is, market forces are causing
> people to look for non OpenStack solutions instead as the pain is still too
> high.
>
> While k8s has a few different deployment tools currently, they are focused
> on getting the small bit of underlying plumbing deployed. Then you use the
> common k8s itself to deploy the rest. Adding a dashboard, dns, ingress,
> sdn, other component is easy in that world.
>
> IMO, OpenStack needs to do something similar. Standardize a small core and
> get that easily deployable, then make it easy to deploy/upgrade the rest of
> the big tent projects on top of that, not next to it as currently is being
> done.
>
> Thanks,
> Kevin
>
>
> Unfortunately, the more operators and end users question the viability of
> a specific project, the less likely it is to be adopted.
>
> It is a very very difficult discussion with an end user to explain that
> function X is no longer available because the latest OpenStack upgrade had
> to be done for security/functional/stability reasons and this
> project/function is not available.
>
> The availability of a function may also have been one of the positives for
> the OpenStack selection so finding a release or two later that it is no
> longer in the portfolio is difficult.
>
> The deprecation policy really helps so we can give a good notice but this
> assumes an equivalent function is available. For example, the built in Nova
> EC2 to EC2 project was an example where we had enough notice to test the
> new solution in parallel and then move with minimum disruption.  Moving an
> entire data centre from Chef to Puppet or running a parallel toolchain, for
> example, has a high cost.
>
> Given the massive functionality increase in other clouds, It will be tough
> to limit the OpenStack offering to the small core. However, expanding with
> unsustainable projects is also not attractive.
>
> Tim
>
>
> 
> From: Joshua Harlow [harlo...@fastmail.com]
> Sent: Thursday, February 16, 2017 10:24 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [chef] Making the Kitchen Great Again: A
> Retrospective on OpenStack & Chef
>
> Alex Schultz wrote:
>
> On Thu, Feb 16, 2017 at 9:12 AM, Ed Leafe  wrote:
>
> On Feb 16, 2017, at 10:07 AM, Doug Hellmann  wrote:
>
> When we signed off on the Big Tent changes we said competition
> between projects was desirable, and that deployers and contributors
> would make choices based on the work being done in those competing
> projects. Basically, the market would decide on the "optimal"
> solution. It's a hard message to hear, but that seems to be what
> is happening.
>
> This.
>
> We got much better at adding new things to OpenStack. We need to get
> better at letting go of old things.
>
> -- Ed Leafe
>
>
>
>
> I agree that the market will dictate what continues to survive, but if
> you're not careful you may be speeding up the decline as the end user
> (deployer/operator/cloud consumer) will switch completely to something
> else because it becomes to difficult to continue to consume via what
> used to be there and no longer is.  I thought the whole point was to
> not have vendor lock-in.  Honestly I think the focus is too much on
> the development and not enough on the consumption of the development
> output.  What are the point of all these features if no one can
> actually consume them.
>
>
> +1 to that.
>
> I've been in the boat of development and consumption of it for my
> *whole* journey in openstack land and I can say the product as a whole
> seems 'underbaked' with regards to the way people consume the
> development output. It seems we have focused on how to do the dev. stuff
> nicely and a nice process there, but sort of forgotten about all that
> being quite useless if no one can consume them (without going through
> much pain or paying a vendor).
>
> This has or has IMHO been a factor in why certain are companies (and the
> people they support) are exiting openstack and just going elsewhere.
>

Re: [openstack-dev] [tripleo] Fwd: TripleO mascot - how can I help your team?

[Dan Prince]

On Thu, 2017-02-16 at 19:54 +, Jeremy Stanley wrote:
> On 2017-02-16 14:09:53 -0500 (-0500), Dan Prince wrote:
> [...]
> > This isn't about aligning anything. It is about artistic control.
> > The
> > foundation wants to have icons their way playing the "community
> > card"
> > to make those who had icons they like conform. It is clear you buy
> > into
> > this.
> > 
> > Each team will have its own mascot anyway so does it really matter
> > if
> > there is some deviation in the mix? I think not. We have a mascot
> > we
> > like. It even fits the general requirements for OpenStack mascots
> > so
> > all we are arguing about here is artistic style really. I say let
> > the
> > developers have some leverage in this category... what is the harm
> > really?
> 
> [...]
> 
> You're really reading far too much conspiracy into this. Keep in
> mind that this was coming from the foundation's marketing team, and
> while they've been very eager to interface with the community on
> this effort they may have failed to some degree in explaining their
> reasons (which as we all know leaves a vacuum where conspiracy
> theories proliferate).
> 
> As I understand things there are some pages on the
> foundation-controlled www.openstack.org site where they want to
> refer to various projects/teams and having a set of icons
> representing them was a desire of the designers for that site, to
> make it more navigable and easier to digest. They place significant
> importance on consistency and aesthetics, and while that doesn't
> necessarily match my personal utilitarian nature I can at least
> understand their position on the matter. Rather than just words or
> meaningless symbols as icons they thought it would be compelling to
> base those icons on mascots, but to maintain the aesthetic of the
> site the specific renderings needed to follow some basic guidelines.
> They could have picked mascots at random out of the aether to use
> there, but instead wanted to solicit input from the teams whose work
> these would represent so that they might have some additional
> special meaning to the community at large.
> 
> As I said earlier in the thread, if you have existing art you like
> then use that in your documentation, in the wiki, on team tee-shirts
> you make, et cetera. The goal is not to take those away. This is a
> simple need for the marketing team and foundation Web site designers
> to have art they can use for their own purposes which meets their
> relatively strict design aesthetics... and if that art is also
> something the community wants to use, then all the better but it's
> in no way mandatory. The foundation has no direct control over
> community members' choices here, nor have they attempted to pretend
> otherwise that I've seen.

And there is that rub again. There is implied along with this pressure
to adopt the new logo. If you don't you'll get a blank space as a sort
of punishment for going your own way. As Monty said directly... they
want conformance and cohesion over team identity.

Read the initial replies on this thread. Almost every single person
besides (Flavio and Monty) preferred to keep the original TripleO
mascot. Same thing on the Ironic thread as far as I can tell (those
devs almost all initially preferred the old mascot before they were
talked out of it.). And then you wore them down. Keep asking the same
question again and again and I guess over time people stop caring.

Its all just silliness really. Why the foundation got involved in this
mascot business to begin with and didn't just leave it to the
individual projects.

And again. Not a great time to be talking about any of this. My sense
of urgency is largely based on the fact that Emilien sent out an
official team stance on this. I wasn't part of that... so apologies for
being late to this conversation.

Dan 



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

Re: [openstack-dev] [tripleo] Fwd: TripleO mascot - how can I help your team?

[Jeremy Stanley]

On 2017-02-16 14:09:53 -0500 (-0500), Dan Prince wrote:
[...]
> This isn't about aligning anything. It is about artistic control. The
> foundation wants to have icons their way playing the "community card"
> to make those who had icons they like conform. It is clear you buy into
> this.
> 
> Each team will have its own mascot anyway so does it really matter if
> there is some deviation in the mix? I think not. We have a mascot we
> like. It even fits the general requirements for OpenStack mascots so
> all we are arguing about here is artistic style really. I say let the
> developers have some leverage in this category... what is the harm
> really?
[...]

You're really reading far too much conspiracy into this. Keep in
mind that this was coming from the foundation's marketing team, and
while they've been very eager to interface with the community on
this effort they may have failed to some degree in explaining their
reasons (which as we all know leaves a vacuum where conspiracy
theories proliferate).

As I understand things there are some pages on the
foundation-controlled www.openstack.org site where they want to
refer to various projects/teams and having a set of icons
representing them was a desire of the designers for that site, to
make it more navigable and easier to digest. They place significant
importance on consistency and aesthetics, and while that doesn't
necessarily match my personal utilitarian nature I can at least
understand their position on the matter. Rather than just words or
meaningless symbols as icons they thought it would be compelling to
base those icons on mascots, but to maintain the aesthetic of the
site the specific renderings needed to follow some basic guidelines.
They could have picked mascots at random out of the aether to use
there, but instead wanted to solicit input from the teams whose work
these would represent so that they might have some additional
special meaning to the community at large.

As I said earlier in the thread, if you have existing art you like
then use that in your documentation, in the wiki, on team tee-shirts
you make, et cetera. The goal is not to take those away. This is a
simple need for the marketing team and foundation Web site designers
to have art they can use for their own purposes which meets their
relatively strict design aesthetics... and if that art is also
something the community wants to use, then all the better but it's
in no way mandatory. The foundation has no direct control over
community members' choices here, nor have they attempted to pretend
otherwise that I've seen.
-- 
Jeremy Stanley

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

[openstack-dev] [release] Release countdown for Ocata Final Release Week, 20-24 Feb

[Doug Hellmann]

Focus
-

The release team will tag the final releases for all milestone-based
projects on 22 February to coincide with the press release distributed
by the Foundation marketing staff.

Release Tasks
-

Liaisons for milestone-based projects should review the set of
unreleased commits from http://paste.openstack.org/show/599304/ and
decide if your project needs a second release candidate today. We
will not be releasing any more candidates after tomorrow except in
the case of serious bugs in the most recent candidates for a project.
Any unreleased patches can then go out in a patch update the week
after the PTG.

PTLs serving for the Pike cycle should review core team membership
and consider removing inactive members. Now is also a good time to
start recruiting new core reviewers, especially during the PTG
discussions.

When the patch with final release versions for the milestone projects
is prepared by the release team, PTLs and liaisons should review
it.

The release team will be meeting on Monday and Tuesday afternoon
at the PTG. Liaisons are welcome to attend and give feedback about
this cycle and future plans. See
https://etherpad.openstack.org/p/relmgt-stable-requirements-ptg-pike for
details.

Important Dates
---

Ocata Final Release: 22 Feb

Ocata release schedule: http://releases.openstack.org/ocata/schedule.html

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

Re: [openstack-dev] [keystone] PTG schedule

[Lance Bragstad]

Based on early feedback I've broken up our first session, which is
dedicated to reviewing things not addressed in Ocata [0], into three
different sessions. I'm hoping this will help us commit enough time to
finding resolutions for each topic, versus cramming it all into 40 minutes.

Keep the feedback coming. Thanks!


[0] https://etherpad.openstack.org/p/pike-ptg-keystone-ocata-carry-over

On Wed, Feb 15, 2017 at 10:24 PM, Lance Bragstad 
wrote:

> Hi all,
>
> I tried to get most of our things shuffled around into some-what of a
> schedule [0]. Everything that was on the list was eventually refactored
> into the agenda.
>
> I've broken the various topics out into their own etherpads and linked
> them back to the main schedule. We should have the freedom to move things
> around as we see fit. The only exceptions are the sessions that we've
> already scheduled with other projects (cross-project policy, cross-project
> federation, or our joint session with horizon). Moving them might be tough
> since we've worked it around schedules from other projects and we've made
> the room reservation [1].
>
> I assume we'll need to make some adjustments before the end of the week.
> If you see anything that conflicts with another session, please let me know.
>
> Thanks!
>
> [0] https://etherpad.openstack.org/p/keystone-pike-ptg
> [1] https://ethercalc.openstack.org/Pike-PTG-Discussion-Rooms
>
__
OpenStack Development Mailing 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] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

[Tim Bell]

On 16 Feb 2017, at 19:42, Fox, Kevin M 
> wrote:

+1. The assumption was market forces will cause the best OpenStack deployment 
tools to win. But the sad reality is, market forces are causing people to look 
for non OpenStack solutions instead as the pain is still too high.

While k8s has a few different deployment tools currently, they are focused on 
getting the small bit of underlying plumbing deployed. Then you use the common 
k8s itself to deploy the rest. Adding a dashboard, dns, ingress, sdn, other 
component is easy in that world.

IMO, OpenStack needs to do something similar. Standardize a small core and get 
that easily deployable, then make it easy to deploy/upgrade the rest of the big 
tent projects on top of that, not next to it as currently is being done.

Thanks,
Kevin

Unfortunately, the more operators and end users question the viability of a 
specific project, the less likely it is to be adopted.
It is a very very difficult discussion with an end user to explain that 
function X is no longer available because the latest OpenStack upgrade had to 
be done for security/functional/stability reasons and this project/function is 
not available.
The availability of a function may also have been one of the positives for the 
OpenStack selection so finding a release or two later that it is no longer in 
the portfolio is difficult.
The deprecation policy really helps so we can give a good notice but this 
assumes an equivalent function is available. For example, the built in Nova EC2 
to EC2 project was an example where we had enough notice to test the new 
solution in parallel and then move with minimum disruption.  Moving an entire 
data centre from Chef to Puppet or running a parallel toolchain, for example, 
has a high cost.
Given the massive functionality increase in other clouds, It will be tough to 
limit the OpenStack offering to the small core. However, expanding with 
unsustainable projects is also not attractive.
Tim


From: Joshua Harlow [harlo...@fastmail.com]
Sent: Thursday, February 16, 2017 10:24 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [chef] Making the Kitchen Great Again: A 
Retrospective on OpenStack & Chef

Alex Schultz wrote:
On Thu, Feb 16, 2017 at 9:12 AM, Ed 
Leafe>  wrote:
On Feb 16, 2017, at 10:07 AM, Doug 
Hellmann>  wrote:

When we signed off on the Big Tent changes we said competition
between projects was desirable, and that deployers and contributors
would make choices based on the work being done in those competing
projects. Basically, the market would decide on the "optimal"
solution. It's a hard message to hear, but that seems to be what
is happening.
This.

We got much better at adding new things to OpenStack. We need to get better at 
letting go of old things.

-- Ed Leafe




I agree that the market will dictate what continues to survive, but if
you're not careful you may be speeding up the decline as the end user
(deployer/operator/cloud consumer) will switch completely to something
else because it becomes to difficult to continue to consume via what
used to be there and no longer is.  I thought the whole point was to
not have vendor lock-in.  Honestly I think the focus is too much on
the development and not enough on the consumption of the development
output.  What are the point of all these features if no one can
actually consume them.


+1 to that.

I've been in the boat of development and consumption of it for my
*whole* journey in openstack land and I can say the product as a whole
seems 'underbaked' with regards to the way people consume the
development output. It seems we have focused on how to do the dev. stuff
nicely and a nice process there, but sort of forgotten about all that
being quite useless if no one can consume them (without going through
much pain or paying a vendor).

This has or has IMHO been a factor in why certain are companies (and the
people they support) are exiting openstack and just going elsewhere.

I personally don't believe fixing this is 'let the market forces' figure
it out for us (what a slow & horrible way to let this play out; I'd
almost rather go pull my fingernails out). I do believe it will require
making opinionated decisions which we have all never been very good at.

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

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

Re: [openstack-dev] [tripleo] tripleo-ui release job failure

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2017-02-16 18:47:48 +:
> On 2017-02-16 14:31:01 -0400 (-0400), Honza Pokorny wrote:
> > The included logs don't give me much to go on.  It fails with a pretty
> > generic timeout message.  I can't even determine if that happened during
> > "npm install" or after.
> > 
> > Is there any more information available on the source of the failure?
> [...]
> 
> The provider in which this job ran seems to be experiencing some
> acute network connectivity issues, which may have caused the `npm
> install` command there to hang indefinitely (at least until the job
> timeout was reached). We have temporarily disabled that provider in
> our CI system while they investigate the problem on their end, and I
> have since re-enqueued the tag ref for tripleo-ui 3.0.0 whose jobs
> appear to have run to completion this time:
> 
>  http://logs.openstack.org/45/452b4cb427a86e4b097b9711fb045a211b5e7039/release/tripleo-ui-nodejs6-npm-publish-tarball/9766f74/
>  >
> 
>  http://logs.openstack.org/45/452b4cb427a86e4b097b9711fb045a211b5e7039/release/tripleo-ui-npm-upload/e6b9438/
>  >
> 

Thanks, Jeremy!


__
OpenStack Development Mailing 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] Fwd: TripleO mascot - how can I help your team?

[Dan Prince]

On Thu, 2017-02-16 at 06:36 -0600, Monty Taylor wrote:
> On 02/15/2017 07:54 PM, Dan Prince wrote:
> > At the high level all of this sounds like a fine grand plan: "Help
> > projects create mascots" with a common theme. On the ground level I
> > can
> > tell you it feels a lot more like you are crushing the spirit of
> > creativity and motivation for some of us.
> 
> Haven't we had this argument on the tech side enough? Do we have to
> have
> it all over again just because there are some illustrators and
> foundation staff involved?
> 
> We KEEP deciding as a community that we value cohesion for OpenStack
> over individual projects having unlimited freedom to do whatever they
> heck they want. This is no different. There are now a set of
> logos/mascots that exist within a common visual language. Neat!
> 
> > What's in a mascot? I dunno. Call it a force of motivation. Call it
> > team building. In fact, one of the first things I did as PTL of
> > TripleO
> > was create a mascot for the project. Perhaps not officially... but
> > there was agreement among those in the project. And we liked the
> > little
> > guy. And he grew on us. And we even iterated on him a bit and made
> > him
> > better.
> 
> Yah - I hear that. But once again, if the project is "OpenStack" and
> not
> just TripleO - that's exactly what's going on here. And the project
> _is_
> OpenStack. That's what we're here to do, that's what we work on,
> that's
> what we are members of a Foundation to support. Not TripleO, not
> Infra,
> not Nova. This isn't the Oslo Foundation or the Ironic consortium.
> It's
> OpenStack.
> 
> That means, for exactly the reasons you list, that it's important.
> It's
> important to underscore and bolster the fact that we are One
> OpenStack.
> 
> > 
> > 
> > 6 months or so ago we were presented with a new owl from the
> > foundation... which had almost none of the same qualities as the
> > original. Many of us took a survey about that and provided
> > feedback,
> > but I haven't found anyone who was really happy with it. Consensus
> > was
> > we liked the originals. Sometimes sticking with your roots is a
> > good
> > thing.
> > 
> > I happened to be off yesterday but I was really discouraged to read
> > that the team is now convinced we have to adopt your version of the
> > owl: http://eavesdrop.openstack.org/meetings/tripleo/2017/tripleo.2
> > 017-
> > 02-14-14.00.log.html
> > 
> > This all sounds like we are being "steamrolled" into using the new
> > owl
> > because things have to align. I'm not asking that you use our owl
> > on
> > your website. But if you want to... then great. I think it is
> > possible
> > to show that things work together without forcing them all to have
> > the
> > same mascot styles:
> >  https://www.linuxfoundation.org/about
> 
> Except that we are not the linux foundation. The linux foundation IS
> a
> loose confederation of unrelated projects that happen to share a
> legal
> parent entity. The LF does great work on behalf of those projects -
> but
> that is not what we are.
> 

I missed that you replied down here as well so take two...

The point there was it is entirely possible to make graphs that show
how things work together with differently themed Mascots. The
foundation doesn't have to force recommend that projects adhere to a
strict styling guide.

> > But I do think the OpenStack Foundation has overstated its case
> > here
> > and should reverse track a bit. Make it *clear* that projects can
> > keep
> > their own version of their mascots. In fact I think the foundation
> > should encourage them to do so (keep the originals). The opposite
> > seems
> > be happening on several projects like TripleO and Ironic.
> > 
> > P.S. vintage TripleO owl "beany babies" would be super cool
> 
> Totally. Make a vintage beanine - that's an awesome idea. I'd wear
> one.
> I've been considering trying to figure out how to make another "What
> the
> F**k is OpenStack?" shirt because mine is dying. The past is cool.
> But
> Dopenstack isn't the present - and honestly that's a good thing. So
> keep
> a sense of nostalgia for the old owl ... but I do NOT think the
> foundation should 'encourage' projects to 'keep' their originals. The
> foundation is expressing that they cannot FORCE a project to do
> anything
> - they do not have that power. But maybe alignment is a thing that
> can
> happen without anyone forcing anyone else to do it?
> 
> It IS important for things to align. It IS important that we have a
> sense of cohesion. Literally 100% of the cases where team
> individuality
> has been placed over membership in the larger effort of OpenStack
> have
> wound up being the source of discord and strife.

From a high level you are overstating the importance of artistic
alignment.  Alignment on technical and artistic fronts are very
different things. I don't buy that we all need to wear the same t-shirt 
styles to be part of the larger OpenStack project. I mean what is next?
Are we all 

Re: [openstack-dev] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

[Sylvain Bauza]

Le 16/02/2017 18:42, Alex Schultz a écrit :
> On Thu, Feb 16, 2017 at 9:12 AM, Ed Leafe  wrote:
>> On Feb 16, 2017, at 10:07 AM, Doug Hellmann  wrote:
>>
>>> When we signed off on the Big Tent changes we said competition
>>> between projects was desirable, and that deployers and contributors
>>> would make choices based on the work being done in those competing
>>> projects. Basically, the market would decide on the "optimal"
>>> solution. It's a hard message to hear, but that seems to be what
>>> is happening.
>>
>> This.
>>
>> We got much better at adding new things to OpenStack. We need to get better 
>> at letting go of old things.
>>
>> -- Ed Leafe
>>
>>
>>
> 
> I agree that the market will dictate what continues to survive, but if
> you're not careful you may be speeding up the decline as the end user
> (deployer/operator/cloud consumer) will switch completely to something
> else because it becomes to difficult to continue to consume via what
> used to be there and no longer is.  I thought the whole point was to
> not have vendor lock-in.  Honestly I think the focus is too much on
> the development and not enough on the consumption of the development
> output.  What are the point of all these features if no one can
> actually consume them.
> 

IMHO, I think the crux of the matter has been discussed previously and
said: it's how having collaboration between projects.

Noone can be seasoned by boiling the OpenStack ocean. It's wide, and you
need to build a boat.


That boat can be by having liaisons between deployment and service
projects. Or, by having influence within those projects - mutually.

Putting the burden on one side doesn't solve the problem. Rather, I'd by
far prefer to see communication at design stages (like for example
during the PTG).

-Sylvain


> 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 Development Mailing 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] Fwd: TripleO mascot - how can I help your team?

[Giulio Fidente]

On 02/16/2017 07:25 PM, Heidi Joy Tretheway wrote:
> Amid the spirited discussion on your mascot, I wanted to clear up confusion 
> about our next steps and your options. 
> 
> 1. I’ve taken Carlos’s sketches to our illustration team to ask them to make 
> the original TripleO owl in the style of the new logo family. This takes a 
> bit of time and probably won’t be ready before the PTG, but I'll send it to 
> Emilien (as I have been communicating directly with PTLs) as soon as it’s 
> ready, to share with the team. 
> 
> 2. At that point, your team can review and decide either (1) yes - adopt it, 
> (2) request slight changes, or (3) decline to use a new mascot. 
> 
> If your team picks #1, you’ll get the logo in about 10 variations 
> (horizontal, vertical, vector, etc).
> 
> If your team picks #2, I need one person (for most teams, this has been the 
> PTL) or a small group who will be willing to represent TripleO’s preference, 
> and chat with me for a few minutes to nail down exactly what needs to be 
> changed. We get a lot of conflicting feedback, so if your team doesn’t have 
> one person to help me select which feedback to use, then I end up doing it 
> (and that makes nobody happy). 
> 
> If your team picks #3, then on things like the project navigator, you’ll just 
> see an empty space (represented by a light gray circle) above the word 
> “TripleO” where the mascot creature would have been, while the other five to 
> eight projects on the page will have their mascot illustration shown. On 
> signage or places where we need to print a logo, your team name will be 
> printed without any illustration. You can keep using your old logo on 
> whatever you print/create, but it won’t appear on official channels. 
> 
> Thanks for your passion for this project!

Heidi, thank you.

Can I ask you to also share what are the requirements/goals around the
new logo? That would help me understand *why* and *what* has been
changed in the original logo and, hopefully, facilitate the happy ending! ;)
-- 
Giulio Fidente
GPG KEY: 08D733BA

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

Re: [openstack-dev] [tripleo] tripleo-ui release job failure

[Jeremy Stanley]

On 2017-02-16 14:31:01 -0400 (-0400), Honza Pokorny wrote:
> The included logs don't give me much to go on.  It fails with a pretty
> generic timeout message.  I can't even determine if that happened during
> "npm install" or after.
> 
> Is there any more information available on the source of the failure?
[...]

The provider in which this job ran seems to be experiencing some
acute network connectivity issues, which may have caused the `npm
install` command there to hang indefinitely (at least until the job
timeout was reached). We have temporarily disabled that provider in
our CI system while they investigate the problem on their end, and I
have since re-enqueued the tag ref for tripleo-ui 3.0.0 whose jobs
appear to have run to completion this time:

http://logs.openstack.org/45/452b4cb427a86e4b097b9711fb045a211b5e7039/release/tripleo-ui-nodejs6-npm-publish-tarball/9766f74/
 >

http://logs.openstack.org/45/452b4cb427a86e4b097b9711fb045a211b5e7039/release/tripleo-ui-npm-upload/e6b9438/
 >

-- 
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] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

[Fox, Kevin M]

+1. The assumption was market forces will cause the best OpenStack deployment 
tools to win. But the sad reality is, market forces are causing people to look 
for non OpenStack solutions instead as the pain is still too high.

While k8s has a few different deployment tools currently, they are focused on 
getting the small bit of underlying plumbing deployed. Then you use the common 
k8s itself to deploy the rest. Adding a dashboard, dns, ingress, sdn, other 
component is easy in that world.

IMO, OpenStack needs to do something similar. Standardize a small core and get 
that easily deployable, then make it easy to deploy/upgrade the rest of the big 
tent projects on top of that, not next to it as currently is being done.

Thanks,
Kevin

From: Joshua Harlow [harlo...@fastmail.com]
Sent: Thursday, February 16, 2017 10:24 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [chef] Making the Kitchen Great Again: A 
Retrospective on OpenStack & Chef

Alex Schultz wrote:
> On Thu, Feb 16, 2017 at 9:12 AM, Ed Leafe  wrote:
>> On Feb 16, 2017, at 10:07 AM, Doug Hellmann  wrote:
>>
>>> When we signed off on the Big Tent changes we said competition
>>> between projects was desirable, and that deployers and contributors
>>> would make choices based on the work being done in those competing
>>> projects. Basically, the market would decide on the "optimal"
>>> solution. It's a hard message to hear, but that seems to be what
>>> is happening.
>> This.
>>
>> We got much better at adding new things to OpenStack. We need to get better 
>> at letting go of old things.
>>
>> -- Ed Leafe
>>
>>
>>
>
> I agree that the market will dictate what continues to survive, but if
> you're not careful you may be speeding up the decline as the end user
> (deployer/operator/cloud consumer) will switch completely to something
> else because it becomes to difficult to continue to consume via what
> used to be there and no longer is.  I thought the whole point was to
> not have vendor lock-in.  Honestly I think the focus is too much on
> the development and not enough on the consumption of the development
> output.  What are the point of all these features if no one can
> actually consume them.
>

+1 to that.

I've been in the boat of development and consumption of it for my
*whole* journey in openstack land and I can say the product as a whole
seems 'underbaked' with regards to the way people consume the
development output. It seems we have focused on how to do the dev. stuff
nicely and a nice process there, but sort of forgotten about all that
being quite useless if no one can consume them (without going through
much pain or paying a vendor).

This has or has IMHO been a factor in why certain are companies (and the
people they support) are exiting openstack and just going elsewhere.

I personally don't believe fixing this is 'let the market forces' figure
it out for us (what a slow & horrible way to let this play out; I'd
almost rather go pull my fingernails out). I do believe it will require
making opinionated decisions which we have all never been very good at.

__
OpenStack Development Mailing 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] tripleo-ui release job failure

[Honza Pokorny]

The included logs don't give me much to go on.  It fails with a pretty
generic timeout message.  I can't even determine if that happened during
"npm install" or after.

Is there any more information available on the source of the failure?

Thanks

Honza Pokorny

On 2017-02-16 12:43, Doug Hellmann wrote:
> The job to build the npm package for tripleo-ui has failed.
> 
> Doug
> 
> --- Begin forwarded message from jenkins ---
> From: jenkins 
> To: release-job-failures 
> Date: Thu, 16 Feb 2017 16:51:50 +
> Subject: [Release-job-failures] Release of openstack/tripleo-ui failed
> 
> Build failed.
> 
> - tripleo-ui-nodejs6-npm-publish-tarball 
> http://logs.openstack.org/45/452b4cb427a86e4b097b9711fb045a211b5e7039/release/tripleo-ui-nodejs6-npm-publish-tarball/6ec2420/
>  : FAILURE in 35m 53s
> - tripleo-ui-npm-upload tripleo-ui-npm-upload : SKIPPED
> 
> --- End forwarded message ---
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [tripleo] Fwd: TripleO mascot - how can I help your team?

[Heidi Joy Tretheway]

Amid the spirited discussion on your mascot, I wanted to clear up confusion 
about our next steps and your options. 

1. I’ve taken Carlos’s sketches to our illustration team to ask them to make 
the original TripleO owl in the style of the new logo family. This takes a bit 
of time and probably won’t be ready before the PTG, but I'll send it to Emilien 
(as I have been communicating directly with PTLs) as soon as it’s ready, to 
share with the team. 

2. At that point, your team can review and decide either (1) yes - adopt it, 
(2) request slight changes, or (3) decline to use a new mascot. 

If your team picks #1, you’ll get the logo in about 10 variations (horizontal, 
vertical, vector, etc).

If your team picks #2, I need one person (for most teams, this has been the 
PTL) or a small group who will be willing to represent TripleO’s preference, 
and chat with me for a few minutes to nail down exactly what needs to be 
changed. We get a lot of conflicting feedback, so if your team doesn’t have one 
person to help me select which feedback to use, then I end up doing it (and 
that makes nobody happy). 

If your team picks #3, then on things like the project navigator, you’ll just 
see an empty space (represented by a light gray circle) above the word 
“TripleO” where the mascot creature would have been, while the other five to 
eight projects on the page will have their mascot illustration shown. On 
signage or places where we need to print a logo, your team name will be printed 
without any illustration. You can keep using your old logo on whatever you 
print/create, but it won’t appear on official channels. 

Thanks for your passion for this project!
__
OpenStack Development Mailing 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] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

[Joshua Harlow]

Alex Schultz wrote:

On Thu, Feb 16, 2017 at 9:12 AM, Ed Leafe  wrote:

On Feb 16, 2017, at 10:07 AM, Doug Hellmann  wrote:


When we signed off on the Big Tent changes we said competition
between projects was desirable, and that deployers and contributors
would make choices based on the work being done in those competing
projects. Basically, the market would decide on the "optimal"
solution. It's a hard message to hear, but that seems to be what
is happening.

This.

We got much better at adding new things to OpenStack. We need to get better at 
letting go of old things.

-- Ed Leafe





I agree that the market will dictate what continues to survive, but if
you're not careful you may be speeding up the decline as the end user
(deployer/operator/cloud consumer) will switch completely to something
else because it becomes to difficult to continue to consume via what
used to be there and no longer is.  I thought the whole point was to
not have vendor lock-in.  Honestly I think the focus is too much on
the development and not enough on the consumption of the development
output.  What are the point of all these features if no one can
actually consume them.



+1 to that.

I've been in the boat of development and consumption of it for my 
*whole* journey in openstack land and I can say the product as a whole 
seems 'underbaked' with regards to the way people consume the 
development output. It seems we have focused on how to do the dev. stuff 
nicely and a nice process there, but sort of forgotten about all that 
being quite useless if no one can consume them (without going through 
much pain or paying a vendor).


This has or has IMHO been a factor in why certain are companies (and the 
people they support) are exiting openstack and just going elsewhere.


I personally don't believe fixing this is 'let the market forces' figure 
it out for us (what a slow & horrible way to let this play out; I'd 
almost rather go pull my fingernails out). I do believe it will require 
making opinionated decisions which we have all never been very good at.


__
OpenStack Development Mailing 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] [horizon] [keystone] Cross-Project Meeting

[Rob Cresswell]

Hey everyone,

Quick reminder about the Keystone-Horizon meeting at 2000 UTC (about 1h45 from 
this email being sent). You can see the details and add it to your calendar via 
http://eavesdrop.openstack.org/#Keystone/Horizon_Collaboration_Meeting

I'd like to keep up these meetings for the foreseeable future, as they were 
really useful in solving some complex long standing issues in Horizon.

There will also be a Keystone/Horizon cross project session at the PTG; 
Wednesday at 2:30 - 3:20 in Savannah. The details are listed on the Keystone 
PTG etherpad (https://etherpad.openstack.org/p/keystone-pike-ptg) in case this 
changes.

Rob
__
OpenStack Development Mailing 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] Do we need service types at all?! (Re: [octavia][sdk] service name for octavia)

[Monty Taylor]

On 02/16/2017 11:21 AM, Jay Pipes wrote:
> On 02/16/2017 08:14 AM, Dean Troyer wrote:
>> On Thu, Feb 16, 2017 at 7:06 AM, Andrey Kurilin
>>  wrote:
>>> Yes, I forgot about it. But it changes nothing.
>>> Custom implementation of particular service should cover the same API
>>> as an
>>> official one. For me, as for user, it doesn't metter if there is
>>> Keystone or
>>> MyAwesomeKeystone, I want just an service which implements Keystone
>>> functionality.
>>
>> Actually it is the name field that we really do not need, nor want.
> 
> Yes, +100 to this.
> 
>> Its continued existence is mostly driven by a desire by deployers to
>> brand their services, nothing should currently be using to as a
>> selector.
> 
> Not sure that the name vs. type thing is actually driven by a deployer
> desire for branding. More likely it's just a vestige of a time when
> project developers didn't care or know all that much about the
> difference between type and name and just put whatever they thought made
> sense.
> 
>>  The type field is what (should be) used in places like the
>> base URL for services under a combined endpoint (ie,
>> host/compute/v2.1/...) on a single port.
> 
> 100% agree.

+1 billion to all of this.


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

[openstack-dev] [tripleo] tripleo-ui release job failure

[Doug Hellmann]

The job to build the npm package for tripleo-ui has failed.

Doug

--- Begin forwarded message from jenkins ---
From: jenkins 
To: release-job-failures 
Date: Thu, 16 Feb 2017 16:51:50 +
Subject: [Release-job-failures] Release of openstack/tripleo-ui failed

Build failed.

- tripleo-ui-nodejs6-npm-publish-tarball 
http://logs.openstack.org/45/452b4cb427a86e4b097b9711fb045a211b5e7039/release/tripleo-ui-nodejs6-npm-publish-tarball/6ec2420/
 : FAILURE in 35m 53s
- tripleo-ui-npm-upload tripleo-ui-npm-upload : SKIPPED

--- End forwarded message ---

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

Re: [openstack-dev] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

[Alex Schultz]

On Thu, Feb 16, 2017 at 9:12 AM, Ed Leafe  wrote:
> On Feb 16, 2017, at 10:07 AM, Doug Hellmann  wrote:
>
>> When we signed off on the Big Tent changes we said competition
>> between projects was desirable, and that deployers and contributors
>> would make choices based on the work being done in those competing
>> projects. Basically, the market would decide on the "optimal"
>> solution. It's a hard message to hear, but that seems to be what
>> is happening.
>
> This.
>
> We got much better at adding new things to OpenStack. We need to get better 
> at letting go of old things.
>
> -- Ed Leafe
>
>
>

I agree that the market will dictate what continues to survive, but if
you're not careful you may be speeding up the decline as the end user
(deployer/operator/cloud consumer) will switch completely to something
else because it becomes to difficult to continue to consume via what
used to be there and no longer is.  I thought the whole point was to
not have vendor lock-in.  Honestly I think the focus is too much on
the development and not enough on the consumption of the development
output.  What are the point of all these features if no one can
actually consume them.

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 Development Mailing 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?

[Dan Prince]

Nice work on the packages Thomas. I've always admired that you got the
Debian packages upstream first :).

Best wishes.

Dan


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.
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [all] Do we need service types at all?! (Re: [octavia][sdk] service name for octavia)

[Jay Pipes]

On 02/16/2017 08:14 AM, Dean Troyer wrote:

On Thu, Feb 16, 2017 at 7:06 AM, Andrey Kurilin  wrote:

Yes, I forgot about it. But it changes nothing.
Custom implementation of particular service should cover the same API as an
official one. For me, as for user, it doesn't metter if there is Keystone or
MyAwesomeKeystone, I want just an service which implements Keystone
functionality.


Actually it is the name field that we really do not need, nor want.


Yes, +100 to this.


Its continued existence is mostly driven by a desire by deployers to
brand their services, nothing should currently be using to as a
selector.


Not sure that the name vs. type thing is actually driven by a deployer 
desire for branding. More likely it's just a vestige of a time when 
project developers didn't care or know all that much about the 
difference between type and name and just put whatever they thought made 
sense.


>  The type field is what (should be) used in places like the

base URL for services under a combined endpoint (ie,
host/compute/v2.1/...) on a single port.


100% agree.

Best,
-jay

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

[openstack-dev] Related to neutron big switch plugin configuration through devstack

[Ruchi Mehta]

Hello,

I am successfully installing devstack in my Ubuntu 16.04 64bit server
system. In that neutron configured only ml2 plugin but  I have to configure
big switch plugin because I am working on Floodlight SDN controller in that
they required big switch plugin for connecting with OpenStack so how to
change configuration file for changing neutron plugin from ml2 to big
switch plugin?
Please solve my this query.

Thanks & Regards;
Ruchi Mehta
M.tech Student (CSE)
__
OpenStack Development Mailing 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] Subject: [all][api] POST /api-wg/news

[Chris Dent]

Greetings OpenStack community,

This week we talked quite a bit about what the API-WG will be trying to do next 
week at the PTG. We'll be sharing time and space with the Architecture working 
group, with rooms on both Monday and Tuesday of the cross-project period of the 
week. Topics are being planned on an etherpad [0], with some discussion there 
on which day will have which topics. This is going to be difficult to manage 
the day of as there will be lots of overlap of topics for interested parties. 
We'll try to provide information in the room as things happen and also make 
regular announcements to the #openstack-ptg IRC channel.

The other primary topic was the ongoing discussion surrounding the API 
compatibility and stability guideline [4]. We're nearly there, with mostly 
details to work out. There was agreement that the guideline, with its assertion 
that versioning is a requirement for the new stability tag will set a high bar 
for projects and this is OK.

One reminder: Projects should make sure that their liaison information is up to 
date at http://specs.openstack.org/openstack/api-wg/liaisons.html . If not, 
please provide a patch to doc/source/liaisons.json to update it.

Because of the PTG there will be no API-WG meeting next week. We'll resume on 
March 2nd.

# Newly Published Guidelines

* Add guidelines for boolean names
  https://review.openstack.org/#/c/411529/

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community. Nothing at 
the moment, but feel free to get in early on the reviews below.

# Guidelines Currently Under Review [3]

* Define pagination guidelines
  https://review.openstack.org/#/c/390973/

* Add API capabilities discovery guideline
  https://review.openstack.org/#/c/386555/

* Refactor and re-validate api change guidelines
  https://review.openstack.org/#/c/421846/

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your concerns in 
an email to the OpenStack developer mailing list[1] with the tag "[api]" in the 
subject. In your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[0] https://etherpad.openstack.org/p/ptg-architecture-workgroup
[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://review.openstack.org/#/c/421846/

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

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

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

[Clint Byrum]

Excerpts from Thomas Goirand's message of 2017-02-15 13:43:46 +0100:
> 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).
> 

Thomas, thanks for all your hard work. I hope you can return to it soon
and that this serves as a notice that we need more investment to keep
OpenStack viable in Debian and Ubuntu.

Can I propose that we start to move some of the libraries and things
like OpenStack Client into DPMT/DPAT?  They don't require constant
attention, and it will be helpful to have a larger team assisting in
the packaging where it doesn't require anything OpenStack specific to
keep moving forward.

__
OpenStack Development Mailing 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] Fwd: TripleO mascot - how can I help your team?

[Dan Prince]

On Thu, 2017-02-16 at 08:36 -0500, Emilien Macchi wrote:
> I'll shamelessly cross-post here, I didn't know where to reply.
> I agree with Monty and Flavio here.
> 
> Heidi has been doing an excellent job in helping OpenStack community
> about $topic, always in the open, which has been very appreciated.
> 
> We, as a team, have agreed on re-iterating on a new proposal to find
> a
> new logo that meets both TripleO devs taste and OpenStack community
> needs. That's how we work together.
> Unfortunately, this choice won't satisfy everyone and that's fine,
> that's how Open Source works I guess.

I don't think I see team agreement here. Was the IRC meeting last
Tuesday what we are using as a basis for this agreement. Not everyone
was present I think... also I think people are quite busy right now
with the upcoming release to be focusing on this discussion right now.

Wouldn't it be wise to postpone this a bit and gather a larger sampling
of the team feelings before making a consolidated statement like this?
Also, before committing to using any option wouldn't it be good to
actually see it first?

Dan

> 
> So the next steps are clear: let's work with Heidi and her team to
> find the best logo for TripleO, and let's all have a Gin Tonic in
> Atlanta.
> 
> And folks, that's a logo, I think we'll all survive.
> Peace.
> 
> On Thu, Feb 16, 2017 at 7:51 AM, Flavio Percoco 
> wrote:
> > On 13/02/17 21:38 -0500, Emilien Macchi wrote:
> > > 
> > > Team, I've got this email from Heidi.
> > > 
> > > I see 3 options :
> > > 
> > > 1. Keep existing logo: http://tripleo.org/_static/tripleo_owl.svg
> > >  .
> > > 
> > > 2. Re-design a new logo that "meets" OpenStack "requirements".
> > > 
> > > 3. Pick-up the one proposed (see below).
> > 
> > 
> > #3
> > 
> > Flavio
> > 
> > > 
> > > 
> > > Personally, I would vote for keeping our existing logo (1.)
> > > unless someone
> > > has time to create another one or if the team likes the proposed
> > > one.
> > > 
> > > The reason why I want to keep our logo is because our current
> > > logo was
> > > created by TripleO devs, we like it and we already have tee-
> > > shirts and
> > > other goodies with it. I don't see any good reason to change it.
> > > 
> > > Discussion is open and we'll vote as a team.
> > > 
> > > Thanks,
> > > 
> > > Emilien.
> > > 
> > > -- Forwarded message --
> > > From: Heidi Joy Tretheway 
> > > Date: Mon, Feb 13, 2017 at 8:27 PM
> > > Subject: TripleO mascot - how can I help your team?
> > > To: Emilien Macchi 
> > > 
> > > 
> > > Hi Emilien,
> > > 
> > > I’m following up on the much-debated TripleO logo. I’d like to
> > > help your
> > > team reach a solution that makes them happy but still fits within
> > > the
> > > family of logos we’re using at the PTG and going forward. Here’s
> > > what our
> > > illustrators came up with, which hides an “O” shape in the owl
> > > (face and
> > > wing arcs).
> > > 
> > > https://www.dropbox.com/sh/qz45miiiam3caiy/AAAzPGYEZRMGH6Otid3bLf
> > > HFa?dl=0
> > > At this point, I don’t have quorum from your team (I got a lot of
> > > conflicting feedback, most of which was “don’t like” but not
> > > actionable
> > > for
> > > the illustrators to make a revision). At the PTG, we’ll have
> > > mascot
> > > stickers and signage for all teams except for Ironic and TripleO,
> > > since
> > > we’re still waiting on your teams to make a final decision.
> > > 
> > > May I recommend that your team choose one person (or a small
> > > group of no
> > > more than three) to finalize this? I was able to work through all
> > > of
> > > Swift’s issues with just a quick 15-minute chat with John
> > > Dickinson and
> > > I’d
> > > like to believe we can solve this for TripleO as well.
> > > 
> > > We know some of your team has expressed concern over retiring the
> > > existing
> > > mascot. It’s not our intention to make anyone “get rid of” a
> > > beloved icon.
> > > Your team can certainly print it on vintage items like shirts and
> > > stickers.
> > > But for official channels like the website, we need a logo to
> > > represent
> > > TripleO that’s cohesive with the rest of the set.
> > > 
> > > Perhaps when you’re face to face with your team at the PTG, you
> > > can
> > > discuss
> > > and hopefully render a final decision to either accept this as a
> > > logo, or
> > > determine a few people willing to make any final changes with me?
> > > 
> > > Thanks in advance for your help!
> > > 
> > > 
> > > [image: photo]
> > > *Heidi Joy Tretheway*
> > > Senior Marketing Manager, OpenStack Foundation
> > > 503 816 9769 | Skype: heidi.tretheway
> > > 
> > >  > > e_id=5499768844845056=0.9726545857097719#>
> > > 
> > > 
> > >  
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > --
> > > Emilien Macchi
> > 
> > 

[openstack-dev] [designate] designate-dashboard 4.0.0.0rc2 (ocata)

[no-reply]

Hello everyone,

A new release candidate for designate-dashboard for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/designate-dashboard/

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

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


http://git.openstack.org/cgit/openstack/designate-dashboard/log/?h=stable/ocata

Release notes for designate-dashboard can be found at:

http://docs.openstack.org/releasenotes/designate-dashboard/



__
OpenStack Development Mailing 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] Some findings while profiling instances boot

[Davanum Srinivas]

Mike, Team,

Rolling the dice here:
https://review.openstack.org/#/c/435009/

Thanks,
Dims

On Thu, Feb 16, 2017 at 11:35 AM, Mike Bayer  wrote:
>
>
> On 02/15/2017 12:46 PM, Daniel Alvarez Sanchez wrote:
>>
>> Also, while having a look at server profiling, around the 33% of the
>> time was spent building SQL queries [1]. Mike Bayer went through this
>> and suggested having a look at baked queries and also submitted a sketch
>> of his proposal [2].
>
>
> Neutron relies heavily on a big JOIN query that returns just one row. In the
> profiling, it seemed like joined eager loading overhead is significant.
> Someone independently opened an upstream issue at
> https://bitbucket.org/zzzeek/sqlalchemy/issues/3915/performance-degradation-on-version-10xx#comment-34442856
> with similar comments.
>
> While the "baked" query thing is the ultimate hammer for "ORM SQL building"
> overhead, it's a very heavy hammer to swing as folks will note in the gerrit
> that shows roughly how it would look, it's involved and not that easy to
> work with.
>
> Fortunately, the joined eager load codepaths here have never been optimized
> for the "many short queries" use case, and a large portion of the overhead
> is all rolled up into some SQL alias objects that can be memoized so that
> most of the work they do happens once, instead of thousands of times.
>
> In https://gerrit.sqlalchemy.org/311  (note this is SQLAlchemy's gerrit, not
> openstack's) I have a patch that reduces the overhead associated
> specifically with joined eager loaded entities by around 270% for a
> worst-case scenario (which Neutron seems to be close to).  If those folks
> running the load tests can please try this revision out and see if it makes
> a dent, that would be helpful.
>
> Note that SQLAlchemy 1.1 has been out for about five months now, and it's
> time that Openstack move up to 1.1 series - that's where the performance
> enhancement will be.
>
>
>
>>
>> I wanted to share these findings with you (probably most of you knew but
>> I'm quite new to OpenStack so It's been a really nice exercise for me to
>> better understand how things work) and gather your feedback about how
>> things can be improved. Also, I'll be happy to share the results and
>> discuss further if you think it's worth during the PTG next week.
>>
>> Thanks a lot for reading and apologies for such a long email!
>>
>> Cheers,
>> Daniel
>> IRC: dalvarez
>>
>> [0] http://imgur.com/WQqaiYQ
>> [1] http://imgur.com/6KrfJUC
>> [2] https://review.openstack.org/430973
>>
>>
>> __
>> OpenStack Development Mailing 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



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

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

[openstack-dev] [tripleo] Ocata RC1 is out - RC2 is ongoing

[Emilien Macchi]

https://media.giphy.com/media/zyin7TYoGmLAs/giphy.gif

We released TripleO Ocata RC1 and created stable/ocata branch.

Details:
* instack 6.0.0 (final). We don't expect more work on this project
  before final release.
* instack-undercloud 6.0.0.0rc1.
* puppet-tripleo 6.2.0 which represents rc1 for us.
* tripleo-common 5.8.0 which represents rc1 for us.
* tripleo-heat-templates 6.0.0.0rc1.
* tripleo-image-elements 6.0.0.0rc1.
* tripleo-puppet-elements 6.0.0.0rc1.
* tripleo-quickstart 2.0.0 (final). We don't expect more work on
  this project before final release. Also, we don't want to branch
  it.
* tripleo-quickstart-extras 2.0.0 (final). We don't expect more
  work on this project before final release. Also, we don't want
  to branch it. Also, release notes will be added in Pike.
* tripleo-validations 5.4.0 which represents rc1 for us.
* tripleo-ui which represents rc1 for us.

>From now, bugfixes reported in Launchpad can be backported to stable/ocata.
Patches related to Composable Upgrades don't require Launchpad bugs
for now, until we provide RC2.

We target TripleO Ocata RC2 by end of next week if possible, otherwise
it will happen the week after PTG.

Congratulations team! We're almost there!
-- 
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] [Watcher] Nominating licanwei to Watcher Core

[Shedimbi, Prudhvi Rao]

+1




On 2/15/17, 10:00 PM, "Hidekazu Nakamura"  wrote:

>+1
>
>> -Original Message-
>> From: Spencer, Christopher M [mailto:christopher.m.spen...@intel.com]
>> Sent: Wednesday, February 15, 2017 11:36 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: Re: [openstack-dev] [Watcher] Nominating licanwei to Watcher Core
>> 
>> +1
>> 
>> 
>> 
>> From: Prashanth Hari 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Wednesday, February 15, 2017 at 5:01 AM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Subject: Re: [openstack-dev] [Watcher] Nominating licanwei to Watcher Core
>> 
>> 
>> 
>> +1
>> 
>> 
>> 
>> On Wed, Feb 15, 2017 at 6:27 AM, Antoine Cabot >  > wrote:
>> 
>>  +1
>> 
>> 
>> 
>>  On Tue, Feb 14, 2017 at 5:57 PM, Jean-Émile DARTOIS
>>  >
>> wrote:
>> 
>>  ​+1
>> 
>> 
>> 
>>  Jean-Emile
>>  DARTOIS
>> 
>> 
>> 
>> {P}
>> 
>> Software Engineer
>> Cloud Computing
>> 
>> {T}
>> 
>> +33 (0) 2 56 35 8260
>> 
>> {W}
>> 
>> www.b-com.com 
>> 
>> 
>> 
>> 
>> 
>>  De : Susanne Balle >  >
>>  Envoyé : mardi 14 février 2017 17:33
>>  À : OpenStack Development Mailing List (not for usage
>> questions)
>>  Objet : Re: [openstack-dev] [Watcher] Nominating licanwei
>> to Watcher Core
>> 
>> 
>> 
>>  +1
>> 
>> 
>> 
>>  On Tue, Feb 14, 2017 at 5:37 AM, Vincent FRANÇOISE
>>  >
>> wrote:
>> 
>>  -BEGIN PGP SIGNED MESSAGE-
>>  Hash: SHA1
>> 
>>  +1
>> 
>>  On 14/02/2017 11:27, ? ? wrote:
>>  > His activity will help Watcher Team to make this
>> project better.
>>  -BEGIN PGP SIGNATURE-
>>  Version: GnuPG v2.0.22 (GNU/Linux)
>> 
>> 
>>  iQEcBAEBAgAGBQJYot3aAAoJEEb+XENQ/jVSvIEH/RsqFZZ7hZyA7ExieF7K4G
>> mN
>> 
>>  d1f1vnPbOR3MgqQTbezixIPIwzrDw9dtpU6q8BRPARP6ja2tOPNoYHc1CZmxgw
>> z9
>> 
>>  Mc5iVhvAaKuzL7KKpeROVkLkVUJ9bZnxNM/pkgiq0qXYoBaitgVdPVTIE6nBLd
>> pV
>> 
>>  yHRkUG24pkojogIJGIbB2cJeKganJ+PrCB59buAof1NqEhujt00akfjHCKbc7W
>> c/
>> 
>>  oSmx2VD3aRn8OcfAhQ1pQgRYpa6MRFBRbDUPejVyiGzFWTDreWA3cLVq2xpGEc
>> CW
>> 
>>  ahcq2MNsZCiFegD4u9jYroULOALhdGBUctONbluaqbfZ7PhPPqQxSJGQq96hTC
>> g=
>>  =WsCi
>>  -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 Development Mailing 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] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

[Doug Hellmann]

Excerpts from Ian Cordasco's message of 2017-02-16 11:20:45 -0500:
> -Original Message-
> From: Ed Leafe 
> Reply: OpenStack Development Mailing List (not for usage questions)
> 
> Date: February 16, 2017 at 10:13:51
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject:  Re: [openstack-dev] [chef] Making the Kitchen Great Again: A
> Retrospective on OpenStack & Chef
> 
> > On Feb 16, 2017, at 10:07 AM, Doug Hellmann wrote:
> >
> > > When we signed off on the Big Tent changes we said competition
> > > between projects was desirable, and that deployers and contributors
> > > would make choices based on the work being done in those competing
> > > projects. Basically, the market would decide on the "optimal"
> > > solution. It's a hard message to hear, but that seems to be what
> > > is happening.
> >
> > This.
> >
> > We got much better at adding new things to OpenStack. We need to get better 
> > at letting go
> > of old things.
> 
> I agree with the idea of making it easier for new contributors from
> outside our walled garden of paid contributors. I won't further derail
> this thread with my opinions of how corporations will begin to exploit
> that and invest less directly in OpenStack's development though.

Influence comes with investment. The less someone contributes, the
less overall input they have into the direction. Entities that have
strong opinions about direction will still need to participate
consistently in order to convince other contributors to follow their
lead.

Doug

> 
> --
> Ian Cordasco
> 
> __
> OpenStack Development Mailing 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] Some findings while profiling instances boot

[Mike Bayer]

On 02/15/2017 12:46 PM, Daniel Alvarez Sanchez wrote:

Also, while having a look at server profiling, around the 33% of the
time was spent building SQL queries [1]. Mike Bayer went through this
and suggested having a look at baked queries and also submitted a sketch
of his proposal [2].


Neutron relies heavily on a big JOIN query that returns just one row. 
In the profiling, it seemed like joined eager loading overhead is 
significant.  Someone independently opened an upstream issue at 
https://bitbucket.org/zzzeek/sqlalchemy/issues/3915/performance-degradation-on-version-10xx#comment-34442856 
with similar comments.


While the "baked" query thing is the ultimate hammer for "ORM SQL 
building" overhead, it's a very heavy hammer to swing as folks will note 
in the gerrit that shows roughly how it would look, it's involved and 
not that easy to work with.


Fortunately, the joined eager load codepaths here have never been 
optimized for the "many short queries" use case, and a large portion of 
the overhead is all rolled up into some SQL alias objects that can be 
memoized so that most of the work they do happens once, instead of 
thousands of times.


In https://gerrit.sqlalchemy.org/311  (note this is SQLAlchemy's gerrit, 
not openstack's) I have a patch that reduces the overhead associated 
specifically with joined eager loaded entities by around 270% for a 
worst-case scenario (which Neutron seems to be close to).  If those 
folks running the load tests can please try this revision out and see if 
it makes a dent, that would be helpful.


Note that SQLAlchemy 1.1 has been out for about five months now, and 
it's time that Openstack move up to 1.1 series - that's where the 
performance enhancement will be.






I wanted to share these findings with you (probably most of you knew but
I'm quite new to OpenStack so It's been a really nice exercise for me to
better understand how things work) and gather your feedback about how
things can be improved. Also, I'll be happy to share the results and
discuss further if you think it's worth during the PTG next week.

Thanks a lot for reading and apologies for such a long email!

Cheers,
Daniel
IRC: dalvarez

[0] http://imgur.com/WQqaiYQ
[1] http://imgur.com/6KrfJUC
[2] https://review.openstack.org/430973


__
OpenStack Development Mailing 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] [nova] Final mascot logo

[Matt Riedemann]

Here are the final logos for the Nova mascot:

https://www.dropbox.com/sh/9l1c7ymyjgpa3cc/AAB9iPZ0HIwn16nzC7G5liuza?dl=0

There will be some stickers and other postings of this at the PTG.

--

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] [ironic][neutron] PTG cross team session

[Vasyl Saienko]

Hello Ironic/Neutron teams,


Ironic team would like to schedule cross session with Neutron team on Mon -
Tues except for Tue 9.30 - 10.00
The topics we would like to talk are added to:
https://etherpad.openstack.org/p/neutron-ptg-pike L151


Sincerely,
Vasyl Saienko
__
OpenStack Development Mailing 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] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

[Monty Taylor]

On 02/16/2017 10:23 AM, Ed Leafe wrote:
> On Feb 16, 2017, at 10:12 AM, Ed Leafe  wrote:
> 
>> We got much better at adding new things to OpenStack. We need to get better 
>> at letting go of old things.
> 
> On re-reading that, it doesn’t sound like what I intended. By “old” I mean 
> things that no longer have enough active support to keep them current. I have 
> nothing against old things, being one myself. :)

/me waves from the old-folks home


__
OpenStack Development Mailing 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] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

[Ed Leafe]

On Feb 16, 2017, at 10:12 AM, Ed Leafe  wrote:

> We got much better at adding new things to OpenStack. We need to get better 
> at letting go of old things.

On re-reading that, it doesn’t sound like what I intended. By “old” I mean 
things that no longer have enough active support to keep them current. I have 
nothing against old things, being one myself. :)


-- Ed Leafe


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

Re: [openstack-dev] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

[Ian Cordasco]

-Original Message-
From: Ed Leafe 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: February 16, 2017 at 10:13:51
To: OpenStack Development Mailing List (not for usage questions)

Subject:  Re: [openstack-dev] [chef] Making the Kitchen Great Again: A
Retrospective on OpenStack & Chef

> On Feb 16, 2017, at 10:07 AM, Doug Hellmann wrote:
>
> > When we signed off on the Big Tent changes we said competition
> > between projects was desirable, and that deployers and contributors
> > would make choices based on the work being done in those competing
> > projects. Basically, the market would decide on the "optimal"
> > solution. It's a hard message to hear, but that seems to be what
> > is happening.
>
> This.
>
> We got much better at adding new things to OpenStack. We need to get better 
> at letting go
> of old things.

I agree with the idea of making it easier for new contributors from
outside our walled garden of paid contributors. I won't further derail
this thread with my opinions of how corporations will begin to exploit
that and invest less directly in OpenStack's development though.

--
Ian Cordasco

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

Re: [openstack-dev] [Packaging-RPM] Nominating Alberto Planas Dominguez for Packaging-RPM core

[Dirk Müller]

Hi Igor,


2017-02-16 15:43 GMT+01:00 Igor Yozhikov :


> I’d like to nominate Alberto Planas Dominguez known as aplanas on irc for
> Packaging-RPM core.
> Alberto done a lot of reviews for as for project modules [1],[2] as for rest
> of OpenStack components [3]. His experience within OpenStack components and
> packaging are very appreciated.

+1

Greetings,
Dirk

__
OpenStack Development Mailing 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] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

[Ed Leafe]

On Feb 16, 2017, at 10:07 AM, Doug Hellmann  wrote:

> When we signed off on the Big Tent changes we said competition
> between projects was desirable, and that deployers and contributors
> would make choices based on the work being done in those competing
> projects. Basically, the market would decide on the "optimal"
> solution. It's a hard message to hear, but that seems to be what
> is happening.

This.

We got much better at adding new things to OpenStack. We need to get better at 
letting go of old things.

-- Ed Leafe






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

Re: [openstack-dev] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

[Doug Hellmann]

Excerpts from Dean Troyer's message of 2017-02-16 08:25:42 -0600:
> On Thu, Feb 16, 2017 at 7:54 AM, Ian Cordasco  wrote:
> > It seems like a lot of people view "developing OpenStack" as more
> > attractive than "making it easy to deploy OpenStack" (via the
> > deployment tools in the tent). Doing both is really something project
> > teams should do, but I don't think shoving all of the deployment
> > tooling in repo makes that any better frankly. If we put our tooling
> > in repo, we'll likely then start collecting RPM/Debian/etc. packaging
> > in repo as well.
> 
> Part of it _is_ the "deployment isn't shiny/new/features", but there
> is also the historical view lingering that we ship tarballs (and
> realistically, git repo tags) so as not to pick favorites and to keep
> deployment and packaging out of the project repos directly.
> 
> We have >5 different tools that are "mainstream" to consider, not even
> the large project teams have enough expertise to maintain those.  I
> had a hard enough time myself keeping both rpm and apt up to date in
> previous projects, much less recipies, playbooks and the odd shell
> script.
> 
> It is also hard to come in to a community and demand that other
> projects suddenly have to support your project just because you showed
> up.  (This works both ways, when we add a "Big Tent" project, now all
> of the downstreams are expected to suddenly add it.)
> 
> The solution I see is to have a mechanism by which important things
> can be communicated from the project developers that can be consumed
> by the packager/deployer community.  Today, however sub-optimal it
> seems to be, that is release notes.  Maybe adding a specific section
> for packaging would be helpful, but in practice that adds one more
> thing to remember to write to a list that is already hard to get devs
> to do.
> 
> Ad Doug mentions elsewhere in this thread, the liaison approach has
> worked in other areas, it may be a useful approach here.  But I know
> as the PTL of a very small project I do not want 5 more hats to wear.
> Maybe one.
> 
> We have encouraged the packaging groups to work together in the past,
> with mixed results, but it seems to me that a lot of the things that
> need to be discovered and learned in new releases will be similar for
> all of the downstream consumers.  Maybe if that downstream community
> could reach a critical mass and suggest a single common way to
> communicate the deployment considerations in a release it would get
> more traction.  And a single project liaison for the collective rather
> than one for each deployment project.

I like the idea of at least standardizing the communication. I agree, we
don't want 5+ new liaison responsibilities, especially for small teams.

> > I think what would help improve willing bidirectional communication
> > between service and deployment/packaging teams would be an
> > understanding that without the deployment/packaging teams, the service
> > teams will likely be out of a job. People will/can not deploy
> > OpenStack without the tooling these other teams provide.
> 
> True in a literal sense.  This is also true for our users, without
> them nobody will deploy a cloud in the first place.  That has not
> changed anything unfortunately, we still regularly give our users
> miserable experiences because it is too much effort to participate
> with the (now comatose) UX team or prioritize making a common log
> format or reduce the number of knobs available to twiddle to make each
> cloud a unique snowflake.
> 
> We can not sustain being all things to all people.  Given the
> contraction of investment being considered and implemented by many of
> our foundation member companies, we will have to make some hard
> decisions about where to spend the resources we have left.  Some of
> those decision are made for us by those member companies promoting
> their own priorities (your example of Ansible contributions is one).
> But as a community we have an opportunity to express our desires and
> potentially influence those decisions.

When we signed off on the Big Tent changes we said competition
between projects was desirable, and that deployers and contributors
would make choices based on the work being done in those competing
projects. Basically, the market would decide on the "optimal"
solution. It's a hard message to hear, but that seems to be what
is happening.

We also said that that cross-project efforts needed to decide what
amount of work they could manage themselves and then empower project
teams to take on the responsibility for everything else. We need
to build tools and write documentation to make it as easy as possible
to contribute, and then be OK with the state of the world if we
don't have 100% coverage of all projects with all deployment tools
or install guides or whatever else falls into that cross-project
category.  We want to have perfect parity everywhere, but everything
is evolving continuously, so 

Re: [openstack-dev] [tripleo] Fwd: TripleO mascot - how can I help your team?

[Marios Andreou]

On 14/02/17 04:38, Emilien Macchi wrote:
> Team, I've got this email from Heidi.
> 
> I see 3 options :
> 
> 1. Keep existing logo: http://tripleo.org/_static/tripleo_owl.svg .
> 
> 2. Re-design a new logo that "meets" OpenStack "requirements".
> 
> 3. Pick-up the one proposed (see below).

Option 1, and if we really can't then, option 2. Carlos has just posted
some nice examples... I mean it would be great if we could keep our owl
like he has (i.e. is it about the fonts whatever 'it' is?)

So I'm not even sure this vote counts anymore, I mean if foundation
simply cannot use our existing logo then it is a moot point.

Thanks to Heidi for working on the logos, and fwiw, if we didn't already
have a logo, the proposed one looks great. As others have commented, we
have t-shirts and stickers with the tripleo owl on it so for many in
this community there is a very strong association between that
particular image and this project

thanks, marios



> 
> 
> Personally, I would vote for keeping our existing logo (1.) unless someone
> has time to create another one or if the team likes the proposed one.
> 
> The reason why I want to keep our logo is because our current logo was
> created by TripleO devs, we like it and we already have tee-shirts and
> other goodies with it. I don't see any good reason to change it.
> 
> Discussion is open and we'll vote as a team.
> 
> Thanks,
> 
> Emilien.
> 
> -- Forwarded message --
> From: Heidi Joy Tretheway 
> Date: Mon, Feb 13, 2017 at 8:27 PM
> Subject: TripleO mascot - how can I help your team?
> To: Emilien Macchi 
> 
> 
> Hi Emilien,
> 
> I’m following up on the much-debated TripleO logo. I’d like to help your
> team reach a solution that makes them happy but still fits within the
> family of logos we’re using at the PTG and going forward. Here’s what our
> illustrators came up with, which hides an “O” shape in the owl (face and
> wing arcs).
> 
> https://www.dropbox.com/sh/qz45miiiam3caiy/AAAzPGYEZRMGH6Otid3bLfHFa?dl=0
> At this point, I don’t have quorum from your team (I got a lot of
> conflicting feedback, most of which was “don’t like” but not actionable for
> the illustrators to make a revision). At the PTG, we’ll have mascot
> stickers and signage for all teams except for Ironic and TripleO, since
> we’re still waiting on your teams to make a final decision.
> 
> May I recommend that your team choose one person (or a small group of no
> more than three) to finalize this? I was able to work through all of
> Swift’s issues with just a quick 15-minute chat with John Dickinson and I’d
> like to believe we can solve this for TripleO as well.
> 
> We know some of your team has expressed concern over retiring the existing
> mascot. It’s not our intention to make anyone “get rid of” a beloved icon.
> Your team can certainly print it on vintage items like shirts and stickers.
> But for official channels like the website, we need a logo to represent
> TripleO that’s cohesive with the rest of the set.
> 
> Perhaps when you’re face to face with your team at the PTG, you can discuss
> and hopefully render a final decision to either accept this as a logo, or
> determine a few people willing to make any final changes with me?
> 
> Thanks in advance for your help!
> 
> 
> [image: photo]
> *Heidi Joy Tretheway*
> Senior Marketing Manager, OpenStack Foundation
> 503 816 9769 | Skype: heidi.tretheway
> 
>   
>   
> 
> 
> 
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing 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

[Pradeep Singh]

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

[openstack-dev] [searchlight] searchlight-ui 2.0.0.0rc2 (ocata)

[no-reply]

Hello everyone,

A new release candidate for searchlight-ui for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/searchlight-ui/

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

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

http://git.openstack.org/cgit/openstack/searchlight-ui/log/?h=stable/ocata

Release notes for searchlight-ui can be found at:

http://docs.openstack.org/releasenotes/searchlight-ui/

If you find an issue that could be considered release-critical, please
file it at:

http://bugs.launchpad.net/searchlight

and tag it *ocata-rc-potential* to bring it to the searchlight-ui
release crew's attention.

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

Re: [openstack-dev] [Packaging-RPM] Nominating Alberto Planas Dominguez for Packaging-RPM core

[Javier Pena]

> +1
> 
> Welcome Alberto!
> 

+1 for me. Good reviews so far, it'll be great to have him as core.

Javier

> 
> On Thu, 2017-02-16 at 17:43 +0300, Igor Yozhikov wrote:
> > Hello team.
> > I want to announce the following changes to Packaging-RPM core team:
> > I’d like to nominate Alberto Planas Dominguez known as aplanas on irc
> > for Packaging-RPM core.
> > Alberto done a lot of reviews for as for project modules [1],[2] as
> > for rest of OpenStack components [3]. His experience within OpenStack
> > components and packaging are very appreciated.
> > 
> > 
> > [1] http://stackalytics.com/?metric=marks_type=all=pac
> > kaging-rpm-group_id=aplanas
> > [2] http://stackalytics.com/?metric=marks_type=all=pac
> > kaging-rpm-group
> > [3] http://stackalytics.com/?user_id=aplanas=marks
> > 
> > Packaging-RPM team please respond with +1/-1 to the proposed changes.
> > 
> > Thanks,
> > Igor Yozhikov
> > Senior Deployment Engineer
> > at Mirantis
> > skype: igor.yozhikov
> > cellular: +7 901 5331200
> > slack: iyozhikov
> > _
> > _
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> > cribe
> > 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] [searchlight] searchlight 2.0.0.0rc2 (ocata)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/searchlight/

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

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

http://git.openstack.org/cgit/openstack/searchlight/log/?h=stable/ocata

Release notes for searchlight can be found at:

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



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

Re: [openstack-dev] [Packaging-RPM] Nominating Alberto Planas Dominguez for Packaging-RPM core

[Thomas Bechtold]

+1

Welcome Alberto!


On Thu, 2017-02-16 at 17:43 +0300, Igor Yozhikov wrote:
> Hello team.
> I want to announce the following changes to Packaging-RPM core team:
> I’d like to nominate Alberto Planas Dominguez known as aplanas on irc
> for Packaging-RPM core.
> Alberto done a lot of reviews for as for project modules [1],[2] as
> for rest of OpenStack components [3]. His experience within OpenStack
> components and packaging are very appreciated.
> 
> 
> [1] http://stackalytics.com/?metric=marks_type=all=pac
> kaging-rpm-group_id=aplanas
> [2] http://stackalytics.com/?metric=marks_type=all=pac
> kaging-rpm-group
> [3] http://stackalytics.com/?user_id=aplanas=marks
> 
> Packaging-RPM team please respond with +1/-1 to the proposed changes.
> 
> Thanks,
> Igor Yozhikov
> Senior Deployment Engineer
> at Mirantis
> skype: igor.yozhikov
> cellular: +7 901 5331200
> slack: iyozhikov
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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] [ironic] New mascot design

[Loo, Ruby]

Hi Heidi,

I'm happy with the proposed logo.

As far as the "kiss" style face painting goes, I don't like it. But that is 
because I am not a fan of KISS or their music. Having said that, I can 
understand why people would like it and why it fits with ironic, so I am fine 
if it is used :)

Thank you for being so patient with us and going the extra kilometres!

--ruby

From: Lucas Alvares Gomes 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, February 16, 2017 at 5:44 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [ironic] New mascot design

Hi,

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.

I'm OK either way, but liked the "KISS" style face painting.


+1 the kiss star looks cool indeed.




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


Fair enough



—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'm OK with this. I think it'll be the closest we'll get to something everyone 
can agree on. +1 from me.


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 

Re: [openstack-dev] [Packaging-RPM] Nominating Alberto Planas Dominguez for Packaging-RPM core

[Haïkel]

2017-02-16 15:43 GMT+01:00 Igor Yozhikov :
> Hello team.
> I want to announce the following changes to Packaging-RPM core team:
> I’d like to nominate Alberto Planas Dominguez known as aplanas on irc for
> Packaging-RPM core.
> Alberto done a lot of reviews for as for project modules [1],[2] as for rest
> of OpenStack components [3]. His experience within OpenStack components and
> packaging are very appreciated.
>

+1
Alberto was nominated for the next cycle and I was and am still supporting this.

Regards,
H.

>
> [1]
> http://stackalytics.com/?metric=marks_type=all=packaging-rpm-group_id=aplanas
> [2]
> http://stackalytics.com/?metric=marks_type=all=packaging-rpm-group
> [3] http://stackalytics.com/?user_id=aplanas=marks
>
> Packaging-RPM team please respond with +1/-1 to the proposed changes.
>
> Thanks,
> Igor Yozhikov
> Senior Deployment Engineer
> at Mirantis
> skype: igor.yozhikov
> cellular: +7 901 5331200
> slack: iyozhikov
>
> __
> OpenStack Development Mailing 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] [telemetry] Triggering alarms on Swift notifications

[Denis Makogon]

Sorry for confusing. I just wanted to try to setup telemetry and try it
with Picasso(Serverless functions).

And your suggestion worked well. So i think it is worth opening issue
against Aodh and Ceilometer for implementing given option configuration
just Panko devstack plugin does.

Kind regards,
Denis Makogon

чт, 16 февр. 2017 г. в 15:54, Mehdi Abaakouk :

> On Thu, Feb 16, 2017 at 03:33:43PM +0200, Denis Makogon wrote:
> >Hello Mehdi. Thanks for response. See comments inline.
> >
> >2017-02-16 15:25 GMT+02:00 Mehdi Abaakouk :
> >
> >> Hi,
> >>
> >> On Thu, Feb 16, 2017 at 03:04:52PM +0200, Denis Makogon wrote:
> >>
> >>> Greetings.
> >>>
> >>> Could someone provide any guidelines for checking why alarm or
> ok-action
> >>> webhooks are not being executed. Is it possible to investigate an
> issue by
> >>> analyzing ceilometer and/or aodh logs?
> >>>
> >>> So, my devstack setup based on master branch with local.conf (see
> >>> https://gist.github.com/denismakogon/4d88bdbea4bf428e55e88d25d52735f6)
> >>>
> >>> Once devstack installed i'm checking if notifications are being emitted
> >>> while uploading files to Swift and i'm able to see events in Ceilometer
> >>> (see https://gist.github.com/denismakogon/c6ad75899dcc50ce2a9b9f6
> >>> a4e0612f7).
> >>>
> >>> After that i'm trying to setup Aodh event alarm (see
> >>> https://gist.github.com/denismakogon/f6449e71ba9bb04cdd0065b52918b5af)
> >>>
> >>> And that's where i'm stuck, while working with Swift i see
> notifications
> >>> are coming from ceilometermiddleware to Panko and available in
> Ceilometer
> >>> via event-list but no alarm being triggered in Aodh.
> >>>
> >>> So, could someone explain me what am i doing wrong or am i missing
> >>> something?
> >>>
> >>
> >> I think devstack plugins currently doesn't setup the Ceilometer stuffs
> to
> >> be able to use events in Aodh.
> >>
> >>
> >So, if i would drop off both Aodh and Panko from this setup it may appear
> >that issue will be solved somehow?
>
> I don't get it, I have thought your goal was to create alarm triggered on
> event. And for this you need Aodh and Ceilometer (not Panko).
>
> You have to do
> https://docs.openstack.org/developer/aodh/event-alarm.html#configuration
> manually to get events emitted by Ceilometer received by Aodh.
>
> >> Note that Aodh doesn't query Panko, but listen for event on alarm.all
> >> topic by
> >> default. I'm guessing the Ceilometer conf/pipeline have to be tweaked to
> >> send
> >> events to Aodh somehow.
> >>
> >
> >Yes, i know that, in this setup Ceilometer depends on Panko as event
> >source, is that right?
>
> No, Panko is for storage of event in a database (It's a API and a
> Ceilometer dispatcher plugin). Events are still built from notification
> by Ceilometer (agent-notification).
>
> Rephrase from Ceilometer point of view. Ceilometer send events to Aodh AND
> Panko.
>
> Regards,
>
> --
> Mehdi Abaakouk
> mail: sil...@sileht.net
> irc: sileht
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Mascot

[Christian Berendt]

> On 14 Feb 2017, at 17:27, Steven Dake (stdake)  wrote:
> 
> The mascot is absolutely fantastic!  Nice work to all involved!

Woot! Awesome!

-- 
Christian Berendt
Chief Executive Officer (CEO)

Mail: bere...@betacloud-solutions.de
Web: https://www.betacloud-solutions.de

Betacloud Solutions GmbH
Teckstrasse 62 / 70190 Stuttgart / Deutschland

Geschäftsführer: Christian Berendt
Unternehmenssitz: Stuttgart
Amtsgericht: Stuttgart, HRB 756139


__
OpenStack Development Mailing 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] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

[Ian Cordasco]

-Original Message-
From: Dean Troyer 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: February 16, 2017 at 08:27:12
To: OpenStack Development Mailing List (not for usage questions)

Subject:  Re: [openstack-dev] [chef] Making the Kitchen Great Again: A
Retrospective on OpenStack & Chef

> On Thu, Feb 16, 2017 at 7:54 AM, Ian Cordasco wrote:
> > It seems like a lot of people view "developing OpenStack" as more
> > attractive than "making it easy to deploy OpenStack" (via the
> > deployment tools in the tent). Doing both is really something project
> > teams should do, but I don't think shoving all of the deployment
> > tooling in repo makes that any better frankly. If we put our tooling
> > in repo, we'll likely then start collecting RPM/Debian/etc. packaging
> > in repo as well.
>
> Part of it _is_ the "deployment isn't shiny/new/features", but there
> is also the historical view lingering that we ship tarballs (and
> realistically, git repo tags) so as not to pick favorites and to keep
> deployment and packaging out of the project repos directly.

Right, I understand that.

> We have >5 different tools that are "mainstream" to consider, not even
> the large project teams have enough expertise to maintain those. I
> had a hard enough time myself keeping both rpm and apt up to date in
> previous projects, much less recipies, playbooks and the odd shell
> script.

Next week it'll be 7. ;)

> It is also hard to come in to a community and demand that other
> projects suddenly have to support your project just because you showed
> up. (This works both ways, when we add a "Big Tent" project, now all
> of the downstreams are expected to suddenly add it.)

Right. And we've seen teams like the UCA team be selective in what
they add (rightfully so).

> The solution I see is to have a mechanism by which important things
> can be communicated from the project developers that can be consumed
> by the packager/deployer community. Today, however sub-optimal it
> seems to be, that is release notes. Maybe adding a specific section
> for packaging would be helpful, but in practice that adds one more
> thing to remember to write to a list that is already hard to get devs
> to do.

I would think the mailing list (with a certain tag) might be better.

> Ad Doug mentions elsewhere in this thread, the liaison approach has
> worked in other areas, it may be a useful approach here. But I know
> as the PTL of a very small project I do not want 5 more hats to wear.
> Maybe one.

Right. And teams like Glance are struggling with their review queue
given the contraction you mention later on.

> We have encouraged the packaging groups to work together in the past,
> with mixed results, but it seems to me that a lot of the things that
> need to be discovered and learned in new releases will be similar for
> all of the downstream consumers. Maybe if that downstream community
> could reach a critical mass and suggest a single common way to
> communicate the deployment considerations in a release it would get
> more traction. And a single project liaison for the collective rather
> than one for each deployment project.

We also have packaging teams that repeatedly denegrate others who
create derivatives of their work while discouraging and denigration
others' participation. I think that coordination will be hard until
those packagers learn the hard lessons of their harmful actions.

> > I think what would help improve willing bidirectional communication
> > between service and deployment/packaging teams would be an
> > understanding that without the deployment/packaging teams, the service
> > teams will likely be out of a job. People will/can not deploy
> > OpenStack without the tooling these other teams provide.
>
> True in a literal sense. This is also true for our users, without
> them nobody will deploy a cloud in the first place. That has not
> changed anything unfortunately, we still regularly give our users
> miserable experiences because it is too much effort to participate
> with the (now comatose) UX team or prioritize making a common log
> format or reduce the number of knobs available to twiddle to make each
> cloud a unique snowflake.
>
> We can not sustain being all things to all people. Given the
> contraction of investment being considered and implemented by many of
> our foundation member companies, we will have to make some hard
> decisions about where to spend the resources we have left. Some of
> those decision are made for us by those member companies promoting
> their own priorities (your example of Ansible contributions is one).
> But as a community we have an opportunity to express our desires and
> potentially influence those decisions.

We are in nearly-violent agreement here. Perhaps given my own
cross-team focus (as a result of my own emmployer's interests) I am
biased in thinking that 

Re: [openstack-dev] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

[Monty Taylor]

On 02/16/2017 08:25 AM, Dean Troyer wrote:
> On Thu, Feb 16, 2017 at 7:54 AM, Ian Cordasco  wrote:
>> It seems like a lot of people view "developing OpenStack" as more
>> attractive than "making it easy to deploy OpenStack" (via the
>> deployment tools in the tent). Doing both is really something project
>> teams should do, but I don't think shoving all of the deployment
>> tooling in repo makes that any better frankly. If we put our tooling
>> in repo, we'll likely then start collecting RPM/Debian/etc. packaging
>> in repo as well.
> 
> Part of it _is_ the "deployment isn't shiny/new/features", but there
> is also the historical view lingering that we ship tarballs (and
> realistically, git repo tags) so as not to pick favorites and to keep
> deployment and packaging out of the project repos directly.
> 
> We have >5 different tools that are "mainstream" to consider, not even
> the large project teams have enough expertise to maintain those.  I
> had a hard enough time myself keeping both rpm and apt up to date in
> previous projects, much less recipies, playbooks and the odd shell
> script.

/me puts on old man pants and settles down by the fire to tell an old yarn

Back in the day - and by that, I mean before devstack existed and before
we were using git and before global-requirements - we did debian
packaging (targetting ubuntu) for all (4) of our projects. This is how
the gate worked. If you needed to express that nova had a new
dependency, you had to first go land a change in the packaging repo that
added the dependency (or bumped the version) The gate installed
dependencies on build hosts via "apt-get build-dep $project"

It worked ... to a degree. But then around the Diablo cycle, our friends
at Red Hat showed up. I remember quite clearly a discussion I had with
markmc at what I remember to be the Essex summit in Boston (but it's
possible I'm placing the memory in the wrong room - sorry, I'm getting
old) where he made the very reasonable argument "I've been using RPM for
ages and have never in my life made a debian package - why should I need
to go learn debian packaging to be able to do python development?"

That argument or some form of it has persisted in our DNA ever since. It
is one of the two reasons we switched from interacting with distro
packages to using virtualenvs and pip (the other is what is now a rather
funny story involving the old bzr vs. git argument that I'll happily
tell anyone over alcohol in person)

It's at the root of why TripleO originally came in to existence - and
also why it originally did not use puppet or chef (ansible and salt
weren't reasonable options yet at the time) It's related to the reason
we use devstack in the gate and not puppet or chef or ansible or salt or
juju. We knew that an OpenStack deployment project that used Puppet
would alienate the folks who used Chef at work, and vice-versa.

Quick digression - the real reason we use devstack in the gate is that
it's literally the first thing that the infra team was handed that
actually WORKED. Before devstack, on different occasions we were handed
repos of cookbooks or puppet modules - but none of them came with any
instructions of how to use them. Then devstack arrived and was as simple
as "run stack.sh" - and it actually worked the first time we tried it -
thus the devstack-gate was ultimately born.

As Dean points out - far from having gotten better, this has actually
multiplied. For from not alienating either the Puppet or the Chef
crowed, we REALLY pissed off both crowds when they thought that the
existence of TripleO as an official project disadvantaged people using
other deployment frameworks. (we totally solved the 2 competing standard
problem by adding a third standard) We now also have kolla and fuel and
TripleO in addition to puppet, chef, ansible, salt and juju. Luckily
there does seem to be collaboration on docker images via kolla - and
TripleO's and fuel's use of puppet is in collaboration with
openstack-puppet - so although we're not coalescing on one approach,
we're finding ways to collaborate on the pieces where we can.

We also have not just Ubuntu and Red Hat - but have gained (and recently
lost the maintainer of) Debian, and we have folks from Gentoo and SuSE
deeply involved. When you multiply
kolla+fuel+TripleO+ansible+salt+puppet+chef+juju by
Ubuntu+CentOS+RHEL+Fedora+SLES+OpenSUSE+Gentoo+Debian ... not to mention
the different reasonable versions of each of those ... it quickly
becomes unworkable an unworkable burden for each project developer to
know how to navigate all of them - as much as I wish that were not true.

I'll shut up now. I'm old - it's time for a nap.

> It is also hard to come in to a community and demand that other
> projects suddenly have to support your project just because you showed
> up.  (This works both ways, when we add a "Big Tent" project, now all
> of the downstreams are expected to suddenly add it.)
> 
> The solution I see is to have 

Re: [openstack-dev] [neutron] Some findings while profiling instances boot

[Daniel Alvarez Sanchez]

Awesome work, Kevin!

For the DHCP notification, in my profiling I got only 10% of the CPU time
[0] without taking the waiting times into account which it's probably what
you also measured.
Your patch seems like a neat and great optimization :)

Also, since "get_devices_details_list_and_failed_devices()" takes quite a
long time, does it make sense to trigger this request asynchronously (same
approach you took for OVO notifier) and continue executing the iteration?
This would not result in a huge improvement but, in the case I showed in
the diagram, both 'get_device_details' can be issued at the same time
instead of one after another and, probably, freeing the iteration for
further processing on the agent side. Thoughts on this?

Regarding, the time of SQL queries, it looks like the server spends a
significant amount of time building those and reducing that time will
result in a nice improvement. Mike's outstanding analysis looks promising
and maybe it's worth to discuss it.

[0] http://imgur.com/lDikZ0I



On Thu, Feb 16, 2017 at 8:23 AM, Kevin Benton  wrote:

> Thanks for the stats and the nice diagram. I did some profiling and I'm
> sure it's the RPC handler on the Neutron server-side behaving like garbage.
>
> There are several causes that I have a string of patches up to address
> that mainly stem from the fact that l2pop requires multiple port status
> updates to function correctly:
>
> * The DHCP notifier will trigger a notification to the DHCP agents on the
> network on a port status update. This wouldn't be too problematic on it's
> own, but it does several queries for networks and segments to determine
> which agents it should talk to. Patch to address it here:
> https://review.openstack.org/#/c/434677/
>
> * The OVO notifier will also generate a notification on any port data
> model change, including the status. This is ultimately the desired
> behavior, but until we eliminate the frivolous status flipping, it's going
> to incur a performance hit. Patch here to put it asynced into the
> background so it doesn't block the port update process:
> https://review.openstack.org/#/c/434678/
>
> * A wasteful DB query in the ML2 PortContext: https://review.op
> enstack.org/#/c/434679/
>
> * More unnecessary  queries for the status update case in the ML2
> PortContext: https://review.openstack.org/#/c/434680/
>
> * Bulking up the DB queries rather than retrieving port details one by
> one.
> https://review.openstack.org/#/c/434681/ https://review.open
> stack.org/#/c/434682/
>
> The top two accounted for more than 60% of the overhead in my profiling
> and they are pretty simple, so we may be able to get them into Ocata for RC
> depending on how other cores feel. If not, they should be good candidates
> for back-porting later. Some of the others start to get more invasive so we
> may be stuck.
>
> Cheers,
> Kevin Benton
>
> On Wed, Feb 15, 2017 at 12:25 PM, Jay Pipes  wrote:
>
>> On 02/15/2017 12:46 PM, Daniel Alvarez Sanchez wrote:
>>
>>> Hi there,
>>>
>>> We're trying to figure out why, sometimes, rpc_loop takes over 10
>>> seconds to process an iteration when booting instances. So we deployed
>>> devstack on a 8GB, 4vCPU VM and did some profiling on the following
>>> command:
>>>
>>> nova boot --flavor m1.nano --image cirros-0.3.4-x86_64-uec --nic
>>> net-name=private --min-count 8 instance
>>>
>>
>> Hi Daniel, thanks for posting the information here. Quick request of you,
>> though... can you try re-running the test but doing 8 separate calls to
>> nova boot instead of using the --min-count 8 parameter? I'm curious to see
>> if you notice any difference in contention/performance.
>>
>> Best,
>> -jay
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Packaging-RPM] Nominating Alberto Planas Dominguez for Packaging-RPM core

[Igor Yozhikov]

Hello team.
I want to announce the following changes to Packaging-RPM core team:
I’d like to nominate Alberto Planas Dominguez known as aplanas on irc for
Packaging-RPM core.
Alberto done a lot of reviews for as for project modules [1],[2] as for
rest of OpenStack components [3]. His experience within OpenStack
components and packaging are very appreciated.


[1]
http://stackalytics.com/?metric=marks_type=all=packaging-rpm-group_id=aplanas
[2]
http://stackalytics.com/?metric=marks_type=all=packaging-rpm-group
[3] http://stackalytics.com/?user_id=aplanas=marks

Packaging-RPM team please respond with +1/-1 to the proposed changes.

Thanks,
Igor Yozhikov
Senior Deployment Engineer
at Mirantis 
skype: igor.yozhikov
cellular: +7 901 5331200
slack: iyozhikov
__
OpenStack Development Mailing 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] Fwd: TripleO mascot - how can I help your team?

[Carlos Camacho Gonzalez]

Hi,

Yeah, I tried drafting something based on our current logo and following my
perception about the new foundation styles,
again here are the files (WIP version, is just a PoC)

https://cdn.rawgit.com/ccamacho/tripleo-graphics/5ed624b8/logos/openstack_
tripleo_logo_h.pdf
https://cdn.rawgit.com/ccamacho/tripleo-graphics/5ed624b8/logos/openstack_
tripleo_logo_h.png
https://cdn.rawgit.com/ccamacho/tripleo-graphics/5ed624b8/logos/openstack_
tripleo_logo_h.svg
https://cdn.rawgit.com/ccamacho/tripleo-graphics/5ed624b8/logos/openstack_
tripleo_logo_v.pdf
https://cdn.rawgit.com/ccamacho/tripleo-graphics/5ed624b8/logos/openstack_
tripleo_logo_v.png
https://cdn.rawgit.com/ccamacho/tripleo-graphics/5ed624b8/logos/openstack_
tripleo_logo_v.svg

Again, don't hesitate on pinging me if you think I can help you solve this
:)

Cheers,
Carlos.



On Thu, Feb 16, 2017 at 2:49 PM, Giulio Fidente  wrote:

> On 02/14/2017 03:38 AM, Emilien Macchi wrote:
> > Team, I've got this email from Heidi.
> >
> > I see 3 options :
> >
> > 1. Keep existing logo: http://tripleo.org/_static/tripleo_owl.svg .
> >
> > 2. Re-design a new logo that "meets" OpenStack "requirements".
> >
> > 3. Pick-up the one proposed (see below).
>
> while not the most skilled around, I can tell I have seen tripleo
> changing a lot over time, the project, not the logo, so I wouldn't ever
> think of tripleo people as hostile to changes
>
> I'd vote for option (1) as well but if someone could iterate over the
> *existing* logo to make it meet the requirements, instead of proposing a
> new one completely different, that would be received better I think; is
> this still an option? I think Carlos (in CC) suggested something like
> that too?
>
> also, to propose a change I think it would be useful to share the (new?)
> requirements as well, so that people can eventually understand those
> better too
> --
> Giulio Fidente
> GPG KEY: 08D733BA
>
__
OpenStack Development Mailing 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] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

[Dean Troyer]

On Thu, Feb 16, 2017 at 7:54 AM, Ian Cordasco  wrote:
> It seems like a lot of people view "developing OpenStack" as more
> attractive than "making it easy to deploy OpenStack" (via the
> deployment tools in the tent). Doing both is really something project
> teams should do, but I don't think shoving all of the deployment
> tooling in repo makes that any better frankly. If we put our tooling
> in repo, we'll likely then start collecting RPM/Debian/etc. packaging
> in repo as well.

Part of it _is_ the "deployment isn't shiny/new/features", but there
is also the historical view lingering that we ship tarballs (and
realistically, git repo tags) so as not to pick favorites and to keep
deployment and packaging out of the project repos directly.

We have >5 different tools that are "mainstream" to consider, not even
the large project teams have enough expertise to maintain those.  I
had a hard enough time myself keeping both rpm and apt up to date in
previous projects, much less recipies, playbooks and the odd shell
script.

It is also hard to come in to a community and demand that other
projects suddenly have to support your project just because you showed
up.  (This works both ways, when we add a "Big Tent" project, now all
of the downstreams are expected to suddenly add it.)

The solution I see is to have a mechanism by which important things
can be communicated from the project developers that can be consumed
by the packager/deployer community.  Today, however sub-optimal it
seems to be, that is release notes.  Maybe adding a specific section
for packaging would be helpful, but in practice that adds one more
thing to remember to write to a list that is already hard to get devs
to do.

Ad Doug mentions elsewhere in this thread, the liaison approach has
worked in other areas, it may be a useful approach here.  But I know
as the PTL of a very small project I do not want 5 more hats to wear.
Maybe one.

We have encouraged the packaging groups to work together in the past,
with mixed results, but it seems to me that a lot of the things that
need to be discovered and learned in new releases will be similar for
all of the downstream consumers.  Maybe if that downstream community
could reach a critical mass and suggest a single common way to
communicate the deployment considerations in a release it would get
more traction.  And a single project liaison for the collective rather
than one for each deployment project.

> I think what would help improve willing bidirectional communication
> between service and deployment/packaging teams would be an
> understanding that without the deployment/packaging teams, the service
> teams will likely be out of a job. People will/can not deploy
> OpenStack without the tooling these other teams provide.

True in a literal sense.  This is also true for our users, without
them nobody will deploy a cloud in the first place.  That has not
changed anything unfortunately, we still regularly give our users
miserable experiences because it is too much effort to participate
with the (now comatose) UX team or prioritize making a common log
format or reduce the number of knobs available to twiddle to make each
cloud a unique snowflake.

We can not sustain being all things to all people.  Given the
contraction of investment being considered and implemented by many of
our foundation member companies, we will have to make some hard
decisions about where to spend the resources we have left.  Some of
those decision are made for us by those member companies promoting
their own priorities (your example of Ansible contributions is one).
But as a community we have an opportunity to express our desires and
potentially influence those decisions.


dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [openstack-dev] [nova] scaling rabbitmq with cells v2 requires manual database update

[Corey Bryant]

On Thu, Feb 16, 2017 at 1:30 AM, Chen CH Ji  wrote:

> Should be this one https://bugs.launchpad.net/nova/+bug/1664913 and
> *https://review.openstack.org/434179*
>  ?
>
> Hey Kevin, sorry I didn't notice your patch/bug.  It looks like this is on
it's way to getting merged:  https://review.openstack.org/#/c/434533
__
OpenStack Development Mailing 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] Do we need service types at all?! (Re: [octavia][sdk] service name for octavia)

[Sean Dague]

On 02/16/2017 08:47 AM, Ian Cordasco wrote:
> -Original Message-
> From: Andrey Kurilin 
> Reply: OpenStack Development Mailing List (not for usage questions)
> 
> Date: February 16, 2017 at 07:08:19
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject:  Re: [openstack-dev] [all] Do we need service types at all?!
> (Re: [octavia][sdk] service name for octavia)
> 
>> On Thu, Feb 16, 2017 at 1:57 PM, Radomir Dopieralski > > wrote:
>>
>>> I think that you have to remember that OpenStack doesn't only work with
>>> officially approved OpenStack services, but with any services that have a
>>> conforming API.
>>>
>>
>> Yes, I forgot about it. But it changes nothing.
>> Custom implementation of particular service should cover the same API as an
>> official one. For me, as for user, it doesn't metter if there is Keystone
>> or MyAwesomeKeystone, I want just an service which implements Keystone
>> functionality.
> 
> As others are trying to explain, what you want is the "OpenStack
> Identity API", not a service whose name matches "*Keystone*". Keystone
> is the implementation "Identity" is the thing it does and what you're
> looking for from a service that is not Keystone.
> 
> Same goes for clouds that swap out RadosGW for Swift. They're looking
> for an OpenStack Object Store API. They're not fuzzy matching on
> project name.

Agree.

That was the general recommendation that has come out of the service
catalog discussions in the past.

Remove the name field, only keep the type field. Only use generic names
in the type field - https://github.com/openstack/service-types-authority

-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

Re: [openstack-dev] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

[Ian Cordasco]

-Original Message-
From: Doug Hellmann 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: February 16, 2017 at 07:06:25
To: openstack-dev 
Subject:  Re: [openstack-dev] [chef] Making the Kitchen Great Again: A
Retrospective on OpenStack & Chef

> Excerpts from Sylvain Bauza's message of 2017-02-16 10:55:14 +0100:
> >
> > Le 16/02/2017 10:17, Neil Jerram a écrit :
> > > On Thu, Feb 16, 2017 at 5:26 AM Joshua Harlow > > > > wrote:
> > >
> > > Radical idea, have each project (not libraries) contain a dockerfile
> > > that builds the project into a deployable unit (or multiple dockerfiles
> > > for projects with multiple components) and then it becomes the projects
> > > responsibility for ensuring that the right code is in that dockerfile to
> > > move from release to release (whether that be a piece of code that does
> > > a configuration migration).
> > >
> > >
> > > I've wondered about that approach, but worried about having the Docker
> > > engine as a new dependency for each OpenStack node. Would that matter?
> > > (Or are there other reasons why OpenStack nodes commonly already have
> > > Docker on them?)
> > >
> >
> > And one could claim that each project should also maintain its Ansible
> > playbooks. And one could claim that each project should also maintain
> > its Chef cookbooks. And one could claim that each project should also
> > maintain its Puppet manifests.
> >
> > I surely understand the problem that it is stated here and how it is
> > difficult for a deployment tool team to cope with the requirements that
> > every project makes every time it writes an upgrade impact.
> >
> > For the good or worst, as a service project developer, the only way to
> > signal the change is to write a release note. I'm not at all seasoned by
> > all the quirks and specifics of a specific deployment tool, and it's
> > always hard time for figuring out if what I write can break other things.
> >
> > What could be the solution to that distributed services problem ? Well,
> > understanding each other problem is certainly one of the solutions.
> > Getting more communication between teams can also certainly help. Having
> > consistent behaviours between heteregenous deployment tools could also
> > be a thing.
>
> Right. The liaison program used by other cross-project teams is
> designed to deal with this communication gap by identifying someone
> to focus on ensuring the communication happens. Perhaps we need to
> apply that idea to to some of the deployment projects as well.

I know the OpenStack-Ansible project went out of its way to try to
create a liaison program with the OpenStack services it works on. The
only engagement (that I'm aware) of it seeing has been from other
Rackspace employees whose management has told them to work on the
Ansible roles to ship the project they work on.

It seems like a lot of people view "developing OpenStack" as more
attractive than "making it easy to deploy OpenStack" (via the
deployment tools in the tent). Doing both is really something project
teams should do, but I don't think shoving all of the deployment
tooling in repo makes that any better frankly. If we put our tooling
in repo, we'll likely then start collecting RPM/Debian/etc. packaging
in repo as well.

I think what would help improve willing bidirectional communication
between service and deployment/packaging teams would be an
understanding that without the deployment/packaging teams, the service
teams will likely be out of a job. People will/can not deploy
OpenStack without the tooling these other teams provide.

Cheers,
--
Ian Cordasco

__
OpenStack Development Mailing 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] Triggering alarms on Swift notifications

[Mehdi Abaakouk]

On Thu, Feb 16, 2017 at 03:33:43PM +0200, Denis Makogon wrote:

Hello Mehdi. Thanks for response. See comments inline.

2017-02-16 15:25 GMT+02:00 Mehdi Abaakouk :


Hi,

On Thu, Feb 16, 2017 at 03:04:52PM +0200, Denis Makogon wrote:


Greetings.

Could someone provide any guidelines for checking why alarm or ok-action
webhooks are not being executed. Is it possible to investigate an issue by
analyzing ceilometer and/or aodh logs?

So, my devstack setup based on master branch with local.conf (see
https://gist.github.com/denismakogon/4d88bdbea4bf428e55e88d25d52735f6)

Once devstack installed i'm checking if notifications are being emitted
while uploading files to Swift and i'm able to see events in Ceilometer
(see https://gist.github.com/denismakogon/c6ad75899dcc50ce2a9b9f6
a4e0612f7).

After that i'm trying to setup Aodh event alarm (see
https://gist.github.com/denismakogon/f6449e71ba9bb04cdd0065b52918b5af)

And that's where i'm stuck, while working with Swift i see notifications
are coming from ceilometermiddleware to Panko and available in Ceilometer
via event-list but no alarm being triggered in Aodh.

So, could someone explain me what am i doing wrong or am i missing
something?



I think devstack plugins currently doesn't setup the Ceilometer stuffs to
be able to use events in Aodh.



So, if i would drop off both Aodh and Panko from this setup it may appear
that issue will be solved somehow?


I don't get it, I have thought your goal was to create alarm triggered on
event. And for this you need Aodh and Ceilometer (not Panko).

You have to do 
https://docs.openstack.org/developer/aodh/event-alarm.html#configuration
manually to get events emitted by Ceilometer received by Aodh.


Note that Aodh doesn't query Panko, but listen for event on alarm.all
topic by
default. I'm guessing the Ceilometer conf/pipeline have to be tweaked to
send
events to Aodh somehow.



Yes, i know that, in this setup Ceilometer depends on Panko as event
source, is that right?


No, Panko is for storage of event in a database (It's a API and a
Ceilometer dispatcher plugin). Events are still built from notification
by Ceilometer (agent-notification).

Rephrase from Ceilometer point of view. Ceilometer send events to Aodh AND 
Panko.

Regards,

--
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht

__
OpenStack Development Mailing 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] Fwd: TripleO mascot - how can I help your team?

[Giulio Fidente]

On 02/14/2017 03:38 AM, Emilien Macchi wrote:
> Team, I've got this email from Heidi.
> 
> I see 3 options :
> 
> 1. Keep existing logo: http://tripleo.org/_static/tripleo_owl.svg .
> 
> 2. Re-design a new logo that "meets" OpenStack "requirements".
> 
> 3. Pick-up the one proposed (see below).

while not the most skilled around, I can tell I have seen tripleo
changing a lot over time, the project, not the logo, so I wouldn't ever
think of tripleo people as hostile to changes

I'd vote for option (1) as well but if someone could iterate over the
*existing* logo to make it meet the requirements, instead of proposing a
new one completely different, that would be received better I think; is
this still an option? I think Carlos (in CC) suggested something like
that too?

also, to propose a change I think it would be useful to share the (new?)
requirements as well, so that people can eventually understand those
better too
-- 
Giulio Fidente
GPG KEY: 08D733BA

__
OpenStack Development Mailing 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] Fwd: TripleO mascot - how can I help your team?

[Flavio Percoco]

On 16/02/17 08:36 -0500, Emilien Macchi wrote:

I'll shamelessly cross-post here, I didn't know where to reply.
I agree with Monty and Flavio here.

Heidi has been doing an excellent job in helping OpenStack community
about $topic, always in the open, which has been very appreciated.

We, as a team, have agreed on re-iterating on a new proposal to find a
new logo that meets both TripleO devs taste and OpenStack community
needs. That's how we work together.
Unfortunately, this choice won't satisfy everyone and that's fine,
that's how Open Source works I guess.

So the next steps are clear: let's work with Heidi and her team to
find the best logo for TripleO, and let's all have a Gin Tonic in
Atlanta.


I'd recommend that someone needs to volunteer to work close with Heidi on this.
There's been effort put in both, the old and the new, logos and to find some
common ground I believe there should be someone in the TripleO team that takes
this on.

Also, I want a Diplomatico... I'll let Gin Tonics to you ;)
Flavio


And folks, that's a logo, I think we'll all survive.
Peace.

On Thu, Feb 16, 2017 at 7:51 AM, Flavio Percoco  wrote:

On 13/02/17 21:38 -0500, Emilien Macchi wrote:


Team, I've got this email from Heidi.

I see 3 options :

1. Keep existing logo: http://tripleo.org/_static/tripleo_owl.svg .

2. Re-design a new logo that "meets" OpenStack "requirements".

3. Pick-up the one proposed (see below).



#3

Flavio




Personally, I would vote for keeping our existing logo (1.) unless someone
has time to create another one or if the team likes the proposed one.

The reason why I want to keep our logo is because our current logo was
created by TripleO devs, we like it and we already have tee-shirts and
other goodies with it. I don't see any good reason to change it.

Discussion is open and we'll vote as a team.

Thanks,

Emilien.

-- Forwarded message --
From: Heidi Joy Tretheway 
Date: Mon, Feb 13, 2017 at 8:27 PM
Subject: TripleO mascot - how can I help your team?
To: Emilien Macchi 


Hi Emilien,

I’m following up on the much-debated TripleO logo. I’d like to help your
team reach a solution that makes them happy but still fits within the
family of logos we’re using at the PTG and going forward. Here’s what our
illustrators came up with, which hides an “O” shape in the owl (face and
wing arcs).

https://www.dropbox.com/sh/qz45miiiam3caiy/AAAzPGYEZRMGH6Otid3bLfHFa?dl=0
At this point, I don’t have quorum from your team (I got a lot of
conflicting feedback, most of which was “don’t like” but not actionable
for
the illustrators to make a revision). At the PTG, we’ll have mascot
stickers and signage for all teams except for Ironic and TripleO, since
we’re still waiting on your teams to make a final decision.

May I recommend that your team choose one person (or a small group of no
more than three) to finalize this? I was able to work through all of
Swift’s issues with just a quick 15-minute chat with John Dickinson and
I’d
like to believe we can solve this for TripleO as well.

We know some of your team has expressed concern over retiring the existing
mascot. It’s not our intention to make anyone “get rid of” a beloved icon.
Your team can certainly print it on vintage items like shirts and
stickers.
But for official channels like the website, we need a logo to represent
TripleO that’s cohesive with the rest of the set.

Perhaps when you’re face to face with your team at the PTG, you can
discuss
and hopefully render a final decision to either accept this as a logo, or
determine a few people willing to make any final changes with me?

Thanks in advance for your help!


[image: photo]
*Heidi Joy Tretheway*
Senior Marketing Manager, OpenStack Foundation
503 816 9769 | Skype: heidi.tretheway




 






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




--
@flaper87
Flavio Percoco

__
OpenStack Development Mailing 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


--
@flaper87
Flavio Percoco

Re: [openstack-dev] [all] Do we need service types at all?! (Re: [octavia][sdk] service name for octavia)

[Ian Cordasco]

-Original Message-
From: Andrey Kurilin 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: February 16, 2017 at 07:08:19
To: OpenStack Development Mailing List (not for usage questions)

Subject:  Re: [openstack-dev] [all] Do we need service types at all?!
(Re: [octavia][sdk] service name for octavia)

> On Thu, Feb 16, 2017 at 1:57 PM, Radomir Dopieralski > > wrote:
>
> > I think that you have to remember that OpenStack doesn't only work with
> > officially approved OpenStack services, but with any services that have a
> > conforming API.
> >
>
> Yes, I forgot about it. But it changes nothing.
> Custom implementation of particular service should cover the same API as an
> official one. For me, as for user, it doesn't metter if there is Keystone
> or MyAwesomeKeystone, I want just an service which implements Keystone
> functionality.

As others are trying to explain, what you want is the "OpenStack
Identity API", not a service whose name matches "*Keystone*". Keystone
is the implementation "Identity" is the thing it does and what you're
looking for from a service that is not Keystone.

Same goes for clouds that swap out RadosGW for Swift. They're looking
for an OpenStack Object Store API. They're not fuzzy matching on
project name.

--
Ian Cordasco

__
OpenStack Development Mailing 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] Fwd: TripleO mascot - how can I help your team?

[Emilien Macchi]

I'll shamelessly cross-post here, I didn't know where to reply.
I agree with Monty and Flavio here.

Heidi has been doing an excellent job in helping OpenStack community
about $topic, always in the open, which has been very appreciated.

We, as a team, have agreed on re-iterating on a new proposal to find a
new logo that meets both TripleO devs taste and OpenStack community
needs. That's how we work together.
Unfortunately, this choice won't satisfy everyone and that's fine,
that's how Open Source works I guess.

So the next steps are clear: let's work with Heidi and her team to
find the best logo for TripleO, and let's all have a Gin Tonic in
Atlanta.

And folks, that's a logo, I think we'll all survive.
Peace.

On Thu, Feb 16, 2017 at 7:51 AM, Flavio Percoco  wrote:
> On 13/02/17 21:38 -0500, Emilien Macchi wrote:
>>
>> Team, I've got this email from Heidi.
>>
>> I see 3 options :
>>
>> 1. Keep existing logo: http://tripleo.org/_static/tripleo_owl.svg .
>>
>> 2. Re-design a new logo that "meets" OpenStack "requirements".
>>
>> 3. Pick-up the one proposed (see below).
>
>
> #3
>
> Flavio
>
>>
>>
>> Personally, I would vote for keeping our existing logo (1.) unless someone
>> has time to create another one or if the team likes the proposed one.
>>
>> The reason why I want to keep our logo is because our current logo was
>> created by TripleO devs, we like it and we already have tee-shirts and
>> other goodies with it. I don't see any good reason to change it.
>>
>> Discussion is open and we'll vote as a team.
>>
>> Thanks,
>>
>> Emilien.
>>
>> -- Forwarded message --
>> From: Heidi Joy Tretheway 
>> Date: Mon, Feb 13, 2017 at 8:27 PM
>> Subject: TripleO mascot - how can I help your team?
>> To: Emilien Macchi 
>>
>>
>> Hi Emilien,
>>
>> I’m following up on the much-debated TripleO logo. I’d like to help your
>> team reach a solution that makes them happy but still fits within the
>> family of logos we’re using at the PTG and going forward. Here’s what our
>> illustrators came up with, which hides an “O” shape in the owl (face and
>> wing arcs).
>>
>> https://www.dropbox.com/sh/qz45miiiam3caiy/AAAzPGYEZRMGH6Otid3bLfHFa?dl=0
>> At this point, I don’t have quorum from your team (I got a lot of
>> conflicting feedback, most of which was “don’t like” but not actionable
>> for
>> the illustrators to make a revision). At the PTG, we’ll have mascot
>> stickers and signage for all teams except for Ironic and TripleO, since
>> we’re still waiting on your teams to make a final decision.
>>
>> May I recommend that your team choose one person (or a small group of no
>> more than three) to finalize this? I was able to work through all of
>> Swift’s issues with just a quick 15-minute chat with John Dickinson and
>> I’d
>> like to believe we can solve this for TripleO as well.
>>
>> We know some of your team has expressed concern over retiring the existing
>> mascot. It’s not our intention to make anyone “get rid of” a beloved icon.
>> Your team can certainly print it on vintage items like shirts and
>> stickers.
>> But for official channels like the website, we need a logo to represent
>> TripleO that’s cohesive with the rest of the set.
>>
>> Perhaps when you’re face to face with your team at the PTG, you can
>> discuss
>> and hopefully render a final decision to either accept this as a logo, or
>> determine a few people willing to make any final changes with me?
>>
>> Thanks in advance for your help!
>>
>>
>> [image: photo]
>> *Heidi Joy Tretheway*
>> Senior Marketing Manager, OpenStack Foundation
>> 503 816 9769 | Skype: heidi.tretheway
>>
>> 
>> 
>> 
>>  
>>
>>
>>
>>
>>
>>
>> --
>> 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
>
>
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing 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] [telemetry] Triggering alarms on Swift notifications

[Denis Makogon]

Hello Mehdi. Thanks for response. See comments inline.

2017-02-16 15:25 GMT+02:00 Mehdi Abaakouk :

> Hi,
>
> On Thu, Feb 16, 2017 at 03:04:52PM +0200, Denis Makogon wrote:
>
>> Greetings.
>>
>> Could someone provide any guidelines for checking why alarm or ok-action
>> webhooks are not being executed. Is it possible to investigate an issue by
>> analyzing ceilometer and/or aodh logs?
>>
>> So, my devstack setup based on master branch with local.conf (see
>> https://gist.github.com/denismakogon/4d88bdbea4bf428e55e88d25d52735f6)
>>
>> Once devstack installed i'm checking if notifications are being emitted
>> while uploading files to Swift and i'm able to see events in Ceilometer
>> (see https://gist.github.com/denismakogon/c6ad75899dcc50ce2a9b9f6
>> a4e0612f7).
>>
>> After that i'm trying to setup Aodh event alarm (see
>> https://gist.github.com/denismakogon/f6449e71ba9bb04cdd0065b52918b5af)
>>
>> And that's where i'm stuck, while working with Swift i see notifications
>> are coming from ceilometermiddleware to Panko and available in Ceilometer
>> via event-list but no alarm being triggered in Aodh.
>>
>> So, could someone explain me what am i doing wrong or am i missing
>> something?
>>
>
> I think devstack plugins currently doesn't setup the Ceilometer stuffs to
> be able to use events in Aodh.
>
>
So, if i would drop off both Aodh and Panko from this setup it may appear
that issue will be solved somehow?


> Note that Aodh doesn't query Panko, but listen for event on alarm.all
> topic by
> default. I'm guessing the Ceilometer conf/pipeline have to be tweaked to
> send
> events to Aodh somehow.
>

Yes, i know that, in this setup Ceilometer depends on Panko as event
source, is that right?


>
> Maybe this [1] have to be done manually.
>
> [1] https://docs.openstack.org/developer/aodh/event-alarm.html#
> configuration


Ok, will try.


>
>
> Regards,
>
> --
> Mehdi Abaakouk
> mail: sil...@sileht.net
> irc: sileht
>
> __
> OpenStack Development Mailing 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] Fwd: TripleO mascot - how can I help your team?

[Dan Prince]

On Thu, 2017-02-16 at 06:36 -0600, Monty Taylor wrote:
> On 02/15/2017 07:54 PM, Dan Prince wrote:
> > At the high level all of this sounds like a fine grand plan: "Help
> > projects create mascots" with a common theme. On the ground level I
> > can
> > tell you it feels a lot more like you are crushing the spirit of
> > creativity and motivation for some of us.
> 
> Haven't we had this argument on the tech side enough? Do we have to
> have
> it all over again just because there are some illustrators and
> foundation staff involved?
> 
> We KEEP deciding as a community that we value cohesion for OpenStack
> over individual projects having unlimited freedom to do whatever they
> heck they want. This is no different. There are now a set of
> logos/mascots that exist within a common visual language. Neat!

Is it *Neat* to make a projects and teams feel bad because they don't
want to change their logo? Is it *Neat* to make arguments that we
aren't  part of the same communities because some people have done
creative things with logos?

No. Its not neat. Its wrong. And its sad. Go ahead... look at what you
are creating and tell yourself it is neat I guess. And I'm sure you'll
get some nice websites and stickers out of it. But if you look on the
ground level at how it makes those who created some of the original
(vintage) stuff feel it isn't good. There is a subtle, don't go off
creating your own version of things or you are a bad person theme
here... and that I'm afraid will squelch, not encourage, creativity and
innovation.

> 
> > What's in a mascot? I dunno. Call it a force of motivation. Call it
> > team building. In fact, one of the first things I did as PTL of
> > TripleO
> > was create a mascot for the project. Perhaps not officially... but
> > there was agreement among those in the project. And we liked the
> > little
> > guy. And he grew on us. And we even iterated on him a bit and made
> > him
> > better.
> 
> Yah - I hear that. But once again, if the project is "OpenStack" and
> not
> just TripleO - that's exactly what's going on here. And the project
> _is_
> OpenStack. That's what we're here to do, that's what we work on,
> that's
> what we are members of a Foundation to support. Not TripleO, not
> Infra,
> not Nova. This isn't the Oslo Foundation or the Ironic consortium.
> It's
> OpenStack.
> 
> That means, for exactly the reasons you list, that it's important.
> It's
> important to underscore and bolster the fact that we are One
> OpenStack.
> 
> > 
> > 
> > 6 months or so ago we were presented with a new owl from the
> > foundation... which had almost none of the same qualities as the
> > original. Many of us took a survey about that and provided
> > feedback,
> > but I haven't found anyone who was really happy with it. Consensus
> > was
> > we liked the originals. Sometimes sticking with your roots is a
> > good
> > thing.
> > 
> > I happened to be off yesterday but I was really discouraged to read
> > that the team is now convinced we have to adopt your version of the
> > owl: http://eavesdrop.openstack.org/meetings/tripleo/2017/tripleo.2
> > 017-
> > 02-14-14.00.log.html
> > 
> > This all sounds like we are being "steamrolled" into using the new
> > owl
> > because things have to align. I'm not asking that you use our owl
> > on
> > your website. But if you want to... then great. I think it is
> > possible
> > to show that things work together without forcing them all to have
> > the
> > same mascot styles:
> >  https://www.linuxfoundation.org/about
> 
> Except that we are not the linux foundation. The linux foundation IS
> a
> loose confederation of unrelated projects that happen to share a
> legal
> parent entity. The LF does great work on behalf of those projects -
> but
> that is not what we are.
> 
> > But I do think the OpenStack Foundation has overstated its case
> > here
> > and should reverse track a bit. Make it *clear* that projects can
> > keep
> > their own version of their mascots. In fact I think the foundation
> > should encourage them to do so (keep the originals). The opposite
> > seems
> > be happening on several projects like TripleO and Ironic.
> > 
> > P.S. vintage TripleO owl "beany babies" would be super cool
> 
> Totally. Make a vintage beanine - that's an awesome idea. I'd wear
> one.
> I've been considering trying to figure out how to make another "What
> the
> F**k is OpenStack?" shirt because mine is dying. The past is cool.
> But
> Dopenstack isn't the present - and honestly that's a good thing. So
> keep
> a sense of nostalgia for the old owl ... but I do NOT think the
> foundation should 'encourage' projects to 'keep' their originals. The
> foundation is expressing that they cannot FORCE a project to do
> anything
> - they do not have that power. But maybe alignment is a thing that
> can
> happen without anyone forcing anyone else to do it?
> 
> It IS important for things to align. It IS important that we have a
> sense of cohesion. Literally 100% of the 

Re: [openstack-dev] [telemetry] Triggering alarms on Swift notifications

[Mehdi Abaakouk]

Hi,

On Thu, Feb 16, 2017 at 03:04:52PM +0200, Denis Makogon wrote:

Greetings.

Could someone provide any guidelines for checking why alarm or ok-action
webhooks are not being executed. Is it possible to investigate an issue by
analyzing ceilometer and/or aodh logs?

So, my devstack setup based on master branch with local.conf (see
https://gist.github.com/denismakogon/4d88bdbea4bf428e55e88d25d52735f6)

Once devstack installed i'm checking if notifications are being emitted
while uploading files to Swift and i'm able to see events in Ceilometer
(see https://gist.github.com/denismakogon/c6ad75899dcc50ce2a9b9f6a4e0612f7).

After that i'm trying to setup Aodh event alarm (see
https://gist.github.com/denismakogon/f6449e71ba9bb04cdd0065b52918b5af)

And that's where i'm stuck, while working with Swift i see notifications
are coming from ceilometermiddleware to Panko and available in Ceilometer
via event-list but no alarm being triggered in Aodh.

So, could someone explain me what am i doing wrong or am i missing
something?


I think devstack plugins currently doesn't setup the Ceilometer stuffs to
be able to use events in Aodh.

Note that Aodh doesn't query Panko, but listen for event on alarm.all topic by
default. I'm guessing the Ceilometer conf/pipeline have to be tweaked to send
events to Aodh somehow.

Maybe this [1] have to be done manually.

[1] https://docs.openstack.org/developer/aodh/event-alarm.html#configuration

Regards,

--
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht

__
OpenStack Development Mailing 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] Do we need service types at all?! (Re: [octavia][sdk] service name for octavia)

[Dean Troyer]

On Thu, Feb 16, 2017 at 7:06 AM, Andrey Kurilin  wrote:
> Yes, I forgot about it. But it changes nothing.
> Custom implementation of particular service should cover the same API as an
> official one. For me, as for user, it doesn't metter if there is Keystone or
> MyAwesomeKeystone, I want just an service which implements Keystone
> functionality.

Actually it is the name field that we really do not need, nor want.
Its continued existence is mostly driven by a desire by deployers to
brand their services, nothing should currently be using to as a
selector.  The type field is what (should be) used in places like the
base URL for services under a combined endpoint (ie,
host/compute/v2.1/...) on a single port.  For any alternate
implementations of a service that a deployer wants to take the place
of an OpenStack service this is how that is done seamlessly, no lying
about the name like the browser User-Agent header nonsense.

dt

-- 

Dean Troyer
dtro...@gmail.com

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

[openstack-dev] [tripleo] tripleo-puppet-elements 6.0.0.0rc1 (ocata)

[no-reply]

Hello everyone,

A new release candidate for tripleo-puppet-elements for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/tripleo-puppet-elements/

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

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


http://git.openstack.org/cgit/openstack/tripleo-puppet-elements/log/?h=stable/ocata

Release notes for tripleo-puppet-elements can be found at:

http://docs.openstack.org/releasenotes/tripleo-puppet-elements/



__
OpenStack Development Mailing 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] Do we need service types at all?! (Re: [octavia][sdk] service name for octavia)

[Andrey Kurilin]

On Thu, Feb 16, 2017 at 1:57 PM, Radomir Dopieralski  wrote:

> I think that you have to remember that OpenStack doesn't only work with
> officially approved OpenStack services, but with any services that have a
> conforming API.
>

Yes, I forgot about it. But it changes nothing.
Custom implementation of particular service should cover the same API as an
official one. For me, as for user, it doesn't metter if there is Keystone
or MyAwesomeKeystone, I want just an service which implements Keystone
functionality.


> OpenStack itself provides implementations of those services, and you are
> right that it's unlikely that there will be two competing implementations
> for the same service type officially endorsed by OpenStack. But you are
> ignoring 3rd-party services that are being used, and also the possibility
> that the services will change in the future. Since it doesn't really cost
> us to keep this flexibility, I think it's reasonable to keep doing it.
>
> On Thu, Feb 16, 2017 at 11:55 AM, Andrey Kurilin 
> wrote:
>
>> Hi everyone!
>>
>> When I started contribution to OpenStack long time ago, I asked about the
>> reason of having two entities - service type and name; at that time I got
>> an answer that service name is a name of the project that implements
>> particular service type, so it is possible to have several projects which
>> implement one service type. That answer satisfied me.
>>
>> The reality of OpenStack is that there is no and there will not be
>> several implementations of one "service type". Even when we had nova-net
>> and neutron, only the neutron registered his service in the catalog.
>>
>> An example of Octavia shows that everybody was ok about having service
>> name equal with type before inconsistency was found. That is why I want to
>> ask again: Do we need two separate entities and if yes - why? Maybe service
>> name and description fields should be enough?
>>
>> On Wed, Feb 15, 2017 at 3:08 AM, Qiming Teng 
>> wrote:
>>
>>> When reviewing a recent patch that adds openstacksdk support to octavia,
>>> I found that octavia is using 'octavia' as its service name instead of
>>> 'loadbalancing' or 'loadbalancingv2' or something similar.
>>>
>>> The overall suggestion is to use a word/phrase that indicates what a
>>> service do instead of the name of the project providing that service.
>>>
>>> Below is the list of the service types currently supported by
>>> openstacksdk:
>>>
>>> 'alarming',# aodh
>>> 'baremetal',   # ironic
>>> 'clustering',  # senlin
>>> 'compute', # nova
>>> 'database',# trove
>>> 'identity',# keystone
>>> 'image',   # glance
>>> 'key-manager', # barbican
>>> 'messaging',   # zaqar
>>> 'metering',# ceilometer
>>> 'network', # neutron
>>> 'object-store',   # swift
>>> 'octavia',# <--- this is an exception
>>> 'orchestration',  # heat
>>> 'volume', # cinder
>>> 'workflowv2', # mistral
>>>
>>> While I believe this has been discussed about a year ago, I'm not sure
>>> if there are things we missed so I'm brining this issue to a broader
>>> audience for discussion.
>>>
>>> Reference:
>>>
>>> [1] Patch to python-openstacksdk:
>>> https://review.openstack.org/#/c/428414
>>> [2] Octavia service naming:
>>> http://git.openstack.org/cgit/openstack/octavia/tree/devstac
>>> k/plugin.sh#n52
>>>
>>> Regards,
>>>  Qiming
>>>
>>>
>>> 
>>> __
>>> 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
>>>
>>
>>
>>
>> --
>> Best regards,
>> Andrey Kurilin.
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

[openstack-dev] [tripleo] tripleo-image-elements 6.0.0.0rc1 (ocata)

[no-reply]

Hello everyone,

A new release candidate for tripleo-image-elements for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/tripleo-image-elements/

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

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


http://git.openstack.org/cgit/openstack/tripleo-image-elements/log/?h=stable/ocata

Release notes for tripleo-image-elements can be found at:

http://docs.openstack.org/releasenotes/tripleo-image-elements/



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

[openstack-dev] [tripleo] tripleo-heat-templates 6.0.0.0rc1 (ocata)

[no-reply]

Hello everyone,

A new release candidate for tripleo-heat-templates for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/tripleo-heat-templates/

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

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


http://git.openstack.org/cgit/openstack/tripleo-heat-templates/log/?h=stable/ocata

Release notes for tripleo-heat-templates can be found at:

http://docs.openstack.org/releasenotes/tripleo-heat-templates/

If you find an issue that could be considered release-critical, please
file it at:

http://bugs.launchpad.net/tripleo

and tag it *ocata-rc-potential* to bring it to the tripleo-heat-templates
release crew's attention.

__
OpenStack Development Mailing 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] Triggering alarms on Swift notifications

[Denis Makogon]

Greetings.

Could someone provide any guidelines for checking why alarm or ok-action
webhooks are not being executed. Is it possible to investigate an issue by
analyzing ceilometer and/or aodh logs?

So, my devstack setup based on master branch with local.conf (see
https://gist.github.com/denismakogon/4d88bdbea4bf428e55e88d25d52735f6)

Once devstack installed i'm checking if notifications are being emitted
while uploading files to Swift and i'm able to see events in Ceilometer
(see https://gist.github.com/denismakogon/c6ad75899dcc50ce2a9b9f6a4e0612f7).

After that i'm trying to setup Aodh event alarm (see
https://gist.github.com/denismakogon/f6449e71ba9bb04cdd0065b52918b5af)

And that's where i'm stuck, while working with Swift i see notifications
are coming from ceilometermiddleware to Panko and available in Ceilometer
via event-list but no alarm being triggered in Aodh.

So, could someone explain me what am i doing wrong or am i missing
something?

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