[openstack-dev] [all] cross-project deployment tool meeting

[Jan Klare]

Hi,

 i just wanted to follow up on this session 
(https://etherpad.openstack.org/p/newton-deployment-tools-discussion 
) were we 
talked about a cross-project meeting for deployment tools. I would love to see 
something like that happen and it would be great if we can find a specific date 
(maybe monthly) to do something like that. If you are interested in going to 
such a meeting, please reply to this mail with a suggestion when you could join 
such a meeting.

Cheers,
Jan (OpenStack Chef)__
OpenStack Development Mailing 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] A proposal to separate the design summit

[Jan Klare]

> On 25 Feb 2016, at 15:54, Doug Hellmann  wrote:
> 
> Excerpts from Jan Klare's message of 2016-02-25 15:29:08 +0100:
>> 
>>> On 25 Feb 2016, at 13:39, Daniel P. Berrange  wrote:
>>> 
>>> On Thu, Feb 25, 2016 at 12:40:27PM +0100, Thierry Carrez wrote:
 Qiming Teng wrote:
> [...]
> Week 1:
> Wednesday-Friday: 3 days Summit.
>   * Primarily an event for marketing, sales, CTOs, architects,
> operators, journalists, ...
>   * Contributors can decide whether they want to attend this.
> Saturday-Sunday:
>   * Social activities: contributors meet-up, hang outs ...
> 
> Week 2:
> Monday-Wednesday: 3 days Design Summit
>   * Primarily an event for developers.
>   * Operators can hold meetups during these days, or join project
> design summits.
> 
> If you need to attend both events, you don't need two trips. Scheduling
> both events by the end of a release cycle can help gather more
> meaningful feedbacks, experiences or lessons from previous releases and
> ensure a better plan for the coming release.
> 
> If you want to attend just the main Summit or only the Design Summit,
> you can plan your trip accordingly.
 
 This was an option we considered. The main objection was that we are pretty
 burnt out and ready to go home when comes Friday on a single-week event, so
 the prospect of doing two consecutive weeks looked a bit like madness
 (especially considering ancillary events like upstream training, the board
 meeting etc. which tend to happen on the weekend before summit already). It
 felt like a good way to reduce our productivity and not make the most of 
 the
 limited common time together. Furthermore it doesn't solve the issue of
 suboptimal timing as described in my original email.
>> 
>> I do not think that the other suggestion of two different events solves the 
>> issues, but instead moves it to another suboptimal timing issue.
>>> 
>>> I'd wager a sizeable number of contributors would outright refuse to attend
>>> an event for 2 weeks. 6-7 days away from family is already a long time. As
>>> such, I would certainly never do any event which spanned 2 weeks, even if
>>> both weeks were relevant to my work.
>> 
>> I don’t think that the suggestion here was to create an event spanning two 
>> full weeks. As far as i understand it, the OpenStack summit itself would 
>> span nearly the exact same time as before and maybe even less if you decide 
>> that you do not want to attend the main summit (or only a part of it), but 
>> just the design one (or only a part of it). In addition to that, i think the 
>> suggestion of 3 days in the first week and 3 days in the following one is 
>> just something we can start a discussion about. I think it would be enough 
>> to just have a 2 day main event (maybe Monday and Tuesday) and schedule the 
>> design summit with 2 or 3 days directly after that (Wednesday to Thursday or 
>> Friday).
> 
> For most folks the summit now is a work week + 2 days for travel
> on either side of it, or at least 7 days (some of us travel further
> than others). Spreading it across 7 full days like this would mean

I do not understand the 7 days you mention here, since i suggested an event 
starting Monday and ending Friday, which would mean a total of 5 days. Adding 
the travel time of two days, means we end up with a total of 7 days, which is 
exactly the work week you mentioned.

