Re: [Openstack-operators] [packaging][ubuntu] nova-api + nova-placement-api package conflict

[James Page]

Hi Chris

On Tue, 27 Jun 2017 at 02:57 Chris Apsey  wrote:

> James,
>
> Bug report submitted.
>

Thanks (https://bugs.launchpad.net/cloud-archive/+bug/1700677 for reference
here).

Fix committed to package git repository; however we have some stable
release updates already in flight which need to clear before I can upload
this one for testing.

Cheers

James
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] OpenStack User Survey Now Open

[Saverio Proto]

Allison I clicked on "Add Deployment" and I got a 404 page (with a cat)

The URL I was redirected to is:
https://www.openstack.org/%7B$Controller.Link%7D%7B$CurrentStep.Template.Title%7D/add-entity

Saverio

2017-06-26 23:44 GMT+02:00 Allison Price :
> Hi everyone,
>
> If you’re running OpenStack, please participate in the OpenStack User
> Survey. If you have already completed the survey before, you can simply
> login to update your deployment details. Please note that if your survey
> response has not been updated in 12 months, it will expire, so we encourage
> you to take this time to update your existing profile so your deployment can
> be included in the upcoming analysis.
>
> As a member of our community, please help us spread the word. We're trying
> to gather as much real-world deployment data as possible to share back with
> you. We have made it easier to complete, and the survey is now available in
> 7 languages—English, German, Indonesian, Japanese, Korean, traditional
> Chinese and simplified Chinese.
>
> The information provided is confidential and will only be presented in
> aggregate unless you consent to making it public.
>
> The deadline to complete the survey and be part of the next report is
> Friday, August 11 at 23:59 UTC.
>
> You can login and complete the OpenStack User Survey here:
> http://www.openstack.org/user-survey
> If you’re interested in joining the OpenStack User Survey Working Group to
> help with the survey analysis, please complete this form:
> https://openstackfoundation.formstack.com/forms/user_survey_working_group
> Help us promote the User Survey:
> https://twitter.com/OpenStack/status/879434563134652416
>
>
> Please let me know if you have any questions.
>
> Cheers,
> Allison
>
>
> Allison Price
> OpenStack Foundation
> alli...@openstack.org
>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [ops-meetup-team] Meeting Reminder - 06/27/17 @ 1400 UTC

[Melvin Hillsman]

Ops Meetup Team Meeting
June 27th, 2017 @ 1400UTC
#openstack-operators

Agenda (feel free to suggest/add to):
- Review previous action items
- Mexico City Midcycle (08/17)
- APAC Midcycle (proposed)
- Open Discussion

Meeting etherpad: https://etherpad.openstack.org/p/ops-meetups-team

Past meetings:
http://eavesdrop.openstack.org/meetings/ops_meetup_team/
http://eavesdrop.openstack.org/meetings/ops_meetups_team/
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Leveraging Gnocchi in Mitaka

[gordon chung]

On 26/06/17 06:07 PM, Tracy Comstock Roesler wrote:
> If I understand what you¹re saying, you think I can try
> direct://?publisher=gnocchi in the pipeline.yaml on the controller nodes,
> but not the compute nodes to bypass the collector?

sorry, i just looked at the code again, it was only implemented in 
ceilometer newton: 
https://github.com/openstack/ceilometer/blob/stable/newton/ceilometer/publisher/direct.py#L35-L37

i imagine you could just backport that to mitaka if you wanted. here's 
the patch for reference: 
https://github.com/openstack/ceilometer/commit/8ed2e7735ec3f17881008a2ffe2fd2dc8ac1db7e

apologies for the false hope.


-- 
gord

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [User-committee] [openstack-dev] [all][tc] Turning TC/UC workgroups into OpenStack SIGs

[Blair Bethwaite]

There is a not insignificant degree of irony in the fact that this
conversation has splintered so that anyone only reading openstack-operators
and/or user-committee is missing 90% of the picture Maybe I just need a
new ML management strategy.

I'd like to add a +1 to Sean's suggestion about WG/SIG/team/whatever tags
on reviews etc. This is something I've also suggested in the past:
http://lists.openstack.org/pipermail/user-committee/2016-October/001328.html.
My thinking at the time was that it would provide a tractable basis for
chairs to build standing discussion items around and help get more user &
ops eyes on blueprints/reviews/etc.

On 27 June 2017 at 10:25, Melvin Hillsman  wrote:

>
>
> On Wed, Jun 21, 2017 at 11:55 AM, Matt Riedemann 
> wrote:
>
>> On 6/21/2017 11:17 AM, Shamail Tahir wrote:
>>
>>>
>>>
>>> On Wed, Jun 21, 2017 at 12:02 PM, Thierry Carrez >> > wrote:
>>>
>>> Shamail Tahir wrote:
>>> > In the past, governance has helped (on the UC WG side) to reduce
>>> > overlaps/duplication in WGs chartered for similar objectives. I
>>> would
>>> > like to understand how we will handle this (if at all) with the
>>> new SIG
>>> > proposa?
>>>
>>> I tend to think that any overlap/duplication would get solved
>>> naturally,
>>> without having to force everyone through an application process that
>>> may
>>> discourage natural emergence of such groups. I feel like an
>>> application
>>> process would be premature optimization. We can always encourage
>>> groups
>>> to merge (or clean them up) after the fact. How much
>>> overlaps/duplicative groups did you end up having ?
>>>
>>>
>>> Fair point, it wasn't many. The reason I recalled this effort was
>>> because we had to go through the exercise after the fact and that made the
>>> volume of WGs to review much larger than had we asked the purpose whenever
>>> they were created. As long as we check back periodically and not let the
>>> work for validation/clean up pile up then this is probably a non-issue.
>>>
>>>
>>> > Also, do we have to replace WGs as a concept or could SIG
>>> > augment them? One suggestion I have would be to keep projects on
>>> the TC
>>> > side and WGs on the UC side and then allow for spin-up/spin-down
>>> of SIGs
>>> > as needed for accomplishing specific goals/tasks (picture of a
>>> diagram
>>> > I created at the Forum[1]).
>>>
>>> I feel like most groups should be inclusive of all community, so I'd
>>> rather see the SIGs being the default, and ops-specific or
>>> dev-specific
>>> groups the exception. To come back to my Public Cloud WG example, you
>>> need to have devs and ops in the same group in the first place before
>>> you would spin-up a "address scalability" SIG. Why not just have a
>>> Public Cloud SIG in the first place?
>>>
>>>
>>> +1, I interpreted originally that each use-case would be a SIG versus
>>> the SIG being able to be segment oriented (in which multiple use-cases
>>> could be pursued)
>>>
>>>
>>>  > [...]
>>> > Finally, how will this change impact the ATC/AUC status of the SIG
>>> > members for voting rights in the TC/UC elections?
>>>
>>> There are various options. Currently you give UC WG leads the AUC
>>> status. We could give any SIG lead both statuses. Or only give the
>>> AUC
>>> status to a subset of SIGs that the UC deems appropriate. It's
>>> really an
>>> implementation detail imho. (Also I would expect any SIG lead to
>>> already
>>> be both AUC and ATC somehow anyway, so that may be a non-issue).
>>>
>>>
>>> We can discuss this later because it really is an implementation detail.
>>> Thanks for the answers.
>>>
>>>
>>> --
>>> Thierry Carrez (ttx)
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> >> subscribe>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>>
>>>
>>>
>>>
>>> --
>>> Thanks,
>>> Shamail Tahir
>>> t: @ShamailXD
>>> tz: Eastern Time
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> I think a key point you're going to want to convey and repeat ad nauseum
>> with this SIG idea is that each SIG is focused on a specific use case and
>> they can be spun up and spun down. Assuming that's what you want them to be.
>>
>> One problem I've seen with the various work groups is they overlap in a
>>

[Openstack-operators] [scientific] IRC Meeting (Tues 2100 UTC): Science app catalogues, network security of research computing on OpenStack

[Blair Bethwaite]

Hi all,

Scientific-WG meeting in ~8 hours in #openstack-meeting. This week's agenda
is largely the same as last week, for alternate TZ.

Cheers,
Blair

-- Forwarded message --
From: Stig Telfer 
Date: 21 June 2017 at 02:51
Subject: [User-committee] [scientific] IRC Meeting: Science app catalogues,
security of research computing on OpenStack - Wednesday 0900 UTC
To: user-committee , "openstack-oper." <
openstack-operators@lists.openstack.org>


Greetings!

We have an IRC meeting on Wednesday at 0900 UTC in channel
#openstack-meeting.

This week we’d like to hear people’s thoughts and experiences on providing
scientific application catalogues to users - in particular with a view to
gathering best practice for a new chapter for the Scientific OpenStack book.

Similarly, we’d like to discuss what people are doing for security of
research computing instances on OpenStack.

The agenda is available here: https://wiki.openstack.
org/wiki/Scientific_working_group#IRC_Meeting_June_21st_2017
Details of the IRC meeting are here: http://eavesdrop.
openstack.org/#Scientific_Working_Group

Please come along with ideas, suggestions or requirements.  All are welcome.

