from:"Anita Kuno"

Re: [OpenStack-Infra] Resigning from infra-core

2019-12-17 Thread Anita Kuno


On 2019-12-09 6:28 p.m., Joshua Hesketh wrote:

It has been a highlight of both my
career and in some cases my life.


The feeling is mutual. be well in all you do.

Anita

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

Re: [OpenStack-Infra] Low Key Monday Evening Get Together

2019-04-28 Thread Anita Kuno


On 2019-04-28 1:27 p.m., Clark Boylan wrote:

Zuul has been confirmed.


Congratulations Zuul team.

Hope you have a lovely celebration.

Anita

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

Re: [OpenStack-Infra] lists upgrade seems to be complete

2019-04-12 Thread Anita Kuno


On 2019-04-12 1:52 p.m., Clark Boylan wrote:

This message acts both as an indication that the upgrade was completed and a 
sanity check that our lists are functioning.

Clark

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



Received.

Thanks to Clark and Jeremy for doing this upgrade.

Seems to be working for me.
Anita

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

[OpenStack-Infra] The wikipage examle as meant to be copied not over-written

2019-01-07 Thread Anita Kuno


Hello:

I see you are working on setting up a third party ci system, thank you.

The wikipage example at: 
https://wiki.openstack.org/wiki/ThirdPartySystems/Example is meant to be 
an example for you to follow, in order for you to create your own page, 
like all the pages linked to this page: 
https://wiki.openstack.org/wiki/ThirdPartySystems


The example is not meant to be over-written by any individual third 
party ci operator for their own system. The example needs to stay as it 
is for everyone to be able to view and follow. I have rolled back your 
edit of the example page.


Please read the instructions again and create a new page for yourself 
with your own title and content in it which is specific to your system. 
Then ensure your new page with your content is linked to this page: 
https://wiki.openstack.org/wiki/ThirdPartySystems


If you continue to have difficulty, please reply to this email or find 
us in the #openstack-infra irc channel on the freenode network: 
https://docs.openstack.org/infra/manual/irc.html


Thank you,
Anita

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

[openstack-dev] Use of capslock on the mailing lists

2018-10-24 Thread Anita Kuno


Hello Gentle Reader:

I'm writing to share my thoughts on how I feel when I open my inbox on 
my account subscribed to OpenStack mailing lists.


I've been subscribed to various lists for some time and have 
accommodated my consumption style to suit the broadcast nature of the 
specific lists; use of filters etcetera.


I have noticed a new habit on some of the mailing lists and I find the 
effect of it to feel rather aggressive to me.


I am used to copious amounts of emails and it is my responsibility as 
consumer to filter out and reply to the ones that affect me.


I'm not comfortable with the recent trend of using capslock. I'm feeling 
yelled at by my inbox. This is having the effect of me giving as little 
attention as possible to anyone using capslock.


I wanted to give capslock affectionados that feedback. If you are using 
it to agressively distance yourself from me as a consumer, it is highly 
successful.


Thank you for reading,
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-operators] [all] Naming the T release of OpenStack

2018-10-18 Thread Anita Kuno


On 2018-10-18 2:35 a.m., Tony Breeds wrote:

Hello all,
 As per [1] the nomination period for names for the T release have
now closed (actually 3 days ago sorry).  The nominated names and any
qualifying remarks can be seen at2].

Proposed Names
  * Tarryall
  * Teakettle
  * Teller
  * Telluride
  * Thomas
  * Thornton
  * Tiger
  * Tincup
  * Timnath
  * Timber
  * Tiny Town
  * Torreys
  * Trail
  * Trinidad
  * Treasure
  * Troublesome
  * Trussville
  * Turret
  * Tyrone

Proposed Names that do not meet the criteria
  * Train

However I'd like to suggest we skip the CIVS poll and select 'Train' as
the release name by TC resolution[3].  My think for this is

  * It's fun and celebrates a humorous moment in our community
  * As a developer I've heard the T release called Train for quite
sometime, and was used often at the PTG[4].
  * As the *next* PTG is also in Colorado we can still choose a
geographic based name for U[5]
  * If train causes a problem for trademark reasons then we can always
run the poll

I'll leave[3] for marked -W for a week for discussion to happen before the
TC can consider / vote on it.

Yours Tony.

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html
[2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals
[3] https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53
[4] https://twitter.com/vkmc/status/1040321043959754752
[5] https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z


I stand in opposition to any action that further undermines democracy.

I have avoided events in Denver lately for this reason.

If the support for Train is as universal as is portrayed, the poll with 
show us that.


I don't care what the name is. I do want to participate in the 
selection. The method of participating has heretofore been a poll. I 
have seen no convincing argument to abandon the use of a poll now.


I stand for what democracy there remains. I would like to participate in 
a poll.


Thank you, Anita

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

Re: [Openstack-operators] [openstack-dev] [Openstack-sigs] [tc]Global Reachout Proposal

2018-09-19 Thread Anita Kuno


On 2018-09-18 08:40 AM, Jeremy Stanley wrote:

On 2018-09-18 11:26:57 +0900 (+0900), Ghanshyam Mann wrote:
[...]

I can understand that IRC cannot be used in China which is very
painful and mostly it is used weChat.

[...]

I have yet to hear anyone provide first-hand confirmation that
access to Freenode's IRC servers is explicitly blocked by the
mainland Chinese government. There has been a lot of speculation
that the usual draconian corporate firewall policies (surprise, the
rest of the World gets to struggle with those too, it's not just a
problem in China) are blocking a variety of messaging protocols from
workplace networks and the people who encounter this can't tell the
difference because they're already accustomed to much of their other
communications being blocked at the border. I too have heard from
someone who's heard from someone that "IRC can't be used in China"
but the concrete reasons why continue to be missing from these
discussions.



I'll reply to this email arbitrarily in order to comply with Zhipeng 
Huang's wishes that the conversation concerned with understanding the 
actual obstacles to communication takes place on the mailing list. I do 
hope I am posting to the correct thread.


In response to part of your comment on the patch at 
https://review.openstack.org/#/c/602697/ which you posted about 5 hours 
ago you said "@Anita you are absolutely right it is only me stuck my 
head out speaks itself the problem I stated in the patch. Many of the 
community tools that we are comfortable with are not that accessible to 
a broader ecosystem. And please assured that I meant I refer the patch 
to the Chinese community, as Leong also did on the ML, to try to bring 
them over to join the convo." and I would like to reply.


I would like to say that I am honoured by your generosity. Thank you. 
Now, when the Chinese community consumes the patch, as well as the 
conversation in the comments, please encourage folks to ask for 
clarification if any descriptions or phrases don't make sense to them. 
One of the best ways of ensuring clear communication is to start off 
slowly and take the time to ask what the other side means. It can seem 
tedious and a waste of time, but I have found it to be very educational 
and helpful in understanding how the other person perceives the 
situation. It also helps me to understand how I am creating obstacles in 
ways that I talk.


Taking time to clarify helps me to adjust how I am speaking so that my 
meaning is more likely to be understood by the group to which I am 
trying to offer my perspective. I do appreciate that many people are 
trying to avoid embarrassment, but I have never found any way to 
understand people in a culture that is not the one I group up in, other 
than embarrassing myself and working through it. Usually I find the 
group I am wanting to understand is more than willing to rescue me from 
my embarrassment and support me in my learning. In a strange way, the 
embarrassment is kind of helpful in order to create understanding 
between myself and those people I am trying to understand.


Thank you, Anita

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

Re: [openstack-dev] [Openstack-sigs] [Openstack-operators] [tc]Global Reachout Proposal

2018-09-19 Thread Anita Kuno


On 2018-09-18 08:40 AM, Jeremy Stanley wrote:

On 2018-09-18 11:26:57 +0900 (+0900), Ghanshyam Mann wrote:
[...]

I can understand that IRC cannot be used in China which is very
painful and mostly it is used weChat.

[...]

I have yet to hear anyone provide first-hand confirmation that
access to Freenode's IRC servers is explicitly blocked by the
mainland Chinese government. There has been a lot of speculation
that the usual draconian corporate firewall policies (surprise, the
rest of the World gets to struggle with those too, it's not just a
problem in China) are blocking a variety of messaging protocols from
workplace networks and the people who encounter this can't tell the
difference because they're already accustomed to much of their other
communications being blocked at the border. I too have heard from
someone who's heard from someone that "IRC can't be used in China"
but the concrete reasons why continue to be missing from these
discussions.



I'll reply to this email arbitrarily in order to comply with Zhipeng 
Huang's wishes that the conversation concerned with understanding the 
actual obstacles to communication takes place on the mailing list. I do 
hope I am posting to the correct thread.


In response to part of your comment on the patch at 
https://review.openstack.org/#/c/602697/ which you posted about 5 hours 
ago you said "@Anita you are absolutely right it is only me stuck my 
head out speaks itself the problem I stated in the patch. Many of the 
community tools that we are comfortable with are not that accessible to 
a broader ecosystem. And please assured that I meant I refer the patch 
to the Chinese community, as Leong also did on the ML, to try to bring 
them over to join the convo." and I would like to reply.


I would like to say that I am honoured by your generosity. Thank you. 
Now, when the Chinese community consumes the patch, as well as the 
conversation in the comments, please encourage folks to ask for 
clarification if any descriptions or phrases don't make sense to them. 
One of the best ways of ensuring clear communication is to start off 
slowly and take the time to ask what the other side means. It can seem 
tedious and a waste of time, but I have found it to be very educational 
and helpful in understanding how the other person perceives the 
situation. It also helps me to understand how I am creating obstacles in 
ways that I talk.


Taking time to clarify helps me to adjust how I am speaking so that my 
meaning is more likely to be understood by the group to which I am 
trying to offer my perspective. I do appreciate that many people are 
trying to avoid embarrassment, but I have never found any way to 
understand people in a culture that is not the one I group up in, other 
than embarrassing myself and working through it. Usually I find the 
group I am wanting to understand is more than willing to rescue me from 
my embarrassment and support me in my learning. In a strange way, the 
embarrassment is kind of helpful in order to create understanding 
between myself and those people I am trying to understand.


Thank you, 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] [election] [tc] thank you

2018-09-05 Thread Anita Kuno


On 2018-09-05 04:01 AM, Thierry Carrez wrote:

Emilien Macchi wrote:



I personally feel like some rotation needs to happen


A very honourable sentiment, Emilien. I'm so grateful to have spent time 
working with your very generous spirit.


To more such work in the future, 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-Infra] Volunteer Systems Administrator

2018-08-19 Thread Anita Kuno


On 2018-08-19 04:46 AM, Marcin Koprowski wrote:

Hello,

First of all, allow me to introduce myself. My name is Marcin and I work in
Poland as an Infrastructure Analyst. I used to be a Systems Administrator,
IT Manager, IT Support Analyst, etc. I have a few years of experience
administering Ubuntu Server and a bunch of Open Source
applications/services.

I don't have any experience with OpenStack, but I'm very keen to learn.

The reason why I'm writing here is that I have more than 10 hours per week
to spare and I would like to help you out somehow. My interest is Systems
Administration and DevOps. Please let me know if you are interested, and if
you are, I will provide you with my CV and link to my Linkedin profile.

Thank you.

Best regards,

Marcin


Hi Marcin:

You are more than welcome to participate, no application process necessary.

There are plenty of tasks available for you to help with, the best way 
to find out which ones and how to learn the systems are by spending time 
in the infra channel (#openstack-infra on the freenode network, you will 
need to register your irc nickname to join the channel) and by 
participating in the weekly infra meeting, #openstack-meeting 19:00 utc 
on Tuesdays.


Root access to servers is granted to those who demonstrate commitment 
and experience with our systems and the only way to get experience is to 
participate.


Your participation would be appreciated. There is usually someone in the 
irc channel in most time zones, weekends tend to be quiet.


Welcome,
Anita



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

Re: [openstack-dev] [all] Ongoing spam in Freenode IRC channels

2018-08-01 Thread Anita Kuno


On 2018-08-01 09:24 AM, Monty Taylor wrote:

On 08/01/2018 12:45 AM, Ian Wienand wrote:

Hello,

It seems freenode is currently receiving a lot of unsolicited traffic
across all channels.  The freenode team are aware [1] and doing their
best.

There are not really a lot of options.  We can set "+r" on channels
which means only nickserv registered users can join channels.  We have
traditionally avoided this, because it is yet one more barrier to
communication when many are already unfamiliar with IRC access.
However, having channels filled with irrelevant messages is also not
very accessible.

This is temporarily enabled in #openstack-infra for the time being, so
we can co-ordinate without interruption.

Thankfully AFAIK we have not needed an abuse policy on this before;
but I guess we are the point we need some sort of coordinated
response.

I'd suggest to start, people with an interest in a channel can request
+r from an IRC admin in #openstack-infra and we track it at [2]


To mitigate the pain caused by +r - we have created a channel called 
#openstack-unregistered and have configured the channels with the +r 
flag to forward people to it. We have also set an entrymsg on 
#openstack-unregistered to:


"Due to a prolonged SPAM attack on freenode, we had to configure 
OpenStack channels to require users to be registered. If you are here, 
you tried to join a channel without being logged in. Please see 
https://freenode.net/kb/answer/registration for instructions on 
registration with NickServ, and make sure you are logged in."


So anyone attempting to join a channel with +r should get that message.


I can confirm this worked for me as advertised with my nick unregistered.

Thank you,
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



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

Re: [openstack-dev] [OpenStack-Infra] Winterscale: a proposal regarding the project infrastructure

2018-05-30 Thread Anita Kuno


On 2018-05-30 12:25 PM, James E. Blair wrote:

I propose we call the overall effort "winterscale".  In the best
tradition of code names, it means nothing; look for no hidden meaning
here.  We won't use it for any actual services we provide.  We'll use it
to refer to the overall effort of restructuring our team and
infrastructure to provide services to projects beyond OpenStack itself.
And we'll stop using it when the restructuring effort is concluded.


I think as names with no meaning go, this is one I find acceptable.

Thank you Jim,
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] Pros and Cons of face-to-face meetings

2018-03-08 Thread Anita Kuno

On 2018-03-08 02:18 PM, Tim Bell wrote:

Fully agree with Doug. At CERN, we use video conferencing for 100s, sometimes 
>1000 participants for the LHC experiments, the trick we've found is to fully 
embrace the chat channels (so remote non-native English speakers can provide 
input) and chairs/vectors who can summarise the remote questions constructively, 
with appropriate priority.

This is actually very close to the etherpad approach, we benefit from the local 
bandwidth if available but do not exclude those who do not have it (or the 
language skills to do it in real time).

Just expanding on the phrase 'the etherpad approach' one instance on the 
Friday saw some infra team members discussing the gerrit upgrade in 
person and one infra team member (snowed in at the same hotel as Doug) 
following along on the etherpad as it was updated and weighing in on the 
updates (either via the etherpad or irc, I'm not sure, my laptop was not 
open).

So again echoing the chorus, there are possibilities, but those 
possibilities require effort and usually prior knowledge of participants 
and their habits.

Thank you,
Anita

Tim

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

Date: Thursday, 8 March 2018 at 20:00
To: openstack-dev 
Subject: Re: [openstack-dev] Pros and Cons of face-to-face meetings

 Excerpts from Jeremy Stanley's message of 2018-03-08 18:34:51 +:
 > On 2018-03-08 12:16:18 -0600 (-0600), Jay S Bryant wrote:
 > [...]
 > > Cinder has been doing this for many years and it has worked
 > > relatively well. It requires a good remote speaker and it also
 > > requires the people in the room to be sensitive to the needs of
 > > those who are remote. I.E. planning topics at a time appropriate
 > > for the remote attendees, ensuring everyone speaks up, etc. If
 > > everyone, however, works to be inclusive with remote participants
 > > it works well.
 > >
 > > We have even managed to make this work between separate mid-cycles
 > > (Cinder and Nova) in the past before we did PTGs.
 > [...]
 >
 > I've seen it work okay when the number of remote participants is
 > small and all are relatively known to the in-person participants.
 > Even so, bridging Doug into the TC discussion at the PTG was
 > challenging for all participants.

 I agree, and I'll point out I was just across town (snowed in at a

 different hotel).

 The conversation the previous day with just the 5-6 people on the

 release team worked a little bit better, but was still challenging
 at times because of audio quality issues.

 So, yes, this can be made to work. It's not trivial, though, and

 the degree to which it works depends a lot on the participants on
 both sides of the connection. I would not expect us to be very
 productive with a large number of people trying to be active in the
 conversation remotely.

 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

__
OpenStack Development Mailing 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] Pros and Cons of face-to-face meetings

2018-03-08 Thread Anita Kuno


On 2018-03-08 01:24 PM, Jay S Bryant wrote:



On 3/8/2018 12:22 PM, Anita Kuno wrote:

On 2018-03-08 09:03 AM, Jens Harbott wrote:

With the current PTG just finished and seeing discussions happen about
the format of the next[0], it seems that the advantages of these seem
to be pretty clear to most, so let me use the occasion to remind
everyone of the disadvantages.

Every meeting that is happening is excluding those contributors that
can not attend it. And with that it is violating the fourth Open
principle[1], having a community that is open to everyone. If you are
wondering whom this would affect, here's a non-exclusive (sic) list of
valid reasons not to attend physical meetings:

- Health issues
- Privilege issues (like not getting visa or travel permits)
- Caretaking responsibilities (children, other family, animals, plants)
- Environmental concerns


I'll add dislike for travel, which affects some of our contributors.



So when you are considering whether it is worth the money and effort
to organise PTGs or similar events, I'd like you also to consider
those being excluded by such activities. It is not without a reason
that IRC and emails have been settled upon as preferred means of
communication. I'm not saying that physical meetings should be dropped
altogether, but maybe more effort can be placed into providing means
of remote participation, which might at least reduce some effects.

[0] 
http://lists.openstack.org/pipermail/openstack-dev/2018-March/127991.html 


[1] https://governance.openstack.org/tc/reference/opens.html

__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Keep in mind that the alternative to the Project Teams Gathering is 
not no Project Teams Gathering, it is projects meeting face-to-face 
after each of them organizied their own meeting. These used to be 
called mid-cycle meetups and the majority of them used to be held in 
the United States. Now I can't predict what will happen in the future, 
but should there be a void in frequency of face-to-face meetings that 
the PTG is currently filling, I would not be surprised to see 
individual projects plan their own face-to-face meetings of some kind 
regardless of what they are called.


Thank you,
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

Anita,

We have already discussed this with the Cinder team and agreed that we 
would want to go back to our mid-cycles in the absence of a PTG.


Jay
(jungleboyj)


Thanks for sharing the data point Jay,
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



__
OpenStack Development Mailing 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] Pros and Cons of face-to-face meetings

2018-03-08 Thread Anita Kuno


On 2018-03-08 09:03 AM, Jens Harbott wrote:

With the current PTG just finished and seeing discussions happen about
the format of the next[0], it seems that the advantages of these seem
to be pretty clear to most, so let me use the occasion to remind
everyone of the disadvantages.

Every meeting that is happening is excluding those contributors that
can not attend it. And with that it is violating the fourth Open
principle[1], having a community that is open to everyone. If you are
wondering whom this would affect, here's a non-exclusive (sic) list of
valid reasons not to attend physical meetings:

- Health issues
- Privilege issues (like not getting visa or travel permits)
- Caretaking responsibilities (children, other family, animals, plants)
- Environmental concerns


I'll add dislike for travel, which affects some of our contributors.



So when you are considering whether it is worth the money and effort
to organise PTGs or similar events, I'd like you also to consider
those being excluded by such activities. It is not without a reason
that IRC and emails have been settled upon as preferred means of
communication. I'm not saying that physical meetings should be dropped
altogether, but maybe more effort can be placed into providing means
of remote participation, which might at least reduce some effects.

[0] http://lists.openstack.org/pipermail/openstack-dev/2018-March/127991.html
[1] https://governance.openstack.org/tc/reference/opens.html

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



Keep in mind that the alternative to the Project Teams Gathering is not 
no Project Teams Gathering, it is projects meeting face-to-face after 
each of them organizied their own meeting. These used to be called 
mid-cycle meetups and the majority of them used to be held in the United 
States. Now I can't predict what will happen in the future, but should 
there be a void in frequency of face-to-face meetings that the PTG is 
currently filling, I would not be surprised to see individual projects 
plan their own face-to-face meetings of some kind regardless of what 
they are called.


Thank you,
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-Infra] Dublin PTG recap

2018-03-07 Thread Anita Kuno


On 2018-03-07 08:54 AM, Clark Boylan wrote:

I've made it home after the PTG and am jet lagged which means it is a great 
time to try and recap some of what happened at the PTG. I'm not going to go 
into a ton of detail for each topic as I think that would make this turn into a 
novel but if people are interested in specific items feel free to start new 
threads for them and we can dig in more there (this has already happened for at 
least one or two topics). Also you can refer back to the PTG etherpad, 
https://etherpad.openstack.org/p/infra-rocky-ptg, for more information and 
notes that were taken at the time.

First thing that everyone should know is that the weather did not cooperate 
with us and resulted in much travel uncertainty and disruption. Mention this so 
that we aren't surprised if some people are slow to respond or otherwise AFK 
while finding their way home. It also meant that by Thursday we had largely 
abandoned our PTG schedule. Apologies if this meant that a topic you were 
interested in was not covered.

For this PTG we ended up having three major themes. There was the cross project 
(helproom) time, zuul topics, and infra services conversations. I think we 
managed to do a reasonable job covering these themes despite the weather and 
illness.