> at least 9 days for anyone who needs to be present for the entire
> event. Given that many technical folks do also need to be present
> for the conference portion of the event to meet with customers, I
> think there would likely be quite a few folks for whom this would
> turn into a very long, tiring, trip where productivity would drop off
> steeply near the middle.
> 
> As Thierry pointed out, it's a bit questionable whether there's
> actually much savings for participants with the extended event.
> Anyone attending only one half will still need to fly to and stay
> in the more expensive venues we're using now, so they save nothing.
> Anyone attending both halves may save the cost of one airline ticket,
> unless they're going to mid-cycles which we wouldn't be able to
> eliminate. In which case extending the event *increases* their costs
> because they end up staying in the more expensive hotel for more
> nights.

The difference in nights in comparison to the current summit of 4 days + 2 days 
travel would be just one night and i do not think than one night in a hotel is 
more expensive than the expenses for a completely separate event.

> 
> We also have to consider the extra difficulty and expense of trying
> to book a venue for such an extended time (considering set up and
> tear down time we need it for longer than we'll be actively using
> it, even if not by a lot).
> 
> Doug
> 
>> 
>> Cheers,
>> Jan
>> 
>>> 
>>> 
>>> 

Re: [openstack-dev] [all] A proposal to separate the design summit

[Jan Klare]

> On 25 Feb 2016, at 13:39, Daniel P. Berrange  wrote:
> 
> On Thu, Feb 25, 2016 at 12:40:27PM +0100, Thierry Carrez wrote:
>> Qiming Teng wrote:
>>> [...]
>>> Week 1:
>>>  Wednesday-Friday: 3 days Summit.
>>>* Primarily an event for marketing, sales, CTOs, architects,
>>>  operators, journalists, ...
>>>* Contributors can decide whether they want to attend this.
>>>  Saturday-Sunday:
>>>* Social activities: contributors meet-up, hang outs ...
>>> 
>>> Week 2:
>>>  Monday-Wednesday: 3 days Design Summit
>>>* Primarily an event for developers.
>>>* Operators can hold meetups during these days, or join project
>>>  design summits.
>>> 
>>> If you need to attend both events, you don't need two trips. Scheduling
>>> both events by the end of a release cycle can help gather more
>>> meaningful feedbacks, experiences or lessons from previous releases and
>>> ensure a better plan for the coming release.
>>> 
>>> If you want to attend just the main Summit or only the Design Summit,
>>> you can plan your trip accordingly.
>> 
>> This was an option we considered. The main objection was that we are pretty
>> burnt out and ready to go home when comes Friday on a single-week event, so
>> the prospect of doing two consecutive weeks looked a bit like madness
>> (especially considering ancillary events like upstream training, the board
>> meeting etc. which tend to happen on the weekend before summit already). It
>> felt like a good way to reduce our productivity and not make the most of the
>> limited common time together. Furthermore it doesn't solve the issue of
>> suboptimal timing as described in my original email.

I do not think that the other suggestion of two different events solves the 
issues, but instead moves it to another suboptimal timing issue.
> 
> I'd wager a sizeable number of contributors would outright refuse to attend
> an event for 2 weeks. 6-7 days away from family is already a long time. As
> such, I would certainly never do any event which spanned 2 weeks, even if
> both weeks were relevant to my work.

I don’t think that the suggestion here was to create an event spanning two full 
weeks. As far as i understand it, the OpenStack summit itself would span nearly 
the exact same time as before and maybe even less if you decide that you do not 
want to attend the main summit (or only a part of it), but just the design one 
(or only a part of it). In addition to that, i think the suggestion of 3 days 
in the first week and 3 days in the following one is just something we can 
start a discussion about. I think it would be enough to just have a 2 day main 
event (maybe Monday and Tuesday) and schedule the design summit with 2 or 3 
days directly after that (Wednesday to Thursday or Friday).

Cheers,
Jan

> 
> 
> Regards,
> Daniel
> -- 
> |: http://berrange.com   -o-
> http://www.flickr.com/photos/dberrange/ 
> :|
> |: http://libvirt.org   -o- 
> http://virt-manager.org  :|
> |: http://autobuild.org    -o- 
> http://search.cpan.org/~danberr/  :|
> |: http://entangle-photo.org    -o-   
> http://live.gnome.org/gtk-vnc  :|
> 
> __
> OpenStack Development Mailing 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] A proposal to separate the design summit

[Jan Klare]

Hi Qiming,

this sounds like a much more pragmatic and practical idea to me and it think 
just splitting the events into two not parallel parts, but keeping them in the 
same “week” would also solve most of the problems mentioned in this thread, but 
allow people to attend both summits without travelling twice as you mentioned. 
The main issue with this idea might be, that this will not reduce the costs of 
the Desing summit, but in my opinion neither will the completely splittet 
solution. Thanks for this suggestion.

Cheers,
Jan

> On 25 Feb 2016, at 09:13, Qiming Teng  wrote:
> 
> Hi, All,
> 
> After reading through all the +1's and -1's, we realized how difficult
> it is to come up with a proposal that makes everyone happy. When we are
> discussing this proposal with some other contributors, we came up with a
> proposal which is a little bit different. This idea could be very
> impractical, very naive, given that we don't know much about the huge
> efforts behind the scheduling, planning, coordination ... etc etc. So,
> please treat this as a random thought.
> 
> Maybe we can still have the Summit and the Design Summit colocated, but
> we can avoid the overlap that has been the source of many troubles. The
> idea is to have both events scheduled by the end of a release cycle. For
> example:
> 
> Week 1:
>  Wednesday-Friday: 3 days Summit.
>* Primarily an event for marketing, sales, CTOs, architects,
>  operators, journalists, ...
>* Contributors can decide whether they want to attend this.
>  Saturday-Sunday:
>* Social activities: contributors meet-up, hang outs ...
> 
> Week 2:
>  Monday-Wednesday: 3 days Design Summit
>* Primarily an event for developers.
>* Operators can hold meetups during these days, or join project
>  design summits.
> 
> If you need to attend both events, you don't need two trips. Scheduling
> both events by the end of a release cycle can help gather more
> meaningful feedbacks, experiences or lessons from previous releases and
> ensure a better plan for the coming release.
> 
> If you want to attend just the main Summit or only the Design Summit,
> you can plan your trip accordingly.
> 
> Thoughts?
> 
> - Qiming
> 
> 
> __
> OpenStack Development Mailing 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] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

[Jan Klare]

Hi Thomas,

good thoughts for a very important topic. I am currently refactoring a lot of 
code inside of the openstack-chef cookbooks and constantly have to ask myself, 
if i now have to add any copyright thingy to any file or am even allowed to 
delete the original copyright in a file after changing 100% of the code in it. 
I do not want to remove any copyright here, but i think this distribution of 
copyrights is very annoying and leads to the issues you mentioned below. In my 
opinion (although i agree, that 1) would be the best option but might be 
impossible since you would have to ask all companies, or find the persons 
responsible or allowed to remove these copyrights), we should move all the 
copyrights from all files to one central file per repo. The big question for me 
is, if we are allowed to do so and finally remove the copyrights from the files 
they are currently in.

Cheers,
Jan

> On 15 Jan 2016, at 13:48, Thomas Goirand  wrote:
> 
> This isn't the first time I'm calling for it. Let's hope this time, I'll
> be heard.
> 
> Randomly, contributors put their company names into source code. When
> they do, then effectively, this tells that a given source file copyright
> holder is whatever is claimed, even though someone from another company
> may have patched it.
> 
> As a result, we have a huge mess. It's impossible for me, as a package
> maintainer, to accurately set the copyright holder names in the
> debian/copyright file, which is a required by the Debian FTP masters.
> 
> I see 2 ways forward:
> 1/ Require everyone to give-up copyright holding, and give it to the
> OpenStack Foundation.
> 2/ Maintain a copyright-holder file in each project.
> 
> The later is needed if we want to do things correctly. Leaving the
> possibility for everyone to just write (c) MyCompany LLC randomly in the
> source code doesn't cut it. Expecting that a package maintainer should
> double-guess copyright holding just by reading the email addresses of
> "git log" output doesn't work either.
> 
> Please remember that a copyright holder has nothing to do with the
> license, neither with the author of some code. So please do *not* take
> over this thread, and discuss authorship or licensing.
> 
> Whatever we choose, I think we should ban having copyright holding text
> within our source code. While licensing is a good idea, as it is
> accurate, the copyright holding information isn't and it's just missleading.
> 
> If I was the only person to choose, I'd say let's go for 1/, but
> probably managers of every company wont agree.
> 
> Some thoughts anyone?
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing 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] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

[Jan Klare]

> On 15 Jan 2016, at 14:57, Jeremy Stanley  wrote:
> 
> On 2016-01-15 07:31:09 -0600 (-0600), Dolph Mathews wrote:
>> This is a topic for legal-discuss, not -dev.
>> 
>>  http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
> 
> And not only that, but we've discussed it to death in years gone by
> (my how short some memories are), resulting in the summary at
> https://wiki.openstack.org/wiki/LegalIssuesFAQ#Copyright_Headers for
> those who choose to learn from history rather than repeating it.
> -- 
> Jeremy Stanley

You are completely right, but maybe this mail was also pointing to the current 
situation we are in (which is ugly) and the sentence:

"
We do not yet have guidance for when to add or remove a copyright header in 
source files.
“

from the wiki you mentioned above. Nevertheless, we should move this discussion 
the another mailing list like stated before and try to fix the “not yet” or at 
least move a bit forward.

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

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

Re: [openstack-dev] [chef] deprecation and removal of old branches

[Jan Klare]

Hi,

i talked to infra and they can remove all of our old branches, but would also 
like us to tag them first. To do this, i (as the PTL) need to push these signed 
tags directly to gerrit. To be able to do this i need to adapt our gerrit acls 
and allow this. While i walked through the whole process, i figured we could 
just clean up a lot more stuff in one step, to adapt to the guidelines in the 
big tent. I pushed up this patch for review 
https://review.openstack.org/#/c/266843 
<https://review.openstack.org/#/c/266843> . While moving people around between 
groups, i would also like to remove the inactive core reviewers from the new 
openstack-chef-core group (mentioned in the commit). To figure out who is still 
active, i would like every core to respond to this email and tell me if he 
still wants to be active or not (no response during this week will be counted 
as a not-active :) ). I will present the final list of 
still-active-core-reviewers in our next weekly meeting on Monday and we can 
decide how to proceed.

Cheers,
Jan

> On 08 Jan 2016, at 11:10, Jan Klare <j.kl...@cloudbau.de> wrote:
> 
> Hi,
> 
> Good point, i will talk to infra and figure out how to properly push these 
> eol tags to the last commits of the branches before we remove them. Since i 
> only got positive feedback on this, i will also go ahead and ask them to help 
> me with the cleanup.
> 
> 
> Cheers,
> Jan
> 
>> On 07 Jan 2016, at 07:42, zhiwei <zhiw...@gmail.com 
>> <mailto:zhiw...@gmail.com>> wrote:
>> 
>> Sounds good, but I think it's better to create some tags just like other 
>> OpenStack projects.
>> 
>> On Thu, Jan 7, 2016 at 9:05 AM, JJ Asghar <j...@chef.io 
>> <mailto:j...@chef.io>> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>> 
>> On 1/6/16 10:22 AM, Samuel Cassiba wrote:
>> > I'm +1 on this idea. Looking at other OpenStack projects (Nova, Neutron,
>> > etc.) on GitHub, they only have stable/liberty and stable/kilo
>> 
>> Sounds good to me too.
>> 
>> 
>> - --
>> Best Regards,
>> JJ Asghar
>> c: 512.619.0722  t: @jjasghar irc: j^2
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG/MacGPG2 v2
>> Comment: GPGTools - https://gpgtools.org <https://gpgtools.org/>
>> 
>> iQIcBAEBCgAGBQJWjbnBAAoJEDZbxzMH0+jTbTcP/i/RbxfmQ2T3wasWUKLup9Y3
>> bbsiUcfocw40ZT2Y/i/fLiH+mGfIRcvXTLMkYdwji7jhoes2Vt3l+S/CmDR9kb59
>> hqxiIft/6kfW3JLjtjkAZtZ5xwa+QSN8DY4aZnnVU9mjdCgDH0DZRuwOZcERZH0Q
>> 6gQeIFp0udGVLfDaF32mEdKRRbSlRil6reciDg6W7g+/1lCys8H7ig0/5rqQxE0o
>> GmKxyGOlEnpPjpVQz1JeBadktHNjRPOJ1ihiHmC8XusMdg0FDppiJUmLd8gmLFNY
>> hRpD2QFHjzlsy+7u5chsiN+ctjawuEZsHCeDD3UDAiSQjptHQy8jw7gl+V4nQry6
>> SSpRYkdfV8k5Pf3nsJ8Yyt0SqYggnqjok7DQ9VxEiLdMyQbG+DE7CQI6w/TxmniC
>> oiScygu8dCh+KUZ7OXUSBWquHWln6eQlWgJNqv/o4UxZJl9NLxkhDU7OgvMvvCjl
>> I1Gx2BdNIcknZhG3KfzUfj1j97whVJkJyHvWMem+pj2BXFY3eIcAkHKx9nHO+cNy
>> hBFWoCUXGJHxsUMHhDH7FhbuvQR8qCHVaRvmMaKMyO+6S+5R1Q/L4dYvxZjHNScn
>> 3JcWaC5+k91Acj6DYrv4hxszUBtM+KpyG/13Z9ed+qwd6QxH8beKD82kES1ZEl+P
>> crT1uNDOT9ToRLWRHEwd
>> =2adb
>> -END PGP SIGNATURE-
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>> <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 
>> <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [chef] deprecation and removal of old branches

[Jan Klare]

Hi,

Good point, i will talk to infra and figure out how to properly push these eol 
tags to the last commits of the branches before we remove them. Since i only 
got positive feedback on this, i will also go ahead and ask them to help me 
with the cleanup.


Cheers,
Jan

> On 07 Jan 2016, at 07:42, zhiwei  wrote:
> 
> Sounds good, but I think it's better to create some tags just like other 
> OpenStack projects.
> 
> On Thu, Jan 7, 2016 at 9:05 AM, JJ Asghar  > wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 1/6/16 10:22 AM, Samuel Cassiba wrote:
> > I'm +1 on this idea. Looking at other OpenStack projects (Nova, Neutron,
> > etc.) on GitHub, they only have stable/liberty and stable/kilo
> 
> Sounds good to me too.
> 
> 
> - --
> Best Regards,
> JJ Asghar
> c: 512.619.0722  t: @jjasghar irc: j^2
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2
> Comment: GPGTools - https://gpgtools.org 
> 
> iQIcBAEBCgAGBQJWjbnBAAoJEDZbxzMH0+jTbTcP/i/RbxfmQ2T3wasWUKLup9Y3
> bbsiUcfocw40ZT2Y/i/fLiH+mGfIRcvXTLMkYdwji7jhoes2Vt3l+S/CmDR9kb59
> hqxiIft/6kfW3JLjtjkAZtZ5xwa+QSN8DY4aZnnVU9mjdCgDH0DZRuwOZcERZH0Q
> 6gQeIFp0udGVLfDaF32mEdKRRbSlRil6reciDg6W7g+/1lCys8H7ig0/5rqQxE0o
> GmKxyGOlEnpPjpVQz1JeBadktHNjRPOJ1ihiHmC8XusMdg0FDppiJUmLd8gmLFNY
> hRpD2QFHjzlsy+7u5chsiN+ctjawuEZsHCeDD3UDAiSQjptHQy8jw7gl+V4nQry6
> SSpRYkdfV8k5Pf3nsJ8Yyt0SqYggnqjok7DQ9VxEiLdMyQbG+DE7CQI6w/TxmniC
> oiScygu8dCh+KUZ7OXUSBWquHWln6eQlWgJNqv/o4UxZJl9NLxkhDU7OgvMvvCjl
> I1Gx2BdNIcknZhG3KfzUfj1j97whVJkJyHvWMem+pj2BXFY3eIcAkHKx9nHO+cNy
> hBFWoCUXGJHxsUMHhDH7FhbuvQR8qCHVaRvmMaKMyO+6S+5R1Q/L4dYvxZjHNScn
> 3JcWaC5+k91Acj6DYrv4hxszUBtM+KpyG/13Z9ed+qwd6QxH8beKD82kES1ZEl+P
> crT1uNDOT9ToRLWRHEwd
> =2adb
> -END PGP SIGNATURE-
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [chef] deprecation and removal of old branches

[Jan Klare]

Hi everybody,

due to a hint on this patch https://review.openstack.org/#/c/264130/1 
 i walked through some of our 
cookbooks and found that we never actually deprecated or removed the old 
branches for most of our cookbooks. To do this, we just need to define which 
branches exactly we want to keep. As far as i remember we agreed on supporting 
n + 1, which would be stable/kilo and stable/liberty imho. I would like to 
remove all the unsupported branches as fast as possible to clean this up. If 
you think otherwise, please write an short answer to this mailing list until 
the end of this week. If nothing prevents the cleanup, i will contact infra at 
the beginning of the next week and ask them to help me with the deletion of all 
old and unsupported branches.

Cheers,
Jan

—
irc: jklare__
OpenStack Development Mailing 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] [chef] Refactoring and cleanup of all cookbooks during the Mitaka cycle

[Jan Klare]

Hi everyone,

we have just merged the last patches to branch our stable/liberty release for 
all our openstack-chef cookbooks (starting right now). During the liberty cycle 
and at the mitaka design summit we discussed our goals for the current cycle 
and our next big steps. Since we identified the refactoring and cleanup as one 
of our main goals during this cycle, we are now getting it started. The biggest 
part of this process is written down in this spec:
http://specs.openstack.org/openstack/openstack-chef-specs/specs/liberty/all/refactor_config_templates.html
 

In addition to that, we are going to remove all of the unmaintained code from 
all cookbooks. Right now this means we are finally going to drop Suse support, 
since there was no contribution during the last 2 cycles to maintain the 
support and we agreed to not keep unmaintained code during the refactoring and 
cleanup process (if there is anybody out there who wants to keep this code, 
please step up and maintain it, we are happy to support you). Most of the other 
specific attributes (e.g. for vmware, ceph or docker) support will be moved 
from the basic service cookbooks to more specialised and opinionated wrapper 
cookbooks or recipes. Although we will drop a lot of code and feature support 
(switch case scenarios) initially in our basic service cookbooks, it should be 
very easy to add this support in wrapper cookbooks after that. We think that 
moving to a modular cookbook style with generic defaults is the best way of 
keeping the cookbooks maintain- and wrapable. Since these patches need to be 
finished in all cookbooks before they will work again, we agreed on the 
following steps for the patch process:
1) remove all unneeded/default attributes from the attributes file and template
2) move all specific attributes (e.g. vmware, ceph or docker) either to 
documentation or a specific recipe
3) cleanup the rest of the attributes by replacing the template with the new 
template logic (refactor_config_templates spec) and adapt the recipe where the 
template ressource is called
4) adapt the specs (unit tests) to work again
5) wait for the other cookbooks to get finished with the same steps to make 
proper integration testing possible again
(see also 
http://eavesdrop.openstack.org/meetings/openstack_chef/2015/openstack_chef.2015-11-09-16.01.log.html
 
)
As soon as we hit step 5 with all cookbooks, we will make additional small 
changes to get our integration testing working again and merge all of the 
changes as soon as this happens. This means that the biggest part of the 
cleanup and refactoring will happen in one commit to achieve a working set of 
cookbooks for integration testing (one commit but at least 5 patchsets to make 
it a little more reviewable). After this big patch, we will continue the 
refactoring process in the usual small steps before releasing a stable branch 
again. The current target for the next release is refactored_stable/liberty 
working at least on ubuntu14.04 and centos7 . We will not include support for 
distributions without at least one active contributor maintaining it after our 
initial cleanup step (might be added lateron). If you think there should be 
support for more distributions initially, please step up and we will try to 
support you as good as possible.

Cheers,
Jan 


irc: jklare
(openstack-chef PTL)__
OpenStack Development Mailing 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] [HA] RFC: moving Pacemaker openstack-resource-agents to stackforge

[Jan Klare]

+1, sounds great, thanks for the effort

cheers,
Jan

Adam Spiers aspi...@suse.com schrieb am Di., 23. Juni 2015 um 12:28 Uhr:

 [cross-posting to openstack-dev and pacemaker lists; please consider
 trimming the recipients list if your reply is not relevant to both
 communities]

 Hi all,

 https://github.com/madkiss/openstack-resource-agents/ is a nice
 repository of Pacemaker High Availability resource agents (RAs) for
 OpenStack, usage of which has been officially recommended in the
 OpenStack High Availability guide.  Here is one of several examples:


 http://docs.openstack.org/high-availability-guide/content/_add_openstack_identity_resource_to_pacemaker.html

 Martin Loschwitz, who owns this repository, has since moved away from
 OpenStack, and no longer maintains it.  I recently proposed moving the
 repository to StackForge, and he gave his consent and in fact said
 that he had the same intention but hadn't got round to it:


 https://github.com/madkiss/openstack-resource-agents/issues/22#issuecomment-113386505

 You can see from that same github issue that several key members of
 the OpenStack Pacemaker sub-community are all in favour.  Therefore
 I am volunteering to do the move to StackForge.

 Another possibility would be to move each RA to its corresponding
 OpenStack project, although this makes a lot less sense to me, since
 it would require the core members of every OpenStack project to care
 enough about Pacemaker to agree to maintain an RA for it.

 This raises the question of maintainership.  SUSE has a vested
 interest in these resource agents, so we would be happy to help
 maintain them.  I believe Red Hat is also using these, so any
 volunteers from there or indeed anywhere else to co-maintain would be
 welcome.  They are already fairly complete, and I don't expect there
 will be a huge amount of change.

 I'm probably getting ahead of myself, but the other big question is
 regarding CI.  Currently there are no tests at all.  Of course we
 could add bashate, and maybe even some functional tests, but
 ultimately some integration tests would be really nice.  However for
 now I propose we focus on the move and defer CI work till later.

 Thoughts?

 Thanks!
 Adam

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

__
OpenStack Development Mailing 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] Social Monday night

[Jan Klare]

 On May 13, 2015, at 10:51 AM, Thierry Carrez thie...@openstack.org wrote:
 
 Kevin Benton wrote:
 I thought it would be fun to have a get-together for Neutron developers
 (and anyone else interested in Neutron development) on Monday night to
 get acquainted before we get into the design sessions on Tuesday.
 
 Nice initiative Kevin!
 
 More generally, Monday is shaping up to be no-party night, so I'd
 encourage every project team to organize small pre-design-summit
 gatherings after the Booth crawl :) Let's just not all crash the Neutron
 one.
 
 There must be an app, a startup or an API to help organize that…


i think there is, i just created this one 
http://attending.io/events/chefstackers-vancouver 
http://attending.io/events/chefstackers-vancouver (time and place will be 
edited after i have talked to the other cores), never used ‘attending' before, 
but looks nice and was easy

cheers,
Jan (jklare)

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

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

[openstack-dev] [chef] Chefstackers Monday Get-together

[Jan Klare]

Hi,

if you are interested or even working with Openstack and Chef and attending the 
summit in Vancouver, you might want to join us on Monday for a nice evening 
full of discussions around that topic (exact meeting point and time will be 
announced in the event and again over the mailing list).

http://attending.io/events/chefstackers-vancouver 
http://attending.io/events/chefstackers-vancouver

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

Re: [openstack-dev] [chef][infra] #openstack-meeting-5 proposal to open up

[Jan Klare]

Hi,

i think you meant 16:00 UTC == 16:00 GMT == 17:00 BST for our meeting on Monday?
Regarding the official meeting room: it would be great if we could get one :)

For our second sync up meeting on Thursday to include people from Asia, 
zhiwei and myself agreed that 8:00 UTC would be a fitting time for Europe and 
Asia. The question here is if anybody else would join the meeting ? If so, 
please respond to this mail, else we would just drop the second meeting.

Cheers,
Jan

 On May 11, 2015, at 10:32 PM, JJ Asghar jasg...@chef.io wrote:
 
 Hey everyone!
 
 The openstack-chef project is attempting to move into the big tent[1]. As 
 part of this we need to move our meeting from #openstack-chef to one of the 
 official meeting rooms.
 
 We have our official meeting time at 1500UTC/1600GMTorBST on Monday and it 
 seems all the rooms are taken.  Is it possible to open up 
 #openstack-meeting-5?
 
 I asked in #openstack-infra and fungi suggested I ask the mailing list.
 
 Thoughts, questions, concerns?
 
 -JJ
 
 [1]: https://review.openstack.org/#/c/175000 
 https://review.openstack.org/#/c/175000__
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [chef] Feedback to move IRC Monday meeting and time.

[Jan Klare]

Hi,

for me (i live in Germany) the full hour (so 15:00 UTC) is fine.

Cheers,
Jan


 On May 6, 2015, at 7:11 PM, JJ Asghar jasg...@chef.io wrote:
 
 Hey everyone!
 
 As we move forward with our big tent move[1] Jan suggested we move from our 
 traditional IRC meeting in our main channel #openstack-chef to one of the 
 official OpenStack meeting channels[2].
 
 This has actually caused a situation that I’d like to make public. In the 
 documentation the times for the meetings are suggested at the top of the 
 hour, we have ours that start at :30 past. This allows for our friends and 
 community members on the west coast of the United States able to join at a 
 pseudo-reasonable time.  The challenge is, if we move it forward to the top 
 of the hour, we may lose the west coast, but if we move it back to the top of 
 the next hour we may lose our friends in Germany and earlier time zones.
 
 I’m not sure what to do here, so i’d like some feedback from the community.  
 
 When we’ve come to a consensus we can attempt to find the open slot in the 
 official IRC channels and i can put the stake in the ground here[3].
 
 Thoughts, questions, concerns?
 
 -JJ
 
 
 
 [1]: https://review.openstack.org/#/c/175000/ 
 https://review.openstack.org/#/c/175000/
 [2]: https://wiki.openstack.org/wiki/Meetings/CreateaMeeting 
 https://wiki.openstack.org/wiki/Meetings/CreateaMeeting
 [3]: https://wiki.openstack.org/wiki/Meetings#Chef_Cookbook_meetings 
 https://wiki.openstack.org/wiki/Meetings#Chef_Cookbook_meetings__
 OpenStack Development Mailing 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