Cheers,
Stig

___
User-committee mailing list
user-commit...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee




-- 
Blair Bethwaite
Senior HPC Consultant

Monash eResearch Centre
Monash University
Room G26, 15 Innovation Walk, Clayton Campus
Clayton VIC 3800
Australia
Mobile: 0439-545-002
Office: +61 3-9903-2800
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [User-committee] [openstack-dev] [all][tc] Turning TC/UC workgroups into OpenStack SIGs

[Thierry Carrez]

Blair Bethwaite wrote:
> There is a not insignificant degree of irony in the fact that this
> conversation has splintered so that anyone only reading
> openstack-operators and/or user-committee is missing 90% of the
> picture Maybe I just need a new ML management strategy.

That irony is not lost on me, and no ML management strategy can help.
Currently for a ops+dev discussion we have 4 options: start it on -dev
(miss ops), start it on -ops (miss devs), cross-post (and miss random
messages that are lost as subscribers don't match, or people don't reply
to both), or try to post separate variants (but then you have to follow
both ends, and your replies miss half the audience). We tried the 4th
option this time -- was a fail but then there are no good option in the
current setup.

Setting up a common ML for common discussions (openstack-sigs) will
really help, even if there will be some pain setting them up and getting
the right readership to them :)

-- 
Thierry Carrez (ttx)

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[Alexandra Settle]

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 
Subject: [Openstack-operators] Fwd: [openstack-dev] [openstack-doc] [dev] 
What's up doc? Summit recap edition


-- Forwarded message --
From: Alexandra Settle mailto:a.set...@outlook.com>>
Date: Fri, May 19, 2017 at 6:12 AM
Subject: [openstack-dev] [openstack-doc] [dev] What's up doc? Summit recap 
edition
To: 
"openstack-d...@lists.openstack.org" 
mailto:openstack-d...@lists.openstack.org>>
Cc: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-...@lists.openstack.org>>



Hi everyone,

The OpenStack manuals project had a really productive week at the OpenStack 
summit in Boston. You can find a list of all the etherpads and attendees here: 
https://etherpad.openstack.org/p/docs-summit

As we all know, we are rapidly losing key contributors and core reviewers. We 
are not alone, this is happening across the board. It is making things harder, 
but not impossible. Since our inception in 2010, we’ve been climbing higher and 
higher trying to achieve the best documentation we could, and uphold our high 
standards. This is something to be incredibly proud of. However, we now need to 
take a step back and realise that the amount of work we are attempting to 
maintain is now out of reach for the team size that we have. At the moment we 
have 13 cores, of which none are full time contributors or reviewers. This 
includes myself.

That being said! I have spent the last week at the summit talking to some of 
our leaders, including Doug Hellmann (cc’d), Jonathan Bryce and Mike Perez 
regarding the future o

Re: [Openstack-operators] Leveraging Gnocchi in Mitaka

[Tracy Comstock Roesler]

No worries, it makes me feel better to know I’m not doing something wrong.

Thanks for all the assistance.

On 6/27/17, 6:54 AM, "gordon chung"  wrote:

>
>
>On 26/06/17 06:07 PM, Tracy Comstock Roesler wrote:
>> If I understand what you¹re saying, you think I can try
>> direct://?publisher=gnocchi in the pipeline.yaml on the controller
>>nodes,
>> but not the compute nodes to bypass the collector?
>
>sorry, i just looked at the code again, it was only implemented in
>ceilometer newton:
>https://github.com/openstack/ceilometer/blob/stable/newton/ceilometer/publ
>isher/direct.py#L35-L37
>
>i imagine you could just backport that to mitaka if you wanted. here's
>the patch for reference:
>https://github.com/openstack/ceilometer/commit/8ed2e7735ec3f17881008a2ffe2
>fd2dc8ac1db7e
>
>apologies for the false hope.
>
>
>-- 
>gord
>

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

Hello all,

Every month we have people asking on IRC or the dev mailing list
having interest in working on OpenStack, and sometimes they're given
different answers from people, or worse, no answer at all.

Suggestion: lets work our efforts together to create some common
documentation so that all teams in OpenStack can benefit.

First it’s important to note that we’re not just talking about code
projects here. OpenStack contributions come in many forms such as
running meet ups, identifying use cases (product working group),
documentation, testing, etc. We want to make sure those potential
contributors feel welcomed too!

What is common documentation? Things like setting up Git, the many
accounts you need to setup to contribute (gerrit, launchpad, OpenStack
foundation account). Not all teams will use some common documentation,
but the point is one or more projects will use them. Having the common
documentation worked on by various projects will better help prevent
duplicated efforts, inconsistent documentation, and hopefully just
more accurate information.