During the cross project conversations we were able to spend time helping 
projects like neutron, ironic, swift, and glance better take advantage of Zuul 
v3. We covered how the gate works, how to convert jobs to native Zuul v3, 
cleaning up old unused jobs, and how to run multinode jobs. We also had a 
conversation with keystone about how they might run performance testing on 
infra. There was also quite a bit of time spent working with the QA team to 
work out how multinode devstack would work in Zuul v3, how to make irrelevant 
files lists more intuitive, and how to wind down grenade testing on our oldest 
supported branch.

Kashyapc brought up nested virt support again which is becoming more important 
with post meltdown/spectre performance slowdowns. This resulted in a few of us 
crashing the public cloud working group's room for a discussion on how to have 
better communication between devs and clouds. Rough plan there is to spin up a 
new neutral mailing list to spark conversations over tools like nested virt 
between all the involved parties.

We covered a number of Zuul topics ranging from scaling out the scheduler to 
dashboard improvements to tenant label restrictions and executor affinity. None 
of these topics seemed controversial and I think we captured good notes on the 
etherpad for these topics in particular. I will call out the tenant label 
restrictions and executor affinity features as items that seemed to come up 
quite a bit from various users for various use cases so I think the importance 
of these features may have gone up after the PTG. One Zuul topic that we 
couldn't quite get into due to illness and last minute travel changes was Zuul 
support for containers. As I understand it there was some pre PTG talk about 
this, but we should probably try to have a proper discussion on the mailing 
list once people are back to normal operating hours.

For infra services we talked about upgrading Gerrit, better multi arch support, 
and rolling out Bionic. The rough plan (details on etherpad) for the Gerrit 
upgrade is to update the operating system for Java 8 this cycle then early next 
cycle upgrade Gerrit to 2.14 or 2.15 depending on which process is simpler for 
us (we will have to test that between now and then). Multi arch support is now 
something we have to think about with the arm64 Linaro cloud roll out. We seem 
to have largely decided that things are moving and largely working and we'll 
tackle problems as they come up. We also have Bionic beta images available. The 
one restriction we'd like to see there is to not gate on them but projects can 
(and in some cases should) go ahead and start using them to determine future 
compatibility particularly with python3.6.

One last major item that came up was how the OpenStack Foundation's CI/CD focus 
area will affect the infra team. This was a topic at the board meeting in 
Dublin which I had to miss due to helping run the helproom, but there were 
discussions with members of the infra team later in the week. The most concrete 
result of that seemed to be a shared understanding of three facets to this 
focus area: 1) The how to and best practices of doing CI/CD properly and 
effectively 2) Zuul and related software as a set of tools to enable (1) and 3) 
the current set of services run by the infra team which may be useful to 
developers outside of OpenStack. We've been promised a proper thread of its own 
from the foundation to start this conversation more broadly with the infra team 
soon so keep an eye out for that.

I've probably forgotten/skipped/missed other topics that are important and 
worth calling out. It was a long week and I'm now jetlagged so you have my

Re: [openstack-dev] [Election] Process Tweaks

2018-02-15 Thread Anita Kuno


On 2018-02-15 02:09 PM, Kendall Nelson wrote:

Hello Everyone,

Over the last few elections, with changes to the election cycle (i.e. the
separation of PTL and TC elections not being back to back), the scripts in
place have become somewhat outdated and brittle.

A few days ago after fixing a number of candidates names in an exceptions
file[1] due to incorrect information given to the docs build by a gerrit
lookup function, we had a conversation about how to fix this and other
issues. The lengthy discussion expanded from how to improve the processes
for both generation of the governance docs with correct candidate names to
the validation of candidates when nominations are posted to Gerrit.

Basically, we are proposing several changes to the scripts that exist and
changes to how nominations are submitted.

1. Uncouple the TC and PTL election processes. Make changes to our tooling
to validate PTL candidates and make those separate from the changes to
validate TC candidates.

2. Change the how-to-submit-candidacy directions to require the candidate's
email address (matching in Gerrit and foundation member profile) as the
file name of their nomination. All other info (name, IRC nick, etc.) should
be set in the foundation member profile. This could also mean a
reformatting the nomination submission altoghether to be YAML or JSON (open
for debate).

3. Create separate jobs for both docs build and candidate validation (and
run separate validation functions for TC elections versus PTL elections).

Please feel free to raise comments, concerns, or better ideas!


Please ensure that all who nominate themselves know that the process is 
meant as a means of communication not as a blockade to standing for 
nomination. That the process of nominating themselves has a back up 
solution, for example the low tech send-an-email-to-dev, should 
something untoward happen whilst they are working through the automated 
process in order to meet the deadline.


Technical glitches and failures do happen and should be acknowledged as 
such, not allowing them to prevent someone from standing should they 
wish to stand.


Thanks,
Anita.



The plan is to schedule time at the PTG to start hacking on some of these
items so feedback before then would be fantastic!

- Your Friendly Neighborhood Election Officials

1: http://git.openstack.org/cgit/openstack/election/tree/exceptions.txt





__
OpenStack Development Mailing 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-Infra] Help needed?

2018-02-06 Thread Anita Kuno


On 2018-02-05 11:09 PM, David Logan wrote:

Hi Folks,

I'm a Unix/Linux Admin of some years experience, looking to contribute to
Openstack as a community Sysadmin.

I have experience in RH/SuSE/CentOS etc, use Puppet daily and am starting
to look at Ansible. Am reasonably cloud aware, used AWS and Azure to a
limited extent. Not much Openstack but we are looking :)

If I can be of any help, please feel free to contact me.

Cheers
David Logan



Hi David:

My suggestion would be to join the #openstack-infra channel on irc, the 
freenode network.


Introduce yourself to clarkb, the Infra program team lead (ptl) and 
settle in for some reading of the backscroll. It is the most immediate 
and up to date source of information of the current goings on.


Clark or others can help you find your way about, getting oriented with 
docs and links and such.


I'm sure someone else has a more through suggestion but this approach 
would be a start.


Welcome to infra,
Anita.


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

Re: [openstack-dev] [All][Infra] Meltdown Patching

2018-01-10 Thread Anita Kuno


On 2018-01-10 01:11 PM, Clark Boylan wrote:

Hello everyone,

As a general heads up Ubuntu has published new kernels which enable kernel page 
table isolation to address the meltdown vulnerability that made the news last 
week. The infra team is currently working through patching our Ubuntu servers 
to pick up these fixes. Unfortunately patching does require reboots so you may 
notice some service outages as we roll through and update things.

As a side note all of our CentOS servers were patched last week when CentOS 
published new kernels. We managed to do these with no service outages, but 
won't be so lucky with one off services running on Ubuntu.

Thank you for your patience and feel free to ask if you have any questions 
related to this or anything else really.

Clark


Thank you Clark,
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] It's time...

2017-10-04 Thread Anita Kuno


On 2017-10-04 11:17 AM, Jeremy Stanley wrote:

On 2017-10-04 22:21:32 +0800 (+0800), Tom Fifield wrote:
[...]

the timing is right for me to step down as your Community Manager.

[...]

Your tireless assistance will be missed. I'm lucky to have been able
to count you as a colleague all these years, and by all means don't
hesitate to reach out if you ever need anything whatsoever. See you
in Sydney to collect on those Australian beers! ;)



Thanks for everything Tom, it has been my pleasure to know you.

You certainly have earned a well deserved rest. I hope you enjoy it.

All good things to you,
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] [keystone][zuul] A Sad Farewell

2017-10-03 Thread Anita Kuno


On 2017-10-02 10:42 PM, Lance Bragstad wrote:

+1,000 to all of what Steve said. It's still tough for me to wrap my
head around all the client/library work you shouldered. Your experience,
perspective, and insight will certainly be missed.

Thanks for being an awesome member of this community and best of luck on
the new gig, they're lucky to have you!

See you in Sydney

On 10/02/2017 09:22 PM, Steve Martinelli wrote:

It was great working with and getting to know you over the years
Jamie, you did tremendous work with in keystone, particularly
maintaining the libraries. I'm sure you'll succeed in your new
position, I'll miss our late-night-east-coast, early-morning-aus
chats. Keep in touch.

On Mon, Oct 2, 2017 at 10:13 PM, Jamie Lennox > wrote:

 Hi All,

 I'm really sad to announce that I'll be leaving the OpenStack
 community (at least for a while), I've accepted a new position
 unrelated to OpenStack that'll begin in a few weeks, and am going
 to be mostly on holiday until then.

 I want to thank everyone I've had the pleasure of working with
 over the last few years - but particularly the Keystone community.
 I feel we as a team and I personally grew a lot over that time, we
 made some amazing achievements, and I couldn't be prouder to have
 worked with all of you.

 Obviously I'll be around at least during the night for some of the
 Sydney summit and will catch up with some of you there, and
 hopefully see some of you at linux.conf.au .
 To everyone else, thank you and I hope we'll meet again.


 Jamie Lennox, Stacker.





I thank you for everything Jamie. You and your wife are incredible 
hosts, thank you.


I'm glad to hear you are doing well for yourself.

If our paths cross again, I'll be delighted.

Be well,
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] Garbage patches for simple typo fixes

2017-09-25 Thread Anita Kuno


On 2017-09-22 06:11 PM, Mike Perez wrote:

On 21:21 Sep 21, Matt Riedemann wrote:

I just wanted to highlight to people that there seems to be a series of
garbage patches in various projects [1] which are basically doing things
like fixing a single typo in a code comment, or very narrowly changing http
to https in links within docs.

Also +1ing ones own changes.

I've been trying to snuff these out in nova, but I see it's basically a
pattern widespread across several projects.

This is the boilerplate comment I give with my -1, feel free to employ it
yourself.

"Sorry but this isn't really a useful change. Fixing typos in code comments
when the context is still clear doesn't really help us, and mostly seems
like looking for padding stats on stackalytics. It's also a drain on our CI
environment.

If you fixed all of the typos in a single module, or in user-facing
documentation, or error messages, or something in the logs, or something
that actually doesn't make sense in code comments, then maybe, but this
isn't one of those things."

I'm not trying to be a jerk here, but this is annoying to the point I felt
the need to say something publicly.

[1] https://review.openstack.org/#/q/author:%255E.*inspur.*

I agree with the frustration here. It was mentioned earlier in the thread the
top 5 wanted [1] is a good step in the right direction. I think also the
efforts on the contributor portal [2] are going to be a helpful link to send
people when they make mistakes.

I'm sure some of the people who haven't had this communicated to them yet
aren't aware, so we should all be aware as demonstrated in Matt's boilerplate
comment to be nice when communicating.

[1] - http://governance.openstack.org/tc/reference/top-5-help-wanted.html


When I click this link I see two items. Perhaps the list can be named 
'help wanted list' and the point about it being the top 5 or having a 
maximum of 5 items can be made in the text. Having a top 5 list with 2 
items may confuse the audience folks are trying to redirect here.


Thanks,
Anita.


[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122534.html



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


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

Re: [openstack-dev] [tc] Declaring explicit minimum database versions

2017-08-15 Thread Anita Kuno


On 2017-08-15 11:59 AM, Monty Taylor wrote:

stabbing himself in the eyes yesterday


I find it interesting that I was just about to read this article: 
https://www.thestar.com/opinion/commentary/2017/08/15/boys-and-men-must-do-the-right-thing-it-will-save-female-lives.html 
when I noticed Monty posted and wanted to read what he had to say.


I still wonder what it will take for leaders in this tech community to 
hold themselves to some sort of account when deciding what language to 
use in work situations.


I am not of the opinion that Monty was advocating violence towards 
anyone. But I do feel the article makes a strong point in that language 
choice matters and normalizing violence is unhealthy if we want to reach 
our stated goals of beneficial gender interactions, including those 
where gender is not front of mind in the interaction.


As for the issue of databases, I hope for Morgan's wellbeing a solution 
can be found.


Thank you,
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] [all][barbican][freezer][horizon][karbor][keystone][mistral][nova][pack-deb][refstack][solum][storlets][swift][tacker][telemetry][watcher][zaqar] Last days for PTL candidate announ

2017-08-11 Thread Anita Kuno


On 2017-08-11 10:21 AM, Jeremy Stanley wrote:

On 2017-08-11 09:37:08 +0200 (+0200), Flavio Percoco wrote:

On 10/08/17 14:04 -0400, Anita Kuno wrote:

[...]

Also to clarify, the election officials serve the TC, not the other
way around.

I would like to clarify this sentence, though. I do not think the
election officials serve the TC, neither the TC serves the
election officials. Both bodies serve the community and the
processes defined by it.

[...]

It's more accurate to say that the election officials are *appointed
by* the TC, but I agree we're all here to serve the community. In
the particular matter of identifying leaderless teams, the election
officials are definitely acting as advisors to the TC, and I can see
how it might be taken as a bit demeaning to imply that it makes them
servants of the TC. They are charged with reporting these findings
to the TC however, so in a sense that is a form of servitude.
Basically, you're both correct depending on how you look at it. ;)

I'm not sure how the phrase "to serve" has become equated with the 
phrase "to be demeaned" but it is a leap I don't make myself.


I consider to be of service to be a privilege and an honour. I was 
honoured to serve the TC as an election official, I guess it is my 
mistake in believing that others would value the same honour.


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] [all][barbican][freezer][horizon][karbor][keystone][mistral][nova][pack-deb][refstack][solum][storlets][swift][tacker][telemetry][watcher][zaqar] Last days for PTL candidate announ

2017-08-10 Thread Anita Kuno

On 2017-08-07 03:50 PM, Kendall Nelson wrote:

Hello Everyone :)

A quick reminder that we are in the last days for PTL candidate
announcements.

If you want to stand for PTL, don't delay, follow the instructions at [1]
to make sure the community knows your intentions.

Make sure your candidacy has been submitted to the openstack/election
repository and approved by election officials.

Election statistics[2]:

This means that with approximately 2.5 days left more than 27% of projects
will be deemed leaderless. In this case the TC will be bound by [3].

I thought that the language in this sentence, that the TC is bound by
the referenced resolution was a bit of mis-stating the relationship, but
I thought I would let it pass and that things would work themselves out.
However having read the language in Emmett's post to the TC reporting
which programs don't have a self-nominated PTL, I'm motivated to clarify.

The TC is not bound. The TC has agreed to follow a process. The election
officials are bound, in as much as they are obliged to communicate the
list of leaderless programs to the TC without delay. The TC is enabled
by the process, not bound by it.

The TC CAN appoint a leader, they are not obliged to appoint a leader.
The TC may do other things as well, it depends on the circumstances.

Also to clarify, the election officials serve the TC, not the other way
around.

I'm not sure how this relationship got confused, if I played a role in
creating the confusion, I apologize.

Thank you,
Anita.

Thank you,

-Kendall Nelson (diablo_rojo)

[1] http://governance.openstack.org/election/#how-to-submit-your-candidacy

[2] Assuming the open reviews below are validated

https://review.openstack.org/#/q/is:open+project:openstack/election

[3]
http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html

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

Re: [OpenStack-Infra] Announcing Gertty 1.5.0

2017-07-30 Thread Anita Kuno


On 2017-07-30 11:08 AM, James E. Blair wrote:

Announcing Gertty 1.5.0
===

Gertty is a console-based interface to the Gerrit Code Review system.

Gertty is designed to support a workflow similar to reading network
news or mail.  It syncs information from Gerrit to local storage to
support disconnected operation and easy manipulation of local git
repos.  It is fast and efficient at dealing with large numbers of
changes and projects.

The full README may be found here:

   https://git.openstack.org/cgit/openstack/gertty/tree/README.rst

Changes since 1.4.0:


* Added support for sorting dashboards and change lists by multiple
   columns

* Added a Unicode graphic indication of the size of changes in the
   change list

* Added the number of changes to the status bar in the change list

* Added a trailing whitespace indication (which can be customized or
   ignored in a custom palette)

* Several bug fixes related to:
   * Negative topic search results
   * Crashes on loading changes with long review messages
   * Avoiding spurious sync failures on conflict queries
   * Errors after encounting a deleted project
   * Better detection of some offline errors
   * Fetching missing refs
   * Gerrit projects created since Gertty started
   * Re-syncing individual changes after a sync failure

Thanks to the following people whose changes are included in this
release:

   Jim Rollenhagen
   Kevin Benton
   Masayuki Igawa
   Matthew Thode

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


Congratulations Jim and Gertty contributors.

Anita.

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

Re: [openstack-dev] [infra] Non-candidacy for Queens cycle Infrastructure PTL

2017-07-26 Thread Anita Kuno


On 2017-07-26 12:55 PM, Jeremy Stanley wrote:

On 2017-07-26 11:44:17 -0500 (-0500), Sean McGinnis wrote:

Thank you for all your work Jeremy. The fact that most don't think
about and aren't aware of all that infra does is a testament to
how well things have been running.

To quote Ken Keeler (Futurama production staff writer):

 When you do things right, people won't be sure you've done
 anything at all.

[Futurama season 3 episode 20, "Godfellas"]
Well I may not be able to describe what you do but I know you work hard 
doing it.


I'm grateful for all the time I have been able to work with you as ptl 
Jeremy, thank you.


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

2017-06-28 Thread 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] Save the Date- Queens PTG

2017-05-24 Thread Anita Kuno


On 2017-05-24 04:16 AM, Thierry Carrez wrote:

Monty Taylor wrote:

On 05/23/2017 06:27 PM, Anita Kuno wrote:

My mistake I mis-read, $149 USD is equal to $201 CDN (Canadian
currency), so it looks like the same price to me.

I believe (although I do not know for absolute certain) that the prices
given were already normalized to USD. So it wasn't $149USD vs $200CDN it
was $149USD vs $200USD.

It is, of course, worth clarifying.

Yes they were normalized to USD.

I take offense to the idea that USD is considered normal, especially 
when referencing hotel rates in a Canadian city. $ means dollar, it 
doesn't mean USD as a default and Canadian only if we feel like it.


Are we still an international organization?

I further question that you were unable to get any Montreal hotel to 
take a substantial piece of business for anything less than $270 CDN. 
That seems very usual to me.


Thank you,
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] Save the Date- Queens PTG

2017-05-23 Thread Anita Kuno


On 2017-05-23 07:25 PM, Anita Kuno wrote:

On 2017-04-05 06:05 PM, Erin Disney wrote:
We are excited to announce the September Project Teams Gathering in 
Denver, CO at the Denver Renaissance Stapleton Hotel this September 
11th-15th.


As mentioned at the Atlanta PTG feedback session in February, we had 
narrowed down our PTG location options to Denver and Montreal. Based 
on attendee feedback we received in Atlanta, we knew keeping room 
rates down was a priority and are excited we were able to negotiate a 
$149/night for attendees in Denver versus nearly $200/night in Montreal.


We are sensitive to international travel and have heard and 
understand concerns regarding both travel to and from the U.S. amidst 
political uncertainty. We are reviewing options for remote 
participation for those unable to join us in person. Moving forward, 
we are planning to host the February/March 2018 PTG in Europe. Stay 
tuned for additional information on future locations for the PTG and 
look forward to Sydney in November 2017 and Vancouver in May 2018 for 
the upcoming OpenStack Summits.


We will share registration and sponsorship information soon on this 
mailing list. Mark your calendars and we hope to see you in Denver!


Erin Disney
OpenStack Marketing
e...@openstack.org <mailto:e...@openstack.org>




According to xe.com (my favourite currency exchange rate website) $140 
USD is equivalent to $189 CDN (Canadian currency), and $200 CDN 
(Canadian currency) is equal to $147 USD.


Sound like a difference in room rate of about $10 per night in 
Canadian currency and $7 per night in US currency.


I must be missing something.

Thank you,
Anita.
My mistake I mis-read, $149 USD is equal to $201 CDN (Canadian 
currency), so it looks like the same price to me.


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] Save the Date- Queens PTG

2017-05-23 Thread Anita Kuno


On 2017-04-05 06:05 PM, Erin Disney wrote:

We are excited to announce the September Project Teams Gathering in Denver, CO 
at the Denver Renaissance Stapleton Hotel this September 11th-15th.

As mentioned at the Atlanta PTG feedback session in February, we had narrowed 
down our PTG location options to Denver and Montreal. Based on attendee 
feedback we received in Atlanta, we knew keeping room rates down was a priority 
and are excited we were able to negotiate a $149/night for attendees in Denver 
versus nearly $200/night in Montreal.

We are sensitive to international travel and have heard and understand concerns 
regarding both travel to and from the U.S. amidst political uncertainty. We are 
reviewing options for remote participation for those unable to join us in 
person. Moving forward, we are planning to host the February/March 2018 PTG in 
Europe. Stay tuned for additional information on future locations for the PTG 
and look forward to Sydney in November 2017 and Vancouver in May 2018 for the 
upcoming OpenStack Summits.

We will share registration and sponsorship information soon on this mailing 
list. Mark your calendars and we hope to see you in Denver!

Erin Disney
OpenStack Marketing
e...@openstack.org 




According to xe.com (my favourite currency exchange rate website) $140 
USD is equivalent to $189 CDN (Canadian currency), and $200 CDN 
(Canadian currency) is equal to $147 USD.


Sound like a difference in room rate of about $10 per night in Canadian 
currency and $7 per night in US currency.


I must be missing something.

Thank you,
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] [tc][all] Do we need a #openstack-tc IRC channel

2017-05-16 Thread Anita Kuno


On 2017-05-16 11:46 AM, Sean Dague wrote:

On 05/16/2017 11:17 AM, Sean McGinnis wrote:

On Tue, May 16, 2017 at 09:38:34AM -0400, Davanum Srinivas wrote:

Folks,

See $TITLE :)

Thanks,
Dims


My preference would be to have an #openstack-tc channel.

One thing I like about the dedicated meeting time was if I was not able to
attend, or when I was just a casual observer, it was easy to catch up on
what was discussed because it was all in one place and did not have any
non TC conversations interlaced.

If we just use -dev, there is a high chance there will be a lot of cross-
talk during discussions. There would also be a lot of effort to grep
through the full day of activity to find things relevant to TC
discussions. If we have a dedicated channel for this, it makes it very
easy for anyone to know where to go to get a clean, easy to read capture
of all relevant discussions. I think that will be important with the
lack of a captured and summarized meeting to look at.

The thing is, IRC should never be a summary or long term storage medium.
IRC is a discussion medium. It is a hallway track. It's where ideas
bounce around lots are left on the floor, there are lots of
misstatements as people explore things. It's not store and forward
messaging, it's realtime chat.

If we want digestible summaries with context, that's never IRC, and we
shouldn't expect people to look to IRC for that. It's source material at
best. I'm not sure of any IRC conversation that's ever been clean, easy
to read, and captures the entire context within it without jumping to
assumptions of shared background that the conversation participants
already have.

Summaries with context need to emerge from here for people to be able to
follow along (out to email or web), and work their way back into the
conversations.

-Sean


I'll disagree on this point.

I do agree IRC is a discussion medium. I further agree that any 
agreements decided upon need to be further disseminated via other media. 
However, I disagree the only value for those trying to catch up with 
items that took place in the past lies in a digestible summary. The 
conversation of how that agreement was arrived at holds great value.


Feel free to disregard what I have to say, because I'm not really 
involved right now. But I would like to feel that should occasion arise 
I could step back in, do my homework reading past conversations and have 
a reasonable understanding of the current state of things.


For me OpenStack is about people, foibles and mistakes included. I think 
there is a huge value in seeing how a conversation develops and how an 
agreement came into being, sometimes this is far more valuable to me 
than the agreement itself. Agreements and policies are constantly 
changing, but the process of discussion and how we reach this agreement 
is often more important both to me and as a demonstration to others of 
how to interact effectively than the final agreement, which will likely 
change next release or two.


If you are going to do away with tc meetings and I can't find the 
backstory in an IRC tc meeting log then at least let me find the 
backstory in a channel somewhere.


I am in favour of using #openstack-dev for this purpose. I appreciate 
Sean McGuinnis' point about have the conversation focused, I don't think 
you would get that even if you had a dedicated #openstack-tc channel. 
Either channel would include side conversations and unrelated chat, I 
don't see anyway for that not to happen. So for me I would go with using 
what we already have, also including Sean and Doug's previous points 
that we already are fractured enough, it sure would be nice to see some 
good use of already existing public spaces.


Thank you,
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-Infra] Ballot for Openstack elections

2017-02-23 Thread Anita Kuno


On 2017-02-23 02:12 PM, Jeremy Stanley wrote:

On 2017-02-23 18:37:49 + (+), Cathy Zhang wrote:

I strongly support the proposal to mandate this. To be fair, I
think TC should mandate this across all projects. In many
complicated and technically hard commits, co-author does not make
any less amount of technical contribution to the commit. If just
the owner is counted, people will start to fight for the ownership
of a commit which is not healthy for the open source community.

For my own case, it is well known that I am the initiator and
project lead of this networking-sfc project and have contributed a
lot to this project on the technical side and project management
side. I have done many reviews and approvals in this cycle and
co-authored quite some commits. It is a surprise to me that
co-author is not counted as technical contributor in Neutron.

The technical limitations for this in the past have been twofold:

1. Gerrit did not provide a usable API for querying arbitrary
substrings from commit messages.

2. Voters must be foundation individual members and we had no way to
query the foundation member database by contributor E-mail address.

The first is less of an issue in the version of Gerrit we're running
now and the second is a situation I'm collaborating with the
foundation's development team to attempt to resolve. In the
meantime, the solution has been that PTLs should entertain requests
from co-authors to be added to the "extra ATCs" list for their
project. I don't personally have any objection to letting change
co-authors vote in elections, we just don't (yet) have a solution to
be able to automatically verify whether they're authorized to vote
under our bylaws and charter.

Separately, there was a problem back when we used to provide free
conference passes to code contributors, where someone at a company
would submit a punctuation fix to a comment in some project, add
half a dozen of their co-workers as co-authors, and then ask for
free admission for all of them (this really happened). Relying on
PTLs to vet extra ATCs before adding them was how we mitigated this.
Now that we no longer rely directly on code contributions to decide
who should get free/discounted conference admission this issue
should hopefully be purely historical. People seem to be far less
interested in gaming elections than going to conferences (or in some
cases scalping free tickets as a money-making scheme).
In addition, under the bylaws 3. (b) (ii) 
https://www.openstack.org/legal/technical-committee-member-policy/ any 
individual may apply to the chair of the Technical Committee for 
extra-ATC status.


Now should anyone elect to do this, I would hope they would have 
conversed with the PTL of their applicable project prior to applying to 
the TC chair.


Also the governance repo, in which the extra-ATCs are recorded, is 
tagged in advance of each election so that any questions about the 
composition of the electoral roll have a common reference point. Should 
an individual elect to apply directly to the TC chair for extra-ATC 
consideration I would highly suggest they do so well in advance of any 
tagging cadence.


To be honest, I suspect any PTL would welcome assistance composing, 
verifying and submitting the list of extra-ATCs to the governance repo. 
People might consider offering to help here.


Thanks,
Anita.

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

Re: [Openstack-operators] [openstack-dev] Supporting our global community

2017-01-29 Thread Anita Kuno

On 2017-01-29 01:34 PM, Jonathan Bryce wrote:

OpenStack is a global open source community. The OpenStack Foundation serves
members in 180 countries focused on advancing the capabilities and
accessibility of open infrastructure everywhere. We fundamentally believe
diversity and collaboration are a powerful force for innovation, and it has
been amazing to see the product of tens of thousands of people around the world
over the last 6+ years.

Lauren, Mark and I disagree with the executive order issued by President Trump
that targets individuals from 7 countries. The order restricts the travel and
movement of people in a discriminatory way that results in a restriction on
access to talent and ideas. It is still unclear how the policies will play out
and be enforced, but we will be watching, advocating for and supporting our
community members to the best of our ability.

This executive order will not impact the governance of the Foundation or the
way the community operates globally. We will continue to support user groups
and community members that are active in the seven countries named by the
executive order, alongside our 120+ user groups around the world. However, we
have two scheduled events in the United States within the next six months that
will attract a global audience: the PTG (Project Teams Gathering) in Atlanta,
Feb 20-24, a smaller event that will bring together hundreds of upstream
contributors, and the OpenStack Summit in Boston, May 8-11, our larger event
that happens every six months.

This executive order could impact some community members' ability to travel to
Atlanta and Boston, but unfortunately it is too late at this point to change
the location of these events. The following three OpenStack Summits, however,
are now scheduled to occur outside of the United States. The next Summit will
be in November 2017 in Sydney, Australia and we are working to finalize the
details so we can announce the following two Summit locations soon.

We’ve already heard from one community member, Mohammed Naser, who is concerned
that his plans to travel from Canada to Atlanta to attend the PTG may be
restricted, simply because he a dual citizen of Canada and Iraq. Mohammed has
been contributing code to OpenStack since 2011 and is the CEO and Founder of
Vexxhost. Blocking his travel would serve no purpose and rob the community of a
valuable contributor during an important event. If you are concerned about the
impact or have any questions, please don't hesitate to reach out to me at
jonat...@openstack.org.

An update: Canada's Immigration Minister held a press conference saying
that Canadians with dual citizenship won't be affected:
http://www.cbc.ca/news/politics/canada-hussen-reaction-to-trump-travel-restrictions-1.3957515
Now that should make things easier for Mohammed Naser but it doesn't
solve the larger problem affecting the whole community.

Also in the above linked article, the Canadian government will accept
those travelers refused entry by the United States due to this order, if
you find yourself in a situation where that information might be of help
to you.

As I already shared with Jonathan in private, I'm Canadian and plan on
avoiding as much travel to the US as I am able for the next four years,
so people not from the 7 named countries are also making choices as a
consequence of this action.

Confident we can collectively envision a productive future for all of us,
Anita.

Political actions like this highlight the importance of our collective values.
The Four Opens, the founding principles of our community, exist to ensure the
free flow of talent and ideas, across geographic, national, organizational or
other lines that might divide us. We believe in humanity. We believe in
opportunity. We believe in the power of collaboration across borders, and we
will continue to carry forward our mission.

We also posted this online:
https://www.openstack.org/blog/2017/01/supporting-our-global-community/

Jonathan Bryce
Mark Collier
Lauren Sell

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

Re: [openstack-dev] Supporting our global community

2017-01-29 Thread Anita Kuno

On 2017-01-29 01:34 PM, Jonathan Bryce wrote:

Confident we can collectively envision a productive future for all of us,
Anita.

We also posted this online:
https://www.openstack.org/blog/2017/01/supporting-our-global-community/

Jonathan Bryce
Mark Collier
Lauren Sell

Re: [openstack-dev] [all] Improving Vendor Driver Discoverability

2017-01-20 Thread Anita Kuno


On 2017-01-17 02:08 AM, Isaac Beckman wrote:

I think that it would also be a good idea to have the option to let the CI
maintainers add some useful information on the current status.
It is very helpful to know that the CI system is under maintenance which
is the reason why it hasn't been reporting for the last week or so...

Isaac Beckman

Office: +972-3-6897874
Fax: +972-3-6897755
Mobile: +972-50-2680180
Email: isa...@il.ibm.com

IBM XIV, Cloud Storage Solutions (previously HSG)
www.ibm.com/storage/disk/xiv
  




From:   "Jay S. Bryant" 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   16/01/2017 21:56
Subject:Re: [openstack-dev] [all] Improving Vendor Driver
Discoverability





On 01/16/2017 12:19 PM, Jonathan Bryce wrote:

On Jan 16, 2017, at 11:58 AM, Jay S. Bryant

 wrote:

On 01/13/2017 10:29 PM, Mike Perez wrote:

The way validation works is completely up to the project team. In my

research

as shown in the Summit etherpad [5] there's a clear trend in projects

doing

continuous integration for validation. If we wanted to we could also

have the

marketplace give the current CI results, which was also requested in

the

feedback from driver maintainers.

Having the CI results reported would be an interesting experiment. I

wonder if having the results even more publicly reported would result in
more stable CI's.  It is a dual edged sword however. Given the instability
of many CI's it could make OpenStack look bad to customers who don't
understand what they are looking at.  Just my thoughts on that idea.

That?s very useful feedback. Having that kind of background upfront is

really helpful. As we make updates on the display side, we can take into
account if certain attributes are potentially unreliable or at a higher
risk of showing instability and have the interface better support that
without it looking like everything is failing and a river of red X?s. Are
there other things that might be similar?

Jonathan


Jonathan,

Glad to be of assistance.

I think reporting some percentage of success might be the most accurate
way to report the CI results.  Not necessarily flagging it good or bed
but leave it for the consumers to see and compare.  Also combine that
with Anita's idea of when the CI last successfully reported and I think
it could give a good barometer for consumers. Our systems all have their
rough times so we need to avoid a 'snapshot in time' view and provide
more of a 'activity over time' view.  Third party CI is a good barometer
of community activity and attention, but not always 100% accurate.

Obviously there will need to be some information included with the
results explaining what they are and helping guide interpretations.

Jay




Since the information about system details (contact information, current 
status - with the option to fill in as many details as you like on your 
individual wikipage) already exists here: 
https://wiki.openstack.org/wiki/ThirdPartySystems I think it would be 
easy to add a link to this wikipage.


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] [all] Improving Vendor Driver Discoverability

2017-01-16 Thread Anita Kuno


On 2017-01-16 01:19 PM, Jonathan Bryce wrote:

On Jan 16, 2017, at 11:58 AM, Jay S. Bryant  
wrote:

On 01/13/2017 10:29 PM, Mike Perez wrote:

The way validation works is completely up to the project team. In my research
as shown in the Summit etherpad [5] there's a clear trend in projects doing
continuous integration for validation. If we wanted to we could also have the
marketplace give the current CI results, which was also requested in the
feedback from driver maintainers.

Having the CI results reported would be an interesting experiment. I wonder if 
having the results even more publicly reported would result in more stable 
CI's.  It is a dual edged sword however. Given the instability of many CI's it 
could make OpenStack look bad to customers who don't understand what they are 
looking at.  Just my thoughts on that idea.

That’s very useful feedback. Having that kind of background upfront is really 
helpful. As we make updates on the display side, we can take into account if 
certain attributes are potentially unreliable or at a higher risk of showing 
instability and have the interface better support that without it looking like 
everything is failing and a river of red X’s.


You could show the timestamp since the last passing test, rather than 
pass or fail as well as how long the driver has been tested. If a driver 
has been tested for 2 years or longer and has gone a week since the last 
passing test chances are the team is working on a bug, either with the 
driver code or the ci system (this can be explained on the page in a 
legend of some sort). This gives the reader more context with which to 
evaluate comparable drivers regarding their elapsed time since last 
successful completion of their ci as well as how long their ci has been 
active.


This might be a more useful and consumable approach for the audience 
which might have little understanding of continuous integration, its 
meaning and its artifacts.


Thanks,
Anita.


  Are there other things that might be similar?

Jonathan






__
OpenStack Development Mailing 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] [release][ptl] not planning to serve as release PTL for Pike

2017-01-13 Thread Anita Kuno


On 2017-01-13 03:19 PM, Steve Martinelli wrote:

+++ Thanks for making it 100x easier to release new libraries, it's now
something I look forward to.

On Fri, Jan 13, 2017 at 3:11 PM, Davanum Srinivas  wrote:


Many thanks for all the automation and all other initiatives Doug!

On Fri, Jan 13, 2017 at 3:00 PM, Doug Hellmann 
wrote:

I announced this at the release team meeting on 6 Jan, but thought
I should also post to the list as well:  I do not plan to serve as
the Release Management team PTL for the Pike release cycle.

It has been my pleasure to serve as PTL, and we've almost finished
the automation work that I envisioned when I joined the team. Now
I would like to shift my focus to some other projects within the
community.  I will still be an active member of the Release Management
team, helping with new initiatives and reviews for releases.

Doug


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


Thank you, Doug, for all your good work as PTL of the release team.

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] Retire the radar project?

2016-12-21 Thread Anita Kuno


On 2016-12-21 07:02 PM, Michael Still wrote:

Hi,

radar was an antique effort to import some outside-OpenStack code that did
CI reliability dashboarding. It was never really a thing, and has been
abandoned over time.

The last commit that wasn't part of a project wide change series was in
January 2015.

Does anyone object to me following the project removal steps described at
http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project

Thanks,
Michael


I have no objection.

Thanks for agreeing to put your code into gerrit in a repo in the first 
place, I appreciate it.


Sorry it never got any attention, time to let it be but a legend.

Thanks Michael,
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] [docs] Stepping down from core

2016-12-21 Thread Anita Kuno


On 2016-12-21 11:11 AM, Matt Kassawara wrote:

Howdy!

After several years of contributing to OpenStack documentation, a
significant change in my career path warrants resigning from my role as a
core reviewer. Working with the OpenStack community was a great experience
and I hope it continues to grow... with sufficient documentation, of course.

Cheers,
Matt



I have so much gratitude for all your hard work, thank you Matt.

May you have clear skies in every direction you turn,
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] [Neutron] Stepping down from core

2016-12-02 Thread Anita Kuno


On 2016-12-01 05:51 PM, Henry Gessau wrote:

I've already communicated this in the neutron meeting and in some neutron
policy patches, but yesterday the PTL actually updated the gerrit ACLs so I
thought I'd drop a note here too.

My work situation has changed and leaves me little time to keep up with my
duties as core reviewer, DB lieutenant, and drivers team member.

Working with the diverse and very talented contributors to Neutron has been
the best experience of my career (which started before many of you were born).
Thank you all for making the team such a great community. Because of you the
project is thriving and will continue to be successful!

I will still be around on IRC, contribute some small patches here and there,
and generally try to keep abreast of Neutron's progress. Don't hesitate to
ping me.

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


Thank you Henry, it has been my pleasure to work with you.

Good wishes go with you,
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] [all][tc] Allowing Teams Based on Vendor-specific Drivers

2016-11-29 Thread Anita Kuno


On 2016-11-29 11:27 AM, Jeremy Stanley wrote:

I think we also need to look harder at the reasons for driver-only
developer teams seeking official status. If it's because they want
to be part of the community and help collaborate with the rest of
us, then as long as they can do that consistent with our overall
goals and ideals I think that's great and we should welcome them as
one of us. If the reason is because they feel it raises the profile
of their products within the OpenStack ecosystem or conveys an
implication of better OpenStack support on their platforms, then we
should work harder as a community to dispel that notion (even if it
means we need to actively sabotage the "tent" as a marketing
platform) and find other places for companies to advertise the level
of OpenStack support their customers should expect.


I think Jeremy raises a very important point here. What is the 
motivation on the part of the driver-only teams?


I personally assumed far too much collaborative intent when I got 
involved with supporting the path to third party testing for drivers. My 
eyes have since been opened. While there are a few driver maintainers 
that are motivated to be collaborative and help others (thank you so 
much) they are far from the norm.


I've taken some time away from keyboard to navel gaze a bit and been 
quite enjoying it. I've been able to think about some of the material 
offered to us during the leadership training in June, particularly 
thinking about groups that are successful in creating an environment of 
collaboration. I found that one of the most important aspects of groups 
that do create and maintain a collaborate atmosphere for all concerned 
is the ability to ensure that all concerned are motivated to create a 
collaborative environment. Businesses offered as case studies in the 
literature provided by Zingermans, create a reciprocally beneficial 
collaborative environment through rigorous filtering during interview 
and selection processes as well as a commitment to help people move 
along should it be evident that they are not motivated by collaborative 
intent. OpenStack can't apply the process but it can align with the 
spirit of the intent, should OpenStack continue to want to create a 
collaborative environment for all concerned.


Some may feel excluded and that is their choice, as long as there is 
always a door way in for those that make the choice of having their 
actions motivated by collaboration for the benefit of all concerned.


Thank you,
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] [Nova] Stepping back

2016-11-22 Thread Anita Kuno


On 2016-11-22 11:39 AM, Andrew Laski wrote:

I should have sent this weeks ago but I'm a bad person who forgets
common courtesy. My employment situation has changed in a way that does
not afford me the necessary time to remain a regular contributor to
Nova, or the broader OpenStack community. So it is with regret that I
announce that I will no longer be actively involved in the project.

Fortunately, for those of you reading this, the Nova community is full
of wonderful and talented individuals who have picked up the work that
I'm not able to continue. Primarily this means parts of the cellsv2
effort, for which I am extremely grateful.

It has been a true pleasure working with you all these past few years
and I'm thankful to have had the opportunity. As I've told people many
times when they ask me what it's like to work on an open source project
like this: working on proprietary software exposes you to smart people
but you're limited to the small set of people within an organization,
working on a project like this exposed me to smart people from many
companies and many parts of the world. I have learned a lot working with
you all. Thanks.

I will continue to lurk in #openstack-nova, and try to stay minimally
involved as time allows, so feel free to ping me there.

-Laski



Thanks Andrew, continued good wishes for whatever you do.

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] [Neutron] Stepping down from core

2016-11-18 Thread Anita Kuno


On 2016-11-17 01:42 PM, Carl Baldwin wrote:

Neutron (and Openstack),

It is with regret that I report that my work situation has changed such
that I'm not able to keep up with my duties as a Neutron core reviewer, L3
lieutenant, and drivers team member. My participation has dropped off
considerably since Newton was released and I think it is fair to step down
and leave an opening for others to fill. There is no shortage of talent in
Neutron and Openstack and I know I'm leaving it in good hands.

I will be more than happy to come back to full participation in Openstack
and Neutron in the future if things change again in that direction. This is
a great community and I've had a great time participating and learning with
you all.

Well, I don't want to drag this out. I will still be around on IRC and will
be happy to help out where I am able. Feel free to ping me.

Carl




Thank you, Carl.

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] [release][ptl] pausing releases until 1 Nov

2016-10-20 Thread Anita Kuno


On 2016-10-20 05:13 PM, Emilien Macchi wrote:

On Thu, Oct 20, 2016 at 9:27 PM, Doug Hellmann  wrote:

It's late in the week and the release and infra teams need to see
to our travel preparations. I am declaring the releases repository
frozen until the Tuesday after summit, 1 Nov.

If there are critical security related issues that require a release
before 1 Nov, please contact me directly via email.

Doug

I take this opportunity to thank doug/dims/ttx for their hard work on
release management; they always help PTLs in a productive and
responsive way to reach the goals.
As a PTL, I always feel happy to deal with release management assisted
by such a great team, with nice tools like reno and openstack/releases
repo.

Thanks again,

Well said, Emilien.

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] [elections][tc]Thoughts on the TC election process

2016-10-11 Thread Anita Kuno


On 2016-10-11 02:07 PM, Clay Gerrard wrote:

On Tue, Oct 11, 2016 at 10:52 AM, Anita Kuno <ante...@anteaya.info> wrote:


On 2016-10-11 01:40 PM, Ed Leafe wrote:


On Oct 11, 2016, at 12:17 PM, Anita Kuno <ante...@anteaya.info> wrote:

There really needs to be a period when a) we know who all the candidates

are, and b) voting has not yet begun.


Why?

The voting period is open for a period of several days, voters have the
ability to vote at any time during that voting period.


   Because many people vote as soon as they receive their ballot.


That is their choice.



Anita,

I agree, that voters may choose to refrain from voting.  I don't hear
anyone saying "people *can not* make time for thoughtful reflection on the
candidates" - but suggestion that perhaps they *did not*?  Is there anyway
we could get numbers about how many voters waited until the end of week
like I did?


No, there is no report from the service that outputs timestamps of when 
votes were submitted.


Now, if the supervisor of the election choose to monitor the status page 
of the poll whilst the poll was happening that person could track how 
many votes were submitted at the time the status page was rendered, 
however it wouldn't be possible to independently verify this information 
and I personally feel asking an election official to add this to their 
duties (what happens if they got pulled onto a more important task?) 
isn't something I would feel comfortable with. Administering elections 
is already stressful enough.




If most voters did wait until later in the week, I think we can reject the
premise as false and accept that the week while voting is open *is* the
time in the process that most of the electorate uses for reflection on the
candidates.

If many *did* vote early in the week before some policy/platform points
were discussed one might even assume these voters have some remorse -
perhaps they will behave differently next time?  Not known.


Agreed, this is not known. What also is unknown is the number of people 
that voted early, followed the discussions and didn't feel any remorse 
in their voting choices.




OTOH, if we actively broadcast a period of time with the expressed purpose
of facilitating this discussion I think it sends a message that we as a
community expect this discussion to happen and have an impact on the
results of the election.  Is there a *downside* to a 3 week election period
as proposed by Ed, Chris and others?


Yes, there is a downside. As I have said several times already in this 
thread, expanding the duration of the election from beginning to end 
increases the time commitment and stress for the election officials. The 
job already takes a lot of planning and a minimum of one month per 
release for the ptl and tc elections, for the nomination period and the 
voting.


Now if people want to explore other opportunities for how candidates are 
differentiated that is fine, so far we seem to be circling around 
different versions of what I had offered. I do think we can come up with 
other ideas. I also think that implementing other ideas can be done in 
the given time frame.


The option I offered was completed during the election timeframe, I 
didn't need to expand the election timeframe to offer additional 
communication about candidates.


Thank you,
Anita.



-Clay





   I know that I typically do so that it doesn’t get lost under the flood

of email.


I have found putting a star on the email when it comes it helps to ensure
I don't lose it, but everyone has a different email organizing workflow.

   This wouldn’t be so bad if you could later change your vote, but once it

is cast, it can’t be changed. What that means is that if a candidate I knew
little about says something that either interests me or turns me off, I can
*use* that information.


You still can now, you just have to choose to listen to candidates prior
to voting.

Monty suggested somewhere that we reissue the email ballots everyday
(since we had email issues this time, I have no idea if that would result
in us being kicked off the service we currently use or not). If the issue
is, I want to ensure I can find my ballot when I need it, I think we can
explore options that don't include requiring election officials to expand
their commitment for an additional week.



A voter can ask the panel of candidates any question they wish such that

they are satisfied prior to voting.


Of course; no one has said otherwise. But if someone else asks a question
that may not have occurred to me to ask, the answers given can still be
influential on my choices. Look at Gordon Chung’s question in this recent
cycle: I’m sure that there were lots of people who benefited from that
question and the many answers, not just Gordon.


I know I benefited from Gord's question, both as a candidate and as a
voter. Thank you, Gord.

Again, I feel the choice exists.



Additionally should the decision be made to go

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

2016-10-11 Thread Anita Kuno


On 2016-10-11 02:35 PM, Thiago da Silva wrote:



On 10/11/2016 01:21 PM, Anita Kuno wrote:

On 2016-10-11 12:57 PM, Thiago da Silva wrote:



On 10/11/2016 12:00 PM, Ed Leafe wrote:

On Oct 11, 2016, at 10:37 AM, Anita Kuno <ante...@anteaya.info> wrote:

Just in case folks care, now is the best time to discuss our 
election process and suggest options or changes for the next round 
of elections. I'm not adverse to discussing it I just think the 
best time for doing so is from the time the last election is over 
up to milestone one. Then we have lots of time for ideas and 
debate and any suggestions, if accepted, have time to be 
implemented and communicated so the process is fair for all, 
candidates and electorate.

Agreed.

During the election is a wonderful time for posing questions to 
candidates in order to clarify their position or stance such that 
the electorate can make an informed choice.
To me, that’s the crux: “during the election”. When exactly should 
that be? Candidates can (and do) declare up to the very last minute 
of the nomination window, and ballots go out immediately after 
that, and voting starts. There really needs to be a period when a) 
we know who all the candidates are, and b) voting has not yet 
begun. I would like to see that period be created so that the kind 
of question/answer/clarify process you mention can happen.

+1
Just to add on to that, it would also be nice to have a better place 
for the questions/answers to be stored.


Have you a suggestion for where you would like to see them?

Also regardless of what is formally set up, anyone can ask questions 
via the mailing list, that option has been used every election that I 
have witnessed, I don't see that changing. I don't think it is 
reasonable to ask officials to curate mailing list posts. I think 
what we are discussing is something in addition to mailing list 
discussions. I don't think anything ever would (or should) replace 
what comes up on the mailing list.

Anita,

Agree that the mailing list is irreplaceable, a lot of of the 
discussion would continue to happen here. I also don't think asking 
anyone to curate the answers is scalable.


Great, we agree.



A *suggestion* would be to come up with a set of questions prior to 
nomination so that candidates could answer in their self-nomination. 
Of course, how we would come up with those questions is then another 
issue. Maybe the questions could even be proposed to the election 
repo[0], starting with an initial set of questions that are then added 
on by others in the community ??? I'm trying to come up with a way to 
repeat what you provided in the '14 election without the burden...


Thiago

[0] - 
https://github.com/openstack/election/tree/master/candidates/ocata/TC


I think the format would be up to whomever administrates it since they 
would have to do the work, accept the stress and pressure and be 
answerable to the community for the choices they make. That is what 
worked best for me.


Thanks Thiago,
Anita.



Thanks,
Anita.

During last week there was a ton of great discussion, but when it 
came to voting time (towards end of the week) it was difficult/time 
consuming to find what each person had said.


-- Ed Leafe








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

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

2016-10-11 Thread Anita Kuno


On 2016-10-11 01:43 PM, Ed Leafe wrote:

On Oct 11, 2016, at 12:26 PM, Anita Kuno <ante...@anteaya.info> wrote:

Instead of two week process, make it three:

Again as I replied to Ed's post, I think we can find options that fit in the 
current timeframe.

Why do we need a week to nominate? Open it up a month before the election, and 
close it a week before. Or open it for two days, and close it a week before. I 
don’t understand why, other than procrastination, we need such a long period. 
If you’re serious about serving, throw you hat into the ring.


-- Ed Leafe

To be honest with you I also questioned why the nomination period had to 
be the length it did, until I was running elections. Turns out people's 
lives, vacation, travel, all those meetings, are such that they need it 
to be at least the length it is in order to run if they want to run. I 
had an instance where someone posted their nomination 10 minutes prior 
to the deadline. I pm'd them and asked, were you just being lazy or 
what? Turns out their work schedule that week was such that the only 
time they could take to compose their nomination and post it was just 
before the deadline. So now I understand firsthand about why it has to 
be at least that long of a period for nomination.


If you make the nomination period longer, you require a longer 
commitment from the election officials. Officiating an election is a 
commitment. The election is top priority at that time. Given the 
expectation around officiating I personally don't think it is fair to 
extend that expectation without it being an actual solution to an actual 
problem.


I don't know what issue we would be fixing by changing the nomination 
period.


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] [elections][tc]Thoughts on the TC election process

2016-10-11 Thread Anita Kuno


On 2016-10-11 01:42 PM, Chris Dent wrote:

On Tue, 11 Oct 2016, Anita Kuno wrote:


* Getting rid of self nomination. Nominations come from the
  electorate at large. They can be refused of course.


What is the current problem with self nomination?


(I almost missed this since it was after your valediction)


Yeah sorry about that, bad formatting on my part. Glad you caught it.



I guess the least roundabout but perhaps insufficiently nuanced way
to put it is: Anyone who wants the job is probably not suited.

The Douglas Adams version of this is:
http://www.brainyquote.com/quotes/quotes/d/douglasada125021.html

Please accept this with the humor with which you would expect given
that author, and also that I'm in this class of self nominated folk.

I think, however, that given the massive commitment required and the
need to balance the role with employment constraints and all the
economic constraints associated with working on OpenStack being work
means that self-nomimation is probably the only realistic way to go. I
mention it more as a way jumping off point for further thinking than
a concrete proposal.

Oh okay, well thanks for clarifying.

I'll let others jump off this one with you, I don't think I'll join in. 
Thanks for the offer though.


Thanks Chris,
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] [elections][tc]Thoughts on the TC election process

2016-10-11 Thread Anita Kuno


On 2016-10-11 01:40 PM, Ed Leafe wrote:

On Oct 11, 2016, at 12:17 PM, Anita Kuno <ante...@anteaya.info> wrote:


There really needs to be a period when a) we know who all the candidates are, 
and b) voting has not yet begun.

Why?

The voting period is open for a period of several days, voters have the ability 
to vote at any time during that voting period.
  
Because many people vote as soon as they receive their ballot.


That is their choice.


  I know that I typically do so that it doesn’t get lost under the flood of 
email.


I have found putting a star on the email when it comes it helps to 
ensure I don't lose it, but everyone has a different email organizing 
workflow.



  This wouldn’t be so bad if you could later change your vote, but once it is 
cast, it can’t be changed. What that means is that if a candidate I knew little 
about says something that either interests me or turns me off, I can *use* that 
information.


You still can now, you just have to choose to listen to candidates prior 
to voting.


Monty suggested somewhere that we reissue the email ballots everyday 
(since we had email issues this time, I have no idea if that would 
result in us being kicked off the service we currently use or not). If 
the issue is, I want to ensure I can find my ballot when I need it, I 
think we can explore options that don't include requiring election 
officials to expand their commitment for an additional week.





A voter can ask the panel of candidates any question they wish such that they 
are satisfied prior to voting.

Of course; no one has said otherwise. But if someone else asks a question that 
may not have occurred to me to ask, the answers given can still be influential 
on my choices. Look at Gordon Chung’s question in this recent cycle: I’m sure 
that there were lots of people who benefited from that question and the many 
answers, not just Gordon.


I know I benefited from Gord's question, both as a candidate and as a 
voter. Thank you, Gord.


Again, I feel the choice exists.




Additionally should the decision be made to go forward with some form of the 
candidate answers as I offered to the electorate in October 2014, those answers 
could be available as platforms are posted such that all responses are 
available as soon as the poll begins.

I think that this is a great idea, and would be willing to help in the effort 
to make that happen again.


Thanks Ed, it felt satisfying to offer it when I did it. I hope others 
feel the same as you.


Thanks,
Anita.




-- Ed Leafe






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



__
OpenStack Development Mailing 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] [elections][tc]Thoughts on the TC election process

2016-10-11 Thread Anita Kuno


On 2016-10-11 12:55 PM, Ruby Loo wrote:

On Tue, Oct 11, 2016 at 12:08 PM, Chris Dent  wrote:


Based on the turnout numbers and a bit of unscientific number
crunching on the voting results it seems that the electorate was
rather more engaged this time around. That's _great_.

As others have said I imagine some significant part of that was
because of more than one mailing of the ballots to help everyone
remember. I think there were probably other factors too:


  Would it be useful to have a not-so-scientific poll, to find out from
folks why they voted and why they didn't vote in previous elections?
Assuming folks respond to the poll :)

--ruby
The likelihood that someone who choose not to do something is going to 
tell you why they choose not to do something via a poll is going to be 
fairly small would be my guess.


I think one would get a much better sense asking people if they voted 
when they see them at summit or other live events and ask them why not 
if they say no. (Given you have first of all qualified the questions as 
allowable for conversation, with the person you are talking to. Voting 
is anonymous on purpose. Also you would have to be clear in your heart 
that you aren't interested in _who_ they voted for, as that information 
is immaterial to them choosing to vote or not, in my opinion.)


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] [elections][tc]Thoughts on the TC election process

2016-10-11 Thread Anita Kuno


On 2016-10-11 12:08 PM, Chris Dent wrote:


Based on the turnout numbers and a bit of unscientific number
crunching on the voting results it seems that the electorate was
rather more engaged this time around. That's _great_.

As others have said I imagine some significant part of that was
because of more than one mailing of the ballots to help everyone
remember. I think there were probably other factors too:

* There was a large pool of candidates this time around from several
  different places on the OpenStack map. That makes for some happy:
  it wasn't the same old thing.

* The questioning and other discussion that happened last week was
  engaging and interesting and made the process something more than
  "I've heard of this person before".

Therefore I think next time around we should have that week of
discussion before the week of voting. Its impact may be greater
when people have time to reflect on the discussion before voting.

Instead of two week process, make it three:


Again as I replied to Ed's post, I think we can find options that fit in 
the current timeframe.


http://lists.openstack.org/pipermail/openstack-dev/2016-October/105449.html

Thank you,
Anita.



1. nominations
2. discussion
3. voting

I don't think we need to make the second week super formal. I hope
we can rely on at least some people to step up with interesting
questions.

Aside from that, more radical things we may want to consider
include:

* Getting rid of self nomination. Nominations come from the
  electorate at large. They can be refused of course.


What is the current problem with self nomination?



* Term limits, either absolute or consecutive. The principles[1]
  enshrine regular handover of power but since that's not always
  been demonstrated, perhaps it needs to be formalized?

* [your idea here please]


[1] 
http://governance.openstack.org/reference/principles.html#changes-in-leadership-are-good




__
OpenStack Development Mailing 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] [elections][tc]Thoughts on the TC election process

2016-10-11 Thread Anita Kuno


On 2016-10-11 12:57 PM, Thiago da Silva wrote:



On 10/11/2016 12:00 PM, Ed Leafe wrote:

On Oct 11, 2016, at 10:37 AM, Anita Kuno <ante...@anteaya.info> wrote:

Just in case folks care, now is the best time to discuss our 
election process and suggest options or changes for the next round 
of elections. I'm not adverse to discussing it I just think the best 
time for doing so is from the time the last election is over up to 
milestone one. Then we have lots of time for ideas and debate and 
any suggestions, if accepted, have time to be implemented and 
communicated so the process is fair for all, candidates and electorate.

Agreed.

During the election is a wonderful time for posing questions to 
candidates in order to clarify their position or stance such that 
the electorate can make an informed choice.
To me, that’s the crux: “during the election”. When exactly should 
that be? Candidates can (and do) declare up to the very last minute 
of the nomination window, and ballots go out immediately after that, 
and voting starts. There really needs to be a period when a) we know 
who all the candidates are, and b) voting has not yet begun. I would 
like to see that period be created so that the kind of 
question/answer/clarify process you mention can happen.

+1
Just to add on to that, it would also be nice to have a better place 
for the questions/answers to be stored.


Have you a suggestion for where you would like to see them?

Also regardless of what is formally set up, anyone can ask questions via 
the mailing list, that option has been used every election that I have 
witnessed, I don't see that changing. I don't think it is reasonable to 
ask officials to curate mailing list posts. I think what we are 
discussing is something in addition to mailing list discussions. I don't 
think anything ever would (or should) replace what comes up on the 
mailing list.


Thanks,
Anita.

During last week there was a ton of great discussion, but when it came 
to voting time (towards end of the week) it was difficult/time 
consuming to find what each person had said.


-- Ed Leafe






__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__ 


OpenStack Development Mailing 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] [elections][tc]Thoughts on the TC election process

2016-10-11 Thread Anita Kuno


On 2016-10-11 12:00 PM, Ed Leafe wrote:

On Oct 11, 2016, at 10:37 AM, Anita Kuno <ante...@anteaya.info> wrote:


Just in case folks care, now is the best time to discuss our election process 
and suggest options or changes for the next round of elections. I'm not adverse 
to discussing it I just think the best time for doing so is from the time the 
last election is over up to milestone one. Then we have lots of time for ideas 
and debate and any suggestions, if accepted, have time to be implemented and 
communicated so the process is fair for all, candidates and electorate.

Agreed.


During the election is a wonderful time for posing questions to candidates in 
order to clarify their position or stance such that the electorate can make an 
informed choice.

To me, that’s the crux: “during the election”. When exactly should that be? 
Candidates can (and do) declare up to the very last minute of the nomination 
window, and ballots go out immediately after that, and voting starts. There 
really needs to be a period when a) we know who all the candidates are, and b) 
voting has not yet begun.


Why?

The voting period is open for a period of several days, voters have the 
ability to vote at any time during that voting period. A voter can ask 
the panel of candidates any question they wish such that they are 
satisfied prior to voting. Additionally should the decision be made to 
go forward with some form of the candidate answers as I offered to the 
electorate in October 2014, those answers could be available as 
platforms are posted such that all responses are available as soon as 
the poll begins.


I think there are many options that are available to enable the 
electorate to make an informed choice that doesn't require the expansion 
of the length of time of the entire voting season. Currently voting for 
both ptl and tc elections are a month in duration, which is an extremely 
stressful time for election officials. I think we can come up with 
options that don't include increasing the time commitment election 
officials already spend on elections.




  I would like to see that period be created so that the kind of 
question/answer/clarify process you mention can happen.


I think we can create the process and still use the current timeframe. I 
didn't need to expand the time for elections in October 2014.


Thank you,
Anita.





-- Ed Leafe






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



__
OpenStack Development Mailing 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] [elections][tc]Thoughts on the TC election process

2016-10-11 Thread Anita Kuno


On 2016-10-04 04:53 PM, Anita Kuno wrote:

On 16-10-04 12:54 PM, Thierry Carrez wrote:

Doug Hellmann wrote:

John Davidge wrote:

Thierry, I'm surprised by your open hostility towards candidates.
Accusing
people of 'pretending' to care about things that they've taken the
time to

This is an excellent example of needing to know the speaker, as
well as their words, and why anonymous elections for leaders
are a bad idea generally and favor native English speakers over
other members of our community.

In this case, I know that Thierry is French and, while his English
is better than I could ever hope my French to be, he sometimes makes
"interesting" word choices, especially where the French and English
words are close in spelling or pronunciation, if not quite so close in
meaning.

In French, "prétendre" has a connotation of "profess" or simply
"say", which is very different from the more negative connotation
of "pretend" in English where common use implies some false intent.
Knowing Thierry and his past contributions well enough to trust his
good intentions, I was able to look past the awkward phrasing to
ask what message he was trying to convey.

Yeah, sorry for the poor choice of words, I didn't mean that candidates
are trying to deceive anyone. I only meant that in my experience, past
members of the TC were overly optimistic in their campaign emails about
how much they thought they would be able to achieve. So looking at the
past track record is important.


A poll in the weeks leading to the self-nomination period could
be used to identify the issues people are most concerned about, and
candidates could be encouraged to address those issues directly in 
their
self-nominations. This would reduce the reliance on a potentially 
messy

question and answer period by pre-empting the greatest concerns.

If my memory serves well, I think Anita (anteaya) drove such a
structured discussion in a past election (identify key issues and ask
candidates to address those questions in their candidacy email). Maybe
she can give us a summary of how well that went.




I had hoped to stay out of this discussion since I consider it poor 
form to discuss the way a race is run whilst the race is being run, 
however here we are.


tl;dr the idea seems sound, my method doesn't scale, other tooling 
needs to be considered if this is something folks want in future


Indeed when I was an election official in the past one of the items 
that both myself and my co-election official identified was the 
difficulty the electorate was having identifying the differences 
between the candidates (some of whom they did not know, since we were 
and have scaled so much in such a short period of time). We felt that 
it was important to do the best we could to give the electorate an 
opportunity (so hard to find a window of time to consume information 
and contemplate it anymore) to compare candidates in a neutral and 
equal way.


The wikipage for the TC election for 2014 has the information: 
https://wiki.openstack.org/wiki/TC_Elections_October_2014
I also would suggest looking at the history of edits to the page to 
get a sense of the work involved in offering this information in this 
way.


I came up with the questions myself: 
https://wiki.openstack.org/wiki/TC_Elections_October_2014#TC_Election_Questions 
Tristan signed off on them but he didn't have as much knowledge of the 
community as I did at the time so I composed them. We debated on 
asking the mailing list for input but since I knew I would be doing 
the lions share of the work on this one I didn't want to have to 
filter through questions and then appear to either pick favourites or 
snub someone should I select or not select their offered question. I 
felt I had enough pressure on myself already taking this on, I didn't 
want to dig myself a deeper hole.


As you can see from the edits to the wikipage (I basically spent 4 
straight days adding answers and reordering existing answers on the 
wikipage - I had a bowl of names in my home and every time a new 
response came in I shook the names and selected them out of the bowl 
to create an order and then did it again for the next question - it 
was time consuming but I felt it was worth it in terms of serving the 
community's interests) I reordered the responses often to ensure that 
preference in response order was moved around. I value the opportunity 
for people to make their own decision very highly and didn't want my 
choices in terms of how the information was presented to play a role 
in how they perceived the information. So I shuffled the answers a lot.


Now in the post mortem of the election tooling discussion in the infra 
meeting we did discuss options for tooling to ensure the responses are 
shuffled when rendered in subsequent elections (I think that may have 
been the time I also presented the idea of moving to a git repo, I 
can't remember) but it wasn't picked u

Re: [openstack-dev] [openstack-announce] OpenStack Newton is officially released!

2016-10-06 Thread Anita Kuno


On 16-10-06 10:04 AM, Doug Hellmann wrote:

Hello OpenStack community,

I'm overjoyed to announce the final releases for the components of
OpenStack Newton, which conclude the 6-month Newton development
cycle.

You will find a complete list of the deliverables for the 31 services
and ~130 other components and libraries that make up the Newton
release, their latest versions, and links to individual project
release notes documents listed on the release site:

 https://releases.openstack.org/newton/

Congratulations to all of the teams who have contributed to this
release!

Our next production cycle, Ocata, has already started. We will meet
in Barcelona October 25-28 at the Ocata Design Summit to plan the
work for the upcoming cycle. I hope to see you there!

Doug

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


Thank you Doug and everyone on the release management team.

Congratulations everyone, nice work on Newton.

Thank you,
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] [elections][tc]Thoughts on the TC election process

2016-10-04 Thread Anita Kuno


On 16-10-04 12:54 PM, Thierry Carrez wrote:

Doug Hellmann wrote:

John Davidge wrote:

Thierry, I'm surprised by your open hostility towards candidates.
Accusing
people of 'pretending' to care about things that they've taken the
time to

This is an excellent example of needing to know the speaker, as
well as their words, and why anonymous elections for leaders
are a bad idea generally and favor native English speakers over
other members of our community.

In this case, I know that Thierry is French and, while his English
is better than I could ever hope my French to be, he sometimes makes
"interesting" word choices, especially where the French and English
words are close in spelling or pronunciation, if not quite so close in
meaning.

In French, "prétendre" has a connotation of "profess" or simply
"say", which is very different from the more negative connotation
of "pretend" in English where common use implies some false intent.
Knowing Thierry and his past contributions well enough to trust his
good intentions, I was able to look past the awkward phrasing to
ask what message he was trying to convey.

Yeah, sorry for the poor choice of words, I didn't mean that candidates
are trying to deceive anyone. I only meant that in my experience, past
members of the TC were overly optimistic in their campaign emails about
how much they thought they would be able to achieve. So looking at the
past track record is important.


A poll in the weeks leading to the self-nomination period could
be used to identify the issues people are most concerned about, and
candidates could be encouraged to address those issues directly in their
self-nominations. This would reduce the reliance on a potentially messy
question and answer period by pre-empting the greatest concerns.

If my memory serves well, I think Anita (anteaya) drove such a
structured discussion in a past election (identify key issues and ask
candidates to address those questions in their candidacy email). Maybe
she can give us a summary of how well that went.




I had hoped to stay out of this discussion since I consider it poor form 
to discuss the way a race is run whilst the race is being run, however 
here we are.


tl;dr the idea seems sound, my method doesn't scale, other tooling needs 
to be considered if this is something folks want in future


Indeed when I was an election official in the past one of the items that 
both myself and my co-election official identified was the difficulty 
the electorate was having identifying the differences between the 
candidates (some of whom they did not know, since we were and have 
scaled so much in such a short period of time). We felt that it was 
important to do the best we could to give the electorate an opportunity 
(so hard to find a window of time to consume information and contemplate 
it anymore) to compare candidates in a neutral and equal way.


The wikipage for the TC election for 2014 has the information: 
https://wiki.openstack.org/wiki/TC_Elections_October_2014
I also would suggest looking at the history of edits to the page to get 
a sense of the work involved in offering this information in this way.


I came up with the questions myself: 
https://wiki.openstack.org/wiki/TC_Elections_October_2014#TC_Election_Questions 
Tristan signed off on them but he didn't have as much knowledge of the 
community as I did at the time so I composed them. We debated on asking 
the mailing list for input but since I knew I would be doing the lions 
share of the work on this one I didn't want to have to filter through 
questions and then appear to either pick favourites or snub someone 
should I select or not select their offered question. I felt I had 
enough pressure on myself already taking this on, I didn't want to dig 
myself a deeper hole.


As you can see from the edits to the wikipage (I basically spent 4 
straight days adding answers and reordering existing answers on the 
wikipage - I had a bowl of names in my home and every time a new 
response came in I shook the names and selected them out of the bowl to 
create an order and then did it again for the next question - it was 
time consuming but I felt it was worth it in terms of serving the 
community's interests) I reordered the responses often to ensure that 
preference in response order was moved around. I value the opportunity 
for people to make their own decision very highly and didn't want my 
choices in terms of how the information was presented to play a role in 
how they perceived the information. So I shuffled the answers a lot.


Now in the post mortem of the election tooling discussion in the infra 
meeting we did discuss options for tooling to ensure the responses are 
shuffled when rendered in subsequent elections (I think that may have 
been the time I also presented the idea of moving to a git repo, I can't 
remember) but it wasn't picked up on and I decided in fairness to let 
others take a turn running elections and didn't pursue it.


I

Re: [openstack-dev] [tc] open question to the candidates

2016-10-03 Thread Anita Kuno


On 16-10-03 11:30 AM, gordon chung wrote:

hi,

as there are many candidates this TC election, i figured i'd ask a
question to better understand the candidates from the usual sales pitch
in self-nominations. hopefully, this will give some insights into the
candidates for those who haven't voted yet. obviously, the following is
completely optional. :)

i initially asked this to John Dickinson[1] in his self-nomination. i'd
like to open this up to everyone. the (re-worded) question is:

the TC has historically been a reactive council that lets others ask for
change and acts as the final approver. do you believe the TC should be a
proactive committee that initiates change and if yes, to what scope?
more generally, what are some specific issues you'd like the TC address
in the coming year?

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104821.html

thanks,


Thanks Gord:

My view of the technical committee is that it is in place to solve 
actual problems not to chase after things which may or may not be a 
problem. One of the best ways to identify if some issue is a problem is 
for someone to identify it is a problem for them. Issues have been 
raised by members of the community approaching the technical committee, 
issues have also been raised by technical committee members themselves.


Whether something is considered reactive or proactive is often based on 
their personal perception as events unfold. Sometimes some members feel 
something should be addressed but need the correct alignment of events 
to occur for the community to agree.


I think one of the largest issues we will face in the coming year is 
what does it mean now that the projects will be meeting at the project 
team gathering in Atlanta in February and the Conference will take place 
in Boston later in the spring. These events affect a lot of people and 
many folks will be confused about what can and can't be accomplished in 
the separate spaces and also the symbology of what this means to them, 
their work and their business plans. I think the Foundation has be 
proactive in communicating this. I think the technical committee to date 
has been proactive in recognizing this is a need. I think the next 
technical committee with have to do both proactive communicating and 
reactive redirecting as folks move toward these events, at these events 
and following up these events. I think these events are much on people's 
minds and the technical committee needs to continue to communicate the 
workflow and expectation of these events in concert with the Foundation 
as it has done thus far.


Thank you,
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

[openstack-dev] [elections] TC candidacy

2016-10-01 Thread Anita Kuno


OpenStack ensures people have a choice.

We give developers choices, which gives deployers choices, which ensures
consumers have choices.

We make choices, evaluate results, revisit and choose again.

OpenStack creates space; personal space, public space. The choice is 
available.


By virtue of OpenStack's existence people retain belief in themselves. They
retain belief in what they can create with others.

OpenStack is an international experience. Not only is there an 
opportunity to

listen and understand people with different perspectives and life
experiences, it is a daily occurrence. In no other environment have I 
spent so
much time considering what the weather is in China, if France is on 
holiday at

the moment, whether my co-workers are safe. I spend time thinking about the
people I work with more than in any other prior environment. Your lives 
are all

so very different from my own.

Yet for the most part, I believe we want similar things, to be useful, 
to help
others and to create something together that is also useful and helps 
others.


Thank you for reading.
Please vote,
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] [packaging][rpm] 3rd-party gates promotion to voting gates

2016-09-29 Thread Anita Kuno


On 16-09-29 08:12 AM, Haïkel wrote:

2016-09-26 16:05 GMT+02:00 Anita Kuno <ante...@anteaya.info>:

On 16-09-26 07:48 AM, Haïkel wrote:

Hi,

following our discussions about 3rd party gates in RPM packaging project,
I suggest that we vote in order to promote the following gates as voting:
- MOS CI
- SUSE CI

After promotion, all patchsets submitted will have to validate these gates
in order to get merged. And gates maintainers should ensure that the gates
are running properly.

Please vote before (and/or during) our thursday meeting.


+1 to promote both MOS and SUSE CI as voting gates.

Regards,
H.


I'm not sure what you mean by voting gates. Gates don't vote, an individual
job can leave a verified +1 in the check queue or/and a verified +2 in the
gate queue.

Third party CI systems do not vote verified +2 in gerrit. They may if the
project chooses vote verified +1 on a project.


Yeah, that was pretty much what was assumed.
Gates that do not leave verified +1 are called non-voting, so
logically gates that leaves verified +1 are called voting gates.


Gate is a pipeline. Jobs run in pipelines (check, gate, post) and leave 
success or failure as results.


There is no such thing as a voting gate. There is a thing called a 
voting job. I think you mean voting job.


Thanks,
Anita.




If you need clarification in what third party ci systems may do in gerrit,
you are welcome to reply to this email, join the #openstack-infra channel or
participate in a third party meeting:
http://eavesdrop.openstack.org/#Third_Party_Meeting

Thank you,
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

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



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

Re: [openstack-dev] [Neutron] Retiring stale stadium projects

2016-09-27 Thread Anita Kuno


On 16-09-27 09:18 PM, Armando M. wrote:

Hi Neutrinos,

I wanted to double check with you the state of these following projects:

- networking-ofagent
- python-neutron-pd-driver

It's my understanding that they are ready for retirement or thereabouts.
Please confirm, and I'll kick off the countdown sequence [1].

Cheers,
Armando

[1] http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project


Please remove the dot files on the first round of the "removing project 
content" step. It often gets missed.


Thank you,
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] [packaging][rpm] 3rd-party gates promotion to voting gates

2016-09-26 Thread Anita Kuno


On 16-09-26 07:48 AM, Haïkel wrote:

Hi,

following our discussions about 3rd party gates in RPM packaging project,
I suggest that we vote in order to promote the following gates as voting:
- MOS CI
- SUSE CI

After promotion, all patchsets submitted will have to validate these gates
in order to get merged. And gates maintainers should ensure that the gates
are running properly.

Please vote before (and/or during) our thursday meeting.


+1 to promote both MOS and SUSE CI as voting gates.

Regards,
H.


I'm not sure what you mean by voting gates. Gates don't vote, an 
individual job can leave a verified +1 in the check queue or/and a 
verified +2 in the gate queue.


Third party CI systems do not vote verified +2 in gerrit. They may if 
the project chooses vote verified +1 on a project.


If you need clarification in what third party ci systems may do in 
gerrit, you are welcome to reply to this email, join the 
#openstack-infra channel or participate in a third party meeting: 
http://eavesdrop.openstack.org/#Third_Party_Meeting


Thank you,
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] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent

2016-09-22 Thread Anita Kuno


On 16-09-21 01:11 PM, Doug Hellmann wrote:

Excerpts from Clint Byrum's message of 2016-09-21 08:56:24 -0700:

Excerpts from Filip Pytloun's message of 2016-09-21 14:58:52 +0200:

Hello,

it's definately our bad that we missed elections in OpenStackSalt
project. Reason is similar to Rob's - we are active on different
channels (mostly IRC as we keep regular meetings) and don't used to
reading mailing lists with lots of generic topics (it would be good to
have separate mailing list for such calls and critical topics or
individual mails to project's core members).

Our project is very active [1], trying to do things the Openstack way
and I think it would be a pitty to remove it from Big Tent just because
we missed mail and therefore our first PTL election.

Of course I don't want to excuse our fault. In case it's not too late,
we will try to be more active in mailing lists like openstack-dev and
not miss such important events next time.

[1] http://stackalytics.com/?module=openstacksalt-group


Seems like we need a bit added to this process which makes sure big tent
projects have their primary IRC channel identified, and a list of core
reviewer and meeting chair IRC nicks to ping when something urgent comes
up. This isn't just useful for elections, but is probably something the
VMT would appreciate as well, and likely anyone else who has an urgent
need to make contact with a team.

IRC channels are listed on team pages on governance.o.o. For example:
http://governance.openstack.org/reference/projects/openstacksalt.html

Core reviewers are accessible through gerrit. For example,
https://review.openstack.org/#/admin/projects/openstack/openstack-salt,access
leads to https://review.openstack.org/#/admin/groups/1268,members

Meeting chair nicks are available on eavesdrop.o.o. For example,
http://eavesdrop.openstack.org/#OpenStack_Salt_Team_Meeting

It might make sense to automate pulling that information together into a
single page somewhere, maybe the team page on governance.o.o.

The larger point is that the community expects teams to be paying
attention to the cycle schedule and taking care of the actions expected
without being individually asked to do so.


I think it might also be useful if we could make the meeting bot remind
teams of any pending actions they need to take such as elections upon
#startmeeting.

I could see that being useful, yes.


Seems like all of that could be automated.


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


I am not convinced this situation arose due to lack of available 
information.


Thank you,
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] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent

2016-09-22 Thread Anita Kuno


On 16-09-22 11:32 AM, Filip Pytloun wrote:

If there's more we can do, we are available at Freenode/#openstack-salt.
I think this right here is your issue. Believing it is the 
responsibility of the tc or other leaders to find you. It isn't.


Be available on #openstack-dev at the very least.

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] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent

2016-09-22 Thread Anita Kuno


On 16-09-21 05:08 PM, Davanum Srinivas wrote:

Jakub,

Please see below.

On Wed, Sep 21, 2016 at 3:46 PM, Jakub Pavlik  wrote:

Hello all,

it took us 2 years of hard working to get these official. OpenStack-Salt is
now used by around 40 production deployments and it is focused very on
operation and popularity is growing. You are removing the project week after
one of top contributor announced that they will use that as part of
solution. We made a mistakes, however I do not think that is reason to
remove us. I do no think that quality of the project is measured like this.
Our PTL got ill and did not do properly his job for last 3 weeks, but this
can happen anybody.

  It is up to you. If you think that we are useless for community, then
remove us and we will have to continue outside of this community. However
growing successful use cases will not be under official openstack community,
which makes my feeling bad.

Data points so far are:
1. No response during Barcelona planning for rooms
2. Lack of candidates for PTL election
3. No activity in the releases/ repository hence no entries in
https://releases.openstack.org/
4. Meetings are not so regular?
http://eavesdrop.openstack.org/meetings/openstack_salt/2016/ (supposed
to be weekly)
5. Is the specs repo really active?
http://git.openstack.org/cgit/openstack/openstack-salt-specs/ is the
work being done elsewhere?
6. Is there an effort to add stuff to the CI jobs running on openstack
infrastructure? (can't seem to find much
http://codesearch.openstack.org/?q=salt=nope=zuul%2Flayout.yaml=project-config)

I'll stop here and switch to #openstack-salt channel to help work you
all through if there is a consensus/willingness from the
openstack-salt team that there's significant work to be done. If you
think you are better off not on the governance, that would be your
call as well.

Thanks,
Dims


Thanks,

Jakub


On 21.9.2016 21:03, Doug Hellmann wrote:

Excerpts from Filip Pytloun's message of 2016-09-21 20:36:42 +0200:

On 2016/09/21 13:23, Doug Hellmann wrote:

The idea of splitting the contributor list comes up pretty regularly
and we rehash the same suggestions each time.  Given that what we
have now worked fine for 57 of the 59 offical teams (the Astara
team knew in advance it would not have a PTL running, and Piet had
some sort of technical issue submitting his candidacy for the UX
team), I'm not yet convinced that we need to make large-scale changes
to our community communication standard practices in support of the
2 remaining teams.

That's not to say that the system we have now is perfect, but we
can't realistically support multiple systems at the same time.  We
need everyone to use the same system, otherwise we have (even more)
fragmented communication. So, we either need everyone to agree to
some new system and then have people step forward to implement it,
or we need to all agree to do our best to use the system we have
in place now.

I think it may work as is (with proper mail filters), but as someone
already
mentioned in this thread it would be better to have someone more
experienced
in Openstack community projects as a core team member or PTL to catch all
these things otherwise it may happen that inexperienced PTL/team just
miss
something like now.

If the team needs help, please ask for it. We should be able to find
someone to do a little mentoring and provide some guidance.


Still I don't think it's such a big issue to just fire project from Big
Tent -
who will benefit from that? Again someone already mentioned what will it
mean
for such team (loss of potencial developers, etc.).
Moreover for teams who are actively working on project as it seems that
both
OpenStackSalt and Security teams do.

Signing up to be a part of the big tent is not free. Membership comes
with expectations and obligations. Failing to meet those may be an
indication that the team isn't ready, or that membership is not a good
fit.


And I thought that real work on a project is our primary goal.. this
situation
is like loosing job when I left dirty coffee cup at my workspace.

I hope you consider team leadership and community participation to
be more important than your analogy implies.

Doug


Did your release liaison follow the instructions to make that happen?
http://git.openstack.org/cgit/openstack/releases/tree/README.rst

That seems to be the reason. There was new release planned with support
for
containerized deployment which would follow that guide (as first releases
were
done during/shortly after openstack-salt move to Big Tent).
As mentioned above - more experienced PTL would be helpful here and we
are
currently talking with people who could fit that position.


I see no emails tagged with [salt] on the mailing list since March of
this year, aside from this thread. Are you using a different communication
channel for team coordination? You mention IRC, but how are new contributors
expected to find you?

Yes, we are using openstack-salt

Re: [openstack-dev] Too many mails on announce list again :)

2016-09-20 Thread Anita Kuno


On 16-09-20 05:38 PM, Morgan Fainberg wrote:

On Tue, Sep 20, 2016 at 9:18 AM, Doug Hellmann 
wrote:


Excerpts from Thierry Carrez's message of 2016-09-20 10:19:04 +0200:

Steve Martinelli wrote:

I think bundling the puppet, ansible and oslo releases together would
cut down on a considerable amount of traffic. Bundling or grouping new
releases may not be the most accurate, but if it encourages the right
folks to read the content instead of brushing it off, I think thats
worth while.

Yeah, I agree that the current "style" of announcing actively trains
people to ignore announces. The trick is that it's non-trivial to
regroup announces (as they are automatically sent as a post-job for each
tag).

Solutions include:

* A daily job that catches releases of the day and batches them into a
single announce (issue being you don't get notified as soon as the
release is available, and the announce email ends up being extremely

long)

* A specific -release ML where all announces are posted, with a daily
job to generate an email (one to -announce for services, one to -dev for
libraries) that links to them, without expanding (issue being you don't
have the natural thread in -dev to react to a broken oslo release)

* Somehow generate the email from the openstack/release request rather
than from the tags

One email, with less detail, generated when a file merges into
openstack/release is my preference because it's easier to implement.

Alternately we could move all of the announcements we have now to
a new -release list and folks that only want one email a day can
subscribe using digest delivery. Of course they could do that with
the list we have now, too.

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


A release list makes a lot of sense. If you also include clear metadata in
the subject such as including the owning project aka: keystone (for
keystone auth, keystonemiddleware, keystoneclient), people can do direct
filtering for what they care about ( as well digest mode).

--/morgan



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


Also you can set the description for the list to state the fact this 
list is meant for releases, so it will curtail complaints from 
subscribers saying we don't like what we are getting.


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] [nova] ops meetup feedback

2016-09-20 Thread Anita Kuno


On 16-09-20 09:20 AM, Sean Dague wrote:

This is a bit delayed due to the release rush, finally getting back to
writing up my experiences at the Ops Meetup.

Nova Feedback Session
=

We had a double session for Feedback for Nova from Operators, raw
etherpad here - https://etherpad.openstack.org/p/NYC-ops-Nova.

The median release people were on in the room was Kilo. Some were
upgrading to Liberty, many had older than Kilo clouds. Remembering
these are the larger ops environments that are engaged enough with the
community to send people to the Ops Meetup.


Performance Bottlenecks
---

* scheduling issues with Ironic - (this is a bug we got through during
   the week after the session)
* live snapshots actually end up performance issue for people

The workarounds config group was not well known, and everyone in the
room wished we advertised that a bit more. The solution for snapshot
performance is in there.

There were also general questions about what scale cells should be
considered at.

ACTION: we should make sure workarounds are advertised better
ACTION: we should have some document about "when cells"?

Networking
--

A number of folks in the room were still on Nova Net, and were a bit
nervous about it going away. As they are Kilo / Liberty it's still a
few upgrades before they get there, but that nervousness and concern
was definitely there.

Policy
--

How are you customizing policy? People were largely making policy
changes to protect their users that didn't really understand cloud
semantics. Turning off features that they thought would confuse them
(like pause). The large number of VM states is confusing, and not
clearly useful for end users, and they would like simplification.

Ideally policy could be set on a project by project admin, because
they would like to delegate that responsibility down.

No one was using the user_id based custom policy (yay!).

There was desire that flavors could be RBAC locked down, which was
actually being done via policy hacks right now. Providers want to
expose some flavors (especially those with aggregate affinity) to only
some projects.

People were excited about the policy in code effort, only concern was
that the defacto documentation of what you could change wouldn't be in
the sample config.

ACTION: ensure there is policy config reference now that the sample
file is empty
ACTION: flavor RBAC is a thing most of the room wanted, is there a
taker on spec / implementation?

Upgrade
---

Everyone waits to do any optional thing until they absolutely have
to.

The Cells API db caught a bunch of people off guard because it was in
Kilo (with release note) optional. Status quo in Liberty, with no
release note about it existing, then forced in Mitaka. When an
optional component is out there make sure it continues to be talked
about in releases even when it's status did not change, or people
forget.

People were on Kilo, so EC2 out of tree didn't really have any
data. About 25% of folks users have some existing AWS tooling, that
it's good to be able to just let them use to onboard them.

The current DB online data upgrade model feels *very opaque* to
ops. They didn't realize the current model Nova was using, and didn't
feel like it was documented anywhere.

ACTION: document the DB data lifecycle better for operators
ACTION: make sure we are cautious in rewarning people about changes
they have to make (like Cells API db)

API
---

API upgrade seemed fine for folks. The only question was the new
policy names, which was taking folks a bit of time to adjust to.

No one in the room was using custom API extensions (or at least
admitted to it when I asked).

Tracking Feedback
-

We talked a bit about tracking feedback. The silence on the ops list
mostly comes from people not using a particular feature, so they don't
really have an opinion.

Most ops do not have time to look at our specs. That is an unlikely
place to get feedback.

Additional Questions


There was an ask about VM HA. I stated that was beyond scope for Nova,
plus Nova's view of the world is non authoritative enough you didn't
want it to do that anyway. I told folks that the NFV efforts were
working on this kind of thing beyond Nova, and people should team up
there.

There was an ask on status of Cinder Multi Attach. We gave them a bit
of status on where things were at.

ACTION: Cinder Multi Attach should maybe be a priority effort in the
next cycle.


Upgrade Pain Points
===

Raw etherpad -
https://etherpad.openstack.org/p/NYC-ops-Upgrades-Pain-points

Most people are a couple of releases back (Kilo / Liberty or even
older). The only team CDing in the room was RAX, they are now 2 to 3
months behind master.

Everyone agrees upgrades are getting better with every release.

Most are taking change windows and downtime for upgrades.

Why are upgrades taking so long?


About half

Re: [openstack-dev] Election Season, PTL and TC September/October 2016

2016-09-13 Thread Anita Kuno


On 16-09-13 10:23 AM, Anita Kuno wrote:

On 16-09-13 09:52 AM, Nate Johnston wrote:

On Tue, Sep 13, 2016 at 07:48:06AM -0500, Sean McGinnis wrote:

On Tue, Sep 13, 2016 at 05:14:56PM +1000, Tony Breeds wrote:

On Fri, Sep 02, 2016 at 12:10:53PM +, Tristan Cacqueray wrote:


Lastly, election officials are also reachable through the
#openstack-election Freenode channel.

I wonder if it's worth having all conversations in #openstack-dev?

There are pros and cons to both.

Having a single purpose election channel certainly make it easy to 
spot election activity

Using openstack-dev increases the possibility of braoder reach.

I don't have a strong opionion either way.

Yours Tony.

No strong opinion either, but I agree openstack-dev would get more
visiblity.

Sean (smcginnis)

I am fine with #openstack-dev if that is the consensus choice, but we
may also want to list the direct contact info for the election officers


Officials, not officers. The role is to administrate as an appointee 
of the technical committee, not police.



so that people can ping directly in case their query happens to get
lost.  The conversation can then come back to #openstack-dev, but then
you would know you had someone's attention.


Well the method of communication up until now has been using the -dev 
mailing list with an invitation to email the election officials 
directly for private matters. That way communication reaches the 
broadest audience and is time insensitive.


Correction, timezone insensitive. The fact that email is time sensitive 
is also one of the features for using it.


Thanks,
Anita.


My experience is that has worked well in the past.

Thank you,
Anita.



But this is my first time helping out on an OpenStack election, so I may
be a bit paranoid about missing something.

--N.

__ 


OpenStack Development Mailing 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] Election Season, PTL and TC September/October 2016

2016-09-13 Thread Anita Kuno


On 16-09-13 09:52 AM, Nate Johnston wrote:

On Tue, Sep 13, 2016 at 07:48:06AM -0500, Sean McGinnis wrote:

On Tue, Sep 13, 2016 at 05:14:56PM +1000, Tony Breeds wrote:

On Fri, Sep 02, 2016 at 12:10:53PM +, Tristan Cacqueray wrote:


Lastly, election officials are also reachable through the
#openstack-election Freenode channel.

I wonder if it's worth having all conversations in #openstack-dev?

There are pros and cons to both.

Having a single purpose election channel certainly make it easy to spot 
election activity
Using openstack-dev increases the possibility of braoder reach.

I don't have a strong opionion either way.

Yours Tony.

No strong opinion either, but I agree openstack-dev would get more
visiblity.

Sean (smcginnis)

I am fine with #openstack-dev if that is the consensus choice, but we
may also want to list the direct contact info for the election officers


Officials, not officers. The role is to administrate as an appointee of 
the technical committee, not police.



so that people can ping directly in case their query happens to get
lost.  The conversation can then come back to #openstack-dev, but then
you would know you had someone's attention.


Well the method of communication up until now has been using the -dev 
mailing list with an invitation to email the election officials directly 
for private matters. That way communication reaches the broadest 
audience and is time insensitive. My experience is that has worked well 
in the past.


Thank you,
Anita.



But this is my first time helping out on an OpenStack election, so I may
be a bit paranoid about missing something.

--N.

__
OpenStack Development Mailing 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] Timeframe for future elections & "Release stewards"

2016-09-07 Thread Anita Kuno

On 16-09-07 02:19 PM, Ian Cordasco wrote:

-Original Message-
From: Anita Kuno <ante...@anteaya.info>
Reply: Anita Kuno <ante...@anteaya.info>
Date: September 7, 2016 at 13:08:44
To: Ian Cordasco <sigmaviru...@gmail.com>, OpenStack Development Mailing List (not 
for usage questions) <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] Timeframe for future elections & "Release 
stewards"

On 16-09-07 01:59 PM, Ian Cordasco wrote:

-Original Message-
From: Anita Kuno
Reply: OpenStack Development Mailing List (not for usage questions)
Date: September 7, 2016 at 12:03:25
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] Timeframe for future elections & "Release 
stewards"

On 16-09-07 12:43 PM, Davanum Srinivas wrote:

Now, the main drawback of holding elections in the middle of a
development cycle is that you don't want to introduce a discontinuity in
leadership in that development cycle. To mitigate that, we propose the
introduction of a new role, the "release steward", which would be
attached to the release cycle. That person (who may or may not double as
PTL) would be responsible for a complete release cycle on a given
project team, from requirements gathering phase to post-release
bugfix-backport phase. A sort of per-cycle release liaison on steroids.

I think this is a great idea. Having a person be on point for a
particular release from inception to whenever we stop caring about it
makes a lot of sense.

I agree. Regardless of how PTL elections end up working, I think we should 
definitely

move forward with this "Release Stewards" concept. It sounds like an excellent 
idea.

Also since "Release Stewards" are nominated by PTL, projects can just
start using this concept right away (as it's not an elected position).
+1 from me.

One question, should "Release Stewards" also be members of the Stable Team for 
that

project or will they become members of the Stable Team? It seems like there 
should be

a

relationship there to me (although maybe not a strictly enforced one).

Welcomed and required are two different things. I think the stable team
is always willing to work with new contributors. I additionally think
that floating the expectation that someone able to take on the release
steward position also is required to entertain the stable team
responsibilities might shy away good candidates for the release steward
position. I think working with the single concept of release steward
first is a good place to begin. Give it space to grow both as a concept
within OpenStack and within individual projects.

I absolutely agree that this could scare off potentially good candidates. I 
also did

a very poor job explaining why I think this is related, I'm sorry.

In my mind, if I were a Release Steward for a project. I would think I'd not 
only be in charge

of helping the initial release but also managing "post-release bugfix-backport 
phase".
That to me is what a PTL does with the Stable Team, so at least I would need to 
coordinate
with the Stable Team. It at least seems implied. Now whether the person be an 
existing
member of the Stable Team, doesn't seem important. But if the person is Release 
Steward,
I'd expect them to be able to help approve changes to the branch/release 
they're stewarding.
That, implies to me, that they'll need to work within the Stable Team. Given 
that train
of thought, it makes sense to me that a Release Steward who is not already a 
Stable Team
member would have to become one to continue their stewardship and would be 
trusted to
(maybe only at first) approve changes for their release and not for all stable 
branches.

Does that help to explain my reasoning for bringing that up?

Yes it does, thanks for taking the time to expand. What you say makes

perfect sense from the perspective of the contributors.

I'm taking a look at the perspective of a manager, who may or may not

know what our actual workflow is and how we operate. There are a number
of folks who unfortunately have to quantify their time working on
OpenStack in terms of percentage of a week or month. For anyone in that
position, and to the managers who care enough to read this list (thank
you by the way) I want to help those in this position to be able to get
permission to do the work if that is their wish. If we keep the time
required to a percentage their manager will approve then we open the
door wider. Hence my recognition of the difference between welcomed and
required. If we keep the required bit to the smallest workable piece
more managers will allow their charges to do the work or at the very
least, not block them.

I absolutely agree. =) (I'm also one of those people who has to track and 
justify % of time on OpenStack so I appreciate your consideration of us, 
sincerely.)

Thanks Ian, I'm glad we are in agreement. I know you had to cut ba

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

2016-09-07 Thread Anita Kuno

On 16-09-07 01:59 PM, Ian Cordasco wrote:

-Original Message-
From: Anita Kuno <ante...@anteaya.info>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: September 7, 2016 at 12:03:25
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] Timeframe for future elections & "Release 
stewards"

On 16-09-07 12:43 PM, Davanum Srinivas wrote:

Now, the main drawback of holding elections in the middle of a
development cycle is that you don't want to introduce a discontinuity in
leadership in that development cycle. To mitigate that, we propose the
introduction of a new role, the "release steward", which would be
attached to the release cycle. That person (who may or may not double as
PTL) would be responsible for a complete release cycle on a given
project team, from requirements gathering phase to post-release
bugfix-backport phase. A sort of per-cycle release liaison on steroids.

I think this is a great idea. Having a person be on point for a
particular release from inception to whenever we stop caring about it
makes a lot of sense.

I agree. Regardless of how PTL elections end up working, I think we should 
definitely

move forward with this "Release Stewards" concept. It sounds like an excellent 
idea.

Also since "Release Stewards" are nominated by PTL, projects can just
start using this concept right away (as it's not an elected position).
+1 from me.

One question, should "Release Stewards" also be members of the Stable Team for 
that

project or will they become members of the Stable Team? It seems like there 
should be a
relationship there to me (although maybe not a strictly enforced one).

Welcomed and required are two different things. I think the stable team

is always willing to work with new contributors. I additionally think
that floating the expectation that someone able to take on the release
steward position also is required to entertain the stable team
responsibilities might shy away good candidates for the release steward
position. I think working with the single concept of release steward
first is a good place to begin. Give it space to grow both as a concept
within OpenStack and within individual projects.

I absolutely agree that this could scare off potentially good candidates. I 
also did a very poor job explaining why I think this is related, I'm sorry.

In my mind, if I were a Release Steward for a project. I would think I'd not only be in 
charge of helping the initial release but also managing "post-release 
bugfix-backport phase". That to me is what a PTL does with the Stable Team, so at 
least I would need to coordinate with the Stable Team. It at least seems implied. Now 
whether the person be an existing member of the Stable Team, doesn't seem important. But 
if the person is Release Steward, I'd expect them to be able to help approve changes to 
the branch/release they're stewarding. That, implies to me, that they'll need to work 
within the Stable Team. Given that train of thought, it makes sense to me that a Release 
Steward who is not already a Stable Team member would have to become one to continue 
their stewardship and would be trusted to (maybe only at first) approve changes for their 
release and not for all stable branches.

Does that help to explain my reasoning for bringing that up?

Yes it does, thanks for taking the time to expand. What you say makes 
perfect sense from the perspective of the contributors.

I'm taking a look at the perspective of a manager, who may or may not 
know what our actual workflow is and how we operate. There are a number 
of folks who unfortunately have to quantify their time working on 
OpenStack in terms of percentage of a week or month. For anyone in that 
position, and to the managers who care enough to read this list (thank 
you by the way) I want to help those in this position to be able to get 
permission to do the work if that is their wish. If we keep the time 
required to a percentage their manager will approve then we open the 
door wider. Hence my recognition of the difference between welcomed and 
required. If we keep the required bit to the smallest workable piece 
more managers will allow their charges to do the work or at the very 
least, not block them.

Thanks,
Anita.

I don't want to scare folks off at all, but I think we should maybe chat a bit 
about this.
--
Ian Cordasco

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

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

2016-09-07 Thread Anita Kuno


On 16-09-07 12:43 PM, Davanum Srinivas wrote:

On Wed, Sep 7, 2016 at 12:35 PM, Ian Cordasco  wrote:


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

Date: September 7, 2016 at 10:58:52
To: openstack-dev@lists.openstack.org 
Subject:  Re: [openstack-dev] [all] Timeframe for future elections & "Release 
stewards"


On 09/07/2016 10:43 AM, Thierry Carrez wrote:

Hi everyone,

As you probably know by now, starting with the Boston event in 2017, the
Summit will happen further away from the release day and more around the
middle of the next development cycle. You can find more info on the
rationale for that at [1] and [2] if interested, this is not the topic
of this email.

One interesting side-effect is that since the timing of the election
period (for PTL and TC positions) is defined in the TC charter[3]
relative to the *Summit*, it means that (unless we change this) we'll
now run elections to renew PTL and TC positions in the middle of the
cycle. Crazy, right ? That's what I first thought. But after discussing
it with various people, this is not as crazy as it sounds.

First, the current election timing is not perfect -- we change PTLs in
the middle of the design summit prep, with old PTLs making Design Summit
space requests that will affect their successor. It's not as if there
was a perfect timing for doing elections.

Second, release cycles are longer than 6 months. They actually start a
few months before actual development starts, with discussions on next
cycle priorities and Design Summit prep. They continue a few months
after release, with critical stable branch backports and communication
about landed features. So they are one year-long, overlapping cycles
(like explained on the diagram at [4]). With that in mind, the PTL/TC
election actually would happen just before the start of the start of the
requirements-gathering pre-development phase of the next development
cycle, which makes a lot of sense.

Now, the main drawback of holding elections in the middle of a
development cycle is that you don't want to introduce a discontinuity in
leadership in that development cycle. To mitigate that, we propose the
introduction of a new role, the "release steward", which would be
attached to the release cycle. That person (who may or may not double as
PTL) would be responsible for a complete release cycle on a given
project team, from requirements gathering phase to post-release
bugfix-backport phase. A sort of per-cycle release liaison on steroids.

Since development cycles overlap, there would be two active release
stewards at all times. This would help with the awkward situation where
the PTL ends up having to think about the next cycle and prepare the
Design Summit (or PTG) while still being knee-deep juggling with feature
freeze exceptions, getting the current release out of the door, and
coordinating early critical fixes stable backports. Those two jobs could
be held by two different people.

Now, some teams (especially those doing intermediary releases) may want
to use the same super-human to handle everything (PTL, release steward,
release+1 steward), and some others might use two or three humans to
spread the load. That's up to them. But once designated by the
newly-elected PTL, the release steward would be responsible for the full
release cycle and would not be displaced by the next PTL 6 months later.
One year being a long time, if a steward needs to step down, the
currently-active PTL would appoint someone else to finish the job.

With this new concept I think we can get the best of both worlds, and
keep the election period as currently defined in the charter (rather
than having to change it). The PTLs we will elect in the coming weeks
won't be renewed before April, 2017 -- while Pike development will start
in February.

I know this can all be a bit confusing, so feel free to reach out to me
with questions on this.

I think this is a great idea. Having a person be on point for a
particular release from inception to whenever we stop caring about it
makes a lot of sense.

I agree. Regardless of how PTL elections end up working, I think we should definitely 
move forward with this "Release Stewards" concept. It sounds like an excellent 
idea.

Also since "Release Stewards" are nominated by PTL, projects can just
start using this concept right away (as it's not an elected position).
+1 from me.


One question, should "Release Stewards" also be members of the Stable Team for 
that project or will they become members of the Stable Team? It seems like there should 
be a relationship there to me (although maybe not a strictly enforced one).


Welcomed and required are two different things. I think the stable team 
is always willing to work with new contributors. I additionally think 
that floating the expectation that someone

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

2016-09-07 Thread Anita Kuno

On 16-09-07 12:20 PM, Barrett, Carol L wrote:

-Original Message-
From: Sean Dague [mailto:s...@dague.net]
Sent: Wednesday, September 07, 2016 9:05 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] Timeframe for future elections & "Release 
stewards"

On 09/07/2016 11:43 AM, Thierry Carrez wrote:

Hi everyone,

As you probably know by now, starting with the Boston event in 2017,
the Summit will happen further away from the release day and more
around the middle of the next development cycle. You can find more
info on the rationale for that at [1] and [2] if interested, this is
not the topic of this email.

One interesting side-effect is that since the timing of the election
period (for PTL and TC positions) is defined in the TC charter[3]
relative to the *Summit*, it means that (unless we change this) we'll
now run elections to renew PTL and TC positions in the middle of the
cycle. Crazy, right ? That's what I first thought. But after
discussing it with various people, this is not as crazy as it sounds.

First, the current election timing is not perfect -- we change PTLs in
the middle of the design summit prep, with old PTLs making Design
Summit space requests that will affect their successor. It's not as if
there was a perfect timing for doing elections.

Second, release cycles are longer than 6 months. They actually start a
few months before actual development starts, with discussions on next
cycle priorities and Design Summit prep. They continue a few months
after release, with critical stable branch backports and communication
about landed features. So they are one year-long, overlapping cycles
(like explained on the diagram at [4]). With that in mind, the PTL/TC
election actually would happen just before the start of the start of
the requirements-gathering pre-development phase of the next
development cycle, which makes a lot of sense.

Now, the main drawback of holding elections in the middle of a
development cycle is that you don't want to introduce a discontinuity
in leadership in that development cycle. To mitigate that, we propose
the introduction of a new role, the "release steward", which would be
attached to the release cycle. That person (who may or may not double
as
PTL) would be responsible for a complete release cycle on a given
project team, from requirements gathering phase to post-release
bugfix-backport phase. A sort of per-cycle release liaison on steroids.

Since development cycles overlap, there would be two active release
stewards at all times. This would help with the awkward situation
where the PTL ends up having to think about the next cycle and prepare
the Design Summit (or PTG) while still being knee-deep juggling with
feature freeze exceptions, getting the current release out of the
door, and coordinating early critical fixes stable backports. Those
two jobs could be held by two different people.

Now, some teams (especially those doing intermediary releases) may
want to use the same super-human to handle everything (PTL, release
steward,
release+1 steward), and some others might use two or three humans to
spread the load. That's up to them. But once designated by the
newly-elected PTL, the release steward would be responsible for the
full release cycle and would not be displaced by the next PTL 6 months later.
One year being a long time, if a steward needs to step down, the
currently-active PTL would appoint someone else to finish the job.

With this new concept I think we can get the best of both worlds, and
keep the election period as currently defined in the charter (rather
than having to change it). The PTLs we will elect in the coming weeks
won't be renewed before April, 2017 -- while Pike development will
start in February.

I know this can all be a bit confusing, so feel free to reach out to
me with questions on this.

[1] http://www.openstack.org/ptg
[2] http://www.openstack.org/ptg/ptgfaq/
[3]
http://governance.openstack.org/reference/charter.html#election-for-pt
l-seats
[4]
http://www.openstack.org/themes/openstack/images/summit-ptg-timeline-r
evised.png

I think another option would be to run the PTL election early, but just don't have the 
turn over happen until the master release opens up. The current transition period is 
> > >
actually quite short as noted by the comments around how design summit planning 
happens. Having the PTL-next elected half way through the cycle, but having PTL 
current >
still > own landing the current release actually provides a lot more transition 
time.

-Sean

I had a similar thought to Sean's, with a few changes. Why not have a PTL own 
the release from start to finish, with the PTL for the next release getting 
elected as above. In this model, it would probably be advisable (or a 
guideline) that a PTL not run for 2 cycles in a row, because the work load 
would be unmanageable. This approach could help to grow a stronger leadership 
pipeline for each project and provide more

Re: [openstack-dev] P and Q naming: all hail Pike and Queens

2016-08-18 Thread Anita Kuno


On 16-08-18 10:59 AM, Monty Taylor wrote:

Hey everybody,

As you all know, voting is only one step in the selection process. We
also have to have vetting done on the choices to identify risk
associated with the selected names.

This time around, the top choice by vote for both P and Q was too
problematic, so we moved down to the next most popular choice on the
list. Luckily, the second choice in each case was not problematic.

So with that, I'd like to officially introduce your release names for
the P and Q releases: Pike and Queens.

Enjoy.

Monty

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


A fish and a university, could be worse.

Thanks Monty,
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-Infra] MeetBot taking unauthorised vacation

2016-08-17 Thread Anita Kuno


On 16-08-17 10:45 AM, Stig Telfer wrote:

I think our meeting ran over time and the openstack bot exited at 1 minute past 
the end of the meeting.  So it’s quite likely there were supposed to be no 
meetings happening at that time, although in reality we were still at it.

Best wishes,
Stig



On 17 Aug 2016, at 15:09, David Moreau Simard  wrote:

I love this.

But on a serious note, the bot has to be restarted when commits are
done to it and usually cores are quite dilligent about not merging
reviews while there are meetings in progress.
Maybe something slipped this time ?

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]


On Wed, Aug 17, 2016 at 6:14 AM, Stig Telfer  wrote:

Hi All -

We just had a Scientific WG meeting in #openstack-meeting but the MeetBot left 
half way through.  Now the meeting cannot end (I’m sure it often feels that 
way).

Best wishes,
Stig


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


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


The last change to the file that contains the list of channels for 
meetbot merged yesterday at 15:23 GMT: 
http://git.openstack.org/cgit/openstack-infra/system-config/commit/hiera/common.yaml?id=6d3fc364f1f0d012672209b844a76b9554e916ea


So I don't think this theory has legs.

Bots disappear for all sorts of reasons, including code changes, I'm 
glad this one came back so you could end the meeting.


Thank you,
Anita.

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

[openstack-dev] PyCon Canada Call for Proposals

2016-08-17 Thread Anita Kuno

I spoke at this conference last year and it is a nice small friendly 
little conf. It was in Toronto last year and will be again this year. It 
is being held in November, most of the audience is university students.


CFP is open for two more weeks: 
https://cfp.pycon.ca/?mc_cid=c7c6b43fde_eid=3eccad7039


Would be great to see you there.

I'm not involved with the organization, just receiving their emails and 
thought I would share.


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] [infra] Jenkinsfile support (or repo/s for them?)

2016-08-15 Thread Anita Kuno


On 16-08-15 01:19 PM, Joshua Harlow wrote:

Hi folks,

I've been experimenting/investigating/playing around with the 'new' 
jenkins pipeline support (see https://jenkins.io/doc/pipeline/ for 
those who don't know what this is) and it got me thinking that there 
are probably X other people/groups/companies that are doing the same 
thing and that to me raises the question of 'why don't we work together'.


Example of a ci-cd workflow for this (in visual form, for those who 
are visually tuned):


https://jenkins.io/images/pipeline/realworld-pipeline-flow.png

Is anyone else looking into how to build jenkinsfiles (or there 
equivalents) for the openstack project repos? Perhaps we can work on 
them together or perhaps even we can include those same jenkinsfiles 
in the project repos themselves (thus making it that much easier to 
point jenkins at the external repos and run them through tests, 
functional tests, integration tests and so-on).


This kind of pipeline *slightly* competes with the zuul and job 
templates and such in the infra repos (but maybe compete is not the 
best wording, and perhaps complement is a better wording); but seeing 
how certain companies (at least mine) use jenkins it would be very 
nice to be able to collaborate on these (for the greater good).


Thoughts?

-Josh

__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


I suggest using the [infra] tag in the subject line if you are looking 
for input from the infra team. I have changed it for my reply.


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] [tc][cinder] tag:follows-standard-deprecation should be removed

2016-08-12 Thread Anita Kuno


On 16-08-12 09:21 AM, Thierry Carrez wrote:

Sean Dague wrote:

I 100% understand the cinder policy of kicking drivers out without CI.
And I think there is a lot of value in ensuring what's in tree is tested.

However, from a user perspective basically it means that if you deploy
Newton cinder and build a storage infrastructure around anything other
than ceph, lvm, or NFS, you have a very real chance of never being able
to upgrade to Ocata, because your driver was fully deleted, unless you
are willing to completely change up your storage architecture during the
upgrade.

That is the kind of reality that should be front and center to the
users. Because it's not just a drop of standard deprecation, it's also a
removal of 'supports upgrade', as Netwon cinder config won't work with
Ocata.

Could there be more of an off ramp / on ramp here to the drivers? If a
driver CI fails to meet the reporting window mark it deprecated for the
next delete window. If a driver is in a deprecated state they need some
long window of continuous reporting to get out of that state (like 120
days or something). Bring in all new drivers in a
deprecated/experimental/untested state, which they only get to shrug off
after the onramp window?

It's definitely important that the project has the ability to clean out
the cruft, but it would be nice to not be overly brutal to our operators
at the same time.

And if not, I think that tags (or lack there of) aren't fully
communicating the situation here. Cinder docs should basically say "only
use ceph / lvm / nfs, as those are the only drivers that we can
guarantee will be in the next release".

+1

Both of the options (keeping cruft in tree vs. having no assurance at
all that your choice of driver will be around in 6 months) are horrible
from an operators standpoint. But I think that's a false dichotomy and
we need a more subtle solution: communicate about sane drivers where we
trust the ability of core team or the vendor to still provide a workable
solution in the next release (following standard deprecation policy)
while still being able to remove cruft if a driver goes stale /
untested. That means defining multiple tiers of trust, and having each
driver build that trust over time.


I think building trust over time is the crucial point here. I think we 
as a community have learned that in certain areas, there is a vast 
amount of clean up to be done by allotting trust prior to it being earned.


Giving folks an opportunity to earn trust, actual trust, not just gaming 
a process, enables everyone to be able to work together optimally. We 
have learned some folks are unwilling to do the work to earn it.


But some folks are worthy of trust and have demonstrated it. Thanks to 
those who have wanted that for themselves.


Thank you,
Anita.



In that other thread I proposed two tiers (in openstack/cinder following
deprecation and stable policies and in a separate Cinder repository if
you don't trust it to follow the policies) since the Cinder team sees
value in keeping them cinder-core-reviewed and in a limited number of
repositories.




__
OpenStack Development Mailing 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][cinder][stable] tag:follows-standard-deprecation should be removed

2016-08-11 Thread Anita Kuno


On 16-08-11 09:36 AM, Doug Hellmann wrote:

Excerpts from Erno Kuvaja's message of 2016-08-11 13:59:54 +0100:

On Thu, Aug 11, 2016 at 1:32 PM, Doug Hellmann  wrote:

Excerpts from Erno Kuvaja's message of 2016-08-11 12:26:59 +0100:

Hi all,

As follow up on the mailing list discussion [0], gerrit activity
[1][2] and cinder 3rd party CI policy [3] I'd like to initiate
discussion how Cinder follows, or rather does not follow, the standard
deprecation policy [4] as the project has been tagged on the assert
page [5].

I'm not here to argue about the justification or rightfulness of the
Cinder policy regarding the drivers with 3rd party CI. (quite frankly
I think the Cinder policy makes lots of sense and thus propose the
removal of the tag rather than change of that policy) Just stating the
obvious that the Cinder policy does not comply with the
follows-standard-deprecation and thus the tag should be removed from
Cinder.

Best,
Erno (jokke) Kuvaja

[0] http://lists.openstack.org/pipermail/openstack-dev/2016-August/100717.html
[1] https://review.openstack.org/#/c/348032/
[2] https://review.openstack.org/#/c/348042/
[3] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
[4] 
https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#requirements
[5] 
https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#application-to-current-projects


Can you be more specific about what you mean? Are you saying that
the policy isn't being followed because the drivers were removed
without a deprecation period, or is there something else to it?

Doug


Yes, that's how I see it. Cinder's own policy is that the drivers can
be removed without any warning to the consumers while the standard
deprecation policy defines quite strict lines about informing the
consumer of the functionality deprecation before it gets removed.

- Erno


Those policies do seem to be in conflict. We should consider whether
it makes sense to adjust Cinder's policy on drivers or remove the
stable tag.

I've added "[stable]" to the subject to get the stable team's input.
I think Tony's TZ means he's likely at the end of his day already,
by maybe some other members of the team will have something to add.

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


I think Cinder's approach to removing third party drivers is to be 
commended. I consider Cinder to be the example to follow in how to 
interact with and address third party drivers and third party driver 
maintainers (or not maintainers).


I would hope other projects follow Cinder's example here, rather than 
perceive themselves as being deterred.


Thank you,
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

[openstack-dev] [requirements][elections] Requirements PTL Results

2016-08-11 Thread Anita Kuno

We'd like to thank all those folks who came out to participate in this 
election on very brief notice. Thank you. The participation rate is 
impressive.


Thank you to all candidates who put themselves forward, showing their 
enthusiasm for the role. It is plain to see this new team has a lot of 
leadership available to it as it moves forward. Congratulations 
Requirements team.


Please join me in welcoming your new Requirements PTL, Tony Breeds (tonyb).

Full election results can be found here: 
http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_02dbd8750c568757


Thank you for a great election,
Anita and 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] Why do we need a Requirements Team and PTL

2016-08-06 Thread Anita Kuno


On 16-08-06 10:34 AM, Davanum Srinivas wrote:

Folks,

Question asked by Julien here:
https://twitter.com/juldanjou/status/761897228596350976

Answer:
There's a boat load of work that goes on in global requirements
process. Here's the list of things that we dropped on the new team
being formed:
https://etherpad.openstack.org/p/requirements-tasks

Please feel free to look at the requirements repo, weekly chats etc to
get an idea.

Also if if you disagree, please bring it up in a community forum so
you get better answers for your concerns.

Thanks,
Dims

I have to say that I am disappointed that if a community member felt 
like questioning a community action, that question did not occur in a 
community channel of communication prior to action being taken.


The election workflow was posted to the mailing list a week prior to the 
election commencing. Questioning the purpose of an election while an 
election is taking place fosters distrust in the election process, which 
is feel is unfair to all those participating in the process with good 
intent.


If you have questions about the purpose of an election please voice them 
at the appropriate time and venue so your concerns can be addressed.


Thank you,
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

[openstack-dev] [requirements][elections] requirements PTL election now open

2016-08-05 Thread Anita Kuno

The OpenStack Requirements PTL election is now open. The poll will close 
after 13:00 utc  August 11, 2016.


The electorate has been sent ballots to the gerrit Preferred Email.

If you have patches returned when you issue this gerrit query, you are 
part of the Requirements electorate: 
https://review.openstack.org/#/q/project:openstack/requirements+is:owner+is:merged+after:2015-07-31+before:2016-08-01
Look in your gerrit preferred email inbox for your ballot. What to do if 
you don't see the email and have a commit returned when running the 
above query:
* check the trash or spam folder of your gerrit Preferred Email address, 
in case it went into trash or spam

* wait a bit and check again, in case your email server is a bit slow
* find the sha of at least one commit from the openstack/requirements 
repositoryand email me and Doug[1]. If we can confirm that you are 
entitled to vote, we will add you to the voters list and you will be 
emailed a ballot.


Candidate statements/platforms can be found in the mailing list thread 
kicking off the election[0].


Thank youfor participating the in the election,

Anita and Doug

[0]http://lists.openstack.org/pipermail/openstack-dev/2016-July/thread.html#100173
[1] d...@doughellmann.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] [ptl][requirements] nomination period started

2016-08-05 Thread Anita Kuno


On 16-07-27 09:41 AM, Matthew Thode wrote:

We've started a period of self nomination in preparation for the
requirements project fully moving into project (as it's still under Doug
Hellmann).

We are gathering the self nominations here before we vote next week.
https://etherpad.openstack.org/p/requirements-ptl-newton

Nominees should also send an email to the openstack-dev list.



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


The candidates for the OpenStack Requirements PTL election are as follows:

* Matthew Thode - prometheanfire

* Tony Breeds - tonyb

* Swapnil Kulkarni - coolsvap

Ballots are forthcoming.


Thank you,

Anita and 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] [ptl][requirements] nomination period started

2016-07-28 Thread Anita Kuno

On 07/27/2016 06:06 PM, Jeremy Stanley wrote:
> On 2016-07-27 17:56:39 -0400 (-0400), Doug Hellmann wrote:
> [...]
>> However, we may have some folks on the core team who have not
>> contributed a patch, since it is far more common to do reviews than
>> to submit changes there (more and more of the changes are being
>> automated). So, we probably need to expand the traditional definition
>> to also include the existing core review team (members of
>> requirements-core [1]), just to be safe.
> [...]
> 
> Easy enough to do for a one-off, but might want to consider
> officially adding them as extra-ATCs in governance down the road to
> make that more explicit. Our existing tooling is already adapted to
> that solution as well (for example, the current i18n voters are
> _all_ recorded as extra-ATCs because we haven't implemented API
> calls to Zanata for integrating it into the normal roll generation
> process yet).
> 
> However, implicitly adding core reviewers seems a little weird as
> they're officially appointed by the PTL and so allowing the
> incumbent PTL to appoint (or remove) specific voters before their
> pending reelection... well anyway, I guess it's balanced out by
> there being a lot more committers to that repo than core reviewers
> on it.
> 

So Doug and I had a chat and we propose the following workflow for
deciding the requirements ptl:
1) Nominations open, done:
http://lists.openstack.org/pipermail/openstack-dev/2016-July/100173.html
2) Nominations close: August 5th, 11:59 utc
3) List of Nominees posted to mailing list, a post appened to the
parent:
http://lists.openstack.org/pipermail/openstack-dev/2016-July/100173.html
4) Election officials start civs poll after 13:00 utc August 5, 2016
5) Election poll closes after 13:00 utc  August 11, 2016
6) Winning candidate will be announced to the mailing list
(openstack-dev@lists.openstack.org)

Electorate:
requirements core reviewers and those who have merged at least one
patch to the requirements repo between 1 Aug 2015 and July 31 2016
can I vote?


https://review.openstack.org/#/q/project:openstack/requirements+is:owner+is:merged+after:2015-07-31+before:2016-08-01

how do I vote?

eligible voters will receive a ballot sent to their gerrit preferred
email, if you are an eligible voter and don't receive an email providing
you a link to the poll by August 6, 2016 please email the election
officials with a gerrit url for your patch confirming your eligibility


Please ask any questions you need to ask to clarify this process so you
understand it.

If you have a question of a personal nature, please don't hesitate to
email both election officials: Doug Hellmann <d...@doughellmann.com> and
Anita Kuno  as soon as you can so we can
ensure you have the answers you need.

Thank you to Jeremy Stanley for his assistance and support as well as
his offer to help us generate the electoral rolls, which include a wip
patch to governance to generate an electoral roll separate from the
Release Management team electorate. After the election, we will abandon
that patch and let the new team propose its own change, including a
mission statement and other metadata, when they seek to become a big
tent project. Gerrit patch: https://review.openstack.org/#/c/348462

Thanks for your participation in the electoral process,

Anita and 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] [ptl][requirements] nomination period started

2016-07-27 Thread Anita Kuno

On 07/27/2016 05:44 PM, Jeremy Stanley wrote:
> On 2016-07-27 17:38:49 -0400 (-0400), Anita Kuno wrote:
> [...]
>> /me assumes Jeremy's follow up suggestion/offer is to help compose the
>> rolls, for which Anita is grateful
> 
> Good guess, and yes I'm happy to if desired but if the means of
> identifying Requirements team voters differs from the norm then that
> may take some additional coding to automate.
> 
Wonderful, as usual, thanks for the constant support. Once the direction
the group wants to take in regards to computing the electorate becomes
clear we can move forward hopefully with details in hand.

Thanks Jeremy,
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] [ptl][requirements] nomination period started

2016-07-27 Thread Anita Kuno

On 07/27/2016 05:08 PM, Jeremy Stanley wrote:
> On 2016-07-27 08:41:17 -0500 (-0500), Matthew Thode wrote:
>> We've started a period of self nomination in preparation for the
>> requirements project fully moving into project (as it's still under Doug
>> Hellmann).
>>
>> We are gathering the self nominations here before we vote next week.
>> https://etherpad.openstack.org/p/requirements-ptl-newton
>>
>> Nominees should also send an email to the openstack-dev list.
> 
> Have you determined whether your electorate are traditional project
> technical contributors (Gerrit owners of changes merged to the
> openstack/requirements repo over the past year) like most teams use,
> or is there a different focus and constituency for this team?
> 

It is a good question. Since they haven't yet determined if they will do
a civs poll or just do a show of hands at a meeting, I was going to give
them a bit and see which direction they wanted to go.

I have an outstanding question to Doug actually on the nature of the
word 'interm' in play currently, because they way I see it a ptl is a
plt and has the same responsibilities as every other ptl adjectives
notwithstanding.

/me assumes Jeremy's follow up suggestion/offer is to help compose the
rolls, for which Anita is grateful

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-operators] Next Ops Midcycle NYC August 25-26

2016-07-14 Thread Anita Kuno

On 07/14/2016 05:59 PM, Chris Morgan wrote:
> car got totaled

I hope everyone involved is safe and in good health. Sorry to hear of
the loss of your car.

Anita.

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

Re: [openstack-dev] [kolla][nova][infra] Voting gates

2016-07-14 Thread Anita Kuno

On 07/14/2016 11:55 AM, Steven Dake (stdake) wrote:
> Antia,
> 
> Thanks for the correction.  I've been at this about 5 years, and agree -
> things are muddy :)
> 
> Kolla cores - when reading this email, please keep Anita's comments in
> mind.
> 
> Regards
> -steve

Thank you Steve,
Anita.

> 
> On 7/14/16, 7:37 AM, "Anita Kuno" <ante...@anteaya.info> wrote:
> 
>> On 07/14/2016 10:21 AM, Steven Dake (stdake) wrote:
>>> Hey folks,
>>>
>>> At the midcycle, we had a session on gating.
>>>
>>> Out of that session came the decision to make the build gates voting
>>
>> Jobs, you have voting jobs, gates do not vote.
>>
>> We have an overload of technical terms as it is. Newcomers look to
>> existing members to understand terminology and culture. Someone
>> continuing to call a term a slang version perpetuates and creates
>> confusion and frustration for people who believed they were using the
>> correct term.
>>
>> http://docs.openstack.org/project-team-guide/testing.html#project-gating
>>
>> Thank you,
>> Anita.
>>
>>
>>> as soon as the mirroring is finished for ubuntu first (because that is
>>> closer for us to get mirroring sorted out) followed by CentOS/Oracle
>>> Linux.  I am taking this work on (mirroring specifically) and expect it
>>> to finish in the next 1-2 weeks (ubuntu only).  After that I will sort
>>> out the centos mirroring.  I'm not sure who got the mirroring work
>>> kicked off in infrastructure - I think it was Jessie Pretorious - if the
>>> credit is wrong apologies, but whoever it was, - huge thanks from me
>>> personally :)
>>>
>>> We are not making the deploy gates voting at this time, although the
>>> plan is to do so once we stablize the last of the gate issues.  I think
>>> we are just down to one issue now, and that is that ubuntu source fails
>>> with an error about VIR MIGRATE AUTO CONVERGE.  This looks to be a nova
>>> bug.  If the nova community has any bones to throw us on how to fix
>>> this, it would be appreciated.  I'd cut and paste the log, but for some
>>> reason C isn't working in my email client at present.
>>>
>>> If folks know of other consistent deploy gate failures, can you please
>>> respond on this thread with either a bug link or a link to a log of the
>>> failure in question.
>>>
>>> The review where it fails is 339776.
>>>
>>> Regards
>>> -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
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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

Re: [openstack-dev] [kolla][nova][infra] Voting gates

2016-07-14 Thread Anita Kuno

On 07/14/2016 10:21 AM, Steven Dake (stdake) wrote:
> Hey folks,
> 
> At the midcycle, we had a session on gating.
> 
> Out of that session came the decision to make the build gates voting

Jobs, you have voting jobs, gates do not vote.

We have an overload of technical terms as it is. Newcomers look to
existing members to understand terminology and culture. Someone
continuing to call a term a slang version perpetuates and creates
confusion and frustration for people who believed they were using the
correct term.

http://docs.openstack.org/project-team-guide/testing.html#project-gating

Thank you,
Anita.


> as soon as the mirroring is finished for ubuntu first (because that is closer 
> for us to get mirroring sorted out) followed by CentOS/Oracle Linux.  I am 
> taking this work on (mirroring specifically) and expect it to finish in the 
> next 1-2 weeks (ubuntu only).  After that I will sort out the centos 
> mirroring.  I'm not sure who got the mirroring work kicked off in 
> infrastructure - I think it was Jessie Pretorious - if the credit is wrong 
> apologies, but whoever it was, - huge thanks from me personally :)
> 
> We are not making the deploy gates voting at this time, although the plan is 
> to do so once we stablize the last of the gate issues.  I think we are just 
> down to one issue now, and that is that ubuntu source fails with an error 
> about VIR MIGRATE AUTO CONVERGE.  This looks to be a nova bug.  If the nova 
> community has any bones to throw us on how to fix this, it would be 
> appreciated.  I'd cut and paste the log, but for some reason C isn't 
> working in my email client at present.
> 
> If folks know of other consistent deploy gate failures, can you please 
> respond on this thread with either a bug link or a link to a log of the 
> failure in question.
> 
> The review where it fails is 339776.
> 
> Regards
> -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] [Cinder][CI] Rule of recheck keywords has been updated

2016-07-13 Thread Anita Kuno

On 07/13/2016 05:36 PM, Sean McGinnis wrote:
> Thanks for sending this out!
> 
> It would be appreciated if all CI maintainers get this updated to follow
> the recommendations soon. It would really help us have consistency
> across systems.
> 
> Sean

Clarifying this is a Cinder decision, so all Cinder Ci maintainers.

Thank you,
Anita.

> 
>> Hello Cinder Third-Party CI Maintainers,
>>
>> The rule of recheck keywords has been discussed in today's IRC meeting [1].
>> And the wiki [2] of tested-3rdParty-drivers has been updated.
>> # The diff is [3].
>>
>> Please check the update and update your CI.
>> It would be appreciated if you could also update the "Recheck trigger" 
>> information in your CI's wiki.
>> You can find your CI's wiki pages at [4].
>>
>> [1] 
>> http://eavesdrop.openstack.org/meetings/cinder/2016/cinder.2016-07-13-16.00.log.html
>> [2] 
>> https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#How_do_I_trigger_my_CI_to_rerun_on_gerrit_comments.3F
>> [3] 
>> https://wiki.openstack.org/w/index.php?title=Cinder/tested-3rdParty-drivers=3690=128050=126774
>> [4] https://wiki.openstack.org/wiki/ThirdPartySystems
>>
>> Best regards,
>> Watanabe.isao
>>
>>
>>
>> __
>> OpenStack Development Mailing 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-operators] Next Ops Midcycle NYC August 25-26

2016-07-07 Thread Anita Kuno

On 07/07/2016 12:43 PM, Shilla Saebi wrote:
> I don't think it's setup yet for the ops mid cycle.

Is there any sense of urgency on this? If not, could there be, please?

This is a significant event in terms of expense (New York accommodations
are very expensive) and logistics (New York accommodations are very hard
to get at any price).

Letting folks register will really help everyone concerned with the
travel logistics involved. Figuring out travel on limited time scales
(less that 2 months now) is challenging anywhere in the world, New York
much more so.

My thanks,
Anita.

> On Thu, Jul 7, 2016 at 12:25 PM, Edgar Magana 
> wrote:
> 
>> Folks,
>> Do we have an eventbrite already set up?
>>
>> Thanks,
>>
>> Edgar
>>
>> On 6/23/16, 1:14 PM, "Saverio Proto"  wrote:
>>
>> Hello there :)
>>
>> is anyone from the openstack foundation or from bloomberg that can
>> help out with this ?
>>
>> I share this for anyone that needs visa.
>>
>> for Austin we had something like this:
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openstack.org_summit_austin-2D2016_austin-2Dand-2Dtravel_=CwICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=Sl397xp9_uCFp4UYQdcPuwBxeFn2lhzgmuF7fVt1pXE=wf9aH1oLv0jEU-Xw0tQijtKexSOVHWxi6gfy8iZn36g=
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__openstackfoundation.formstack.com_forms_visa-5Fform-5Faustin-5Fsummit=CwICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=Sl397xp9_uCFp4UYQdcPuwBxeFn2lhzgmuF7fVt1pXE=n4Mtj1sOz0froNvkbC4f-w7qd-lF26MJ1aFZWtSi_f8=
>>
>> anyone that needs to apply for Visa will need a 'US point of contact
>> information'.
>>
>> Basically, if the organizer of the Ops Midcycle is officially the
>> openstack foundation or bloomberg, I need to enter in my visa
>> application the following info:
>>
>> Organization name
>> Address in the US
>> Phone number
>> Email
>>
>> It must be a phone number and a email where in case there is a check,
>> somebody can tell "yes of course, this guy exist and is coming to the
>> conference" :)
>>
>> How we sort this out ?
>>
>> thank you
>>
>> Saverio
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators=CwICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=Sl397xp9_uCFp4UYQdcPuwBxeFn2lhzgmuF7fVt1pXE=hJ_UMzKTYvPT5NCIcRrq6bc1D7JZx9FZl9nzLqla8SM=
>>
>>
>> ___
>> 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 mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Next Ops Midcycle NYC August 25-26

2016-06-23 Thread Anita Kuno

On 06/23/2016 04:42 PM, Mark Voelker wrote:
> Hi Folks,
> 
> A quick update on this: today’s the last day of earlybird pricing for 
> OpenStack East, so if you’d like to attend both events I’d encourage you to 
> register now (it’s only $99 for the next ~7 hours):
> 
> https://www.eventbrite.com/e/openstack-east-tickets-22413148330?ref=ebtnebregn
> 
> If you can’t register today, some good news: I spoke with the conference 
> organizers and it looks like we’ll be able to get some sort of discount code 
> for folks who are attending the Ops Midcycle and also want to attend 
> OpenStack East!  We’re still working out logistics, so bear with me—I’ll send 
> along some more info when I have it.
> 
> At Your Service,
> 
> Mark T. Voelker
> 
> 
> 
>> On Jun 22, 2016, at 2:16 PM, Mark Voelker  wrote:
>>
>> It would definitely be cool to have more ops folks attend both events.  I’d 
>> be happy to check in with the rest of the organizers and see if there’s a 
>> possibility of working something out.
>>
>> At Your Service,
>>
>> Mark T. Voelker
>>
>>
>>
>>> On Jun 22, 2016, at 12:27 PM, David Medberry  wrote:
>>>
>>> Would be sweet if that offer could be extended at least a week as we go 
>>> through the corp travel process. OTOH, $99 is almost cheap enough to buy 
>>> and not care I'll be doing that I guess.
>>>
>>> On Wed, Jun 22, 2016 at 9:44 AM, Matt Jarvis 
>>>  wrote:
>>> Hi Mark
>>>
>>> Given we've not got the Eventbrite for the Ops Meetup live yet, is there 
>>> any chance you could extend the early bird pricing or give operators who 
>>> may be travelling for the Ops Meetup a discount code ? I suspect there may 
>>> be quite a lot of interest for those travelling some distance. 
>>>
>>> Matt
>>>
>>> On 22 June 2016 at 14:58, Mark Voelker  wrote:
>>> Hi Ops,
>>>
>>> FYI for those that may not be aware, that’s also the week of OpenStack 
>>> East.  OpenStack East runs August 23-24 also in New York City (about ~15-20 
>>> minutes away from Civic Hall by MTA at the Playstation Theater).  If you’re 
>>> coming to town for the Ops Midcycle, you may want to make a week of it.  
>>> Earlybird pricing for OpenStack East is still available but prices increase 
>>> tomorrow:
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.openstackeast.com_=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc=Pouk4RdhAp3O0-4z088jjeJcdTHWxG2QEHGPaCapbAg=pst_dGQnf8jOAggeotgW1NJGzEAbCpWryQ7tNon78IM=
>>>  
>>>
>>> At Your Service,
>>>
>>> Mark T. Voelker
>>> (wearer of many hats, one of which is OpenStack East steering committee 
>>> member)
>>>
>>>
>>>
 On Jun 21, 2016, at 11:36 AM, Jonathan D. Proulx  
 wrote:

 Hi All,

 The Ops Meetups Team has selected[1] New York City as the location of the
 next mid-cycle meetup on August 25 and 26 2016 at Civic Hall[2]

 Many thanks to Bloomberg for sponsoring the location.  And thanks to
 BestBuy as well for their offer of the Seattle location.  The choice
 was very close and hopefully their offer will stand for our next North
 American meet-up.

 There's quite a bit of work to do to make this all happen in the
 next couple of months so it's still a great time to join the Ops
 Meetups Team[3] and help out.

 -Jon

 --

 [1] 
 http://eavesdrop.openstack.org/meetings/ops_meetups_team/2016/ops_meetups_team.2016-06-21-14.02.html
 [2] 
 https://urldefense.proofpoint.com/v2/url?u=http-3A__civichall.org_about-2Dcivic-2Dhall_=CwICAg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc=oAH-SSZ6EFikpmcyUpbf3984kyPBIuLJKkQadC6CKUw=36Kl-0b4WBC06xaYXo0V5AM2lHzvjhL48bBV48cz2is=
 [3] https://wiki.openstack.org/wiki/Ops_Meetups_Team


 ___
 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
>>>
>>>
>>> DataCentred Limited registered in England and Wales no. 05611763
>>> ___
>>> 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 mailing list
> OpenStack-operators@lists.openstack.org
>

Re: [openstack-dev] [all] what do you work on upstream of OpenStack?

2016-06-23 Thread Anita Kuno

On 06/23/2016 08:37 AM, Doug Hellmann wrote:
> Excerpts from Doug Hellmann's message of 2016-06-13 15:11:17 -0400:
>> I'm trying to pull together some information about contributions
>> that OpenStack community members have made *upstream* of OpenStack,
>> via code, docs, bug reports, or anything else to dependencies that
>> we have.
>>
>> If you've made a contribution of that sort, I would appreciate a
>> quick note.  Please reply off-list, there's no need to spam everyone,
>> and I'll post the summary if folks want to see it.
>>
>> Thanks,
>> Doug
>>
> 
> I've summarized the results of all of your responses (on and off
> list) on a blog post this morning [1]. I removed individual names
> because I was concentrating on the community as a whole, rather than
> individual contributions.
> 
> I'm sure there are projects not listed, either because I missed
> something in my summary or because someone didn't reply. Please feel
> free to leave a comment on the post with references to other projects.
> It's not necessary to link to specific commits or bugs or anything like
> that, unless there's something you would especially like to highlight.
> 
> Thank you for your input into the survey. I'm impressed with the
> breadth of the results. I'm very happy to know that our community,
> which so often seems to be focused on building new projects, also
> contributes to existing projects that we all rely on.
> 
> Doug
> 
> [1] 
> https://doughellmann.com/blog/2016/06/23/openstack-contributions-to-other-open-source-projects/
> 
> __
> OpenStack Development Mailing 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 for putting this together Doug that is an impressive list.

It is interesting as I had not considered Zuul and Jenkins Job Builder
to be 'other open source tools' but you are correct, it is a way to look
at them.

Thanks Doug,
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-Infra] Request help for ICLA error

2016-06-17 Thread Anita Kuno

On 06/17/2016 06:22 PM, Steven Dake (stdake) wrote:
> Soffie,
> 
> I'm happy to spend 15 minutes on a google hangout or webex where you can 
> screen share and I can walk you through getting your environment setup.  I 
> know every combination of problems related to ICLA setup helping my good 
> friends at Red Hat and Cisco get a basic setup going in their environment.
> 
> Ping me sdake on channel #openstack-kolla on freenode, and I'll provide a 
> link to webex.  You will need a mac or  windows machine to use webex.  Google 
> hangouts also has a screen sharing feature if you can set it up.  I am 
> usually around all the time. :)
> 
> Regards
> -steve

This is a generous offer, Steve.

I'd just like to make it clear to users that the infra team doesn't
support windows questions. So if this user goes to great efforts to get
access to windows to use webex, the use of that tool only goes as far as
Steve's offer, it is not indicative of what kind of support users can
expect from the infra team.

Thanks,
Anita.

> 
> 
> From: Soffie Huang 
> >
> Date: Wednesday, June 15, 2016 at 3:58 AM
> To: openstack-infra 
> >
> Subject: [OpenStack-Infra] Request help for ICLA error
> 
> 
> Hello Infra Team,
> 
> I am trying to push the code changes for sanbox. But while initiating the
> review I am getting the following Error.
> 
> ---
> fatal: ICLA contributor agreement requires current contact information.
> Please review your contact information:
>   https://review.openstack.org/#/settings/contact
> fatal: Could not read from remote repository.
> 
> Please make sure you have the correct access rights
> and the repository exists.
> -
> 
> I have signed the ICLA by providing my email address and also I tried to
> update my contact details at the link given above. While updating the
> details I am getting server error.
> 
> Could you help me with this issue?
> 
> 
> Here is my detail information:
> 
> 
> 
> 
> 
> Thanks,
> 
> Soffie
> 
> 
> 
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> 


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

Re: [openstack-dev] Invitation to join Hangzhou Bug Smash

2016-06-17 Thread Anita Kuno

On 06/17/2016 12:00 AM, Wang, Shane wrote:
> Anita, sorry about replying to you slowly. Because we are a committee from a 
> couple of companies, and need discussion, which causes slowness.
> I am not the only decision maker. Thanks Anita;)
> 
> Regards.
> --
> Shane

No apology necessary, thank you Shane. You are doing a wonderful job
coordinating the event and if there is fault it is mine for not
following the rules.

Take all the time you need and rest assured I am fine if the response is
no. The decision is yours and your group's.

Thanks for your consideration,
Anita.


> -Original Message-
> From: Anita Kuno [mailto:ante...@anteaya.info] 
> Sent: Friday, June 17, 2016 7:18 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] Invitation to join Hangzhou Bug Smash
> 
> On 06/16/2016 07:03 PM, Matt Riedemann wrote:
>> On 6/14/2016 9:03 PM, Anita Kuno wrote:
>>>
>>> I'll reply in private first because I am a core reviewer on the 
>>> project-config repo, which was not mentioned in your list but you 
>>> might consider useful to you at the bug smash nonetheless.
>>>
>>> Let me know if you would like me to attend and I'll reply in public, 
>>> if not no worries.
>>>
>>> Thank you,
>>> 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
>>>
>>
>> Busted!
>>
> Yeah, I know. I was tired and wasn't paying attention to the to: field.
> Good thing I pretend like everything I say in private is public anyway.
> 
> Shane and folks are still welcome to tell me no, I didn't want them to feel 
> obliged and I still don't. Even if I fail at private.
> 
> Thanks Matt :)
> 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
> 
> __
> OpenStack Development Mailing 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] Invitation to join Hangzhou Bug Smash

2016-06-16 Thread Anita Kuno

On 06/16/2016 07:03 PM, Matt Riedemann wrote:
> On 6/14/2016 9:03 PM, Anita Kuno wrote:
>>
>> I'll reply in private first because I am a core reviewer on the
>> project-config repo, which was not mentioned in your list but you might
>> consider useful to you at the bug smash nonetheless.
>>
>> Let me know if you would like me to attend and I'll reply in public, if
>> not no worries.
>>
>> Thank you,
>> 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
>>
> 
> Busted!
> 
Yeah, I know. I was tired and wasn't paying attention to the to: field.
Good thing I pretend like everything I say in private is public anyway.

Shane and folks are still welcome to tell me no, I didn't want them to
feel obliged and I still don't. Even if I fail at private.

Thanks Matt :)
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] Invitation to join Hangzhou Bug Smash

2016-06-14 Thread Anita Kuno

On 06/13/2016 04:06 AM, Wang, Shane wrote:
> Hi, OpenStackers,
> 
> As you know, Huawei, Intel and CESI are hosting the 4th China OpenStack Bug 
> Smash at Hangzhou, China.
> The 1st China Bug Smash was at Shanghai, the 2nd was at Xi'an, and the 3rd 
> was at Chengdu.
> 
> We are constructing the etherpad page for registration, and the date will be 
> around July 11 (probably July 6 - 8, but to be determined very soon).
> 
> The China teams will still focus on Neutron, Nova, Cinder, Heat, Magnum, 
> Rally, Ironic, Dragonflow and Watcher, etc. projects, so need developers to 
> join and fix bugs as many as possible, and cores to be on site to moderate 
> the code changes and merges. Welcome to the smash mash at Hangzhou - 
> http://www.chinahighlights.com/hangzhou/attraction/.
> 
> Good news is still that for the first two cores who are from those above 
> projects and respond to this invitation in my email inbox and copy the CC 
> list, the sponsors are pleased to sponsor your international travel, 
> including flight and hotel. Please simply reply to me.
> 
> Best regards,
> --
> China OpenStack Bug Smash Team
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

I'll reply in private first because I am a core reviewer on the
project-config repo, which was not mentioned in your list but you might
consider useful to you at the bug smash nonetheless.

Let me know if you would like me to attend and I'll reply in public, if
not no worries.

Thank you,
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] [Magnum] The Magnum Midcycle

2016-06-14 Thread Anita Kuno

On 06/09/2016 02:27 PM, Tim Bell wrote:
> If we can confirm the dates and location, there is a reasonable chance we 
> could also offer remote conferencing using Vidyo at CERN. While it is not the 
> same as an F2F experience, it would provide the possibility for remote 
> participation for those who could not make it to Geneva.
> 
> We may also be able to organize tours, such as to the anti-matter factory and 
> super conducting magnet test labs prior or afterwards if anyone is interested…
> 
> Tim

Shame Magnum said no, I was trying to figure out how to join the mid-cycle.

What other projects would make sense for you to host mid-cycles for
should the opportunity arise? I can keep my ears open.

Thanks Tim,
Anita.

> 
> From: Spyros Trigazis 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: Wednesday 8 June 2016 at 16:43
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Subject: Re: [openstack-dev] [Magnum] The Magnum Midcycle
> 
> Hi Hongbin.
> 
> CERN's location: https://goo.gl/maps/DWbDVjnAvJJ2
> 
> Cheers,
> Spyros
> 
> 
> On 8 June 2016 at 16:01, Hongbin Lu 
> > wrote:
> Ricardo,
> 
> Thanks for the offer. Would I know where is the exact location?
> 
> Best regards,
> Hongbin
> 
>> -Original Message-
>> From: Ricardo Rocha 
>> [mailto:rocha.po...@gmail.com]
>> Sent: June-08-16 5:43 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Magnum] The Magnum Midcycle
>>
>> Hi Hongbin.
>>
>> Not sure how this fits everyone, but we would be happy to host it at
>> CERN. How do people feel about it? We can add a nice tour of the place
>> as a bonus :)
>>
>> Let us know.
>>
>> Ricardo
>>
>>
>>
>> On Tue, Jun 7, 2016 at 10:32 PM, Hongbin Lu 
>> >
>> wrote:
>>> Hi all,
>>>
>>>
>>>
>>> Please find the Doodle pool below for selecting the Magnum midcycle
>> date.
>>> Presumably, it will be a 2 days event. The location is undecided for
>> now.
>>> The previous midcycles were hosted in bay area so I guess we will
>> stay
>>> there at this time.
>>>
>>>
>>>
>>> http://doodle.com/poll/5tbcyc37yb7ckiec
>>>
>>>
>>>
>>> In addition, the Magnum team is finding a host for the midcycle.
>>> Please let us know if you interest to host us.
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Hongbin
>>>
>>>
>>>
>> __
>>>  OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> ___
>> ___
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-
>> requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing 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] [all][tc] Require a level playing field for OpenStack projects

2016-06-14 Thread Anita Kuno

On 06/14/2016 10:44 AM, Hayes, Graham wrote:
> On 14/06/2016 15:00, Thierry Carrez wrote:
>> Hi everyone,
>>
>> I just proposed a new requirement for OpenStack "official" projects,
>> which I think is worth discussing beyond the governance review:
>>
>> https://review.openstack.org/#/c/329448/
>>
>>  From an upstream perspective, I see us as being in the business of
>> providing open collaboration playing fields in order to build projects
>> to reach the OpenStack Mission. We collectively provide resources
>> (infra, horizontal teams, events...) in order to enable that open
>> collaboration.
>>
>> An important characteristic of these open collaboration grounds is that
>> they need to be a level playing field, where no specific organization is
>> being given an unfair advantage. I expect the teams that we bless as
>> "official" project teams to operate in that fair manner. Otherwise we
>> end up blessing what is essentially a trojan horse for a given
>> organization, open-washing their project in the process. Such a project
>> can totally exist as an unofficial project (and even be developed on
>> OpenStack infrastructure) but I don't think it should be given free
>> space in our Design Summits or benefit from "OpenStack community" branding.
>>
>> So if, in a given project team, developers from one specific
>> organization benefit from access to specific knowledge or hardware
>> (think 3rd-party testing blackboxes that decide if a patch goes in, or
>> access to proprietary hardware or software that the open source code
>> primarily interfaces with), then this project team should probably be
>> rejected under the "open community" rule. Projects with a lot of drivers
>> (like Cinder) provide an interesting grey area, but as long as all
>> drivers are in and there is a fully functional (and popular) open source
>> implementation, I think no specific organization would be considered as
>> unfairly benefiting compared to others.
>>
>> A few months ago we had the discussion about what "no open core" means
>> in 2016, in the context of the Poppy team candidacy. With our reading at
>> the time we ended up rejecting Poppy partly because it was interfacing
>> with proprietary technologies. However, I think what we originally
>> wanted to ensure with this rule was that no specific organization would
>> use the OpenStack open source code as crippled bait to sell their
>> specific proprietary add-on.
>>
>> I think taking the view that OpenStack projects need to be open, level
>> collaboration playing fields encapsulates that nicely. In the Poppy
>> case, nobody in the Poppy team has an unfair advantage over others, so
>> we should not reject them purely on the grounds that this interfaces
>> with non-open-source solutions (leaving only the infrastructure/testing
>> requirement to solve). On the other hand, a Neutron plugin targeting a
>> specific piece of networking hardware would likely give an unfair
>> advantage to developers of the hardware's manufacturer (having access to
>> that gear for testing and being able to see and make changes to its
>> proprietary source code) -- that project should probably live as an
>> unofficial OpenStack project.
>>
>> Comments, thoughts ?
>>
> 
> 
>  From our perspective, we (designate) currently have a few drivers from 
> proprietary vendors, and would like to add one in the near future.
> 
> The current drivers are marked as "release compatible" - aka someone is
> nominated to test the driver throughout the release cycle, and then
> during the RC fully validate the driver.
> 
> The new driver will have 3rd party CI, to test it on every commit.
> 
> These are (very) small parts of the code base, but part of it none
> the less. If this is passes, should we push these plugins to separate
> repos, and not include them as part of the Designate project?
> 
> As another idea - if we have to move them out of tree - could we have
> another "type" of project?
> 
> A lot of projects have "drivers" for vendor hardware / software -
> could there be a way of marking projects as drivers of a deliverable -
> as most of these drivers will be very tied to specific versions of
> OpenStack projects.
> 
> I fully agree with the sentiment, and overall aim of the requirement,
> I just want to ensure we have as little negative impact on deployers
> as possible.
> 
>   -- Graham

I highly recommend you spend some time interacting with the Neutron,
Nova, Cinder and Ironic communities to learn how they approach this
issue. Each community has a slightly different approach to interacting
with vendors with different pain points in each approach. I think
learning from these projects regarding this issue would be a great way
to formulate your best plan for designate. Also time spent with Mike
Perez on this issue is an investment as far as I'm concerned.

Thank you,
Anita.

> 
> __
> OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [all] what do you work on upstream of OpenStack?

2016-06-13 Thread Anita Kuno

On 06/13/2016 03:11 PM, Doug Hellmann wrote:
> I'm trying to pull together some information about contributions
> that OpenStack community members have made *upstream* of OpenStack,
> via code, docs, bug reports, or anything else to dependencies that
> we have.
> 
> If you've made a contribution of that sort, I would appreciate a
> quick note.  Please reply off-list, there's no need to spam everyone,
> and I'll post the summary if folks want to see it.
> 
> Thanks,
> 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
> 
Upstream gerrit.

I think it was a doc whitespace patch or comment whitespace patch. It
was fairly insignificant but it exists.

Thanks for asking the question,
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

1 2 3 4 5 6 7 8 >

1 - 100 of 779 matches

Mail list logo