Re: [openstack-dev] [stable][release] Last release date vs End of Life date

[ChangBo Guo]

Thanks tony  for raising up this, better document this in some place :-)

2017-06-28 16:51 GMT+08:00 Thierry Carrez :

> Sean McGinnis wrote:
> > On Tue, Jun 27, 2017 at 02:47:30PM -0400, Doug Hellmann wrote:
> >> Excerpts from Tony Breeds's message of 2017-06-27 16:51:37 +1000:
> >>> Hi all,
> >>> Up 'til now we haven't set a last release date for a stable branch
> >>> approaching end of life.  It seems like formalizing that would be a
> good
> >>> thing.
> >>>
> >>> This comes up as we need time to verify that said release integrates
> >>> well (at least doesn't break) said branch.  So should we define a date
> >>> for the last release for *libraries* services are less critical as
> we're
> >>> always testing the HEAD of that branch.
> >>>
> >>> I'd suggest it be 2 weeks before EOL date.  Thoughts?
> >>
> >> That makes sense.
> >
> > Agree, that makes sense to me too. Unless something has gone horribly
> wrong,
> > two weeks should be plenty to make sure things are settled before things
> get
> > wrapped up.
>
> +1
>
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
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] [all][tc] How to deal with confusion around "hosted projects"

[Steven Dake]

On Wed, Jun 28, 2017 at 2:50 PM, Monty Taylor  wrote:

> On 06/28/2017 09:50 AM, Thierry Carrez wrote:
>
>> Hi everyone,
>>
>> Two weeks ago, as a result of a discussion at the Board+TC+UC workgroup
>> working on "better communicating what is openstack", I started a
>> thread[1] about moving away from big tent terminology. The thread went
>> in a lot of directions, including discussing GitHub mirroring strategy,
>> what makes projects want to be official, the need for returning to a
>> past when everything was (supposedly) simpler, and naming fun.
>>
>> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-June
>> /118368.html
>>
>> Many agreed that the "Big Tent" name (as a synonym to "official
>> openstack projects") is hurting more than it helps, and we should stop
>> using it. The issue is, merely stopping using it won't be enough. We
>> have tried, and the name sticks. You need to replace the name by
>> something that sticks more, or address the root cause directly.
>>
>> The central issue being discussed here is an issue of external
>> perception. It's hard for newcomers to the OpenStack world to see what
>> is a part of OpenStack and what's not. If you google "openstack machine
>> learning", the first hits are Cognitive and Meteos, and it's impossible
>> to tell that those are actually not OpenStack projects. One of those has
>> been dead for 2 years -- having people think that those are official
>> projects hurts all the OpenStack projects, by lowering expectations
>> around what that means, in terms of quality, maintenance, or community.
>>
>> The confusion mainly stems from the fact that OpenStack project
>> infrastructure is open to any open source project (and it's nobody's job
>> to clean up dead things). So you can find (on our wiki, on our
>> mailing-list, on our cgit farm, on our gerrit, on our GitHub
>> organization...) things that are actually not OpenStack, even with the
>> expansive "are you one of us" definition. Arguably the most confusing
>> aspect is the "openstack/" prefix in the git repository name, which
>> indicates some kind of brand association.
>>
>> I'd say we have two options. We can address the perception issue on the
>> edges, or you can treat the root cause. Neither of those options is
>> really an OpenStack  governance change (or "big tent" change) -- they
>> are more about what to do with things that are actually *not* in our
>> governance.
>>
>> Addressing the perception on the edges means making it clearer when
>> things are not official. The thread above discussed a lot of potential
>> solutions. We could give unofficial things a catchy group name
>> (Stackforge, Opium, Electrons...), and hope it sticks. We could find a
>> way to tag all projects on GitHub that are not official, or mirror them
>> to another organization, or stop mirroring them altogether. We could
>> remove the openstack/ prefix from all the projects we host. We could
>> actively mark all wiki pages that are not about an official project. We
>> could set up a separate Gerrit or separate ML for hosted projects
>> development discussions. The main issue with that approach is that it's
>> a *lot* of work, and it never completely eliminates the confusion.
>>
>> Removing the root cause would be a more radical move: stop offering
>> hosting to non-OpenStack projects on OpenStack infrastructure
>> altogether. We originally did that for a reason, though. The benefits of
>> offering that service are:
>>
>
> I disagree that this is removing the root cause.
>
> I believe this is reacting to a misunderstanding by hiding from it. I do
> not believe that doing this provides any value to us as a community.
>
> Even though we do not actually use github for development, we have
> implicitly accepted the false premise that github is a requirement. It is
> suggested that the existence of git repos in the openstack/ github org is
> confusing to people. And our reaction to that is to cut off access to our
> Open Source tools that we set up to collaboratively develop cloud software
> and tell people to go use the thing that people suggest is one of the
> causes of people being confused?
>
> * People are not 'confused' by what OpenStack is.
>
> Being "confused" is a passive-aggressive way of expressing that they
> DISAGREE with what OpenStack is. We still have _plenty_ of people who
> express that they think we should only be IaaS - so they're still going to
> be unhappy with cloudkitty, congress and karbor.
>

Monty,

I think you are right on the money on this second point although it is
missing a salient point.  There really are two problems here.

If we as a community disagree about the answer "What is OpenStack?" how
should we expect a Google search to answer this question for us?  Most
people that have been working on OpenStack for a long time might agree
there is a "common core" of projects that make up OpenStack.  I'll call
this as what you refer to as "OpenStack should only be an 

[openstack-dev] [octavia] Weekly meeting time and channel change

[Michael Johnson]

As discussed in today's octavia IRC meeting we are changing the meeting time
and IRC channel for the weekly meeting.

Starting next week we will now be meeting at 17:00 UTC on Wednesdays in
channel #openstack-meeting.

This is the same day, just three hours earlier to accommodate team members
in different time zones.

Details can be found here: http://eavesdrop.openstack.org/#Octavia_Meeting

An ICS file is available here:
http://eavesdrop.openstack.org/calendars/octavia-meeting.ics

The original proposal is here:
http://lists.openstack.org/pipermail/openstack-dev/2017-June/118363.html

The "Doodle" we used for voting is here:
https://doodle.com/poll/kxvii2tn9rydp6ed

I hope to see more of you joining us for the octavia meeting!

Michael



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

[openstack-dev] [glance] stepping down from glance core and other related groups

[Nikhil Komawar]

I am thankful to the community for such amazing experience over the past
few years. For the changes required for glance personnel in the active
cycle, I would like to step down from core as I cannot commit as much time
upstream. I was hanging out to help in general but even that time
commitment will be difficult in the coming months. This should effectively
mean, me stepping down from the release, core-sec, specs core groups too. I
am happy to help where needed on case by case basis but I do not think
+2/-2 rights or me being subscribed to glance-core-sec is needed for such.

Good luck to glancers and all those who form (ionic or covalent) bonds with
the glance community. Cheers.

-- 
--
Thanks,
Nikhil
__
OpenStack Development Mailing 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] [glance] nominating Abhishek Kekane for glance core

[Nikhil Komawar]

This is a good move. I appreciate strong decisions as these are much needed
now.

On Fri, Jun 16, 2017 at 10:26 AM, Brian Rosmaita  wrote:

> I'm nominating Abhishek Kekane (abhishekk on IRC) to be a Glance core
> for the Pike cycle.  Abhishek has been around the Glance community for
> a long time and is familiar with the architecture and design patterns
> used in Glance and its related projects.  He's contributed code,
> triaged bugs, provided bugfixes, and done quality reviews for Glance.
>
> Abhishek has been proposed for Glance core before, but some members of
> the community were concerned that he wasn't able to devote sufficient
> time to Glance.  Given the current situation with the project,
> however, it would be an enormous help to have someone as knowledgeable
> about Glance as Abhishek to have +2 powers.  I discussed this with
> Abhishek, he's aware that some in the community have that concern, and
> he's agreed to be a core reviewer for the Pike cycle.  The community
> can revisit his status early in Queens.
>
> Now that I've written that down, that puts Abhishek in the same boat
> as all core reviewers, i.e., their levels of participation and
> commitment are assessed at the beginning of each cycle and adjustments
> made.
>
>

Although I am unsure about my commitment for Queens, in my current
situation I can no longer help with urgent reviews so I would like to step
down. A official email to follow.



> In any case, I'd like to put Abhishek to work as soon as possible!  So
> please reply to this message with comments or concerns before 23:59
> UTC on Monday 19 June.  I'd like to confirm Abhishek as a core on
> Tuesday 20 June.
>
> thanks,
> 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
>



-- 
--
Thanks,
Nikhil
__
OpenStack Development Mailing 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][tc] How to deal with confusion around "hosted projects"

[Sean McGinnis]

> 
> The central issue being discussed here is an issue of external
> perception. It's hard for newcomers to the OpenStack world to see what
> is a part of OpenStack and what's not. If you google "openstack machine
> learning", the first hits are Cognitive and Meteos, and it's impossible
> to tell that those are actually not OpenStack projects. One of those has
> been dead for 2 years -- having people think that those are official
> projects hurts all the OpenStack projects, by lowering expectations
> around what that means, in terms of quality, maintenance, or community.
> 

Maybe this is a bit of a tangent from the overall discussion, but
since a lot of confusion, and bad perception, can stem from dead
projects - as a first small step, could we move dead projects
out of openstack/* into closedstack/* and move or mark their wiki
to indicate it is just for legacy reference?


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

Re: [openstack-dev] [heat] Deprecate/Remove deferred_auth_method=password config option

[Kaz Shinohara]

Hi,

> No, I think we still need this, because it is disabled by default -
> this option allows you to enable defeating token expiry via trusts,
My understanding for the current implementation is..
`deferred_auth_method=trust` triggers getting trust_id and storing it in the db.
`reauthentication_method=trust` triggers getting trust scoped token by
taking the trust id(Allow reauthentication)
Those looks somehow duplicated because trust_id is required only when
you want to get the trust scoped token, it's ok for heat to get
trust_id when he need to get trust scoped token, isn't it ?

In case of removing the password authentication, why don't we remove
`deferred_auth_method` from heat.conf and unify
'reauthentication_method' to triggers getting trust_id and getting
trust scoped token.

Cheers,
Kaz

2017-06-21 16:51 GMT+09:00 Steven Hardy :
> On Fri, Jun 16, 2017 at 10:09 AM, Kaz Shinohara  wrote:
>> Hi Rabi,
>>
>>
>> I still takes `deferred _auth_method=password` behalf of trusts because we
>> don't enable trusts in the Keystone side due to some internal reason.
>> The issues what you pointed are correct(e.g. user_domain_id), we don't use
>> the domain well and also added some patches to skip those issues.
>> But I guess that the majority of heat users already moved to trusts and it
>> is obviously better solution in terms of security and granular role control.
>> As the edge case(perhaps), if a user want to take password auth, it would be
>> too tricky for them to introduce it, therefore I agree your 2nd option.
>>
>> If we will remove the `deferred_auth_method=password` from heat.conf,
>> should we keep `deferred_auth_method` self or will replace it to a new
>> config option just to specify the trusts enable/disable ?  Do you have any
>> idea on this?
>
> I don't think it makes sense to have an enable/disable trusts config
> option unless there is an alternative (e.g we've discussed oauth in
> the past and in future there may be alternatives to trusts).
>
> I guess if there was sufficient interest we could have some option
> that blacklists all resources that require deferred authentication,
> but I'm not sure folks are actually asking for that right now?
>
> My preference is to deprecate deferred_auth_method, since right now
> there's not really any alternative that works for us.
>
>> Also I'm thinking that `reauthentication_method` also might be
>> changed/merged ?
>
> No, I think we still need this, because it is disabled by default -
> this option allows you to enable defeating token expiry via trusts,
> which is something an operator must opt-in to IMO (we should not
> enable this by default, as it's really only intended for certain edge
> cases such as TripleO where there are often very long running stack
> operations that may exceed the keystone token expiry).
>
> Steve
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[David Moreau Simard]

On Wed, Jun 28, 2017 at 5:50 PM, Monty Taylor  wrote:
> Such people are under the misguided impression that kicking cloudkitty out
> of OpenStack will somehow cause Nova features to land quicker. I can't even
> begin to express all of the ways in which it's wrong.

So much this.
I wonder where this perception is coming from, but I've definitely
seen it around.
Perhaps most notably from Mr. Shuttleworth [1] ?

Kicking projects like Cloudkitty isn't going to make the developers
working on Cloudkitty magically start working on Nova, Cinder or
Keystone.

[1]: 
http://www.eweek.com/cloud/ubuntu-linux-founder-tells-openstack-to-focus-on-things-that-matter

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]

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

[openstack-dev] [QA] Meeting Thursday June 29th at 8:00 UTC

[Ghanshyam Mann]

Hello everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, June 29th at 8:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_June_29th_2017_.280800_UTC.29

Anyone is welcome to add an item to the agenda.

-gmann

__
OpenStack Development Mailing 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] removing domain configuration upload via keystone-manage

[Lance Bragstad]

Cool - I'm glad this is generating discussion. I personally don't see a
whole lot of maintenance costs with `keystone-manage
domain_config_upload`. I was parsing deprecation warnings in the code
base and noticed it was staged for removal, but it wasn't clear when or
why. It also wasn't very clear if there was a desire to move away from
the file-based approach all together, but it was something that came up
in the meeting.

Based on the responses and the reasons listed, I think removing the
deprecation to avoid confusion on where we stand would be a good thing
(especially since it's low maintenance).

I appreciate the feedback!


On 06/28/2017 04:22 PM, Steve Martinelli wrote:
> ++ to what colleen said. I've always preferred using the file-backed
> approach.
>
> I think we deprecated it for completeness and to only have a single
> tool for configuring LDAP-backed domains. If it's tested well enough
> and not much effort to support then we should keep it around as an
> alternative method for configuring LDAP-backed domains.
>
> On Wed, Jun 28, 2017 at 4:53 PM, Colleen Murphy  > wrote:
>
>> On Wed, Jun 28, 2017 at 2:00 AM, Lance Bragstad
>> > wrote:
>>
>> Hi all,
>>
>> Keystone has deprecated the domain configuration upload
>> capability provided through `keystone-manage`. We
>> discussed it's removal in today's meeting [0] and wanted
>> to send a quick note to the operator list. The ability to
>> upload a domain config into keystone was done as a
>> stop-gap until the API was marked as stable [1]. It seems
>> as though file-based domain configuration was only a
>> band-aid until full support was done.
>>
>> Of the operators using the domain config API in keystone,
>> how many are backing their configurations with actual
>> configuration files versus the API?
>>
>>
>> [0]
>> 
>> http://eavesdrop.openstack.org/meetings/keystone/2017/keystone.2017-06-27-18.00.log.html#l-167
>> 
>> 
>> [1]
>> 
>> https://github.com/openstack/keystone/commit/a5c5f5bce812fad3c6c88a23203bd6c00451e7b3
>> 
>> 
>>
>  I am not clear on why we need to deprecate and remove file-backed
> domain configuration. The way I see it:
>
> * It's reflectve with the primary configuration, so I can copy
> over the chunks I need from keystone.conf into
> /etc/keystone/domains/keystone.domain.conf without thinking too
> hard about it
> * It's convenient for deployment tools to just lay down config files
> * It's not that much extra effort for the keystone team to
> maintain (is it?)
>
> The use case for file-backed domain configs is for smaller clouds
> with just one or two LDAP-backed domains. There's not a real need
> for users to change domain configs so the file-backed config is
> plenty fine. I don't see a lot of gain from removing that
> functionality.
>
> I don't particularly care about the keystone-manage tool, if that
> goes away it would still be relatively easy to write a python
> script to parse and upload configs if a user does eventually
> decide to transition.
>
> As a side note, SUSE happens to be using file-backed domain
> configs in our product. It would not be a big deal to rewrite that
> bit to use the API, but I think it's just as easy to let us keep
> using it.
>
> Colleen
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
>
>
>
>
> __
> OpenStack Development Mailing 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] [tricircle]

[Vega Cai]

Hi Meher,

Welcome to join Tricircle!

Both Keystone and Tricircle services are running under Apache, so if
Keystone failed to start after enabling Tricircle, I guess there might be
some problems of Apache configuration. You can check what services are
enabled in Apache by listing this folder: /etc/apache2/sites-enabled.

tricircle@zhiyuan-1:~/devstack$ ls /etc/apache2/sites-enabled/
keystone-wsgi-admin.conf  keystone-wsgi-public.conf
 nova-placement-api.conf  tricircle-api.conf

Above is the result from my Ubuntu machine.

Also, could you provide me the log of DevStack after enabling Tricircle so
I can get more hints.

BR
Zhiyuan

On Wed, 28 Jun 2017 at 21:17  wrote:

> Hello everyone,
>
>
>
> I introduce myself; Meher Hihi; I am doing my internship at Orange Labs
> Networks Lannion-France for the diploma of computer network and
> telecommunications engineer.
>
>
>
> I am working on innovative distribution solutions for the virtualization
> infrastructure of the network functions and more specifically on the
> Openstack Tricircle solution, which is why I join your community to
> participate in your discussions and learn from your advice.
>
>
>
> Indeed, I try to install Tricircle on a single node by following this
> documentation “
> https://docs.openstack.org/developer/tricircle/installation-guide.html#single-pod-installation-with-devstack
> ”.
>
> I managed to install Devstack without any problems, but when I modify the
> local.conf file by adding the Tricircle plugin integration and the HOST_IP,
> the script does not want to work and stops on an error of Start of the
> Keystone service.
>
>
>
> I wanted to know if the problem is with my config file that is attached or
> I lack other things to configure. You will also find in the file the IP
> address of the machine.
>
>
>
> I thank you in advance for the help you will bring me. Sincerely,
>
>
>
> Best regards,
>
>
>
> Meher
>
>
>
> [image: Logo Orange] 
>
>
>
> *Meher Hihi *
> Intern
> ORANGE/IMT/OLN/WNI/ODIS/NAVI
>
> Fixe : +33 2 96 07 03 71
> 
> Mobile : +33 7 58 38 68 87
> 
> meher.h...@orange.com
>
>
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO][keystone] Pt. 2 of Passing along some field feedback

[Lance Bragstad]

On 06/28/2017 03:20 PM, Ben Nemec wrote:
>
>
> On 06/28/2017 02:47 PM, Lance Bragstad wrote:
>>
>>
>> On 06/28/2017 02:29 PM, Fox, Kevin M wrote:
>>> I think everyone would benefit from a read-only role for keystone
>>> out of the box. Can we get this into keystone rather then in the
>>> various distro's?
>> Yeah - I think that would be an awesome idea. John Garbutt had some good
>> work on this earlier in the cycle. Most of it was documented in specs
>> [0] [1]. FWIW - this will be another policy change that is going to have
>> cross-project effects. It's implementation or impact won't be isolated
>> to keystone if we want read-only roles out-of-the-box.
>>
>> [0] https://review.openstack.org/#/c/427872/19
>> [1] https://review.openstack.org/#/c/428454/
>
> Cool, I will point our folks at those specs.  I know doing a custom
> read-only role has been pretty painful, so I expect they would be very
> happy if this functionality could become standard.
Absolutely - it would be awesome to provide some standard roles out of
the box (at least for the sake of interoperability). I'm happy to help
in any way I can. We also have the weekly policy meeting that's focused
on nailing down cross-project issues with policy [0].

[0] http://eavesdrop.openstack.org/#Keystone_Policy_Meeting
>
> Thanks for the replies.
>
> -Ben
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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] [all][tc] How to deal with confusion around "hosted projects"

[David Moreau Simard]

Hi !

I thought my perspective might be valuable as the author of a project that
would likely end up being slashed: ARA [1].

In a nutshell, ARA provides easy and seamless Ansible reporting on playbook
runs.

It has nothing to do with OpenStack, to be honest: it doesn't require
OpenStack to run, it doesn't run on OpenStack.
We highlight that ARA is not an "official" OpenStack project in the
contributors' documentation [2].

But, it was born out of necessity inside the RDO community (call that the
extended OpenStack community, if you will) due to the vast amount of our
workloads that are driven by Ansible.

I like to draw a parallel between ARA and JJB [3] (Jenkins Job Builder) as
two tools that the OpenStack community develops and use without slapping
the OpenStack brand on them.
If we take a step back, would projects like Nodepool or Zuul also be
affected by this kind of cut ? Where do we draw the line ? Are they
OpenStack projects or not ?

For me, applying for ARA to be hosted as a "community" project [4], or what
would've been a "Stackforge" project long ago, was a completely logical
choice to me.

I could go and praise how the Gerrit workflow is vastly superior than
GitHub pull requests or that the Zuul-driven CI is completely awesome.
But... The truth is that I sincerely hoped it would help the project gain
exposure and credibility in order to drive adoption *inside* the OpenStack
community.

We say that hindsight is 20/20, but, in retrospect [5], I guess we could
say it worked.
Maybe out of luck, maybe out of sheer dedication and long weekends spent
working on the project.

The reality is that today, ARA is used by many different projects inside
the OpenStack ecosystem -- to name a few:
- OpenStack-Ansible
- TripleO
- Browbeat
- Kolla/Kolla-Ansible
- Devstack-Gate

But also, like Jenkins Job Builder, it has gained adoption outside of the
OpenStack community -- such as inside the OpenShift Ansible community or
BonnyCI.

Being part of the OpenStack "ecosystem" allows ARA to do things like easily
implement a gate job almost verbatim from OpenStack-Ansible [6] to make
sure that each new commit doesn't break them.
I feel that this is useful and powerful not just for ARA but for
OpenStack-Ansible and the other projects that use it as well.

Ironically, some projects feel hindered by this ecosystem (see: Gnocchi)
and have made an exit.
I do not share these feelings and I would in fact be very sad to be shown
the door.

My 0.02$CAD (not worth much right now)

​[1]​: https://github.com/openstack/ara
​[2]: ​http://ara.readthedocs.io/en/latest/contributing.html#contributing
[3]: https://github.com/openstack-infra/jenkins-job-builder
[4]: https://review.openstack.org/#/c/321226/
​[5]:
https://dmsimard.com/2017/05/08/ara-is-one-year-old-a-look-back-at-the-past-year/
​
​[6]:
https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/ara.yaml#L21-L89
​

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]

On Jun 28, 2017 6:46 PM, "James E. Blair"  wrote:

Thierry Carrez  writes:

> Removing the root cause would be a more radical move: stop offering
> hosting to non-OpenStack projects on OpenStack infrastructure
> altogether. We originally did that for a reason, though. The benefits of
> offering that service are:
>
> 1- it lets us set up code repositories and testing infrastructure before
> a project applies to be an official OpenStack project.
>
> 2- it lets us host things that are not openstack but which we work on
> (like abandoned Python libraries or GPL-licensed things) in a familiar
> environment
>
> 3- it spreads "the openstack way" (Gerrit, Zuul) beyond openstack itself

I think this omits what I consider the underlying reason for why we did
it:

It helps us build a community around OpenStack.

Early on we had so many people telling us that we needed to support
"ecosystem" projects better.  That was the word they used at the time.
Many of us said "hey, you're free to use github" and they told us that
wasn't enough.

We eventually got the message and invited them in, and it surpassed our
expectations and I think surprised even the most optimistic of us.  We
ended up in a place where anyone with an OpenStack related idea can try
it out and collaborate frictionlessly with everyone else in the
OpenStack community on it, and in doing so, become recognized in the
community for that.  The ability for someone to build something on top
of OpenStack as part of the OpenStack community has been empowering.

I confess to being a skeptic and a convert.  I wasn't thrilled about the
unbounded additional responsibility when we started this, but now that
we're here, I think it's one of the best things about the project and I
would hate to cleave our community by ending it.

-Jim

__
OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [tripleo] Queens PTG

[Giulio Fidente]

On 06/28/2017 04:35 PM, Emilien Macchi wrote:
> Hey folks,
> 
> Let's start to prepare the next PTG in Denver.
> 
> Here's the schedule draft:
> https://docs.google.com/spreadsheets/d/1xmOdT6uZ5XqViActr5sBOaz_mEgjKSCY7NEWcAEcT-A/pubhtml?gid=397241312=true=gmail
> We'll have a room Wednesday, Thursday and Friday. We'll probably
> finish by end of Friday morning.
> 
> Etherpad for the PTG:
> https://etherpad.openstack.org/p/tripleo-ptg-queens

thanks Emilien!

I've added a session into the agenda about the integration of
ceph-ansible as this brough in a generic functionality in Heat and
TripleO which allows services to describe workflows to be executed
during the overcloud deployment steps

I think it'd be nice to review together what the submissions tracked by
the two blueprints actually do [1] [2] and how!

Flavio is using some of this code for Kubernetes integration as well

1.
https://blueprints.launchpad.net/heat/+spec/mistral-new-resource-type-workflow-execution

2. https://blueprints.launchpad.net/tripleo/+spec/tripleo-ceph-ansible

-- 
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] [stable]requirements] Bootstrapiing requirements-stable-core

[Sean McGinnis]

>
> This has been out there for just under 1 week with only positive
> feedback.  So I'm going to jump the gun by 70mins and just go ahead and
> do this.
> 
> Welcome Dirk, Matthew and Sean!
> 
> Yours Tony.

Thanks Tony, I will do my best to help out in whatever way I can.

Sean

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

Re: [openstack-dev] [all][stable][ptls] Tagging mitaka as EOL

[Tony Breeds]

On Wed, Jun 28, 2017 at 11:50:34PM +, Jeremy Stanley wrote:

> Indeed, that's a bummer. I hadn't noticed it until you pointed it
> out and assumed it had made it into the 2.13 series. Well, we're
> planning to look at logistics for a 2.14 upgrade soon once 2.13 is
> (hopefully!) in production, we just didn't want to backtrack and
> lose forward momentum on the current upgrade train. The transition
> to 2.14 will probably be a bit messy what with needing newer Java,
> which is why we can't adjust our plans easily at this stage.

In the meantime we could look at adding permissions such that the Stable
PTL (Well actually I guess eventually it'd be the same bot that does the
release tagging) can push tags and abandon changes on all projects.

Right now stable-maint-core can do that in a lot of projects but the
coverage isn't complete.

That would allow us to make forward progress and reduce the task for the
infra team to deleting the branches.  It does of course introduce a
race where I could tag a branch as EOL and then that project merge
another change.  Can you think of a way to avoid that?

Yours Tony.


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

Re: [openstack-dev] [openstack-helm] Announcing OpenStack-Helm as a hosted project

[Jaesuk Ahn]

This is a amazing news. Let’s make it super great together. :) 

Jaesuk Ahn, Ph.D. 

Open System Lab, SK Telecom 

. OpenStack Korea User Group Coordinator & 

. Cloud Native Computing Seoul Meetup Organizer 

On 2017년 6월 29일 (목) at 오전 9:31 Ihor Dvoretskyi

<
mailto:Ihor Dvoretskyi 
> wrote:

a, pre, code, a:link, body { word-wrap: break-word !important; }

Amazing news, my congratulations!

I'm excited to see how Kubernetes+OpenStack collaboration moves forward.

__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe:
mailto:openstack-dev-requ...@lists.openstack.org
?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

On Thu, Jun 29, 2017 at 3:07 AM, Steve Wilkerson

<
mailto:wilkers.st...@gmail.com
>

wrote:

Hello everyone!

Now that Boston has come and gone, we'd like to formally announce that

OpenStack-Helm is now a hosted project on OpenStack infra. We received

a great deal of positive feedback in Boston, and we're excited to see

what's next for both OpenStack and Kubernetes together.

We'd like to invite anyone who's interested in working on OpenStack on

top of Kubernetes to contribute to OpenStack-Helm.  The OpenStack-Helm

wiki can be found here:
https://wiki.openstack.org/wiki/Openstack-helm
.  The OpenStack-Helm

Launchpad currently has blueprints listed that are new-contributor

friendly, and we’d be happy to help any new contributors either find

or identify work that would be helpful as the project moves forward.

Anyone is welcome to join us in #openstack-helm on freenode and/or the

#openstack-helm channel in the Kubernetes Slack team (we've got a

chatbot that mirrors all chat between the two). Our weekly meeting is

at 3:00PM UTC on Tuesdays in #openstack-meeting-5  (next Tuesday’s

meeting on 7/4 will be cancelled due to the holiday).  Both the

Eavesdrop history of our meetings and the agenda for future meetings

can be found via links on the wiki page.

On behalf of the core team; alanmeadows, v1k0d3n, portdirect,

lrensing, lamt, and myself, I'd really like to thank the help and

support we've got thus far, and we look forward to meeting and working

with new contributors. If you have any questions, please feel free to

reach out.

Cheers,

srwilkers

__

__

__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe:
http://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] [stable]requirements] Bootstrapiing requirements-stable-core

[Tony Breeds]

On Thu, Jun 22, 2017 at 11:48:09AM +1000, Tony Breeds wrote:
> Hi All,
>   Recently it's been clear that we need a requirements-stable team.
> Until npw that's been handled by the release managers and the
> stable-maint-core team.
> 
> With the merge of [1] The have the groundwork for that team.  I'd like
> to nominate:
> 
>  * dmllr -- Dirk Mueller
>  * prometheanfire -- Matthew Thode
>  * SeanM -- Sean McGinnis
> 
> As that initial team.  Each of them has been doing regular reviews on
> stable branches and have shown an understanding of how the stable policy
> applies to the requirements repo.

This has been out there for just under 1 week with only positive
feedback.  So I'm going to jump the gun by 70mins and just go ahead and
do this.

Welcome Dirk, Matthew and Sean!

Yours Tony.


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

Re: [openstack-dev] [openstack-helm] Announcing OpenStack-Helm as a hosted project

[Ihor Dvoretskyi]

Amazing news, my congratulations!

I'm excited to see how Kubernetes+OpenStack collaboration moves forward.

On Thu, Jun 29, 2017 at 3:07 AM, Steve Wilkerson 
wrote:

> Hello everyone!
>
>
> Now that Boston has come and gone, we'd like to formally announce that
> OpenStack-Helm is now a hosted project on OpenStack infra. We received
> a great deal of positive feedback in Boston, and we're excited to see
> what's next for both OpenStack and Kubernetes together.
>
>
> We'd like to invite anyone who's interested in working on OpenStack on
> top of Kubernetes to contribute to OpenStack-Helm.  The OpenStack-Helm
> wiki can be found here:
> https://wiki.openstack.org/wiki/Openstack-helm.  The OpenStack-Helm
> Launchpad currently has blueprints listed that are new-contributor
> friendly, and we’d be happy to help any new contributors either find
> or identify work that would be helpful as the project moves forward.
>
>
> Anyone is welcome to join us in #openstack-helm on freenode and/or the
> #openstack-helm channel in the Kubernetes Slack team (we've got a
> chatbot that mirrors all chat between the two). Our weekly meeting is
> at 3:00PM UTC on Tuesdays in #openstack-meeting-5  (next Tuesday’s
> meeting on 7/4 will be cancelled due to the holiday).  Both the
> Eavesdrop history of our meetings and the agenda for future meetings
> can be found via links on the wiki page.
>
>
> On behalf of the core team; alanmeadows, v1k0d3n, portdirect,
> lrensing, lamt, and myself, I'd really like to thank the help and
> support we've got thus far, and we look forward to meeting and working
> with new contributors. If you have any questions, please feel free to
> reach out.
>
>
> Cheers,
>
> srwilkers
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [openstack-helm] Announcing OpenStack-Helm as a hosted project

[Steve Wilkerson]

Hello everyone!


Now that Boston has come and gone, we'd like to formally announce that
OpenStack-Helm is now a hosted project on OpenStack infra. We received
a great deal of positive feedback in Boston, and we're excited to see
what's next for both OpenStack and Kubernetes together.


We'd like to invite anyone who's interested in working on OpenStack on
top of Kubernetes to contribute to OpenStack-Helm.  The OpenStack-Helm
wiki can be found here:
https://wiki.openstack.org/wiki/Openstack-helm.  The OpenStack-Helm
Launchpad currently has blueprints listed that are new-contributor
friendly, and we’d be happy to help any new contributors either find
or identify work that would be helpful as the project moves forward.


Anyone is welcome to join us in #openstack-helm on freenode and/or the
#openstack-helm channel in the Kubernetes Slack team (we've got a
chatbot that mirrors all chat between the two). Our weekly meeting is
at 3:00PM UTC on Tuesdays in #openstack-meeting-5  (next Tuesday’s
meeting on 7/4 will be cancelled due to the holiday).  Both the
Eavesdrop history of our meetings and the agenda for future meetings
can be found via links on the wiki page.


On behalf of the core team; alanmeadows, v1k0d3n, portdirect,
lrensing, lamt, and myself, I'd really like to thank the help and
support we've got thus far, and we look forward to meeting and working
with new contributors. If you have any questions, please feel free to
reach out.


Cheers,

srwilkers

__
OpenStack Development Mailing 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][stable][ptls] Tagging mitaka as EOL

[Jeremy Stanley]

On 2017-06-28 13:21:46 +1000 (+1000), Tony Breeds wrote:
> On Tue, Jun 27, 2017 at 08:59:27PM +, Jeremy Stanley wrote:
> 
> > Fingers crossed that we'll be able to switch to Gerrit 2.13 soon and
> > resume that much needed development effort.
> 
> This looks to have landed in 2.14[1] :(   I don't know how hard it'd be
> to backport to 2.13 or even if that's a thing we'd do.
> 
> It certainly doesn't cleanly cherry-pick :(
> 
> Yours Tony.
> 
> [1] https://gerrit-review.googlesource.com/c/85512

Indeed, that's a bummer. I hadn't noticed it until you pointed it
out and assumed it had made it into the 2.13 series. Well, we're
planning to look at logistics for a 2.14 upgrade soon once 2.13 is
(hopefully!) in production, we just didn't want to backtrack and
lose forward momentum on the current upgrade train. The transition
to 2.14 will probably be a bit messy what with needing newer Java,
which is why we can't adjust our plans easily at this stage.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[James E. Blair]

Thierry Carrez  writes:

> Removing the root cause would be a more radical move: stop offering
> hosting to non-OpenStack projects on OpenStack infrastructure
> altogether. We originally did that for a reason, though. The benefits of
> offering that service are:
>
> 1- it lets us set up code repositories and testing infrastructure before
> a project applies to be an official OpenStack project.
>
> 2- it lets us host things that are not openstack but which we work on
> (like abandoned Python libraries or GPL-licensed things) in a familiar
> environment
>
> 3- it spreads "the openstack way" (Gerrit, Zuul) beyond openstack itself

I think this omits what I consider the underlying reason for why we did
it:

It helps us build a community around OpenStack.

Early on we had so many people telling us that we needed to support
"ecosystem" projects better.  That was the word they used at the time.
Many of us said "hey, you're free to use github" and they told us that
wasn't enough.

We eventually got the message and invited them in, and it surpassed our
expectations and I think surprised even the most optimistic of us.  We
ended up in a place where anyone with an OpenStack related idea can try
it out and collaborate frictionlessly with everyone else in the
OpenStack community on it, and in doing so, become recognized in the
community for that.  The ability for someone to build something on top
of OpenStack as part of the OpenStack community has been empowering.

I confess to being a skeptic and a convert.  I wasn't thrilled about the
unbounded additional responsibility when we started this, but now that
we're here, I think it's one of the best things about the project and I
would hate to cleave our community by ending it.

-Jim

__
OpenStack Development Mailing 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] [octavia] Webex to discuss Octavia L3 active/active spec

[Jason Niesz]

As discussed in the weekly Octavia irc meeting, I am scheduling a Webex and 
follow-up meeting to discuss the L3 active/active spec 
(https://review.openstack.org/#/c/453005/).  The goal of this meeting is to 
finalize the details around the spec in order to get it accepted for the Pike 
release.  Meeting details are below.

Date & Time: July 6th 2017 @ 8 AM PST

Webex Details:
Link: 
https://walmart.webex.com/walmart/j.php?MTID=m44d6a41784ad59af24215fe75d501261
Dial-in: +1-855-797-9485
Meeting Number: 741 827 527
Meeting Password: 1

Thanks,

Jason Niesz


__
OpenStack Development Mailing 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] Journey to running functional job with Python 3

[Sławek Kapłoński]

Hello,

I just added fullstack python35 job in project-config
Patch to add testing in tox.ini is ready to review also: 
https://review.openstack.org/#/c/477681
I also wrote some notes in Your etherpad and made first patch to fix fullstack 
tests: https://review.openstack.org/#/c/478652
I hope it will be helpful for You :)

—
Best regards
Slawek Kaplonski
sla...@kaplonski.pl




> Wiadomość napisana przez Jakub Libosvar  w dniu 
> 13.06.2017, o godz. 18:39:
> 
> Hi folks,
> 
> we've been tracking the OpenStack common goal for Python 3 in our
> Neutron CI meetings. As an outcome we created a list of categorized
> failures in current non-voting job. There are 250 failures that we split
> into 14 categories. The list can be found here:
> 
> https://etherpad.openstack.org/p/py3-neutron-pike
> 
> Consider this email as a call-for-action in case you'd like to
> participate in this goal. If you decide to work on one failure category,
> please write down your name to the etherpad above.
> 
> Thanks to all who will join this effort! :)
> 
> Jakub
> 
> __
> OpenStack Development Mailing 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: Message signed with OpenPGP
__
OpenStack Development Mailing 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][tc] How to deal with confusion around "hosted projects"

[Monty Taylor]

On 06/28/2017 09:50 AM, Thierry Carrez wrote:

Hi everyone,

Two weeks ago, as a result of a discussion at the Board+TC+UC workgroup
working on "better communicating what is openstack", I started a
thread[1] about moving away from big tent terminology. The thread went
in a lot of directions, including discussing GitHub mirroring strategy,
what makes projects want to be official, the need for returning to a
past when everything was (supposedly) simpler, and naming fun.

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-June/118368.html

Many agreed that the "Big Tent" name (as a synonym to "official
openstack projects") is hurting more than it helps, and we should stop
using it. The issue is, merely stopping using it won't be enough. We
have tried, and the name sticks. You need to replace the name by
something that sticks more, or address the root cause directly.

The central issue being discussed here is an issue of external
perception. It's hard for newcomers to the OpenStack world to see what
is a part of OpenStack and what's not. If you google "openstack machine
learning", the first hits are Cognitive and Meteos, and it's impossible
to tell that those are actually not OpenStack projects. One of those has
been dead for 2 years -- having people think that those are official
projects hurts all the OpenStack projects, by lowering expectations
around what that means, in terms of quality, maintenance, or community.

The confusion mainly stems from the fact that OpenStack project
infrastructure is open to any open source project (and it's nobody's job
to clean up dead things). So you can find (on our wiki, on our
mailing-list, on our cgit farm, on our gerrit, on our GitHub
organization...) things that are actually not OpenStack, even with the
expansive "are you one of us" definition. Arguably the most confusing
aspect is the "openstack/" prefix in the git repository name, which
indicates some kind of brand association.

I'd say we have two options. We can address the perception issue on the
edges, or you can treat the root cause. Neither of those options is
really an OpenStack  governance change (or "big tent" change) -- they
are more about what to do with things that are actually *not* in our
governance.

Addressing the perception on the edges means making it clearer when
things are not official. The thread above discussed a lot of potential
solutions. We could give unofficial things a catchy group name
(Stackforge, Opium, Electrons...), and hope it sticks. We could find a
way to tag all projects on GitHub that are not official, or mirror them
to another organization, or stop mirroring them altogether. We could
remove the openstack/ prefix from all the projects we host. We could
actively mark all wiki pages that are not about an official project. We
could set up a separate Gerrit or separate ML for hosted projects
development discussions. The main issue with that approach is that it's
a *lot* of work, and it never completely eliminates the confusion.

Removing the root cause would be a more radical move: stop offering
hosting to non-OpenStack projects on OpenStack infrastructure
altogether. We originally did that for a reason, though. The benefits of
offering that service are:


I disagree that this is removing the root cause.

I believe this is reacting to a misunderstanding by hiding from it. I do 
not believe that doing this provides any value to us as a community.


Even though we do not actually use github for development, we have 
implicitly accepted the false premise that github is a requirement. It 
is suggested that the existence of git repos in the openstack/ github 
org is confusing to people. And our reaction to that is to cut off 
access to our Open Source tools that we set up to collaboratively 
develop cloud software and tell people to go use the thing that people 
suggest is one of the causes of people being confused?


* People are not 'confused' by what OpenStack is.

Being "confused" is a passive-aggressive way of expressing that they 
DISAGREE with what OpenStack is. We still have _plenty_ of people who 
express that they think we should only be IaaS - so they're still going 
to be unhappy with cloudkitty, congress and karbor.


Such people are under the misguided impression that kicking cloudkitty 
out of OpenStack will somehow cause Nova features to land quicker. I 
can't even begin to express all of the ways in which it's wrong. We 
aren't a top-down corporate structure and we can't 'reassign' humans - 
but even if we WERE - this flawed thinking runs afoul of the Mythical 
Man Month.


* Kicking non-official things out will not help

If I'm wrong about the above and it really is all just about not being 
able to navigate a set of repositories that are prefixed with the string 
'openstack/', it STILL WON'T HELP.


There are 1049 official repos. There are only 1676 repos in gerrit.

Do we honestly think that people who are confused are going to be less 
confused by the number 

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Monty Taylor]

On 06/28/2017 01:48 PM, Clay Gerrard wrote:



On Wed, Jun 28, 2017 at 7:50 AM, Thierry Carrez > wrote:



2- it lets us host things that are not openstack but which we work on
(like abandoned Python libraries or GPL-licensed things) in a familiar
environment


Do we no longer think openstack hosted infra holds a competitive 
advantage for teams that are trying to efficiently collaborate building 
software in service of the mission?


I think it absolutely does.

If we do, why would we agree on a plan that basically tells teams that 
are trying to "get stuff done" to go work it out on github and travis ci 
or whatever?  Maybe worse, what happens when a team/project/community 
grows up around *one* workflow (not because it's better; but just 
because the OpenStack workflow is exclusionary) but then it sees it's 
operators/deployers/users adoption swelling around OpenStack and wants 
to "join"?  Is adopting the hosted infrastructure later... optional?


++ to these questions

This is the reason I do not think we should stop hosting 'non-official' 
software. There are many things we have that allow for collaboration 
across individual project domains that we have developed over time 
exactly to address all of these issues. They may not always fit everyone 
perfect, but they provide enough value that our problem is currently 
that "too many people" want to collaborate directly, rather than that 
our tooling is driving people away.


If we do NOT think hosting on openstack-infra offers competitive 
advantage for teams that are trying to efficiently collaborate building 
software in service of the mission ... why heck not?!


-Clay


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




__
OpenStack Development Mailing 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] removing domain configuration upload via keystone-manage

[Steve Martinelli]

++ to what colleen said. I've always preferred using the file-backed
approach.

I think we deprecated it for completeness and to only have a single tool
for configuring LDAP-backed domains. If it's tested well enough and not
much effort to support then we should keep it around as an alternative
method for configuring LDAP-backed domains.

On Wed, Jun 28, 2017 at 4:53 PM, Colleen Murphy  wrote:

> On Wed, Jun 28, 2017 at 2:00 AM, Lance Bragstad 
>> wrote:
>>
>>> Hi all,
>>>
>>> Keystone has deprecated the domain configuration upload capability
>>> provided through `keystone-manage`. We discussed it's removal in today's
>>> meeting [0] and wanted to send a quick note to the operator list. The
>>> ability to upload a domain config into keystone was done as a stop-gap
>>> until the API was marked as stable [1]. It seems as though file-based
>>> domain configuration was only a band-aid until full support was done.
>>>
>>> Of the operators using the domain config API in keystone, how many are
>>> backing their configurations with actual configuration files versus the API?
>>>
>>>
>>> [0] http://eavesdrop.openstack.org/meetings/keystone/2017/keysto
>>> ne.2017-06-27-18.00.log.html#l-167 [1] https://github.com/openstack/k
>>> eystone/commit/a5c5f5bce812fad3c6c88a23203bd6c00451e7b3
>>>
>>  I am not clear on why we need to deprecate and remove file-backed domain
> configuration. The way I see it:
>
> * It's reflectve with the primary configuration, so I can copy over the
> chunks I need from keystone.conf into 
> /etc/keystone/domains/keystone.domain.conf
> without thinking too hard about it
> * It's convenient for deployment tools to just lay down config files
> * It's not that much extra effort for the keystone team to maintain (is
> it?)
>
> The use case for file-backed domain configs is for smaller clouds with
> just one or two LDAP-backed domains. There's not a real need for users to
> change domain configs so the file-backed config is plenty fine. I don't see
> a lot of gain from removing that functionality.
>
> I don't particularly care about the keystone-manage tool, if that goes
> away it would still be relatively easy to write a python script to parse
> and upload configs if a user does eventually decide to transition.
>
> As a side note, SUSE happens to be using file-backed domain configs in our
> product. It would not be a big deal to rewrite that bit to use the API, but
> I think it's just as easy to let us keep using it.
>
> Colleen
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] removing domain configuration upload via keystone-manage

[Colleen Murphy]

>
> On Wed, Jun 28, 2017 at 2:00 AM, Lance Bragstad 
> wrote:
>
>> Hi all,
>>
>> Keystone has deprecated the domain configuration upload capability
>> provided through `keystone-manage`. We discussed it's removal in today's
>> meeting [0] and wanted to send a quick note to the operator list. The
>> ability to upload a domain config into keystone was done as a stop-gap
>> until the API was marked as stable [1]. It seems as though file-based
>> domain configuration was only a band-aid until full support was done.
>>
>> Of the operators using the domain config API in keystone, how many are
>> backing their configurations with actual configuration files versus the API?
>>
>>
>> [0] http://eavesdrop.openstack.org/meetings/keystone/2017/keysto
>> ne.2017-06-27-18.00.log.html#l-167 [1] https://github.com/openstack/k
>> eystone/commit/a5c5f5bce812fad3c6c88a23203bd6c00451e7b3
>>
>  I am not clear on why we need to deprecate and remove file-backed domain
configuration. The way I see it:

* It's reflectve with the primary configuration, so I can copy over the
chunks I need from keystone.conf into
/etc/keystone/domains/keystone.domain.conf without thinking too hard about
it
* It's convenient for deployment tools to just lay down config files
* It's not that much extra effort for the keystone team to maintain (is it?)

The use case for file-backed domain configs is for smaller clouds with just
one or two LDAP-backed domains. There's not a real need for users to change
domain configs so the file-backed config is plenty fine. I don't see a lot
of gain from removing that functionality.

I don't particularly care about the keystone-manage tool, if that goes away
it would still be relatively easy to write a python script to parse and
upload configs if a user does eventually decide to transition.

As a side note, SUSE happens to be using file-backed domain configs in our
product. It would not be a big deal to rewrite that bit to use the API, but
I think it's just as easy to let us keep using it.

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

Re: [openstack-dev] [TripleO] Pt. 2 of Passing along some field feedback

[Ben Nemec]

On 06/28/2017 03:03 PM, Steven Hardy wrote:

On Wed, Jun 28, 2017 at 8:06 PM, Ben Nemec  wrote:

A few weeks later than I had planned, but here's the other half of the field
feedback I mentioned in my previous email:

* They very emphatically want in-place upgrades to work when moving from
non-containerized to containerized.  I think this is already the plan, but I
told them I'd make sure development was aware of the desire.


It is the plan, and already has basic CI coverage via
gate-tripleo-ci-centos-7-containers-multinode-upgrades-nv

At this point we need more testing of production-like deployments but
in general this is expected to work.


Okay, that's what I thought and told them initially, but they feel quite 
strongly about this so I told them I would check.  Job done. :-)





* There was also great interest in contributing back some of the custom
templates that they've had to write to get advanced features working in the
field.  Here again we recommended that they start with an RFE so things
could be triaged appropriately.  I'm hoping we can find some developer time
to help polish and shepherd these things through the review process.

* Policy configuration was discussed, and I pointed them at some recent work
we have done around that:
https://docs.openstack.org/developer/tripleo-docs/advanced_deployment/api_policies.html
I'm not sure it fully addressed their issues, but I suggested they take a
closer look and provide feedback on any ways it doesn't meet their needs.

The specific use case they were looking at right now was adding a read-only
role.  They did provide me with a repo containing their initial work, but
unfortunately it's private to Red Hat so I can't share it here.

* They wanted to be able to maintain separate role files instead of one
monolithic roles_data.yaml.  Apparently they have a pre-deploy script now
that essentially concatenates some individual files to get this
functionality.  I think this has already been addressed by
https://review.openstack.org/#/c/445687


Yes this is already possible, but only via the CLI - that feature
needs porting to tripleo-common so that it can be consumed by
tripleo-ui, which was discussed but I'm not sure on the latest status.


* They've also been looking at ways to reorganize the templates in a more
intuitive fashion.  At first glance the changes seemed reasonable, but they
were still just defining the layout.  I don't know that they've actually
tried to use the reorganized templates yet and given the number of relative
paths in tht I suspect it may be a bigger headache than they expect, but I
thought it was interesting.  There may at least be elements of this work
that we can use to make the templates easier to understand for deployers.


More information on this would be helpful, e.g what specific issues
they are trying to solve and the layout they found to be better and
why?


Looking at the contents of the repo again I'm not sure they actually 
rearranged tht at all.  I think they may just have been defining a 
structure for their environment files and role definitions.  I probably 
need to follow up with them when they have a little more concrete idea 
of what they want to do around 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

Re: [openstack-dev] [storyboard][infra][docs] Report a bug and storyboard

[Adam Coldrick]

Hi Andreas,

On 2017-06-28 07:33, Andreas Jaeger wrote:

Hi Storyboard team,

the openstackdocstheme has a "Report a bug" feature, where you can 
click

on the Bug icon and get a link to project's bug area in launchpad
together with information about the documentation (bug tag, git URL of
build, date, SHA, extra text).

How can this be done with storyboard?


Currently there is no support for this exact functionality in StoryBoard 
itself.
You could add some JavaScript to the docs theme to make a POST request 
to the
StoryBoard API with the relevant parameters set, but this would need 
some work
to also get a valid StoryBoard access token to use in the request 
somehow.


Other than that you could settle for linking to an individual project 
view in
StoryBoard, for example https://storyboard.openstack.org/#!/project/456 
has a
button on it for logged-in users to create a story which automatically 
has a

task in that project.

The ability to construct an link to StoryBoard's web UI which 
automatically
populates part of the things needed to create a story seems generally 
useful
though. In particular I can see it potentially being helpful for 
resolving our
lack of bug templates, which has been raised as a problem on more than 
one

occasion.

Supporting this type of feature would allow folk to construct URLs which
automatically populate the description field with some template of their 
choice,
which should hopefully be useful enough to solve both that problem and 
the need
to replicate this "Report a bug" feature adequately. I intend to take a 
look at

how much work it'd be for us to implement that kind of thing in the near
future, and hopefully that'll lead to a more ideal solution than those I 
outlined

above.

Best Regards,

Adam

__
OpenStack Development Mailing 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][keystone] Pt. 2 of Passing along some field feedback

[Ben Nemec]

On 06/28/2017 02:47 PM, Lance Bragstad wrote:



On 06/28/2017 02:29 PM, Fox, Kevin M wrote:

I think everyone would benefit from a read-only role for keystone out of the 
box. Can we get this into keystone rather then in the various distro's?

Yeah - I think that would be an awesome idea. John Garbutt had some good
work on this earlier in the cycle. Most of it was documented in specs
[0] [1]. FWIW - this will be another policy change that is going to have
cross-project effects. It's implementation or impact won't be isolated
to keystone if we want read-only roles out-of-the-box.

[0] https://review.openstack.org/#/c/427872/19
[1] https://review.openstack.org/#/c/428454/


Cool, I will point our folks at those specs.  I know doing a custom 
read-only role has been pretty painful, so I expect they would be very 
happy if this functionality could become standard.


Thanks for the replies.

-Ben

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

[openstack-dev] [tc][swg] The future of the Stewardship Working Group

[Colette Alexander]

Hello Stackers,

As many of you know, I recently took a job with Spotify in New York City. I
spoke with many folks about the transition plans when I was at the Boston
Forum, and we all decided that it would make sense for me to get settled
into the new position before deciding what amounts of time I had to tend to
SWG work, and therefore what my future in the community would look like.

My new job has become a lot busier a lot sooner than expected. I think I'll
have a little bit more time in my schedule in the next month or so to do
OpenStack related work, but after summer holidays, I expect things to pick
back up again.

Because of all of the unknowns around my availability for working on SWG
things, I think now is a good time to start discussing a potential
replacement for me as the chair of the group. I have loved working with
OpenStack and I plan on sticking around in the IRC channel and monitoring
mailing list work, but I don't think it's fair to the SWG, TC or the entire
community for me to stay on as chair when I can't devote as much time as
I'd like to spearheading efforts in the community.

So - that means I'd love to hear from folks about who might be a good
replacement. I have spoken to a few people behind the scenes to gauge
interest, but I'd like to open it up the community as a whole at this point
to start a discussion.

For those of you who don't know what the Stewardship Working Group is:
https://wiki.openstack.org/wiki/Stewardship_Working_Group is a good place
to start

Some of the workstreams going on:
a) Follow up on project ideas from leadership training
https://etherpad.openstack.org/p/pathtocontribution
https://etherpad.openstack.org/p/communication-vision

b) Any more poking/helping along of the TC with their current vision

c) An actual vision for the SWG and their next batch of work (this would be
based on feedback from the training sessions above, and from the community,
collected at the Atlanta PTG - https://etherpad.openstack.org/p/AtlantaPTG-
SWG

d) The future of leadership training (more to schedule? break it up into
smaller groups? who knows?)

I'd be happy to onboard anyone who's interested in terms of getting them up
to speed on these items.

If anyone wants to discuss any of this with me directly I'm gothicmindfood
on IRC.

Thanks so much for being such an amazing community to be in - you all
continue to be some of my favorite humans and I'm so lucky to have gotten a
chance to work with you.

Sincerely,

-colette/gothicmindfood
__
OpenStack Development Mailing 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] Pt. 2 of Passing along some field feedback

[Steven Hardy]

On Wed, Jun 28, 2017 at 8:06 PM, Ben Nemec  wrote:
> A few weeks later than I had planned, but here's the other half of the field
> feedback I mentioned in my previous email:
>
> * They very emphatically want in-place upgrades to work when moving from
> non-containerized to containerized.  I think this is already the plan, but I
> told them I'd make sure development was aware of the desire.

It is the plan, and already has basic CI coverage via
gate-tripleo-ci-centos-7-containers-multinode-upgrades-nv

At this point we need more testing of production-like deployments but
in general this is expected to work.

> * There was also great interest in contributing back some of the custom
> templates that they've had to write to get advanced features working in the
> field.  Here again we recommended that they start with an RFE so things
> could be triaged appropriately.  I'm hoping we can find some developer time
> to help polish and shepherd these things through the review process.
>
> * Policy configuration was discussed, and I pointed them at some recent work
> we have done around that:
> https://docs.openstack.org/developer/tripleo-docs/advanced_deployment/api_policies.html
> I'm not sure it fully addressed their issues, but I suggested they take a
> closer look and provide feedback on any ways it doesn't meet their needs.
>
> The specific use case they were looking at right now was adding a read-only
> role.  They did provide me with a repo containing their initial work, but
> unfortunately it's private to Red Hat so I can't share it here.
>
> * They wanted to be able to maintain separate role files instead of one
> monolithic roles_data.yaml.  Apparently they have a pre-deploy script now
> that essentially concatenates some individual files to get this
> functionality.  I think this has already been addressed by
> https://review.openstack.org/#/c/445687

Yes this is already possible, but only via the CLI - that feature
needs porting to tripleo-common so that it can be consumed by
tripleo-ui, which was discussed but I'm not sure on the latest status.

> * They've also been looking at ways to reorganize the templates in a more
> intuitive fashion.  At first glance the changes seemed reasonable, but they
> were still just defining the layout.  I don't know that they've actually
> tried to use the reorganized templates yet and given the number of relative
> paths in tht I suspect it may be a bigger headache than they expect, but I
> thought it was interesting.  There may at least be elements of this work
> that we can use to make the templates easier to understand for deployers.

More information on this would be helpful, e.g what specific issues
they are trying to solve and the layout they found to be better and
why?

Thanks,

Steve

__
OpenStack Development Mailing 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][keystone] Pt. 2 of Passing along some field feedback

[Lance Bragstad]

On 06/28/2017 02:29 PM, Fox, Kevin M wrote:
> I think everyone would benefit from a read-only role for keystone out of the 
> box. Can we get this into keystone rather then in the various distro's?
Yeah - I think that would be an awesome idea. John Garbutt had some good
work on this earlier in the cycle. Most of it was documented in specs
[0] [1]. FWIW - this will be another policy change that is going to have
cross-project effects. It's implementation or impact won't be isolated
to keystone if we want read-only roles out-of-the-box.

[0] https://review.openstack.org/#/c/427872/19
[1] https://review.openstack.org/#/c/428454/
>
> Thanks,
> Kevin
> 
> From: Ben Nemec [openst...@nemebean.com]
> Sent: Wednesday, June 28, 2017 12:06 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [TripleO] Pt. 2 of Passing along some field feedback
>
> A few weeks later than I had planned, but here's the other half of the
> field feedback I mentioned in my previous email:
>
> * They very emphatically want in-place upgrades to work when moving from
> non-containerized to containerized.  I think this is already the plan,
> but I told them I'd make sure development was aware of the desire.
>
> * There was also great interest in contributing back some of the custom
> templates that they've had to write to get advanced features working in
> the field.  Here again we recommended that they start with an RFE so
> things could be triaged appropriately.  I'm hoping we can find some
> developer time to help polish and shepherd these things through the
> review process.
>
> * Policy configuration was discussed, and I pointed them at some recent
> work we have done around that:
> https://docs.openstack.org/developer/tripleo-docs/advanced_deployment/api_policies.html
>   I'm not sure it fully addressed their issues, but I suggested they
> take a closer look and provide feedback on any ways it doesn't meet
> their needs.
>
> The specific use case they were looking at right now was adding a
> read-only role.  They did provide me with a repo containing their
> initial work, but unfortunately it's private to Red Hat so I can't share
> it here.
>
> * They wanted to be able to maintain separate role files instead of one
> monolithic roles_data.yaml.  Apparently they have a pre-deploy script
> now that essentially concatenates some individual files to get this
> functionality.  I think this has already been addressed by
> https://review.openstack.org/#/c/445687
>
> * They've also been looking at ways to reorganize the templates in a
> more intuitive fashion.  At first glance the changes seemed reasonable,
> but they were still just defining the layout.  I don't know that they've
> actually tried to use the reorganized templates yet and given the number
> of relative paths in tht I suspect it may be a bigger headache than they
> expect, but I thought it was interesting.  There may at least be
> elements of this work that we can use to make the templates easier to
> understand for deployers.
>
> Thanks.
>
> -Ben
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing 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] [TripleO][keystone] Pt. 2 of Passing along some field feedback

[Fox, Kevin M]

I think everyone would benefit from a read-only role for keystone out of the 
box. Can we get this into keystone rather then in the various distro's?

Thanks,
Kevin

From: Ben Nemec [openst...@nemebean.com]
Sent: Wednesday, June 28, 2017 12:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [TripleO] Pt. 2 of Passing along some field feedback

A few weeks later than I had planned, but here's the other half of the
field feedback I mentioned in my previous email:

* They very emphatically want in-place upgrades to work when moving from
non-containerized to containerized.  I think this is already the plan,
but I told them I'd make sure development was aware of the desire.

* There was also great interest in contributing back some of the custom
templates that they've had to write to get advanced features working in
the field.  Here again we recommended that they start with an RFE so
things could be triaged appropriately.  I'm hoping we can find some
developer time to help polish and shepherd these things through the
review process.

* Policy configuration was discussed, and I pointed them at some recent
work we have done around that:
https://docs.openstack.org/developer/tripleo-docs/advanced_deployment/api_policies.html
  I'm not sure it fully addressed their issues, but I suggested they
take a closer look and provide feedback on any ways it doesn't meet
their needs.

The specific use case they were looking at right now was adding a
read-only role.  They did provide me with a repo containing their
initial work, but unfortunately it's private to Red Hat so I can't share
it here.

* They wanted to be able to maintain separate role files instead of one
monolithic roles_data.yaml.  Apparently they have a pre-deploy script
now that essentially concatenates some individual files to get this
functionality.  I think this has already been addressed by
https://review.openstack.org/#/c/445687

* They've also been looking at ways to reorganize the templates in a
more intuitive fashion.  At first glance the changes seemed reasonable,
but they were still just defining the layout.  I don't know that they've
actually tried to use the reorganized templates yet and given the number
of relative paths in tht I suspect it may be a bigger headache than they
expect, but I thought it was interesting.  There may at least be
elements of this work that we can use to make the templates easier to
understand for deployers.

Thanks.

-Ben

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

__
OpenStack Development Mailing 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] removing domain configuration upload via keystone-manage

[Lance Bragstad]

That sounds like reason enough to bump the removal of it to Queens or
later. This was also discussed in IRC today [0]. We've decided to move
forward with the following steps:

- Deprecate the ability to have file-backed domain configuration since
removing the ability to upload domains via keystone-manage makes
file-backed domain configs less useful
- Bump the removal date of domain configuration uploads via keystone-manage
- Remove both pieces together in a subsequent release

Thanks for the input!

[0]
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2017-06-28.log.html#t2017-06-28T18:10:06


On 06/28/2017 04:43 AM, Juan Antonio Osorio wrote:
> On the TripleO side we use the file based approach. Using the API
> would have been easier to orchestrate (no need for reloads/restarts)
> but it's not available yet in puppet-keystone.
>
> On Wed, Jun 28, 2017 at 2:00 AM, Lance Bragstad  > wrote:
>
> Hi all,
>
> Keystone has deprecated the domain configuration upload capability
> provided through `keystone-manage`. We discussed it's removal in
> today's meeting [0] and wanted to send a quick note to the
> operator list. The ability to upload a domain config into keystone
> was done as a stop-gap until the API was marked as stable [1]. It
> seems as though file-based domain configuration was only a
> band-aid until full support was done.
>
> Of the operators using the domain config API in keystone, how many
> are backing their configurations with actual configuration files
> versus the API?
>
>
> [0]
> 
> http://eavesdrop.openstack.org/meetings/keystone/2017/keystone.2017-06-27-18.00.log.html#l-167
> 
> 
> [1]
> 
> https://github.com/openstack/keystone/commit/a5c5f5bce812fad3c6c88a23203bd6c00451e7b3
> 
> 
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
>
>
>
>
> -- 
> Juan Antonio Osorio R.
> e-mail: jaosor...@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



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

[openstack-dev] [TripleO] Pt. 2 of Passing along some field feedback

[Ben Nemec]

A few weeks later than I had planned, but here's the other half of the 
field feedback I mentioned in my previous email:


* They very emphatically want in-place upgrades to work when moving from 
non-containerized to containerized.  I think this is already the plan, 
but I told them I'd make sure development was aware of the desire.


* There was also great interest in contributing back some of the custom 
templates that they've had to write to get advanced features working in 
the field.  Here again we recommended that they start with an RFE so 
things could be triaged appropriately.  I'm hoping we can find some 
developer time to help polish and shepherd these things through the 
review process.


* Policy configuration was discussed, and I pointed them at some recent 
work we have done around that: 
https://docs.openstack.org/developer/tripleo-docs/advanced_deployment/api_policies.html 
 I'm not sure it fully addressed their issues, but I suggested they 
take a closer look and provide feedback on any ways it doesn't meet 
their needs.


The specific use case they were looking at right now was adding a 
read-only role.  They did provide me with a repo containing their 
initial work, but unfortunately it's private to Red Hat so I can't share 
it here.


* They wanted to be able to maintain separate role files instead of one 
monolithic roles_data.yaml.  Apparently they have a pre-deploy script 
now that essentially concatenates some individual files to get this 
functionality.  I think this has already been addressed by 
https://review.openstack.org/#/c/445687


* They've also been looking at ways to reorganize the templates in a 
more intuitive fashion.  At first glance the changes seemed reasonable, 
but they were still just defining the layout.  I don't know that they've 
actually tried to use the reorganized templates yet and given the number 
of relative paths in tht I suspect it may be a bigger headache than they 
expect, but I thought it was interesting.  There may at least be 
elements of this work that we can use to make the templates easier to 
understand for deployers.


Thanks.

-Ben

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Clay Gerrard]

On Wed, Jun 28, 2017 at 7:50 AM, Thierry Carrez 
wrote:

> It's hard for newcomers to the OpenStack world to see what
> is a part of OpenStack and what's not.


Just an aside, this Perception problems works in our favor sometimes too.
I know in the past some BigCorp contributors have been told to "go work on
OpenStack" and the ambiguity leaves room for creative allocation of
resources.  Sometimes the rule-of-thumb is as simple as "if it's hosted on
OpenStack infra you can contribute".  I think internally we understand
software in service of the mission isn't strictly limited to projects under
TC governance - but on the outside ... there's a "perception problem" ;)

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Clay Gerrard]

On Wed, Jun 28, 2017 at 7:50 AM, Thierry Carrez 
wrote:

>
> 2- it lets us host things that are not openstack but which we work on
> (like abandoned Python libraries or GPL-licensed things) in a familiar
> environment
>
>
Do we no longer think openstack hosted infra holds a competitive advantage
for teams that are trying to efficiently collaborate building software in
service of the mission?

If we do, why would we agree on a plan that basically tells teams that are
trying to "get stuff done" to go work it out on github and travis ci or
whatever?  Maybe worse, what happens when a team/project/community grows up
around *one* workflow (not because it's better; but just because the
OpenStack workflow is exclusionary) but then it sees it's
operators/deployers/users adoption swelling around OpenStack and wants to
"join"?  Is adopting the hosted infrastructure later... optional?

If we do NOT think hosting on openstack-infra offers competitive advantage
for teams that are trying to efficiently collaborate building software in
service of the mission ... why heck not?!

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

[openstack-dev] [keystone] office-hours tag

[Lance Bragstad]

Hey all,

I've created a new official tag, 'office-hours' [0]. If you're reviewing
or triaging bugs and come across one that would be a good fit for us to
tackle during office hours, please feel free to tag it. I was
maintaining lists locally, and I'm sure you were, too. This should help
reduce duplicate lists and we can parse the tagged bugs at the beginning
of each session. Let me know if you have any questions.

Thanks,

Lance


[0] https://goo.gl/ZvvBx2



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

[openstack-dev] [doc[ptls] Doc meeting

[Alexandra Settle]

Hey everyone,

The docs meeting will continue in #openstack-meeting as scheduled (Thursday, 
29th of June at 16:00 UTC).

There will be no official agenda, I am opening up this meeting for any docs 
liaisons and PTLs to come and chat about the docs migration and any questions 
they may have.

The meeting chair will be me! Hope you can all make it ☺

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Jay Pipes]

On 06/28/2017 01:07 PM, Clint Byrum wrote:

The root cause of all of this until now has been not really knowing what
OpenStack is. The visioning recently done was a great step in the right
direction toward this. I would like to make sure that we acknowledge
this while we address symptoms of the past choices we made.

In particular, I wonder if landing the vision, pushing harder to fill
in any missing parts of the constellation concept, and getting actual
constellations defined _immediately_, would do just as much as drawing
these concerte lines around abstract bits of software.


So much this.

Best,
-jay

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Clint Byrum]

This message makes a bunch of salient, valid points, none of which I
wish to directly address.

However, on the whole, I think the analysis stops short of pushing through
to a root cause, and thus, the solution proposed is entirely focused on
symptoms.

The root cause of all of this until now has been not really knowing what
OpenStack is. The visioning recently done was a great step in the right
direction toward this. I would like to make sure that we acknowledge
this while we address symptoms of the past choices we made.

In particular, I wonder if landing the vision, pushing harder to fill
in any missing parts of the constellation concept, and getting actual
constellations defined _immediately_, would do just as much as drawing
these concerte lines around abstract bits of software.

So, I'm not saying any of this is wrong. I like the solution proposed,
and I think all of the problems stated are in fact problems. I just
wonder if we're bouncing off "visions are hard" and falling into a bit
of yak shaving around the easy problems when we as a community should
remain focused on the vision.

If nothing else, I'd like to see it clearly stated how this solution
fits in with the vision.

Excerpts from Thierry Carrez's message of 2017-06-28 16:50:01 +0200:
> Hi everyone,
> 
> Two weeks ago, as a result of a discussion at the Board+TC+UC workgroup
> working on "better communicating what is openstack", I started a
> thread[1] about moving away from big tent terminology. The thread went
> in a lot of directions, including discussing GitHub mirroring strategy,
> what makes projects want to be official, the need for returning to a
> past when everything was (supposedly) simpler, and naming fun.
> 
> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-June/118368.html
> 
> Many agreed that the "Big Tent" name (as a synonym to "official
> openstack projects") is hurting more than it helps, and we should stop
> using it. The issue is, merely stopping using it won't be enough. We
> have tried, and the name sticks. You need to replace the name by
> something that sticks more, or address the root cause directly.
> 
> The central issue being discussed here is an issue of external
> perception. It's hard for newcomers to the OpenStack world to see what
> is a part of OpenStack and what's not. If you google "openstack machine
> learning", the first hits are Cognitive and Meteos, and it's impossible
> to tell that those are actually not OpenStack projects. One of those has
> been dead for 2 years -- having people think that those are official
> projects hurts all the OpenStack projects, by lowering expectations
> around what that means, in terms of quality, maintenance, or community.
> 
> The confusion mainly stems from the fact that OpenStack project
> infrastructure is open to any open source project (and it's nobody's job
> to clean up dead things). So you can find (on our wiki, on our
> mailing-list, on our cgit farm, on our gerrit, on our GitHub
> organization...) things that are actually not OpenStack, even with the
> expansive "are you one of us" definition. Arguably the most confusing
> aspect is the "openstack/" prefix in the git repository name, which
> indicates some kind of brand association.
> 
> I'd say we have two options. We can address the perception issue on the
> edges, or you can treat the root cause. Neither of those options is
> really an OpenStack  governance change (or "big tent" change) -- they
> are more about what to do with things that are actually *not* in our
> governance.
> 
> Addressing the perception on the edges means making it clearer when
> things are not official. The thread above discussed a lot of potential
> solutions. We could give unofficial things a catchy group name
> (Stackforge, Opium, Electrons...), and hope it sticks. We could find a
> way to tag all projects on GitHub that are not official, or mirror them
> to another organization, or stop mirroring them altogether. We could
> remove the openstack/ prefix from all the projects we host. We could
> actively mark all wiki pages that are not about an official project. We
> could set up a separate Gerrit or separate ML for hosted projects
> development discussions. The main issue with that approach is that it's
> a *lot* of work, and it never completely eliminates the confusion.
> 
> Removing the root cause would be a more radical move: stop offering
> hosting to non-OpenStack projects on OpenStack infrastructure
> altogether. We originally did that for a reason, though. The benefits of
> offering that service are:
> 
> 1- it lets us set up code repositories and testing infrastructure before
> a project applies to be an official OpenStack project.
> 
> 2- it lets us host things that are not openstack but which we work on
> (like abandoned Python libraries or GPL-licensed things) in a familiar
> environment
> 
> 3- it spreads "the openstack way" (Gerrit, Zuul) beyond openstack itself
> 
> I would argue that we could handle 

Re: [openstack-dev] [octavia] fail to plug vip to amphora

[Michael Johnson]

Hi Yipei,

 

I have meant to add this as a config option, but in the interim you can do the 
following to disable the automatic cleanup by disabling the revert flow in 
taskflow:

 

octavia/common/base_taskflow.py line 37 add “never_resolve=True,” to the engine 
load parameters.

 

Michael

 

From: Yipei Niu [mailto:newy...@gmail.com] 
Sent: Monday, June 26, 2017 11:34 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [octavia] fail to plug vip to amphora

 

Hi, Micheal,

 

Thanks a lot for your help, but I still have one question. 

 

In Octavia, once the controller worker fails plugging VIP to the amphora, the 
amphora is deleted immediately, making it impossible to trace the error. How to 
prevent Octavia from stopping and deleting the amphora? 

 

Best regards,

Yipei 

 

On Mon, Jun 26, 2017 at 11:21 AM, Yipei Niu  > wrote:

Hi, all,

 

I am trying to create a load balancer in octavia. The amphora can be booted 
successfully, and can be reached via icmp. However, octavia fails to plug vip 
to the amphora through the amphora client api and returns 500 status code, 
causing some errors as follows.

 

   |__Flow 
'octavia-create-loadbalancer-flow': InternalServerError: Internal Server Error

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
Traceback (most recent call last):

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
  File 
"/usr/local/lib/python2.7/dist-packages/taskflow/engines/action_engine/executor.py",
 line 53, in _execute_task

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
result = task.execute(**arguments)

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
  File 
"/opt/stack/octavia/octavia/controller/worker/tasks/amphora_driver_tasks.py", 
line 240, in execute

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
amphorae_network_config)

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
  File 
"/opt/stack/octavia/octavia/controller/worker/tasks/amphora_driver_tasks.py", 
line 219, in execute

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
amphora, loadbalancer, amphorae_network_config)

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
  File 
"/opt/stack/octavia/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 
137, in post_vip_plug

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
net_info)

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
  File 
"/opt/stack/octavia/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 
378, in plug_vip

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
return exc.check_exception(r)

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
  File "/opt/stack/octavia/octavia/amphorae/drivers/haproxy/exceptions.py", 
line 32, in check_exception

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
raise responses[status_code]()

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
InternalServerError: Internal Server Error

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker

 

To fix the problem, I log in the amphora and find that there is one http server 
process is listening on port 9443, so I think the amphora api services is 
active. But do not know how to further investigate what error happens inside 
the amphora api service and solve it? Look forward to your valuable comments.

 

Best regards,

Yipei 

 

__
OpenStack Development Mailing 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][tc] How to deal with confusion around "hosted projects"

[Thierry Carrez]

Anita Kuno wrote:
> On 2017-06-28 10:50 AM, Thierry Carrez wrote:
>> For (1) we could have an "onboarding" project team that would help
>> incoming projects through the initial steps of becoming an openstack
>> project. The team would act as an umbrella team, an experimental area
>> for projects that have some potential to become an OpenStack project one
>> day. There would be a time limit -- if after one year(?) it looks like
>> you won't become an openstack project after all, the onboarding team
>> would clean you up. I actually think a bit more project mentoring would
>> serve us better than our current hands-free approach.
> Who is going to staff this team?
> 
> I think a large reason that we are in the situation we are in is due to
> the fact that large corp can't see the importance of paying salaries for
> people to help others and keep things clean and tidy. They will foot the
> bill for building the thing, they tend to be reluctant to pay to keep
> things tidy and well maintained.
> 
> I'm not saying it isn't a good idea. I felt the work was very valuable
> when I did it and I thought the community appreciated it a lot. But for
> the last year I have not had the benefit of an employer who feels there
> is enough value in this approach to pay my salary to do the work.
> 
> Would be glad to be proven wrong.

At the TC level, we started to try to pair prospective teams with
mentors to help them through. I'm pretty sure current and past
volunteers on this task would be happy to help and seed that team.

It's not that much work, and it's work we end up doing anyway (questions
always get asked, they just get asked at awkward times in the
application process).

Currently the first contact we get is when a project team applies to
become an official project (which invariably comes too early). Engaging
earlier with a team of mentors sounds like it would save us a lot of
problems down the line, and clear out a lot of confusion with the process.

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [tripleo][kolla][puppet] DLRN maintenance on June 29, 8:00 AM UTC

[Javier Pena]

This is also of interest for CI jobs in TripleO, kolla and 
puppet-openstack-integration.

Javier

- Forwarded Message -
Hi,

We need to run some maintenance activities on the DLRN public instance on June 
29, starting at 8:00 UTC time (10:00 CET). As a result, the repositories hosted 
by trunk.rdoproject.org will be intermittently unavailable. The maintenance is 
expected to last 1 hour.

Regards,
Javier

___
rdo-list mailing list
rdo-l...@redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list

To unsubscribe: rdo-list-unsubscr...@redhat.com

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Anita Kuno]

On 2017-06-28 10:50 AM, Thierry Carrez wrote:

For (1) we could have an "onboarding" project team that would help
incoming projects through the initial steps of becoming an openstack
project. The team would act as an umbrella team, an experimental area
for projects that have some potential to become an OpenStack project one
day. There would be a time limit -- if after one year(?) it looks like
you won't become an openstack project after all, the onboarding team
would clean you up. I actually think a bit more project mentoring would
serve us better than our current hands-free approach.

Who is going to staff this team?

I think a large reason that we are in the situation we are in is due to 
the fact that large corp can't see the importance of paying salaries for 
people to help others and keep things clean and tidy. They will foot the 
bill for building the thing, they tend to be reluctant to pay to keep 
things tidy and well maintained.


I'm not saying it isn't a good idea. I felt the work was very valuable 
when I did it and I thought the community appreciated it a lot. But for 
the last year I have not had the benefit of an employer who feels there 
is enough value in this approach to pay my salary to do the work.


Would be glad to be proven wrong.

Thanks,
Anita.

__
OpenStack Development Mailing 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][kolla-ansible] Proposing Surya (spsurya) for core

[Swapnil Kulkarni]

On Wed, Jun 14, 2017 at 9:16 PM, Michał Jastrzębski  wrote:
> Hello,
>
> With great pleasure I'm kicking off another core voting to
> kolla-ansible and kolla teams:) this one is about spsurya. Voting will
> be open for 2 weeks (till 28th Jun).
>
> Consider this mail my +1 vote, you know the drill:)
>
> Regards,
> Michal
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


+1

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

Re: [openstack-dev] [octavia] fail to plug vip to amphora

[Yipei Niu]

Hi, Ganpat,

Thanks a lot for your comments. I do not really understand your solution.
Do you mean I need to create a dummy file and verify it in the amphora?

Best regards,
Yipei
__
OpenStack Development Mailing 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][tc] How to deal with confusion around "hosted projects"

[Neil Jerram]

On Wed, Jun 28, 2017 at 3:50 PM Thierry Carrez 
wrote:

> Removing the root cause would be a more radical move: stop offering
> hosting to non-OpenStack projects on OpenStack infrastructure
> altogether. [...]


I think this is the right solution for OpenStack.  In particular, I think
it will clarify external perception, and will promote internal focus on
developing integration between the remaining projects that _are_ OpenStack.

I say that even as maintainer of one of the hosted non-official projects
(networking-calico) that would be booted out under this proposal.  I will
have a bit of work to do to set up equivalent CI that I currently get from
the OpenStack infrastructure - but that will have fringe benefits too, in
terms of my team's ability to change things more rapidly.  I'm grateful for
the experience and mentoring that I've had while using the OpenStack
infrastructure - that makes me feel confident that I can now set up what
networking-calico needs myself.

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

Re: [openstack-dev] [ptls][all][tc][docs] Documentation migration spec

[Doug Hellmann]

Excerpts from Andreas Jaeger's message of 2017-06-28 08:45:47 +0200:
> For those migrating from oslosphinx to openstackdocstheme, I strongly
> advise to follow the docs for openstackdocstheme 1.11 on how to set it up:
> 
> https://docs.openstack.org/openstackdocstheme/latest/
> 
> Andreas

Another work item is moving the automatically generated class
documentation that pbr produces by setting the api_doc_dir value
in the pbr section of setup.cfg.

See https://docs.openstack.org/developer/pbr/user/using.html#pbr
for details and https://review.openstack.org/#/c/478294/2/setup.cfg
for an example.

Doug

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

Re: [openstack-dev] [masakari][nova] Allow evacuation of instances in resized state

[Chris Friesen]

On 06/28/2017 05:50 AM, Kekane, Abhishek wrote:


In masakari, we are setting an instance to an error state if the vmstate is
resized before evacuating it to a new host.


Arguably the instance should be set to an error state as soon as you notice that 
the compute node is down.



Once an instance (which was in
resized state) is evacuated then it becomes active on the new host. The main
problem with this implementation from user’s point of view is the instance goes
into active state after evacuation, it should be in stopped state if the prior
action on the instance before resizing was stop. In masakari, It’s possible to
set the vm state to stopped state after evacuation but for a short period the
instance will go into the active state which is unacceptable.


That's a valid point, I think.


*Proposing changes to Nova:*

In the current nova code, if the instance is in stopped state before evacuation,
then it remains in the stopped state after evacuation is complete. On the
similar lines, we are proposing nova should allow instance to be evacuated in
resized state and after evacuation the instance should remain in stopped state
if the prior action on the instance is stopped before resizing.


The current nova code looks at the vm_state to decide whether or not it's 
allowable to evacuate, and while "stopped" is a valid state to evacuate from 
"resized" is not.  In your scenario it's both "stopped" *and* "resized" 
simultaneously, but there's no way to represent that in the vmstate so I think 
we'd have to check the power state, which would mean extending the 
check_instance_state() routine since it doesn't currently handle the power state.


The trickier question is how to handle the "resized" state...after evacuating an 
instance in the "resized" state should you be able to revert the resize?  If so, 
how would that work in the case where the instance was resized on the same host 
originally and that host is no longer available?  If not, then you'll end up 
with resources permanently reserved on the host the instance was on before the 
resize.  I suppose one option would be to auto-confirm the resize in the case of 
a resize-to-same-host, but that'll be tricky to process with the host not available.


Also, it should be noted that when rebuilding/evacuating a "stopped" instance 
the nova code just boots it up as normal and sets the vm_state to "active", then 
realizes that it's supposed to be stopped and sets the task_state to 
"powering_off" and goes down the normal path to stop the instance, eventually 
setting the vm_state to "stopped".  So you're still going to end up with the 
same state transitions as what you have now, though the timing will probably be 
a bit tighter.  If you really want a stopped instance to not actually start up 
on a rebuild/evacuate then that would be additional work.


Chris

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

Re: [openstack-dev] [ptls][all][tc][docs] Documentation migration spec

[Doug Hellmann]

Excerpts from Alexandra Settle's message of 2017-06-23 12:09:41 +:
> Hi everyone,
> 
> This morning (afternoon) the specification for the documentation migration 
> was merged. Thanks to all that took time to review :)
> 
> You can now view here in all its glory: 
> https://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html
> 
> If you have any questions, feel free to shoot them to me or Doug :)
> 
> Let’s begin!
> 
> Alex

Based on some work Sean did with the nova API reference project, I've
set up a burndown chart to track our progress. It updates hourly.

https://doughellmann.com/doc-migration/

Doug

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2017-06-28 16:50:01 +0200:
> Hi everyone,
> 
> Two weeks ago, as a result of a discussion at the Board+TC+UC workgroup
> working on "better communicating what is openstack", I started a
> thread[1] about moving away from big tent terminology. The thread went
> in a lot of directions, including discussing GitHub mirroring strategy,
> what makes projects want to be official, the need for returning to a
> past when everything was (supposedly) simpler, and naming fun.
> 
> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-June/118368.html
> 
> Many agreed that the "Big Tent" name (as a synonym to "official
> openstack projects") is hurting more than it helps, and we should stop
> using it. The issue is, merely stopping using it won't be enough. We
> have tried, and the name sticks. You need to replace the name by
> something that sticks more, or address the root cause directly.
> 
> The central issue being discussed here is an issue of external
> perception. It's hard for newcomers to the OpenStack world to see what
> is a part of OpenStack and what's not. If you google "openstack machine
> learning", the first hits are Cognitive and Meteos, and it's impossible
> to tell that those are actually not OpenStack projects. One of those has
> been dead for 2 years -- having people think that those are official
> projects hurts all the OpenStack projects, by lowering expectations
> around what that means, in terms of quality, maintenance, or community.
> 
> The confusion mainly stems from the fact that OpenStack project
> infrastructure is open to any open source project (and it's nobody's job
> to clean up dead things). So you can find (on our wiki, on our
> mailing-list, on our cgit farm, on our gerrit, on our GitHub
> organization...) things that are actually not OpenStack, even with the
> expansive "are you one of us" definition. Arguably the most confusing
> aspect is the "openstack/" prefix in the git repository name, which
> indicates some kind of brand association.
> 
> I'd say we have two options. We can address the perception issue on the
> edges, or you can treat the root cause. Neither of those options is
> really an OpenStack  governance change (or "big tent" change) -- they
> are more about what to do with things that are actually *not* in our
> governance.
> 
> Addressing the perception on the edges means making it clearer when
> things are not official. The thread above discussed a lot of potential
> solutions. We could give unofficial things a catchy group name
> (Stackforge, Opium, Electrons...), and hope it sticks. We could find a
> way to tag all projects on GitHub that are not official, or mirror them
> to another organization, or stop mirroring them altogether. We could
> remove the openstack/ prefix from all the projects we host. We could
> actively mark all wiki pages that are not about an official project. We
> could set up a separate Gerrit or separate ML for hosted projects
> development discussions. The main issue with that approach is that it's
> a *lot* of work, and it never completely eliminates the confusion.
> 
> Removing the root cause would be a more radical move: stop offering
> hosting to non-OpenStack projects on OpenStack infrastructure
> altogether. We originally did that for a reason, though. The benefits of
> offering that service are:
> 
> 1- it lets us set up code repositories and testing infrastructure before
> a project applies to be an official OpenStack project.
> 
> 2- it lets us host things that are not openstack but which we work on
> (like abandoned Python libraries or GPL-licensed things) in a familiar
> environment
> 
> 3- it spreads "the openstack way" (Gerrit, Zuul) beyond openstack itself
> 
> I would argue that we could handle (1) and (2) within our current
> governance.
> 
> For (1) we could have an "onboarding" project team that would help
> incoming projects through the initial steps of becoming an openstack
> project. The team would act as an umbrella team, an experimental area
> for projects that have some potential to become an OpenStack project one
> day. There would be a time limit -- if after one year(?) it looks like
> you won't become an openstack project after all, the onboarding team
> would clean you up. I actually think a bit more project mentoring would
> serve us better than our current hands-free approach.
> 
> For (2) we could also have some other official project team as an
> umbrella for those deps we depend on and have to continue maintaining.
> Or we could expand Oslo's team scope to cover it. It's just a couple of
> repositories anyway.
> 
> That leaves (3). I would argue that was a nice thing to have, but its
> impact was very limited (not so many successful/alive projects in that
> category). I guess if the need is still there and people really want to
> work on this, it could be (and actually has been) set up as a parallel
> infrastructure. The confusion that stems from running it 

Re: [openstack-dev] [nova] bug triage experimentation

[Sean Dague]

On 06/28/2017 10:33 AM, Ben Nemec wrote:
> 
> 
> On 06/23/2017 11:52 AM, Sean Dague wrote:
>> The Nova bug backlog is just over 800 open bugs, which while
>> historically not terrible, remains too large to be collectively usable
>> to figure out where things stand. We've had a few recent issues where we
>> just happened to discover upgrade bugs filed 4 months ago that needed
>> fixes and backports.
>>
>> Historically we've tried to just solve the bug backlog with volunteers.
>> We've had many a brave person dive into here, and burn out after 4 - 6
>> months. And we're currently without a bug lead. Having done a big giant
>> purge in the past
>> (http://lists.openstack.org/pipermail/openstack-dev/2014-September/046517.html)
>>
>> I know how daunting this all can be.
>>
>> I don't think that people can currently solve the bug triage problem at
>> the current workload that it creates. We've got to reduce the smart
>> human part of that workload.
>>
>> But, I think that we can also learn some lessons from what active github
>> projects do.
>>
>> #1 Bot away bad states
>>
>> There are known bad states of bugs - In Progress with no open patch,
>> Assigned but not In Progress. We can just bot these away with scripts.
>> Even better would be to react immediately on bugs like those, that helps
>> to train folks how to use our workflow. I've got some starter scripts
>> for this up at - https://github.com/sdague/nova-bug-tools
> 
> Just saw the update on https://bugs.launchpad.net/nova/+bug/1698010 and
> I don't agree that assigned but not in progress is an invalid state.  If
> it persists for a period of time then sure, but to me assigning yourself
> a bug is a signal that you're working on it and nobody else needs to.
> Otherwise you end up with multiple people working a bug without
> realizing someone else already was.  I've seen that happen more than once.

The other case, where folks assign themselves and never do anything,
happens about 100 times a month.

We don't live in an exclusive lock environment, anyone can push a fix
for a bug, and gerrit assigns it to them. I don't see why we'd treat LP
any differently. Yes, this sometimes leads to duplicate fixes, however
in the current model it's far more frequent for bugs to be blocked away
as "assigned" when no one is working on them.

A future version might be smarter and give folks a 7 day window or
something, but parsing back the history to understand the right logic
there is tricky enough that it's a future enhancement at best.

-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] realtime kvm cpu affinities

[Chris Friesen]

On 06/28/2017 03:34 AM, Sahid Orentino Ferdjaoui wrote:

On Tue, Jun 27, 2017 at 04:00:35PM +0200, Henning Schild wrote:



As far as i remember it was not straight forward to get two novas onto
one host in the older release, i am not surprised that causing trouble
with the update to mitaka. If we agree on 2 novas and aggregates as the
recommended way we should make sure the 2 novas is a supported feature,
covered in test-cases and documented.
Dedicating a whole machine to either RT or nonRT would imho be no
viable option.


The realtime nodes should be isolated by aggregates as you seem to do.


Yes, with two novas on one machine. They share one libvirt using
different instrance-prefixes and have some other config options set, so
they do not collide on resources.


It's clearly not what I was suggesting, you should have 2 groups of
compute hosts. One aggregate with hosts for the non-RT VMs and an
other one for hosts with RT VMs.


Not all clouds are large enough to have an entire physical machine dedicated to 
RT VMs.  So Henning divided up the resources of the physical machine between two 
nova-compute instances and put them in separate aggregates.


It would be easier for operators if one single nova instance could manage both 
RT and non-RT instances on the same host (presumably running an RT OS).


Chris

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

[openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Thierry Carrez]

Hi everyone,

Two weeks ago, as a result of a discussion at the Board+TC+UC workgroup
working on "better communicating what is openstack", I started a
thread[1] about moving away from big tent terminology. The thread went
in a lot of directions, including discussing GitHub mirroring strategy,
what makes projects want to be official, the need for returning to a
past when everything was (supposedly) simpler, and naming fun.

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-June/118368.html

Many agreed that the "Big Tent" name (as a synonym to "official
openstack projects") is hurting more than it helps, and we should stop
using it. The issue is, merely stopping using it won't be enough. We
have tried, and the name sticks. You need to replace the name by
something that sticks more, or address the root cause directly.

The central issue being discussed here is an issue of external
perception. It's hard for newcomers to the OpenStack world to see what
is a part of OpenStack and what's not. If you google "openstack machine
learning", the first hits are Cognitive and Meteos, and it's impossible
to tell that those are actually not OpenStack projects. One of those has
been dead for 2 years -- having people think that those are official
projects hurts all the OpenStack projects, by lowering expectations
around what that means, in terms of quality, maintenance, or community.

The confusion mainly stems from the fact that OpenStack project
infrastructure is open to any open source project (and it's nobody's job
to clean up dead things). So you can find (on our wiki, on our
mailing-list, on our cgit farm, on our gerrit, on our GitHub
organization...) things that are actually not OpenStack, even with the
expansive "are you one of us" definition. Arguably the most confusing
aspect is the "openstack/" prefix in the git repository name, which
indicates some kind of brand association.

I'd say we have two options. We can address the perception issue on the
edges, or you can treat the root cause. Neither of those options is
really an OpenStack  governance change (or "big tent" change) -- they
are more about what to do with things that are actually *not* in our
governance.

Addressing the perception on the edges means making it clearer when
things are not official. The thread above discussed a lot of potential
solutions. We could give unofficial things a catchy group name
(Stackforge, Opium, Electrons...), and hope it sticks. We could find a
way to tag all projects on GitHub that are not official, or mirror them
to another organization, or stop mirroring them altogether. We could
remove the openstack/ prefix from all the projects we host. We could
actively mark all wiki pages that are not about an official project. We
could set up a separate Gerrit or separate ML for hosted projects
development discussions. The main issue with that approach is that it's
a *lot* of work, and it never completely eliminates the confusion.

Removing the root cause would be a more radical move: stop offering
hosting to non-OpenStack projects on OpenStack infrastructure
altogether. We originally did that for a reason, though. The benefits of
offering that service are:

1- it lets us set up code repositories and testing infrastructure before
a project applies to be an official OpenStack project.

2- it lets us host things that are not openstack but which we work on
(like abandoned Python libraries or GPL-licensed things) in a familiar
environment

3- it spreads "the openstack way" (Gerrit, Zuul) beyond openstack itself

I would argue that we could handle (1) and (2) within our current
governance.

For (1) we could have an "onboarding" project team that would help
incoming projects through the initial steps of becoming an openstack
project. The team would act as an umbrella team, an experimental area
for projects that have some potential to become an OpenStack project one
day. There would be a time limit -- if after one year(?) it looks like
you won't become an openstack project after all, the onboarding team
would clean you up. I actually think a bit more project mentoring would
serve us better than our current hands-free approach.

For (2) we could also have some other official project team as an
umbrella for those deps we depend on and have to continue maintaining.
Or we could expand Oslo's team scope to cover it. It's just a couple of
repositories anyway.

That leaves (3). I would argue that was a nice thing to have, but its
impact was very limited (not so many successful/alive projects in that
category). I guess if the need is still there and people really want to
work on this, it could be (and actually has been) set up as a parallel
infrastructure. The confusion that stems from running it on top of the
very same infrastructure is just too costly for us at this point.

This radical solution still means work, but it's one-time governance
work, rather than infra changes / continuous curation work. It *is*
radical though, especially 

Re: [openstack-dev] [kolla][kolla-ansible] Proposing Surya (spsurya) for core

[Michał Jastrzębski]

Aaaand it's done. Congrats Surya and welcome to core team!

On 27 June 2017 at 19:56, zhubingbing  wrote:
>
>
>
> +1
>
>>> -Original Message-
>>> From: Michał Jastrzębski [mailto:inc...@gmail.com]
>>> Sent: Wednesday, June 14, 2017 10:46 PM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> 
>>> Subject: [openstack-dev] [kolla][kolla-ansible] Proposing Surya (spsurya)
>>> for
>>> core
>>>
>>> Hello,
>>>
>>> With great pleasure I'm kicking off another core voting to kolla-ansible
>>> and
>>> kolla teams:) this one is about spsurya. Voting will be open for 2 weeks
>>> (till
>>> 28th Jun).
>>>
>>> Consider this mail my +1 vote, you know the drill:)
>>>
>>> Regards,
>>> Michal
>>>
>>>
>>
>>-
>>duonghq
>>__
>>OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

[openstack-dev] [tripleo] Queens PTG

[Emilien Macchi]

Hey folks,

Let's start to prepare the next PTG in Denver.

Here's the schedule draft:
https://docs.google.com/spreadsheets/d/1xmOdT6uZ5XqViActr5sBOaz_mEgjKSCY7NEWcAEcT-A/pubhtml?gid=397241312=true=gmail
We'll have a room Wednesday, Thursday and Friday. We'll probably
finish by end of Friday morning.

Etherpad for the PTG:
https://etherpad.openstack.org/p/tripleo-ptg-queens

There is no agenda or topics yet but please feel free to propose things.

We'll make sure we make some progress on PTG scheduling before end of pike-3.

Thanks,
-- 
Emilien Macchi

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

[openstack-dev] [telemetry][ceilometer]Cannot get vmware virtual machine's disk usage rate via vsphere inspector

[Along Meng]

HI, all
Today I try to add a new pollster plugin in ceilometer-agent-compute to
collect vmware virtual machines's disk usage rate.

After researched the vmware docs:
https://www.vmware.com/support/developer/converter-
sdk/conv61_apireference/disk_counters.html#usage

I think I can call the vsphere inspector get the counter capacity.provisioned
and capacity.usage.
Then I can get the virtual machine's disk usage rate via: disk_util =
capacity.usage/capacity.provisioned

*But, when I add a new function in vsphere inspector like below, It cannot
get any data from vcenter:*
My example code like this:

ceilometer.compute.virt.vmware.inspector.VsphereInspector#inspect_disks
=
def inspect_disks(self, instance, duration=None):
vm_moid = self._ops.get_vm_moid(instance.id)
if not vm_moid:
raise virt_inspector.InstanceNotFoundException(
_('VM %s not found in VMware vSphere') % instance.id)

VC_DISK_PROVISIONED_CNTR = "disk:capacity.provisioned:average"
disk_counter_id = self._ops.get_perf_counter_id(VC_DISK_PROVISIONED_CNTR
)
disk_infos = self._ops.query_vm_aggregate_stats(vm_moid,
mem_counter_id, duration)
print “The disk info is:%s” % disk_infos


The disk_infos is empty.

I try to use these functions to query the counter value:
self._ops.query_vm_device_stats(vm_moid, disk_counter_id, duration)
self._ops.query_vm_aggregate_stats(vm_moid, mem_counter_id, duration)

*But cannot get any data from vcenter, and I'm sure the vcenter service is
correct in my env.*

*Does anyone know what's wrong with my code? *
*Or is there any other solutions for my requirement.*

Thanks~

==
MengAlong
__
OpenStack Development Mailing 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] bug triage experimentation

[Ben Nemec]

On 06/23/2017 11:52 AM, Sean Dague wrote:

The Nova bug backlog is just over 800 open bugs, which while
historically not terrible, remains too large to be collectively usable
to figure out where things stand. We've had a few recent issues where we
just happened to discover upgrade bugs filed 4 months ago that needed
fixes and backports.

Historically we've tried to just solve the bug backlog with volunteers.
We've had many a brave person dive into here, and burn out after 4 - 6
months. And we're currently without a bug lead. Having done a big giant
purge in the past
(http://lists.openstack.org/pipermail/openstack-dev/2014-September/046517.html)
I know how daunting this all can be.

I don't think that people can currently solve the bug triage problem at
the current workload that it creates. We've got to reduce the smart
human part of that workload.

But, I think that we can also learn some lessons from what active github
projects do.

#1 Bot away bad states

There are known bad states of bugs - In Progress with no open patch,
Assigned but not In Progress. We can just bot these away with scripts.
Even better would be to react immediately on bugs like those, that helps
to train folks how to use our workflow. I've got some starter scripts
for this up at - https://github.com/sdague/nova-bug-tools


Just saw the update on https://bugs.launchpad.net/nova/+bug/1698010 and 
I don't agree that assigned but not in progress is an invalid state.  If 
it persists for a period of time then sure, but to me assigning yourself 
a bug is a signal that you're working on it and nobody else needs to. 
Otherwise you end up with multiple people working a bug without 
realizing someone else already was.  I've seen that happen more than once.


Would it be possible to only un-assign such bugs if they've been in that 
state for a week?  At that point it seems safe to say the assignee has 
either moved on or that the bug is tricky and additional input would be 
useful anyway.


Otherwise, big +1 to a bug bot.  I need to try running it against the 
~700 open TripleO bugs...




#2 Use tag based workflow

One lesson from github projects, is the github tracker has no workflow.
Issues are openned or closed. Workflow has to be invented by every team
based on a set of tags. Sometimes that's annoying, but often times it's
super handy, because it allows the tracker to change workflows and not
try to change the meaning of things like "Confirmed vs. Triaged" in your
mind.

We can probably tag for information we know we need at lot easier. I'm
considering something like

* needs.system-version
* needs.openstack-version
* needs.logs
* needs.subteam-feedback
* has.system-version
* has.openstack-version
* has.reproduce

Some of these a bot can process the text on and tell if that info was
provided, and comment how to provide the updated info. Some of this
would be human, but with official tags, it would probably help.

#3 machine assisted functional tagging

I'm playing around with some things that might be useful in mapping new
bugs into existing functional buckets like: libvirt, volumes, etc. We'll
see how useful it ends up being.

#4 reporting on smaller slices

Build some tooling to report on the status and change over time of bugs
under various tags. This will help visualize how we are doing
(hopefully) and where the biggest piles of issues are.

The intent is the normal unit of interaction would be one of these
smaller piles. Be they the 76 libvirt bugs, 61 volumes bugs, or 36
vmware bugs. It would also highlight the rates of change in these piles,
and what's getting attention and what is not.


This is going to be kind of an ongoing experiment, but as we currently
have no one spear heading bug triage, it seemed like a good time to try
this out.

Comments and other suggestions are welcomed. The tooling will have the
nova flow in mind, but I'm trying to make it so it takes a project name
as params on all the scripts, so anyone can use it. It's a little hack
and slash right now to discover what the right patterns are.

-Sean



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

Re: [openstack-dev] [tc][all] Move away from meeting channels

[Jeremy Stanley]

On 2017-06-28 11:41:50 +0200 (+0200), Flavio Percoco wrote:
> On 27/06/17 18:22 +, Jeremy Stanley wrote:
[...]
> >By lurking in official meeting channels I'm often able to jump
> >straight into a discussion when someone asks me a question in a
> >meeting I wouldn't normally attend but am around during. I can see
> >the discussion instantly up to that point as opposed to
> >inconveniencing the attendees by asking to have everything repeated
> >for me after /join'ing. The channel logs on eavesdrop.o.o aren't
> >really a substitute there because of the batched flushing in the bot
> >delays Web-based logs by some number of minutes.
> 
> Would recommend folks pinging you (and others) on openstack-dev be
> enough? You can then momentarily join the channel and they can
> bring you up to speed, although it is not as convinient as just
> being there.

It will be a viable (if less convenient) workaround, sure. Most
often it comes up like:

[protracted discussion of problem over several minutes time]
 we probably need to do [solution X]
 how do we go about accomplishing [solution X]?
[long pause]
 maybe fungi knows... hey, fungi: you around?

If this were taking place on a less common channel I don't lurk in
(granted I've taken to lurking in lots of individual projects'
channels for similar reasons), then once they got me to /join they'd
have the pleasure of spending several minutes repeating themselves
to catch me up before I could answer.

> I'd also like to encourage folks to reach out on the ML if people
> don't happen to be around on IRC.

Yes, this I agree with. Contrary to popular belief, I am sometimes
briefly unconscious. However, people often forget or never get
around to doing that, so I'm happy when I can help more immediately
(or at least spot it in scrollback when my wetware comes out of
standby, and follow up with them at that time if it seems
important).

Anyway, I don't think we need to propose "moving away from meeting
channels" but rather "allowing teams to not use meeting channels if
it's inconvenient for them." I expect many (most even?) teams who
continue to hold regularly scheduled meetings would do so in the
official meeting channels even if given the opportunity and freedom
to use a different channel.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [Watcher] handle multiple data sources in watcher

[Bin Zhou]

Vincent,

Thanks for your comment. Here is my understanding of the problem:
1. cloud operators will choose one particular metrics monitoring stack/source
but not multiple of them on the same target;
2. in the same cloud, it is possible that some compute are monitored
with Monasca, some computes are monitored with ceilometer, but it is
not the common deployment practice
3. In the same cloud, it is very rare that multiple monitoring stacks
run on the same compute - here is why: 1) larger performance overhead,
2) correlation between different data samples become difficult (due to
potentially different sampling intervals, and API interfaces), 3) not
scale;

Basically the design I proposed is to support all the three scenarios
above, but the implementation will be optimized for scenario #1 only.
1. define a global configuration of default monitoring stack, for example,
[Defaults]
default_metrics = Monasca
default_alarm = Monasca
metrics_engines = Monasca, Gnnochi, Ceilometer, ## list of metrics
engines in preference order

[Metrics]
Monasca_URL = ""
Gnnochi_URL = ""
...
[Alarms]
Monasca_URL = ""
Aodh= ""

[Events]


2. At the time when watcher starts, watcher read in all the
configurations and populated its internal data structure including the
preference and availability.
3. An abstract layer will be built for each data source. For
example, the following interfaces will be implemented for metrics
data source:
get_metrics_cpu()
get_metrics_io()
get_metrics_memory()
4. Each data source pliugin will implement the abstract interface. If the
plugin doesn't support the function, it will throw exceptions
5. A consumer of a service, will use the abstract interface to access
the service. Unless a caller specify a engine explicitly, the default
engine will be used. If the default engine does not support the
function, the call will be directed to the next available engine in
the preference order.

Please let me know what you think.

regards,
Bin

On Thu, Jun 22, 2017 at 10:52 AM, Vincent FRANCOISE
 wrote:
> Bin Zhou,
>
> IMHO, we should have a new configuration that introduces weights for each
> metrics backend we intend to use. Then, we use the datasource with the
> biggest weight that actually provides the metric we are requesting. This way,
> only one datasource will ever serve a given metric although many datasources
> may be involved at once. By doing so, we can provide sensible defaults as to
> which datasource has the best expected performance (i.e. prefer Monasca
> over Ghocchi wherever possible or vice-versa) and also provide something
> that will work straight out of the box.
>
> What do you think?
>
> Vincent Françoise
> 
> From: Bin Zhou 
> Sent: 22 June 2017 15:39
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [Watcher] handle multiple data sources in watcher
>
> Hi All,
>
> I am working on the blueprint
> https://blueprints.launchpad.net/watcher/+spec/watcher-multi-datasource.
> It is a good idea to construct an abstract layer and hide data source
> details from the consumer of the data. But I have one doubt about the
> possibility of using multiple metrics data sources at the same
> deployment. Metrics instrumentation is not free, it comes with
> overhead of CPU, memory, storage. Production deployment should always
> avoid to use multiple monitoring tools for the same metrics.
>
> I propose to have a default monitoring engine in  the watcher
> configuration. In case that multiple monitoring engines are
> configured, and a user has to collect different metrics from different
> monitoring engine, the caller has to specify the engine explicitly to
> avoid using the default engine.
>
> Please let me know if you have any concerns or better solutions. Thanks!
>
> Bin Zhou (lakerzhou)
>
> __
> OpenStack Development Mailing 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] diskimage builder works for trusty but not for xenial

[Ignazio Cassano]

PS
PS
Unfortunately os-refresh-config is not working also for centos7 if I create
a new image today and then a new centos 7 instance on ocata.
Last centos7 image where os-refresh-config works fine has been created with
diskimage-builder on 23 of March 2017.
Please, what is changed meanwhile ?
Regards
Ignazio

2017-06-22 8:00 GMT+02:00 Ignazio Cassano :

> It works fine
> Thanks
>
> 2017-06-22 0:24 GMT+02:00 Ian Wienand :
>
>> On 06/21/2017 04:44 PM, Ignazio Cassano wrote:
>>
>>> * Connection #0 to host cloud-images.ubuntu.com left intact
>>> Downloaded and cached
>>> http://cloud-images.ubuntu.com/xenial/current/xenial-server-
>>> cloudimg-amd64-root.tar.gz,
>>> having forced upstream caches to revalidate
>>> xenial-server-cloudimg-amd64-root.tar.gz: FAILED
>>> sha256sum: WARNING: 1 computed checksum did NOT match
>>>
>>
>> Are there any problems on http://cloud-images.ubuntu.com ?
>>>
>>
>> There was [1] which is apparently fixed.
>>
>> As Paul mentioned, the -minimal builds take a different approach and
>> build the image from debootstrap, rather than modifying the upstream
>> image.  They are generally well tested just as a side-effect of infra
>> relying on them daily.  You can use DIB_DISTRIBUTION_MIRROR to set
>> that to a local mirror and eliminate another source of instability
>> (however, that leaves the mirror in the final image ... a known issue.
>> Contributions welcome :)
>>
>> -i
>>
>> [1] https://bugs.launchpad.net/cloud-images/+bug/1699396
>>
>>
>
__
OpenStack Development Mailing 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]

[meher.hihi]

Hello everyone,

I introduce myself; Meher Hihi; I am doing my internship at Orange Labs 
Networks Lannion-France for the diploma of computer network and 
telecommunications engineer.

I am working on innovative distribution solutions for the virtualization 
infrastructure of the network functions and more specifically on the Openstack 
Tricircle solution, which is why I join your community to participate in your 
discussions and learn from your advice.

Indeed, I try to install Tricircle on a single node by following this 
documentation 
"https://docs.openstack.org/developer/tricircle/installation-guide.html#single-pod-installation-with-devstack;.
I managed to install Devstack without any problems, but when I modify the 
local.conf file by adding the Tricircle plugin integration and the HOST_IP, the 
script does not want to work and stops on an error of Start of the Keystone 
service.

I wanted to know if the problem is with my config file that is attached or I 
lack other things to configure. You will also find in the file the IP address 
of the machine.

I thank you in advance for the help you will bring me. Sincerely,

Best regards,

Meher

[Logo Orange]

Meher Hihi
Intern
ORANGE/IMT/OLN/WNI/ODIS/NAVI
Fixe : +33 2 96 07 03 
71
Mobile : +33 7 58 38 68 
87
meher.h...@orange.com



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

[stack@Tricircle devstack]$ cat local.conf
#
Sample DevStack local.conf.
#
# This sample file is intended to be used for your typical Tricircle DevStack
# environment that's running all of OpenStack on a single host.
#
# No changes to this sample configuration are required for this to work.
#

[[local|localrc]]

ADMIN_PASSWORD=secret
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
SERVICE_TOKEN=$ADMIN_PASSWORD

HOST_IP=192.168.123.72

# Specify Central Region name
# CENTRAL_REGION_NAME=CentralRegion

# Specify port for central Neutron server
# TRICIRCLE_NEUTRON_PORT=20001

enable_plugin tricircle https://github.com/openstack/tricircle/

# disable_service horizon

GIT_BASE=${GIT_BASE:-https://git.openstack.org}




[stack@Tricircle devstack]$ ip addr
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 52:54:00:f8:74:c3 brd ff:ff:ff:ff:ff:ff
inet 192.168.123.72/24 brd 192.168.123.255 scope global eth0
   valid_lft forever preferred_lft forever
inet6 fe80::8fb4:fcf8:f6fb:90ce/64 scope link
   valid_lft forever preferred_lft forever
3: virbr0:  mtu 1500 qdisc noqueue state 
DOWN qlen 1000
link/ether 52:54:00:3a:a3:fb brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
   valid_lft forever preferred_lft forever
4: virbr0-nic:  mtu 1500 qdisc pfifo_fast master virbr0 
state DOWN qlen 1000
link/ether 52:54:00:3a:a3:fb brd ff:ff:ff:ff:ff:ff
5: ovs-system:  mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 16:5e:36:91:33:69 brd ff:ff:ff:ff:ff:ff
6: br-int:  mtu 1500 qdisc noop state DOWN qlen 1000
link/ether ae:51:80:27:77:4a brd ff:ff:ff:ff:ff:ff
7: br-ex:  mtu 1500 qdisc noqueue state 
UNKNOWN qlen 1000
link/ether be:a5:b3:15:69:44 brd 

Re: [openstack-dev] [OpenStack-docs] [Openstack-operators][dev][doc] Operations Guide future

[Alexandra Settle]

Hi Mario,

Just so everyone is aware that you’re offering assistance, I’ve re-added the ML 
back in.

Definitely appreciate the help! The only schedule is that it is delivered by 
the Pike release. You can see the details and dates here: 
https://releases.openstack.org/pike/schedule.html

Thank you again! Anyone else able to help Mario?

Cheers,

Alex

From: Mario Pranjic 
Date: Wednesday, June 28, 2017 at 7:32 AM
To: Alexandra Settle 
Subject: Re: [OpenStack-docs] [Openstack-operators][dev][doc] Operations Guide 
future


Hi,

I can help with wiki. It depends what are the schedules?

I am on vacation with sometimes limited access to machine with net. If it's not 
on a tight schedule day to day basis, count me in.


Mario Pranjic, M.Sc.C.S, RHCSA, RHCE
t: +47 454 90 613
e: ma...@pranjic.no
skype: mario.pranjic.no
LinkedIn: https://no.linkedin.com/in/mariopranjic
On 06/27/2017 05:52 PM, Alexandra Settle wrote:
Thanks everyone for your feedback regarding the proposal below.

Going forwards we are going to implement Option 3.

If anyone is able to help out with this migration, please let me know :)

Looking forward to getting started!

From: Alexandra Settle 
Date: Thursday, June 1, 2017 at 4:06 PM
To: OpenStack Operators 
,
 
"'openstack-d...@lists.openstack.org'"
 
Cc: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [Openstack-operators] [dev] [doc] Operations Guide future

Hi everyone,

I haven’t had any feedback regarding moving the Operations Guide to the 
OpenStack wiki. I’m not taking silence as compliance. I would really like to 
hear people’s opinions on this matter.

To recap:

1.  Option one: Kill the Operations Guide completely and move the 
Administration Guide to project repos.
2.  Option two: Combine the Operations and Administration Guides (and then 
this will be moved into the project-specific repos)
3.  Option three: Move Operations Guide to OpenStack wiki (for ease of 
operator-specific maintainability) and move the Administration Guide to project 
repos.

Personally, I think that option 3 is more realistic. The idea for the last 
option is that operators are maintaining operator-specific documentation and 
updating it as they go along and we’re not losing anything by combining or 
deleting. I don’t want to lose what we have by going with option 1, and I think 
option 2 is just a workaround without fixing the problem – we are not getting 
contributions to the project.

Thoughts?

Alex

From: Alexandra Settle 
Date: Friday, May 19, 2017 at 1:38 PM
To: Melvin Hillsman , 
OpenStack Operators 

Subject: Re: [Openstack-operators] Fwd: [openstack-dev] [openstack-doc] [dev] 
What's up doc? Summit recap edition

Hi everyone,

Adding to this, I would like to draw your attention to the last dot point of my 
email:

“One of the key takeaways from the summit was the session that I joint 
moderated with Melvin Hillsman regarding the Operations and Administration 
Guides. You can find the etherpad with notes here: 
https://etherpad.openstack.org/p/admin-ops-guides  The session was really 
helpful – we were able to discuss with the operators present the current 
situation of the documentation team, and how they could help us maintain the 
two guides, aimed at the same audience. The operator’s present at the session 
agreed that the Administration Guide was important, and could be maintained 
upstream. However, they voted and agreed that the best course of action for the 
Operations Guide was for it to be pulled down and put into a wiki that the 
operators could manage themselves. We will be looking at actioning this item as 
soon as possible.”

I would like to go ahead with this, but I would appreciate feedback from 
operators who were not able to attend the summit. In the etherpad you will see 
the three options that the operators in the room recommended as being viable, 
and the voted option being moving the Operations Guide out of 
docs.openstack.org into a wiki. The aim of this was to empower the operations 
community to take more control of the updates in an environment they are more 
familiar with (and available to others).

What does everyone think of the proposed options? Questions? Other thoughts?

Alex

From: Melvin Hillsman 
Date: Friday, May 19, 2017 at 1:30 PM
To: OpenStack Operators 

[openstack-dev] [masakari][nova] Allow evacuation of instances in resized state

[Kekane, Abhishek]

Hi Devs,

Masakari [1] provides Virtual Machine High Availability (VMHA) service for 
OpenStack clouds by automatically recovering the KVM-based Virtual Machine(VM)s 
from failure events such as VM process down, provisioning process down, and 
nova-compute host failure. It also provides API service to manage and control 
the automated rescue mechanism.

Masakari use cases:
---
1. Allow evacuation of an instance which is in resized state.
2. If instance was in stopped state before resizing then after evacuation it 
should remain in stopped state instead of active state.

Problem from Nova:
--
Nova does not allow evacuation of an instance which is in resized state.

Implementation in masakari:
---
In masakari, we are setting an instance to an error state if the vmstate is 
resized before evacuating it to a new host. Once an instance (which was in 
resized state) is evacuated then it becomes active on the new host. The main 
problem with this implementation from user's point of view is the instance goes 
into active state after evacuation, it should be in stopped state if the prior 
action on the instance before resizing was stop. In masakari, It's possible to 
set the vm state to stopped state after evacuation but for a short period the 
instance will go into the active state which is unacceptable.

Proposing changes to Nova:
In the current nova code, if the instance is in stopped state before 
evacuation, then it remains in the stopped state after evacuation is complete. 
On the similar lines, we are proposing nova should allow instance to be 
evacuated in resized state and after evacuation the instance should remain in 
stopped state if the prior action on the instance is stopped before resizing.  
If the vmstate is resized, the old vmstate in instance_systemmetadata will be 
either active/stop. Based on this old vmstate, nova compute can decide whether 
to set the vm state to active or stopped during evacuation.

Please let me know your opinion about allowing evacuation of instances in 
resized state in nova.

[1] https://github.com/openstack/masakari

Thank you,

Abhishek Kekane


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
OpenStack Development Mailing 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] diskimage builder works for trusty but not for xenial

[Ignazio Cassano]

PS
I generated a centos7 and a xenial image with the same disk image builder
version/procedure but when I create a xenial instance on ocata, running
os-refresh-config it reports the following output:
root@nuovaxenial:~# os-refresh-config
[2017-06-28 10:32:28,104] (os-refresh-config) [INFO] Starting phase
pre-configure
Traceback (most recent call last):
  File "/usr/local/bin/os-refresh-config", line 11, in 
sys.exit(main())
  File
"/opt/stack/venvs/os-refresh-config/local/lib/python2.7/site-packages/os_refresh_config/os_refresh_config.py",
line 149, in main
subprocess.check_call(args, close_fds=True)
  File "/usr/lib/python2.7/subprocess.py", line 536, in check_call
retcode = call(*popenargs, **kwargs)
  File "/usr/lib/python2.7/subprocess.py", line 523, in call
return Popen(*popenargs, **kwargs).wait()
  File "/usr/lib/python2.7/subprocess.py", line 711, in __init__
errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1343, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory



Centos 7 works fine

Regards
Ignazio


2017-06-22 8:00 GMT+02:00 Ignazio Cassano :

> It works fine
> Thanks
>
> 2017-06-22 0:24 GMT+02:00 Ian Wienand :
>
>> On 06/21/2017 04:44 PM, Ignazio Cassano wrote:
>>
>>> * Connection #0 to host cloud-images.ubuntu.com left intact
>>> Downloaded and cached
>>> http://cloud-images.ubuntu.com/xenial/current/xenial-server-
>>> cloudimg-amd64-root.tar.gz,
>>> having forced upstream caches to revalidate
>>> xenial-server-cloudimg-amd64-root.tar.gz: FAILED
>>> sha256sum: WARNING: 1 computed checksum did NOT match
>>>
>>
>> Are there any problems on http://cloud-images.ubuntu.com ?
>>>
>>
>> There was [1] which is apparently fixed.
>>
>> As Paul mentioned, the -minimal builds take a different approach and
>> build the image from debootstrap, rather than modifying the upstream
>> image.  They are generally well tested just as a side-effect of infra
>> relying on them daily.  You can use DIB_DISTRIBUTION_MIRROR to set
>> that to a local mirror and eliminate another source of instability
>> (however, that leaves the mirror in the final image ... a known issue.
>> Contributions welcome :)
>>
>> -i
>>
>> [1] https://bugs.launchpad.net/cloud-images/+bug/1699396
>>
>>
>
__
OpenStack Development Mailing 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] Routed Networks, flat driver and physical network awareness

[Sam Betts (sambetts)]

Thanks for the interest in Ironic routed networks support! I think some of our 
on-going work should solve the issues you’ve described here.

On the ironic service side the major feature required for routed networks 
support is physical network awareness, patches for this are progressing well 
and can be found here: https://review.openstack.org/#/q/topic:bug/1666009

This feature will allow ironic to be aware of which neutron physnet each 
baremetal node NIC is connected too, which lets us make intelligent decisions 
when mapping neutron ports to physical NICs on the baremetal server, and which 
provides us with required information to feed the segment to host mapping data 
into neutron.

The additional pieces which will be required to make routed networks work exist 
the new openstack/networking-baremetal repo, which is where we will be storing 
any neutron drivers and agents required to make ironic neutron networking 
operate correctly.

The first puzzle piece is a new ML2 driver which provides the functionality for 
binding baremetal vnic type ports into statically/manually configured (flat) 
networks:
https://review.openstack.org/#/c/448073/

With this driver, the flat network interface in Ironic will no longer 
incorrectly do the port binding for flat networks by binding the neutron port 
to the nova host that requested the ironic deploy, and instead it will be able 
to use the baremetal vnic type and set the binding host id to the ironic node 
uuid.

The second puzzle piece is to do with populating the host to physical network 
mapping information in neutron so that it can calculate the segment to host 
mapping information, that is done by using the neutron L2 agent RPC API to push 
this information up into neutron, and the current proposed solution for that 
can be found here: https://review.openstack.org/#/c/456235/

Once this is in place then neutron will be aware about which physical network 
segments each baremetal is plugged into and by populating nova placement’s API 
aggregates (like it does for normal nova compute hosts) will ensure that 
scheduling gives you a valid baremetal node when you request a baremetal 
instance on a routed network.

Any help and/or reviews of this work would be most appreciated, 

Sam Betts (sambetts)

On 28/06/2017, 10:31, "Harald Jensås"  wrote:

Hi,

With the following Neutron patches recently merged, it is now possible
to provide DHCP service to instances on remote routed networks that
have a dhcp forwarder configured.

https://review.openstack.org/#/c/459861/
https://review.openstack.org/#/c/468744/ 
https://review.openstack.org/476477

This enables provisioning of baremetal machines on remote routed
networks as well. Removing the need to deploy ironic
conductor/inspector etc with local connection to each routed network
segment.

However with the flat driver this does not work, because the flat
driver bind neutron ports to the node running ironic-conductor service,
e.g 'nova_host_id'. Not to the actual baremetal node. (Ref: https://git
hub.com/openstack/ironic/blob/master/ironic/drivers/modules/network/fla
t.py#L64)

The result of binding to the 'nova_host_id' causes this error for
baremetal nodes on the remote routed network segment.

INFO ironic.conductor.task_manager [req-11f5c864-cc1a-49ee-b224-
a6695c1a9678 87f6dc660b1f43f79efa4355080e118c
6a8453039524487ca0bbf191cdc6317d - default default] Node f19ecc51-c8ec-
4d34-a349-206a5ae97ed2 moved to provision state "deploy fail
ed" from state "deploying"; target provision state is "active":
NetworkError: Unable to set binding:host_id for neutron port 5e674173-
32d9-4ec9-be2a-7f2b3aa02336. Error: Host ironic-
conductor.node.example.com is not connected to a segment where the
existing fixed_ips on port 5e6741
73-32d9-4ec9-be2a-7f2b3aa02336 will function given the routed network
topology.


I can workaround this by not binding the port:
$ sudo sed -i \
s/'binding:host_id': host_id/'binding:host_id': None/" \
ironic/drivers/modules/network/flat.py


I can see good progress on the phys-net aware spec. But with the flat
driver this will not help, as the nova_host_id is used for binding. Not
the ironic baremetal node uuid.


What would be a good way forward here?
 - Change the flat driver to not bind the port?
 - Change the flat driver to bind using the ironic node uuid, and rely
on phys-net info being populated in Neutron? (Requieres: baremetal
neutron agent https://review.openstack.org/#/c/456235/ + several
changes related to phys-net)
 - Another driver? 'flat-routed' that does one of the above?
 - Keep the flat driver, but register the ironic-conductor as a
separate host in neutron and populate phys-nets in neutron for this
'ironic_host_id' with all networks 

Re: [openstack-dev] [octavia] fail to plug vip to amphora

[Ganpat Agarwal]

Hello Yipei,

"*octavia.amphorae.backends.agent.api_server.listener [-] Failed to verify
haproxy file: Command '['haproxy', '-c', '-L', 'NK20KVuD6oi5NrRP7KOVflM*
*3MsQ', '-f',
'/var/lib/octavia/bca2c985-471a-4477-8217-92fa71d04cb7/haproxy.cfg.new']'
returned non-zero exit status 1*"

Verification of haproxy cfg file is failing.

You can create a dummy file from the haproxy template files(jinja2 files)
and verify on any system with haproxy installed.
*haproxy -c -f "filename"*

Regards,
Ganpat

On Wed, Jun 28, 2017 at 3:19 PM, Yipei Niu  wrote:

> Hi, Michael,
>
> Thanks for your help. I have already created a load balancer successfully,
> but failed creating a listener. The detailed errors of amphora-agent and
> syslog in the amphora are as follows.
>
> In amphora-agent.log:
>
> [2017-06-28 08:54:12 +] [1209] [INFO] Starting gunicorn 19.7.0
> [2017-06-28 08:54:13 +] [1209] [DEBUG] Arbiter booted
> [2017-06-28 08:54:13 +] [1209] [INFO] Listening at: http://[::]:9443
> (1209)
> [2017-06-28 08:54:13 +] [1209] [INFO] Using worker: sync
> [2017-06-28 08:54:13 +] [1209] [DEBUG] 1 workers
> [2017-06-28 08:54:13 +] [1816] [INFO] Booting worker with pid: 1816
> [2017-06-28 08:54:15 +] [1816] [DEBUG] POST /0.5/plug/vip/10.0.1.8
> :::192.168.0.12 - - [28/Jun/2017:08:54:59 +] "POST /0.5/plug/vip/
> 10.0.1.8 HTTP/1.1" 202 78 "-" "Octavia HaProxy Rest Client/0.5 (
> https://wiki.openstack.org/wiki/Octavia)"
> [2017-06-28 08:59:18 +] [1816] [DEBUG] PUT
> /0.5/listeners/9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4/
> bca2c985-471a-4477-8217-92fa71d04cb7/haproxy
> :::192.168.0.12 - - [28/Jun/2017:08:59:19 +] "PUT
> /0.5/listeners/9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4/
> bca2c985-471a-4477-8217-92fa71d04cb7/haproxy HTTP/1.1" 400 414 "-"
> "Octavia HaProxy Rest Client/0.5 (https://wiki.openstack.org/wiki/Octavia
> )"
>
> In syslog:
>
> Jun 28 08:57:14 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 ec2:
> #
> Jun 28 08:57:14 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 ec2:
> -BEGIN SSH HOST KEY FINGERPRINTS-
> Jun 28 08:57:14 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 ec2: 1024
> SHA256:qDQcKq2Je/CzlpPndccMf0aR0u/KPJEEIAl4RraAgVc
> root@amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 (DSA)
> Jun 28 08:57:15 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 ec2: 256
> SHA256:n+5tCCdJwASMaD/kJ6fm0kVNvXDh4aO0si2Uls4MXkI
> root@amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 (ECDSA)
> Jun 28 08:57:15 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 ec2: 256
> SHA256:7RWMBOW+QKzeolI6BDSpav9dVZuon58weIQJ9/peVxE
> root@amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 (ED25519)
> Jun 28 08:57:16 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 ec2: 2048
> SHA256:9z+EcAAUyTENKJRctKCzPslK6Yf4c7s9R8sEflDITIU
> root@amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 (RSA)
> Jun 28 08:57:16 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 ec2:
> -END SSH HOST KEY FINGERPRINTS-
> Jun 28 08:57:16 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 ec2:
> #
> Jun 28 08:57:17 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4
> cloud-init[2092]: Cloud-init v. 0.7.9 running 'modules:final' at Wed, 28
> Jun 2017 08:57:03 +. Up 713.82 seconds.
> Jun 28 08:57:17 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4
> cloud-init[2092]: Cloud-init v. 0.7.9 finished at Wed, 28 Jun 2017 08:57:16
> +. Datasource DataSourceConfigDrive [net,ver=2][source=/dev/sr0].  Up
> 727.30 seconds
> Jun 28 08:57:19 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 systemd[1]:
> Started Execute cloud user/final scripts.
> Jun 28 08:57:19 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 systemd[1]:
> Reached target Cloud-init target.
> Jun 28 08:57:19 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 systemd[1]:
> Startup finished in 52.054s (kernel) + 11min 17.647s (userspace) = 12min
> 9.702s.
> Jun 28 08:59:19 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4
> amphora-agent[1209]: 2017-06-28 08:59:19.243 1816 ERROR
> octavia.amphorae.backends.agent.api_server.listener [-] Failed to verify
> haproxy file: Command '['haproxy', '-c', '-L', 'NK20KVuD6oi5NrRP7KOVflM
> 3MsQ', '-f', 
> '/var/lib/octavia/bca2c985-471a-4477-8217-92fa71d04cb7/haproxy.cfg.new']'
> returned non-zero exit status 1
> Jun 28 09:00:11 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 systemd[1]:
> Starting Cleanup of Temporary Directories...
> Jun 28 09:00:12 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4
> systemd-tmpfiles[3040]: [/usr/lib/tmpfiles.d/var.conf:14] Duplicate line
> for path "/var/log", ignoring.
> Jun 28 09:00:15 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 systemd[1]:
> Started Cleanup of Temporary Directories.
>
> Look forward to your valuable comments.
>
> Best regards,
> Yipei
>
> On Tue, Jun 27, 2017 at 2:33 PM, Yipei Niu  wrote:
>
>> Hi, Micheal,
>>
>> Thanks a lot for your help, but I still have one question.
>>
>> In Octavia, once 

Re: [openstack-dev] [octavia] fail to plug vip to amphora

[Yipei Niu]

Hi, Michael,

Thanks for your help. I have already created a load balancer successfully,
but failed creating a listener. The detailed errors of amphora-agent and
syslog in the amphora are as follows.

In amphora-agent.log:

[2017-06-28 08:54:12 +] [1209] [INFO] Starting gunicorn 19.7.0
[2017-06-28 08:54:13 +] [1209] [DEBUG] Arbiter booted
[2017-06-28 08:54:13 +] [1209] [INFO] Listening at: http://[::]:9443
(1209)
[2017-06-28 08:54:13 +] [1209] [INFO] Using worker: sync
[2017-06-28 08:54:13 +] [1209] [DEBUG] 1 workers
[2017-06-28 08:54:13 +] [1816] [INFO] Booting worker with pid: 1816
[2017-06-28 08:54:15 +] [1816] [DEBUG] POST /0.5/plug/vip/10.0.1.8
:::192.168.0.12 - - [28/Jun/2017:08:54:59 +] "POST /0.5/plug/vip/
10.0.1.8 HTTP/1.1" 202 78 "-" "Octavia HaProxy Rest Client/0.5 (
https://wiki.openstack.org/wiki/Octavia)"
[2017-06-28 08:59:18 +] [1816] [DEBUG] PUT
/0.5/listeners/9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4/bca2c985-471a-4477-8217-92fa71d04cb7/haproxy
:::192.168.0.12 - - [28/Jun/2017:08:59:19 +] "PUT
/0.5/listeners/9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4/bca2c985-471a-4477-8217-92fa71d04cb7/haproxy
HTTP/1.1" 400 414 "-" "Octavia HaProxy Rest Client/0.5 (
https://wiki.openstack.org/wiki/Octavia)"

In syslog:

Jun 28 08:57:14 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 ec2:
#
Jun 28 08:57:14 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 ec2:
-BEGIN SSH HOST KEY FINGERPRINTS-
Jun 28 08:57:14 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 ec2: 1024
SHA256:qDQcKq2Je/CzlpPndccMf0aR0u/KPJEEIAl4RraAgVc
root@amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 (DSA)
Jun 28 08:57:15 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 ec2: 256
SHA256:n+5tCCdJwASMaD/kJ6fm0kVNvXDh4aO0si2Uls4MXkI
root@amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 (ECDSA)
Jun 28 08:57:15 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 ec2: 256
SHA256:7RWMBOW+QKzeolI6BDSpav9dVZuon58weIQJ9/peVxE
root@amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 (ED25519)
Jun 28 08:57:16 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 ec2: 2048
SHA256:9z+EcAAUyTENKJRctKCzPslK6Yf4c7s9R8sEflDITIU
root@amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 (RSA)
Jun 28 08:57:16 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 ec2: -END
SSH HOST KEY FINGERPRINTS-
Jun 28 08:57:16 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 ec2:
#
Jun 28 08:57:17 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4
cloud-init[2092]: Cloud-init v. 0.7.9 running 'modules:final' at Wed, 28
Jun 2017 08:57:03 +. Up 713.82 seconds.
Jun 28 08:57:17 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4
cloud-init[2092]: Cloud-init v. 0.7.9 finished at Wed, 28 Jun 2017 08:57:16
+. Datasource DataSourceConfigDrive [net,ver=2][source=/dev/sr0].  Up
727.30 seconds
Jun 28 08:57:19 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 systemd[1]:
Started Execute cloud user/final scripts.
Jun 28 08:57:19 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 systemd[1]:
Reached target Cloud-init target.
Jun 28 08:57:19 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 systemd[1]:
Startup finished in 52.054s (kernel) + 11min 17.647s (userspace) = 12min
9.702s.
Jun 28 08:59:19 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4
amphora-agent[1209]: 2017-06-28 08:59:19.243 1816 ERROR
octavia.amphorae.backends.agent.api_server.listener [-] Failed to verify
haproxy file: Command '['haproxy', '-c', '-L', 'NK20KVuD6oi5NrRP7KOVflM
3MsQ', '-f',
'/var/lib/octavia/bca2c985-471a-4477-8217-92fa71d04cb7/haproxy.cfg.new']'
returned non-zero exit status 1
Jun 28 09:00:11 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 systemd[1]:
Starting Cleanup of Temporary Directories...
Jun 28 09:00:12 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4
systemd-tmpfiles[3040]: [/usr/lib/tmpfiles.d/var.conf:14] Duplicate line
for path "/var/log", ignoring.
Jun 28 09:00:15 amphora-9ed4f0a5-6b1e-4832-97cc-fb8d1518cbd4 systemd[1]:
Started Cleanup of Temporary Directories.

Look forward to your valuable comments.

Best regards,
Yipei

On Tue, Jun 27, 2017 at 2:33 PM, Yipei Niu  wrote:

> Hi, Micheal,
>
> Thanks a lot for your help, but I still have one question.
>
> In Octavia, once the controller worker fails plugging VIP to the amphora,
> the amphora is deleted immediately, making it impossible to trace the
> error. How to prevent Octavia from stopping and deleting the amphora?
>
> Best regards,
> Yipei
>
> On Mon, Jun 26, 2017 at 11:21 AM, Yipei Niu  wrote:
>
>> Hi, all,
>>
>> I am trying to create a load balancer in octavia. The amphora can be
>> booted successfully, and can be reached via icmp. However, octavia fails to
>> plug vip to the amphora through the amphora client api and returns 500
>> status code, causing some errors as follows.
>>
>>|__Flow
>> 'octavia-create-loadbalancer-flow': InternalServerError: Internal Server
>> Error
>> 

Re: [openstack-dev] [tc][all] Move away from meeting channels

[Flavio Percoco]

On 27/06/17 18:22 +, Jeremy Stanley wrote:

On 2017-06-26 15:27:21 +0200 (+0200), Thierry Carrez wrote:

Flavio Percoco wrote:
> [...]
> Not being able to easily ping someone during a meeting is kind
> of a bummer but I'd argue that assuming someone is in the
> meeting channel and available at all times is a mistake to begin
> with.

I think people can be pinged by PM or on #openstack-dev, it's just an
habit to take. It's just that there are cases  where people passively
mention you, without going up to a formal ping -- I usually go back
later to that person to answer the issue they informally raised. We'll
lose that, but it's minor enough.

[...]

By lurking in official meeting channels I'm often able to jump
straight into a discussion when someone asks me a question in a
meeting I wouldn't normally attend but am around during. I can see
the discussion instantly up to that point as opposed to
inconveniencing the attendees by asking to have everything repeated
for me after /join'ing. The channel logs on eavesdrop.o.o aren't
really a substitute there because of the batched flushing in the bot
delays Web-based logs by some number of minutes.


Would recommend folks pinging you (and others) on openstack-dev be enough? You
can then momentarily join the channel and they can bring you up to speed,
although it is not as convinient as just being there.

I'd also like to encourage folks to reach out on the ML if people don't happen
to be around on IRC.

Flavio

--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [openstack-ansible][neutron][designate] Failure trying to set dns_domain from command line

[Graham Hayes]

On 27/06/17 23:53, Lawrence J. Albinson wrote:
> Hi Graham,
> 
> As ever, many thanks for clarifying that. And I shall put in a feature
> request as you suggest.
> 
> In the meantime, presumably the missing pieces that I need are those
> described in:
> 
> https://docs.openstack.org/ocata/networking-guide/config-dns-int.html
> 
> under
> 
> 'Configuring OpenStack Networking for integration with an external
> DNS service'.
> 
> and covering:
> 
> [default]
> external_dns_driver = designate
> 
> [designate]
> url =  etc 
> 
> Kind regards, Lawrence

Yes, that is the right section.

- Graham

> 
> On 27/06/17 16:57, Graham Hayes wrote:
>> On 27/06/17 16:36, Lawrence J. Albinson wrote:
>>> Hi Graham,
>>>
>>> Many thanks for the pointer. I hadn't added dns to the plugin list.
>>>
>>> I did, however, set the following:
>>>
>>> neutron_designate_enabled:  True
>> Ah - unfortunately there is two ways of integrating Neutron + Designate
>>
>> The external DNS plug, which allows you to use "--dns-domain" on a per
>> network basis, and "designate-sink"
>>
>> designate-sink was written before Designate was an official project, and
>> uses notifications. It is very powerful, but requires deployers to
>> write custom plugins for it to work well.
>>
>> What OSA is missing is "neutron external DNS integration" - which is the
>> code that we use for "--dns-domain"
>>
>> If you file a request here it will go on to the to do list:
>>
>> https://blueprints.launchpad.net/openstack-ansible
>>
>> - Graham
>>
>>> I'm wondering if the two together will fix things. I shall know by the 
>>> morning.
>>>
>>> Again, many thanks.
>>>
>>> Kind regards, Lawrence
>>> 
>>> From: Graham Hayes
>>> Sent: 27 June 2017 16:14
>>> To: openstack-dev@lists.openstack.org
>>> Subject: Re: [openstack-dev] [openstack-ansible][neutron][designate] 
>>> Failure trying to set dns_domain from command line
>>>
>>> On 27/06/17 15:01, Lawrence J. Albinson wrote:
 Hello Colleagues,

 I am trying to enable dynamic updating of DNSaaS when a port or VM is
 created/deleted.

 I have DNSaaS working with Bind9 as the back-end and I am able to
 manually create/update/delete entries with the openstack client and/or
 the designate client and see Bind9 reflect those changes.

 However, I am unable to set a dns_domain name for a network from the
 openstack CLI and/or the neutron CLI.

 I have tried the following:

 neutron net-update --dns-domain example.com
 64b50baa-acd8-4269-8a3a-767b70c7d18d
 neutron net-update --dns-domain example.com public
 neutron net-update --dns-domain example.com.
 64b50baa-acd8-4269-8a3a-767b70c7d18d
 neutron net-update --dns-domain example.com. public

 The response is always the same, namely:

 Unrecognized attribute(s) 'dns_domain'
 Neutron server returns request_ids:
 ['req-be15e08a-b3b0-458c-a045-ffac7ce3ebbd']

 Before I go searching through the Neutron source, does anyone know if
 this is a 'hole' in the Neutron API and, if so, has it been fixed after
 the commit point being used by openstack-ansible tag 15.1.3.

 Kind regards, Lawrence
>>> Hi Lawrence,
>>>
>>> Did you enable the DNS plugin in neutron?
>>>
>>> Adding "dns" to the list here [0] should enable the --dns-domain
>>> attribute.
>>>
>>> 0 -
>>> https://github.com/openstack/openstack-ansible-os_neutron/blob/15.1.3/defaults/main.yml#L133
>>>
>>> However, it does not look like OpenStack Ansible code supports Neutron
>>> calling Designate to update DNS Recordsets yet.
>>>
>>> It looks like a missing feature - I am not sure how OSA deals with
>>> feature requests, but if you are on IRC they use #openstack-ansible
>>>
>>> Thanks
>>>
>>> - Graham
>>>
>>>
 Lawrence J Albinson



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



0x23BA8E2E.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
__

Re: [openstack-dev] [keystone] removing domain configuration upload via keystone-manage

[Juan Antonio Osorio]

On the TripleO side we use the file based approach. Using the API would
have been easier to orchestrate (no need for reloads/restarts) but it's not
available yet in puppet-keystone.

On Wed, Jun 28, 2017 at 2:00 AM, Lance Bragstad  wrote:

> Hi all,
>
> Keystone has deprecated the domain configuration upload capability
> provided through `keystone-manage`. We discussed it's removal in today's
> meeting [0] and wanted to send a quick note to the operator list. The
> ability to upload a domain config into keystone was done as a stop-gap
> until the API was marked as stable [1]. It seems as though file-based
> domain configuration was only a band-aid until full support was done.
>
> Of the operators using the domain config API in keystone, how many are
> backing their configurations with actual configuration files versus the API?
>
>
> [0] http://eavesdrop.openstack.org/meetings/keystone/2017/
> keystone.2017-06-27-18.00.log.html#l-167 [1] https://github.com/openstack/
> keystone/commit/a5c5f5bce812fad3c6c88a23203bd6c00451e7b3
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@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] realtime kvm cpu affinities

[Sahid Orentino Ferdjaoui]

On Tue, Jun 27, 2017 at 04:00:35PM +0200, Henning Schild wrote:
> Am Tue, 27 Jun 2017 09:44:22 +0200
> schrieb Sahid Orentino Ferdjaoui :
> 
> > On Mon, Jun 26, 2017 at 10:19:12AM +0200, Henning Schild wrote:
> > > Am Sun, 25 Jun 2017 10:09:10 +0200
> > > schrieb Sahid Orentino Ferdjaoui :
> > >   
> > > > On Fri, Jun 23, 2017 at 10:34:26AM -0600, Chris Friesen wrote:  
> > > > > On 06/23/2017 09:35 AM, Henning Schild wrote:
> > > > > > Am Fri, 23 Jun 2017 11:11:10 +0200
> > > > > > schrieb Sahid Orentino Ferdjaoui :
> > > > > 
> > > > > > > In Linux RT context, and as you mentioned, the non-RT vCPU
> > > > > > > can acquire some guest kernel lock, then be pre-empted by
> > > > > > > emulator thread while holding this lock. This situation
> > > > > > > blocks RT vCPUs from doing its work. So that is why we have
> > > > > > > implemented [2]. For DPDK I don't think we have such
> > > > > > > problems because it's running in userland.
> > > > > > > 
> > > > > > > So for DPDK context I think we could have a mask like we
> > > > > > > have for RT and basically considering vCPU0 to handle best
> > > > > > > effort works (emulator threads, SSH...). I think it's the
> > > > > > > current pattern used by DPDK users.
> > > > > > 
> > > > > > DPDK is just a library and one can imagine an application
> > > > > > that has cross-core communication/synchronisation needs where
> > > > > > the emulator slowing down vpu0 will also slow down vcpu1. You
> > > > > > DPDK application would have to know which of its cores did
> > > > > > not get a full pcpu.
> > > > > > 
> > > > > > I am not sure what the DPDK-example is doing in this
> > > > > > discussion, would that not just be cpu_policy=dedicated? I
> > > > > > guess normal behaviour of dedicated is that emulators and io
> > > > > > happily share pCPUs with vCPUs and you are looking for a way
> > > > > > to restrict emulators/io to a subset of pCPUs because you can
> > > > > > live with some of them beeing not 100%.
> > > > > 
> > > > > Yes.  A typical DPDK-using VM might look something like this:
> > > > > 
> > > > > vCPU0: non-realtime, housekeeping and I/O, handles all virtual
> > > > > interrupts and "normal" linux stuff, emulator runs on same pCPU
> > > > > vCPU1: realtime, runs in tight loop in userspace processing
> > > > > packets vCPU2: realtime, runs in tight loop in userspace
> > > > > processing packets vCPU3: realtime, runs in tight loop in
> > > > > userspace processing packets
> > > > > 
> > > > > In this context, vCPUs 1-3 don't really ever enter the kernel,
> > > > > and we've offloaded as much kernel work as possible from them
> > > > > onto vCPU0.  This works pretty well with the current system.
> > > > > 
> > > > > > > For RT we have to isolate the emulator threads to an
> > > > > > > additional pCPU per guests or as your are suggesting to a
> > > > > > > set of pCPUs for all the guests running.
> > > > > > > 
> > > > > > > I think we should introduce a new option:
> > > > > > > 
> > > > > > >- hw:cpu_emulator_threads_mask=^1
> > > > > > > 
> > > > > > > If on 'nova.conf' - that mask will be applied to the set of
> > > > > > > all host CPUs (vcpu_pin_set) to basically pack the emulator
> > > > > > > threads of all VMs running here (useful for RT context).
> > > > > > 
> > > > > > That would allow modelling exactly what we need.
> > > > > > In nova.conf we are talking absolute known values, no need
> > > > > > for a mask and a set is much easier to read. Also using the
> > > > > > same name does not sound like a good idea.
> > > > > > And the name vcpu_pin_set clearly suggest what kind of load
> > > > > > runs here, if using a mask it should be called pin_set.
> > > > > 
> > > > > I agree with Henning.
> > > > > 
> > > > > In nova.conf we should just use a set, something like
> > > > > "rt_emulator_vcpu_pin_set" which would be used for running the
> > > > > emulator/io threads of *only* realtime instances.
> > > > 
> > > > I'm not agree with you, we have a set of pCPUs and we want to
> > > > substract some of them for the emulator threads. We need a mask.
> > > > The only set we need is to selection which pCPUs Nova can use
> > > > (vcpus_pin_set).  
> > > 
> > > At that point it does not really matter whether it is a set or a
> > > mask. They can both express the same where a set is easier to
> > > read/configure. With the same argument you could say that
> > > vcpu_pin_set should be a mask over the hosts pcpus.
> > > 
> > > As i said before: vcpu_pin_set should be renamed because all sorts
> > > of threads are put here (pcpu_pin_set?). But that would be a bigger
> > > change and should be discussed as a seperate issue.
> > > 
> > > So far we talked about a compute-node for realtime only doing
> > > realtime. In that case vcpu_pin_set + emulator_io_mask would work.
> > > If you want to run regular VMs on the same host, you can run a
> > > second nova, 

[openstack-dev] [ironic] Routed Networks, flat driver and physical network awareness

[Harald Jensås]

Hi,

With the following Neutron patches recently merged, it is now possible
to provide DHCP service to instances on remote routed networks that
have a dhcp forwarder configured.

https://review.openstack.org/#/c/459861/
https://review.openstack.org/#/c/468744/ 
https://review.openstack.org/476477

This enables provisioning of baremetal machines on remote routed
networks as well. Removing the need to deploy ironic
conductor/inspector etc with local connection to each routed network
segment.

However with the flat driver this does not work, because the flat
driver bind neutron ports to the node running ironic-conductor service,
e.g 'nova_host_id'. Not to the actual baremetal node. (Ref: https://git
hub.com/openstack/ironic/blob/master/ironic/drivers/modules/network/fla
t.py#L64)

The result of binding to the 'nova_host_id' causes this error for
baremetal nodes on the remote routed network segment.

INFO ironic.conductor.task_manager [req-11f5c864-cc1a-49ee-b224-
a6695c1a9678 87f6dc660b1f43f79efa4355080e118c
6a8453039524487ca0bbf191cdc6317d - default default] Node f19ecc51-c8ec-
4d34-a349-206a5ae97ed2 moved to provision state "deploy fail
ed" from state "deploying"; target provision state is "active":
NetworkError: Unable to set binding:host_id for neutron port 5e674173-
32d9-4ec9-be2a-7f2b3aa02336. Error: Host ironic-
conductor.node.example.com is not connected to a segment where the
existing fixed_ips on port 5e6741
73-32d9-4ec9-be2a-7f2b3aa02336 will function given the routed network
topology.


I can workaround this by not binding the port:
$ sudo sed -i \
s/'binding:host_id': host_id/'binding:host_id': None/" \
ironic/drivers/modules/network/flat.py


I can see good progress on the phys-net aware spec. But with the flat
driver this will not help, as the nova_host_id is used for binding. Not
the ironic baremetal node uuid.


What would be a good way forward here?
 - Change the flat driver to not bind the port?
 - Change the flat driver to bind using the ironic node uuid, and rely
on phys-net info being populated in Neutron? (Requieres: baremetal
neutron agent https://review.openstack.org/#/c/456235/ + several
changes related to phys-net)
 - Another driver? 'flat-routed' that does one of the above?
 - Keep the flat driver, but register the ironic-conductor as a
separate host in neutron and populate phys-nets in neutron for this
'ironic_host_id' with all networks available on the baremetal nodes
ironic is managing?

Is there already a plan? Other options?


-- 
|Harald Jensås    |  irc: hjensas


__
OpenStack Development Mailing 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] diskimage builder works for trusty but not for xenial

[Ignazio Cassano]

Hello, I said that disk image builder works fine for xenial, but also if it
is able to create the image, instances not working with heat
softwaredeployment:
os-collect-config and os-refresh-config give a lot of errors.
This not happens with centos7.
Regards
Ignazio

2017-06-22 8:00 GMT+02:00 Ignazio Cassano :

> It works fine
> Thanks
>
> 2017-06-22 0:24 GMT+02:00 Ian Wienand :
>
>> On 06/21/2017 04:44 PM, Ignazio Cassano wrote:
>>
>>> * Connection #0 to host cloud-images.ubuntu.com left intact
>>> Downloaded and cached
>>> http://cloud-images.ubuntu.com/xenial/current/xenial-server-
>>> cloudimg-amd64-root.tar.gz,
>>> having forced upstream caches to revalidate
>>> xenial-server-cloudimg-amd64-root.tar.gz: FAILED
>>> sha256sum: WARNING: 1 computed checksum did NOT match
>>>
>>
>> Are there any problems on http://cloud-images.ubuntu.com ?
>>>
>>
>> There was [1] which is apparently fixed.
>>
>> As Paul mentioned, the -minimal builds take a different approach and
>> build the image from debootstrap, rather than modifying the upstream
>> image.  They are generally well tested just as a side-effect of infra
>> relying on them daily.  You can use DIB_DISTRIBUTION_MIRROR to set
>> that to a local mirror and eliminate another source of instability
>> (however, that leaves the mirror in the final image ... a known issue.
>> Contributions welcome :)
>>
>> -i
>>
>> [1] https://bugs.launchpad.net/cloud-images/+bug/1699396
>>
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

[Renat Akhmerov]

Cool, thanks Dougal!

Renat Akhmerov
@Nokia

On 28 Jun 2017, 15:21 +0700, Dougal Matthews , wrote:
> > On 23 June 2017 at 12:52, Thierry Carrez  wrote:
> > > Dougal Matthews wrote:
> > > >>     We have been trying to break the requirement on mistral (from
> > > >>     tripleo-common) but it is proving to be harder than expected. We 
> > > >>are
> > > >>     really doing some nasty things, but I wont go into details here :-)
> > > >>     If anyone is interested, feel free to reach out.
> > > >
> > > > After sending that we did make some solid progress. We are two patches
> > > > away from breaking the link AFAICT.
> > > >
> > > > 1. https://review.openstack.org/#/c/454719/
> > > > 2. https://review.openstack.org/#/c/476866/
> > > >
> > > > Both have some errors that need to be resolved but it is looking much
> > > > closer now.
> > >
> > > That's definitely the best way to handle the situation, so if you are
> > > confident that we can complete the transition to depending on
> > > mistral-lib before the non-client lib freeze (~ July 20), we should try
> > > that.
> >
> > Almost there. All the changes we need have landed in tripleo-common. 
> > Mistral is no longer imported (only mistral-lib is).
> >
> > I have proposed a tripleo-common release [1] and a patch to remove Mistral 
> > from the global requirements [2].
> >
> >
> > [1]: https://review.openstack.org/#/c/478426/
> > [2]: https://review.openstack.org/#/c/477450/
> >
> >
> > >
> > > --
> > > Thierry Carrez (ttx)
> > >
> > > __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing 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] [stable][release] Last release date vs End of Life date

[Thierry Carrez]

Sean McGinnis wrote:
> On Tue, Jun 27, 2017 at 02:47:30PM -0400, Doug Hellmann wrote:
>> Excerpts from Tony Breeds's message of 2017-06-27 16:51:37 +1000:
>>> Hi all,
>>> Up 'til now we haven't set a last release date for a stable branch
>>> approaching end of life.  It seems like formalizing that would be a good
>>> thing.
>>>
>>> This comes up as we need time to verify that said release integrates
>>> well (at least doesn't break) said branch.  So should we define a date
>>> for the last release for *libraries* services are less critical as we're
>>> always testing the HEAD of that branch.
>>>
>>> I'd suggest it be 2 weeks before EOL date.  Thoughts?
>>
>> That makes sense.
> 
> Agree, that makes sense to me too. Unless something has gone horribly wrong,
> two weeks should be plenty to make sure things are settled before things get
> wrapped up.

+1


-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

[Dougal Matthews]

On 23 June 2017 at 12:52, Thierry Carrez  wrote:

> Dougal Matthews wrote:
> >> We have been trying to break the requirement on mistral (from
> >> tripleo-common) but it is proving to be harder than expected. We are
> >> really doing some nasty things, but I wont go into details here :-)
> >> If anyone is interested, feel free to reach out.
> >
> > After sending that we did make some solid progress. We are two patches
> > away from breaking the link AFAICT.
> >
> > 1. https://review.openstack.org/#/c/454719/
> > 2. https://review.openstack.org/#/c/476866/
> >
> > Both have some errors that need to be resolved but it is looking much
> > closer now.
>
> That's definitely the best way to handle the situation, so if you are
> confident that we can complete the transition to depending on
> mistral-lib before the non-client lib freeze (~ July 20), we should try
> that.
>

Almost there. All the changes we need have landed in tripleo-common.
Mistral is no longer imported (only mistral-lib is).

I have proposed a tripleo-common release [1] and a patch to remove Mistral
from the global requirements [2].


[1]: https://review.openstack.org/#/c/478426/
[2]: https://review.openstack.org/#/c/477450/



>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] Nominate Yumeng Bao to the core team

[Vincent FRANCOISE]

+1
On 27/06/17 15:45, ? ? (Alexander Chadin) wrote:
Hi watcher folks,

I'd like to nominate Yumeng Bao to the core team. She has made a lot of 
contributions including specifications,
features and bug fixes. Yumeng has attended PTG and Summit with her 
presentation related to the Watcher.
Yumeng is active on IRC channels and take a part on weekly meetings as well.

Please, vote with +1/-1.

Best Regards,
_
Alexander Chadin
OpenStack Developer


--

Vincent
FRANCOISE

{P} R Engineer
Network & Security
{T} +33 (0) 2 56 35 88 53
{W} www.b-com.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] [ptls][all][tc][docs] Documentation migration spec

[Andreas Jaeger]

For those migrating from oslosphinx to openstackdocstheme, I strongly
advise to follow the docs for openstackdocstheme 1.11 on how to set it up:

https://docs.openstack.org/openstackdocstheme/latest/

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


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

Re: [openstack-dev] [tripleo] OpenStack manuals project migration - Progress for TripleO

[Andreas Jaeger]

On 2017-06-27 22:54, Emilien Macchi wrote:
> Full background, context and details can be read here:
> http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html
> 
> TL;DR: there is a massive cross-project effort which aims to migrate
> documentations out of a central repository and into project trees,
> managed by project teams instead of OpenStack Manual team (who is
> running with low number of contributors at this time). (Alex feel free
> to correct me if I said something wrong).
> 
> There is a list of things we need to do to achieve this goal, if
> possible by the end of Pike:
> https://etherpad.openstack.org/p/doc-migration-tracking
> 
> Here's a first (basic) iteration:
> Switch release notes to use openstacktheme:
> https://review.openstack.org/#/q/topic:doc_migration+owner:%22Emilien+Macchi+%253Cemilien%2540redhat.com%253E%22
> (for all TripleO projects).

I commented on your first review with a -1 that probably applies to all
of them.

Please see https://docs.openstack.org/openstackdocstheme/latest/ how to
setup openstackdocstheme 1.11 properly.

Especially if you want to use the "Report a bug" feature, you need to
add more variables,

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


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

[openstack-dev] [storyboard][infra][docs] Report a bug and storyboard

[Andreas Jaeger]

Hi Storyboard team,

the openstackdocstheme has a "Report a bug" feature, where you can click
on the Bug icon and get a link to project's bug area in launchpad
together with information about the documentation (bug tag, git URL of
build, date, SHA, extra text).

How can this be done with storyboard?

Example: See the Bug icon on https://docs.openstack.org/admin-guide/ .
It gives the following URL as time of writing:

https://bugs.launchpad.net/openstack-manuals/+filebug?field.title=OpenStack%20Administrator%20Guide%20in%20Administrator%20Guide=%0A%0A%0AThis%20bug%20tracker%20is%20for%20errors%20with%20the%20documentation,%20use%20the%20following%20as%20a%20template%20and%20remove%20or%20add%20fields%20as%20you%20see%20fit.%20Convert%20[%20]%20into%20[x]%20to%20check%20boxes:%0A%0A-%20[%20]%20This%20doc%20is%20inaccurate%20in%20this%20way:%20__%0A-%20[%20]%20This%20is%20a%20doc%20addition%20request.%0A-%20[%20]%20I%20have%20a%20fix%20to%20the%20document%20that%20I%20can%20paste%20below%20including%20example:%20input%20and%20output.%20%0A%0AIf%20you%20have%20a%20troubleshooting%20or%20support%20issue,%20use%20the%20following%20%20resources:%0A%0A%20-%20Ask%20OpenStack:%20http://ask.openstack.org%0A%20-%20The%20mailing%20list:%20http://lists.openstack.org%0A%20-%20IRC:%20%27openstack%27%20channel%20on%20Freenode%0A%0A---%0ARelease:%2015.0.0%20on%202017-06-27%2009:57%0ASHA:%20cc281cac69483977f3eed49f03f9bfac850cd7f0%0ASource:%20https://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/source/index.rst%0AURL:%20https://docs.openstack.org/admin-guide/=admin-guide

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

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

Re: [openstack-dev] [stable][release] Last release date vs End of Life date

[Sean McGinnis]

On Tue, Jun 27, 2017 at 02:47:30PM -0400, Doug Hellmann wrote:
> Excerpts from Tony Breeds's message of 2017-06-27 16:51:37 +1000:
> > Hi all,
> > Up 'til now we haven't set a last release date for a stable branch
> > approaching end of life.  It seems like formalizing that would be a good
> > thing.
> > 
> > This comes up as we need time to verify that said release integrates
> > well (at least doesn't break) said branch.  So should we define a date
> > for the last release for *libraries* services are less critical as we're
> > always testing the HEAD of that branch.
> > 
> > I'd suggest it be 2 weeks before EOL date.  Thoughts?
> > 
> > Yours Tony.
> 
> That makes sense.
> 
> Doug


Agree, that makes sense to me too. Unless something has gone horribly wrong,
two weeks should be plenty to make sure things are settled before things get
wrapped up.

Sean

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