A team might use special tools to do their work. These can also be
integrated in this idea as well.

Once we have common documentation we can have something like:
    1. Choose your own adventure: I want to contribute by code
    2. What service type are you interested in? (Database, Block
storage, compute)
    3. Here’s step-by-step common documentation to setting up Git,
IRC, Mailing Lists, Accounts, etc.
    4. A service type project might choose to also include additional
documentation in that flow for special tools, etc.

Important things to note in this flow:
    * How do you want to contribute?
    * Here are **clear** names that identify the team. Not code names
like Cloud Kitty, Cinder, etc.
    * The documentation should really aim to not be daunting:
    * Someone should be able to glance at it and feel like they can
finish things in five minutes. Not be yet another tab left in their
browser that they’ll eventually forget about
    * No wall of text!
    * Use screen shots
    * Avoid covering every issue you could hit along the way.

## Examples of More Simple Documentation
I worked on some documentation for the Upstream University preparation
that has received excellent feedback meet close to these suggestions:
    * IRC [1]
    * Git [2]
    * Account Setup [3]

## 500 Feet Birds Eye view
There will be a Contributor landing page on the openstack.org website.
Existing contributors will find reference links to quickly jump to
things. New contributors will find a banner at the top of the page to
direct them to the choose your own adventure to contributing to
OpenStack, with ordered documentation flow that reuses existing
documentation when necessary. Picture also a progress bar somewhere to
show how close you are to being ready to contribute to whatever team.
Of course there are a lot of other fancy things we can come up with,
but I think getting something up as an initial pass would be better
than what we have today.

Here's an example of what the sections/chapters could look like:

- Code
        * Volumes (Cinder)
             * IRC
             * Git
             * Account Setup
             * Generating Configs
        * Compute (Nova)
             * IRC
             * Git
             * Account Setup
        * Something about hypervisors (matrix?)
-  Use Cases
* Products (Product working group)
* IRC
    * Git
* Use Case format

There are some rough mock up ideas [4]. Probably Sphinx will be fine
for this. Potentially we could use this content for conference lunch
and learns, upstream university, and the on-boarding events at the
Forum. What do you all think?

[1] - http://docs.openstack.org/upstream-training/irc.html
[2] - http://docs.openstack.org/upstream-training/git.html
[3] - http://docs.openstack.org/upstream-training/accounts.html
[4] - 
https://www.dropbox.com/s/o46xh1cp0sv0045/OpenStack%20contributor%20portal.pdf?dl=0

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [telecom-nfv] Meeting #29

[Curtis]

Hi All,

Our next meeting is tomorrow, 15:00 UTC in #openstack-meeting-4.

Thanks,
Curtis.

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [keystone] removing domain configuration upload via keystone-manage

[Lance Bragstad]

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



signature.asc
Description: OpenPGP digital signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [User-committee] [scientific] 0900 UTC meeting time change?

[Blair Bethwaite]

Hi all,

Review up for this: https://review.openstack.org/478317

Cheers,

On 21 June 2017 at 18:54, Stig Telfer  wrote:

> Doing future meetings at 1100UTC would also be fine by me.  I’ll put it on
> the agenda for today’s meeting (in ~10 minutes)
>
> Stig
>
>
> On 21 Jun 2017, at 09:13, Blair Bethwaite 
> wrote:
>
> Thanks Pierre. That's also my preference.
>
> Just to be clear, today's 0900 UTC meeting (45 mins from now) is going
> ahead at the usual time.
>
> On 21 Jun. 2017 5:21 pm, "Pierre Riteau"  wrote:
>
> Hi Blair,
>
> I strongly prefer 1100 UTC.
>
> Pierre
>
> > On 21 Jun 2017, at 06:54, Blair Bethwaite 
> wrote:
> >
> > Hi all,
> >
> > The Scientific-WG's 0900 UTC meeting time (it's the non-US friendly
> time) is increasingly difficult for me to make. A couple of meetings back
> we discussed changing it and had general agreement. The purpose here is to
> get a straw poll of preferences for -2 or +2 to the current time, i.e., do
> you prefer 0700 or 1100 UTC instead (subject to meeting channel
> availability)?
> >
> > Cheers,
> > b1airo
> > ___
> > User-committee mailing list
> > user-commit...@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>


-- 
Blair Bethwaite
Senior HPC Consultant

Monash eResearch Centre
Monash University
Room G26, 15 Innovation Walk, Clayton Campus
Clayton VIC 3800
Australia
Mobile: 0439-545-002
Office: +61 3-9903-2800
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators