Re: [openstack-dev] [neutron] [third-party] collecting recheck command to re-trigger third party CI
Doug Wiegley wrote on 09/03/2014 11:24:24 PM: > From: > > Doug Wiegley > Date: > > 09/03/2014 11:25 PM > > Subject: > > Re: [openstack-dev] [neutron] [third-party] collecting recheck > command to re-trigger third party CI > > Hi all, > > May I suggest putting your feedback into this review, which is on the same > subject? > > https://review.openstack.org/#/c/118623/ Thanks Doug, I just saw this thread - yes this patch was the result of infra IRC channel and Third Party meeting discussions. I believe the proper way to specify if individual CI system recheck is supported is to have this shown in CI system's wiki page, which is also now a requirement. If the CI system does not support an individual recheck, then the default behavior would be to just support "recheck" as is currently required. Any feedback on this proposal is welcomed in the patchset noted above. Kurt Taylor (krtaylor) > > > Thanks, > doug > > On 9/3/14, 8:57 PM, "trinath.soman...@freescale.com" > wrote: > > >This is a Good option to go with. > > > >To trigger a specific CI, CI can have their own string or in a community > >specified format. Like retrigger-freescale .. > > > >Also, in the ML or in IRC rooms, I have seen many people asking on how to > >recheck with an X CI. > > > >And many people are not aware of what string to use to trigger a recheck > >for certain CI. > > > >As we have now a separate page for each CI, it would be good to have > >"Trigger String" too in those pages. > > > >+1 to Akihiro Motoki for this email. > > > > > > > >-- > >Trinath Somanchi - B39208 > >trinath.soman...@freescale.com | extn: 4048 > > > >-Original Message- > >From: Akihiro Motoki [mailto:amot...@gmail.com] > >Sent: Wednesday, September 03, 2014 11:34 PM > >To: OpenStack Development Mailing List > >Subject: [openstack-dev] [neutron] [third-party] collecting recheck > >command to re-trigger third party CI > > > >Hi Neutron team, > > > >There are many third party CI in Neutron and we sometimes/usually want to > >retrigger third party CI to confirm results. > >A comment syntax varies across third party CI, so I think it is useful to > >gather "recheck command" in one place. I struggled to know how to rerun a > >specific CI. > > > >I added to "recheck command" column in the list of Neutron plugins and > >drivers [1]. > >Could you add "recheck command" of your CI in the table? > >If it is not available, please add "N/A". > > > >Note that supporting recheck is one of the requirements of third party > >testing. [2] I understand not all CIs support it due to various reasons, > >but collecting it is useful for developers and reviewers. > > > >A syntax of "recheck command" is under discussion in infra review [3]. > >I believe the column of "recheck command" is still useful even after the > >official syntax is defined because it is not an easy thing to know each > >CI system name. > > > >[1] > >https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugi > >n_and_Drivers > >[2] http://ci.openstack.org/third_party.html#requirements > >[3] https://review.openstack.org/#/c/118623/ > > > >Thanks, > >Akihiro > > > >___ > >OpenStack-dev mailing list > >OpenStack-dev@lists.openstack.org > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > >___ > >OpenStack-dev mailing list > >OpenStack-dev@lists.openstack.org > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] OpenStack bootstrapping hour - Friday Sept 19th - 3pm EST
On Mon, Sep 15, 2014 at 7:04 PM, Rochelle.RochelleGrober wrote: > +1000 > This is *great*. Not only for newbies, but refreshers, learning different > approaches, putting faces to the signatures, etc. And Mock best practices is > a brilliant starting place for developers. Yes! > I'd like to vote for a few others: > - Development environment (different ones: PyCharms, Eclipse, IDE for Docs, > etc) > - Tracking down a bug: log searching, back tracing, etc. > - Fixing a bug: From assigning in Launchpad through clone, fix, git review, > etc. > - Writing an integrated test: setup, data recording/collection/clean tear > down. - Third-party CI testing and consuming Infrastructure services > Sorry to have such a big wish list, but for people who learn experientially, > this will be immensely useful. > > --Rocky > > -Original Message- > From: Sean Dague [mailto:s...@dague.net] > Sent: Monday, September 15, 2014 3:56 PM > To: openstack-dev@lists.openstack.org > Subject: [openstack-dev] [all] OpenStack bootstrapping hour - Friday Sept > 19th - 3pm EST > > Assuming this turns out to be useful, we're thinking about lots of other > deep dives. The intent is that these are indepth dives. We as a > community have learned so many things over the last 4 years, but as > OpenStack has gotten so large, being familiar with more than a narrow > slice is hard. This is hopefully a part of the solution to address that. > As I've told others, if nothing else, I'm looking forward to learning a > ton in the process. > > Final links for the hangout + etherpad will be posted a little later in > the week. Mostly wanted to make people aware it was coming. > > -Sean > > -- > Sean Dague > http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] new (docs) requirement for third party CI
Joe Gordon wrote on 01/08/2014 12:40:47 PM: > Re: [openstack-dev] [nova] new (docs) requirement for third party CI > > > On Jan 8, 2014 7:12 AM, "Matt Riedemann" wrote: > > > > If no one is against this or has something to add, I'll update the wiki. > -1 to putting this in the wiki. This isn't a nova only issue. We are > trying to collect the requirements here: > https://review.openstack.org/#/c/63478/ > > > > [1] https://wiki.openstack.org/wiki/HypervisorSupportMatrix/ > DeprecationPlan#Specific_Requirements > > Once this is more solid, is the eventual plan to put this out on the wiki? There are several pockets of organization around 3rd party CI. It makes tracking all of them across all the projects difficult. I would like to see this organized into a global set of requirements, then maybe additional per project specifics for nova, neutron, etc. Kurt Taylor (krtaylor) OpenStack Development - PowerKVM CI IBM Linux Technology Center___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Infra] [third-party]Time for Additional Meeting for third-party
Thanks for starting this discussion Anita. The existing meeting time on Monday has never worked well for me. We could follow what other working groups have done, having alternating meeting times to accommodate everyone. I propose that we have 2 meetings of Third-party CI Ops, alternating weeks: Wednesday 1400 UTC in #openstack-meeting-3 Wednesday 2200 UTC in #openstack-meeting-3 Kurt Taylor (krtaylor) On Tue, Dec 2, 2014 at 2:46 AM, Nurit Vilosny wrote: > HI, > Thanks Anita for pushing it. We will be able to be much more involved if > meetings would be earlier. > We're located in Israel, so Mondays anytime between 8:00 - 16:00, will be > ideal for us. > > Nurit > > -Original Message- > From: trinath.soman...@freescale.com [mailto: > trinath.soman...@freescale.com] > Sent: Tuesday, December 02, 2014 10:32 AM > To: Anita Kuno; openstack Development Mailing List; > openstack-in...@lists.openstack.org > Subject: Re: [openstack-dev] [OpenStack-Infra] [third-party]Time for > Additional Meeting for third-party > > Hi- > > Its nice to have CI operators meetings. > > I'm from India, Its okay for me for 05:00AM UTC on Tuesdays. > > -- > Trinath Somanchi - B39208 > trinath.soman...@freescale.com | extn: 4048 > > -Original Message- > From: Anita Kuno [mailto:ante...@anteaya.info] > Sent: Tuesday, December 02, 2014 1:37 AM > To: openstack Development Mailing List; > openstack-in...@lists.openstack.org > Subject: [OpenStack-Infra] [third-party]Time for Additional Meeting for > third-party > > One of the actions from the Kilo Third-Party CI summit session was to > start up an additional meeting for CI operators to participate from > non-North American time zones. > > Please reply to this email with times/days that would work for you. The > current third party meeting is on Mondays at 1800 utc which works well > since Infra meetings are on Tuesdays. If we could find a time that works > for Europe and APAC that is also on Monday that would be ideal. > > Josh Hesketh has said he will try to be available for these meetings, he > is in Australia. > > Let's get a sense of what days and timeframes work for those interested > and then we can narrow it down and pick a channel. > > Thanks everyone, > Anita. > > ___ > OpenStack-Infra mailing list > openstack-in...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [third-party] Third-party CI documentation WG forming
At the kilo summit third-party session we discussed the need for a complete overhaul of the third-party CI documentation. Several in attendance volunteered to help with this effort. To help get us started, I have created an etherpad to help organize the thoughts of those involved. https://etherpad.openstack.org/p/third-party-ci-documentation Please thoroughly review the existing documentation and also add yourself as a contact to this etherpad if you wish to participate. I have put some initial thoughts and links there, but please feel free to add to it. When we get a group signed up, we can decide how to proceed. Since the Infra manual virtual sprint was such a success, how would everyone feel about a 2 day third-party CI documentation virtual sprint? I think we could bang out a pretty nice doc in that timeframe. Thanks! Kurt Taylor (krtaylor) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Infra] [third-party]Time for Additional Meeting for third-party
In my opinion, further discussion is needed. The proposal on the table is to have 2 weekly meetings, one at the existing time of 1800UTC on Monday and, also in the same week, to have another meeting at 0800 UTC on Tuesday. Here are some of the problems that I see with this approach: 1. Meeting content: Having 2 meetings per week is more than is needed at this stage of the working group. There just isn't enough meeting content to justify having two meetings every week. 2. Decisions: Any decision made at one meeting will potentially be undone at the next, or at least not fully explained. It will be difficult to keep consistent direction with the overall work group. 3. Meeting chair(s): Currently we do not have a commitment for a long-term chair of this new second weekly meeting. I will not be able to attend this new meeting at the proposed time. 4. Current meeting time: I am not aware of anyone that likes the current time of 1800 UTC on Monday. The current time is the main reason it is hard for EU and APAC CI Operators to attend. My proposal was to have only 1 meeting per week at alternating times, just as other work groups have done to solve this problem. (See examples at: https://wiki.openstack.org/wiki/Meetings) I volunteered to chair, then ask other CI Operators to chair as the meetings evolved. The meeting times could be any between 1300-0300 UTC. That way, one week we are good for US and Europe, the next week for APAC. Kurt Taylor (krtaylor) On Wed, Dec 3, 2014 at 11:10 PM, trinath.soman...@freescale.com < trinath.soman...@freescale.com> wrote: > +1. > > -- > Trinath Somanchi - B39208 > trinath.soman...@freescale.com | extn: 4048 > > -Original Message- > From: Anita Kuno [mailto:ante...@anteaya.info] > Sent: Thursday, December 04, 2014 3:55 AM > To: openstack-in...@lists.openstack.org > Subject: Re: [OpenStack-Infra] [openstack-dev] [third-party]Time for > Additional Meeting for third-party > > On 12/03/2014 03:15 AM, Omri Marcovitch wrote: > > Hello Anteaya, > > > > A meeting between 8:00 - 16:00 UTC time will be great (Israel). > > > > > > Thanks > > Omri > > > > -Original Message- > > From: Joshua Hesketh [mailto:joshua.hesk...@rackspace.com] > > Sent: Wednesday, December 03, 2014 9:04 AM > > To: He, Yongli; OpenStack Development Mailing List (not for usage > > questions); openstack-in...@lists.openstack.org > > Subject: Re: [openstack-dev] [OpenStack-Infra] [third-party]Time for > > Additional Meeting for third-party > > > > Hey, > > > > 0700 -> 1000 UTC would work for me most weeks fwiw. > > > > Cheers, > > Josh > > > > Rackspace Australia > > > > On 12/3/14 11:17 AM, He, Yongli wrote: > >> anteaya, > >> > >> UTC 7:00 AM to UTC9:00, or UTC11:30 to UTC13:00 is ideal time for china. > >> > >> if there is no time slot there, just pick up any time between UTC > >> 7:00 AM to UCT 13:00. ( UTC9:00 to UTC 11:30 is on road to home and > >> dinner.) > >> > >> Yongi He > >> -Original Message- > >> From: Anita Kuno [mailto:ante...@anteaya.info] > >> Sent: Tuesday, December 02, 2014 4:07 AM > >> To: openstack Development Mailing List; > >> openstack-in...@lists.openstack.org > >> Subject: [openstack-dev] [third-party]Time for Additional Meeting for > >> third-party > >> > >> One of the actions from the Kilo Third-Party CI summit session was to > start up an additional meeting for CI operators to participate from > non-North American time zones. > >> > >> Please reply to this email with times/days that would work for you. The > current third party meeting is on Mondays at 1800 utc which works well > since Infra meetings are on Tuesdays. If we could find a time that works > for Europe and APAC that is also on Monday that would be ideal. > >> > >> Josh Hesketh has said he will try to be available for these meetings, > he is in Australia. > >> > >> Let's get a sense of what days and timeframes work for those interested > and then we can narrow it down and pick a channel. > >> > >> Thanks everyone, > >> Anita. > >> > > Okay first of all thanks to everyone who replied. > > Again, to clarify, the purpose of this thread has been to find a suitable > additional third-party meeting time geared towards folks in EU and APAC. We > live on a sphere, there is no time that will suit everyone. > > It looks like we are converging on 0800 UTC as a time and I am going to > suggest Tuesdays. We have very little competition for space at that date > + time combination so we can
[openstack-dev] [Third-party] Voting for new Third-party CI weekly IRC meeting time
All of the feedback so far has supported moving the existing IRC Third-party CI meeting to better fit a worldwide audience. The consensus is that we will have only 1 meeting per week at alternating times. You can see examples of other teams with alternating meeting times at: https://wiki.openstack.org/wiki/Meetings This way, one week we are good for one part of the world, the next week for the other. You will not need to attend both meetings, just the meeting time every other week that fits your schedule. Proposed times in UTC are being voted on here: https://www.google.com/moderator/#16/e=21b93c Please vote on the time that is best for you. I would like to finalize the new times this week. Thanks! Kurt Taylor (krtaylor) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Third-party] Voting for new Third-party CI weekly IRC meeting time
Anita, I really appreciate your willingness to host a meeting, but, the response from the group in the previous thread was in support of the alternating meeting approach. Daya, Erlon, Trinath, Steve, Misha and others all agreed. I am confused why you would not want to go with the consensus on this. Thanks again for everything that you do for us! Kurt Taylor (krtaylor) On Tue, Dec 9, 2014 at 10:55 AM, Anita Kuno wrote: > On 12/09/2014 08:32 AM, Kurt Taylor wrote: > > All of the feedback so far has supported moving the existing IRC > > Third-party CI meeting to better fit a worldwide audience. > > > > The consensus is that we will have only 1 meeting per week at alternating > > times. You can see examples of other teams with alternating meeting times > > at: https://wiki.openstack.org/wiki/Meetings > > > > This way, one week we are good for one part of the world, the next week > for > > the other. You will not need to attend both meetings, just the meeting > time > > every other week that fits your schedule. > > > > Proposed times in UTC are being voted on here: > > https://www.google.com/moderator/#16/e=21b93c > > > > Please vote on the time that is best for you. I would like to finalize > the > > new times this week. > > > > Thanks! > > Kurt Taylor (krtaylor) > > > > > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > Note that Kurt is welcome to do as he pleases with his own time. > > I will be having meetings in the irc channel for the times that I have > booked. > > Thanks, > Anita. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Third-party] Voting for new Third-party CI weekly IRC meeting time
So far it looks like we have centered around 2 options: Option "A" 1200 and 2200 UTC Option "D" 1500 and 0400 UTC There is still time to pick your best time. Please vote at https://www.google.com/moderator/#16/e=21b93c Special thanks to Steve, Daya, Markus, Mikhail, Emily, Nurit, Edwin and Ramy for taking the time to vote. Kurt Taylor (krtaylor) On Tue, Dec 9, 2014 at 9:32 AM, Kurt Taylor wrote: > All of the feedback so far has supported moving the existing IRC > Third-party CI meeting to better fit a worldwide audience. > > The consensus is that we will have only 1 meeting per week at alternating > times. You can see examples of other teams with alternating meeting times > at: https://wiki.openstack.org/wiki/Meetings > > This way, one week we are good for one part of the world, the next week > for the other. You will not need to attend both meetings, just the meeting > time every other week that fits your schedule. > > Proposed times in UTC are being voted on here: > https://www.google.com/moderator/#16/e=21b93c > > Please vote on the time that is best for you. I would like to finalize the > new times this week. > > Thanks! > Kurt Taylor (krtaylor) > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Third-party] Voting for new Third-party CI weekly IRC meeting time
Anita, please, creating yet another meeting time without input from anyone just confuses the issue. The work group has agreed unanimously on alternating weekly meeting times, and are currently voting on the best for everyone. ( https://www.google.com/moderator/#16/e=21b93c 14 voters so far, thanks everyone!) Once we finalize the voting, I was going to start up the new meeting times in the new year. Until then, we would stay at our normal time, Monday at 1800 UTC. I am still confused why you would not want to go with the consensus on this. And, thanks again for everything that you do for us! Kurt Taylor (krtaylor) On Mon, Dec 15, 2014 at 9:23 AM, Anita Kuno wrote: > > On 12/09/2014 11:55 AM, Anita Kuno wrote: > > On 12/09/2014 08:32 AM, Kurt Taylor wrote: > >> All of the feedback so far has supported moving the existing IRC > >> Third-party CI meeting to better fit a worldwide audience. > >> > >> The consensus is that we will have only 1 meeting per week at > alternating > >> times. You can see examples of other teams with alternating meeting > times > >> at: https://wiki.openstack.org/wiki/Meetings > >> > >> This way, one week we are good for one part of the world, the next week > for > >> the other. You will not need to attend both meetings, just the meeting > time > >> every other week that fits your schedule. > >> > >> Proposed times in UTC are being voted on here: > >> https://www.google.com/moderator/#16/e=21b93c > >> > >> Please vote on the time that is best for you. I would like to finalize > the > >> new times this week. > >> > >> Thanks! > >> Kurt Taylor (krtaylor) > >> > >> > >> > >> ___ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > Note that Kurt is welcome to do as he pleases with his own time. > > > > I will be having meetings in the irc channel for the times that I have > > booked. > > > > Thanks, > > Anita. > > > Just in case anyone remains confused, I am chairing third party meetings > Mondays at 1500 UTC and Tuesdays at 0800 UTC in #openstack-meeting. > There is a meeting currently in progress. > > This is a great time for people who don't understand requirements to > show up and ask questions. > > Thank you, > Anita. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Third-party] Voting for new Third-party CI weekly IRC meeting time
On Mon, Dec 15, 2014 at 10:24 AM, Anita Kuno wrote: > > On 12/15/2014 10:55 AM, Kurt Taylor wrote: > > Anita, please, creating yet another meeting time without input from > anyone > > just confuses the issue. > When I ask people to attend meetings to reduce noise on the mailing > list, there had better be some meetings. > I don't think we have a problem with the volume of third-party email. In fact, I wish there was even more questions and discussion. I encourage everyone to use whatever method (meetings or email) to get involved. > > I am grateful for the time you have spent chairing, thank you. It gave > me a huge break and allowed me to focus on other things (like reviews) > that I had to neglect due to the amount of time third party was taking > from my life. > No problem at all. I'm just a CI operator running a meeting for CI operators, I get just as much out of it as everyone else. > > I need there to be meetings to answer questions for people and will be > chairing meetings on the dates and times I have specified, like I said > that I would do. > I don't know how to move forward with this, except to follow what the group has agreed on. I will be happy to kick off the meetings we are voting on, but I hope to bring other CI operators in the mix to help with chairing, leading development work groups, and sharing their best practices. I think we are on the right track to do some great things in Kilo! Kurt Taylor (krtaylor) > > Thank you, > Anita. > > > > > The work group has agreed unanimously on alternating weekly meeting > times, > > and are currently voting on the best for everyone. ( > > https://www.google.com/moderator/#16/e=21b93c 14 voters so far, thanks > > everyone!) Once we finalize the voting, I was going to start up the new > > meeting times in the new year. Until then, we would stay at our normal > > time, Monday at 1800 UTC. > > > > I am still confused why you would not want to go with the consensus on > this. > > > > And, thanks again for everything that you do for us! > > Kurt Taylor (krtaylor) > > > > > > On Mon, Dec 15, 2014 at 9:23 AM, Anita Kuno > wrote: > >> > >> On 12/09/2014 11:55 AM, Anita Kuno wrote: > >>> On 12/09/2014 08:32 AM, Kurt Taylor wrote: > >>>> All of the feedback so far has supported moving the existing IRC > >>>> Third-party CI meeting to better fit a worldwide audience. > >>>> > >>>> The consensus is that we will have only 1 meeting per week at > >> alternating > >>>> times. You can see examples of other teams with alternating meeting > >> times > >>>> at: https://wiki.openstack.org/wiki/Meetings > >>>> > >>>> This way, one week we are good for one part of the world, the next > week > >> for > >>>> the other. You will not need to attend both meetings, just the meeting > >> time > >>>> every other week that fits your schedule. > >>>> > >>>> Proposed times in UTC are being voted on here: > >>>> https://www.google.com/moderator/#16/e=21b93c > >>>> > >>>> Please vote on the time that is best for you. I would like to finalize > >> the > >>>> new times this week. > >>>> > >>>> Thanks! > >>>> Kurt Taylor (krtaylor) > >>>> > >>>> > >>>> > >>>> ___ > >>>> OpenStack-dev mailing list > >>>> OpenStack-dev@lists.openstack.org > >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>>> > >>> Note that Kurt is welcome to do as he pleases with his own time. > >>> > >>> I will be having meetings in the irc channel for the times that I have > >>> booked. > >>> > >>> Thanks, > >>> Anita. > >>> > >> Just in case anyone remains confused, I am chairing third party meetings > >> Mondays at 1500 UTC and Tuesdays at 0800 UTC in #openstack-meeting. > >> There is a meeting currently in progress. > >> > >> This is a great time for people who don't understand requirements to > >> show up and ask questions. > >> > >> Thank you, > >> Anita. > >> > >> ___ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Infra] [third-party]Time for Additional Meeting for third-party
On Mon, Dec 15, 2014 at 7:07 PM, Stefano Maffulli wrote: > > On 12/05/2014 07:08 AM, Kurt Taylor wrote: > > 1. Meeting content: Having 2 meetings per week is more than is needed at > > this stage of the working group. There just isn't enough meeting content > > to justify having two meetings every week. > > I'd like to discuss this further: the stated objectives of the meetings > are very wide and may allow for more than one slot per week. In > particular I'm seeing the two below as good candidates for 'meet as many > times as possible': > >* to provide a forum for the curious and for OpenStack programs who > are not yet in this space but may be in the future >* to encourage questions from third party folks and support the > sourcing of answers > > > > As I mentioned above, probably one way to do this is to make some slots > more focused on engaging newcomers and answering questions, more like > serendipitous mentoring sessions with the less involved, while another > slot could be dedicated to more focused and long term efforts, with more > committed people? > This is an excellent idea, let's split the meetings into: 1) Mentoring - mentoring new CI team members and operators, help them understand infra tools and processes. Anita can continue her fantastic work here. 2) Working Group - working meeting for documentation, reviewing patches for relevant work, and improving the consumability of infra CI components. I will be happy to chair these meetings initially. I am sure I can get help with these meetings for the other time zones also. With this approach we can also continue to use the new meeting times voted on by the group, and each is focused on targeting a specific group with very different needs. Thanks Stefano! Kurt Taylor (krtaylor) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [third-party] Third-party CI meeting change
There will be a new working group meeting for improving the consumability of infra CI components and documentation. The vote has been tallied and the meeting times will be Wednesdays at 1500/0400 UTC alternating. The existing meeting at 1800 UTC on Monday January 5th (and all future meetings at that time) will be cancelled and we will start the new time on January 7th with 1500 UTC. The following week, January 14th, will be at the alternating time 0400 UTC. The other times on Monday and Tuesday will remain unchanged for helping new CI operators in understanding the infra tools and processes. Refer to the meetings page for more details: https://wiki.openstack.org/wiki/Meetings#Third_Party_Meeting Thanks, Kurt Taylor (krtaylor) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][ThirdPartyCI][PCI] Intel Third party Hardware based CI for PCI
The public link for your test logs should really be a host name instead of an IP address. That way if you have to change it again in the future, you won't have dead links in old comments. You may already know, but all of the requirements and recommendations are here: http://git.openstack.org/cgit/openstack-infra/system-config/tree/doc/source/third_party.rst Kurt Taylor (krtaylor) On Sun, Jan 11, 2015 at 11:18 PM, yongli he wrote: > 在 2015年01月08日 10:31, yongli he 写道: > to make a more stable service we upgrade the networking device, then the > log server address change to a new > IP address: 198.175.100.33 > > so the sample log change to(replace the 192.55.68.190 to new address): > > > http://198.175.100.33/143614/6/ > http://198.175.100.33/139900/4 > http://198.175.100.33/143372/3/ > http://198.175.100.33/141995/6/ > http://198.175.100.33/137715/13/ > http://198.175.100.33/133269/14/ > > Yongli He > > > Hi, > > Intel set up a Hardware based Third Part CI. it's already running sets > of PCI test cases > for several weeks (do not sent out comments, just log the result) > the log server and these test cases seems fairly stable now. to begin > given comments to nova > repository, what other necessary work need to be address? > > Details: > 1. ThirdPartySystems <https://wiki.openstack.org/wiki/ThirdPartySystems> > Information > https://wiki.openstack.org/wiki/ThirdPartySystems/Intel-PCI-CI > > 2. a sample logs: > <http://192.55.68.190/138795/6/> > > 3. Test cases on github: > > https://github.com/intel-hw-ci/Intel-Openstack-Hardware-CI/tree/master/pci_testcases > > > > Thanks > Yongli He > > > > __ > OpenStack Development Mailing 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] [third-party] Third-party CI Documentation sprint, January 21-23
Hello all, The OpenStack Third-party CI working group will be hosting a virtual sprint for refreshing and improving the related third-party CI documentation. We will meet immediately following the working group weekly meeting on January 21st and the sprint will run for 48 hours. Where: freenode #openstack-sprint When: January 21st-23nd (1600UTC for 48 hours) Please join us if you would like to help, even if just for a couple of hours. I created a etherpad for the sprint here: https://etherpad.openstack.org/p/third-party-ci-documentation Having some infra core reviewers available during the sprint would be great so we could review and close out the patches as they come in. Thanks everyone! Kurt Taylor (krtaylor) __ OpenStack Development Mailing 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] [third-party] Third-party CI Documentation sprint, January 21-23
Just a reminder, the third-party documentation sprint is happening now. Come help if you can! Kurt Taylor (krtaylor) On Sat, Jan 17, 2015 at 5:29 PM, Kurt Taylor wrote: > Hello all, > > The OpenStack Third-party CI working group will be hosting a virtual > sprint for refreshing and improving the related third-party CI > documentation. We will meet immediately following the working group weekly > meeting on January 21st and the sprint will run for 48 hours. > > Where: freenode #openstack-sprint > When: January 21st-23nd (1600UTC for 48 hours) > > Please join us if you would like to help, even if just for a couple of > hours. I created a etherpad for the sprint here: > https://etherpad.openstack.org/p/third-party-ci-documentation > > Having some infra core reviewers available during the sprint would be > great so we could review and close out the patches as they come in. > > Thanks everyone! > Kurt Taylor (krtaylor) > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [OpenStack-Infra] [3rd party testing] Atlanta meetup for 3rd party testing?
Sorry if you get this twice. Since summit is approaching quickly, I wanted to see if anyone had interest in forming a meetup for 3rd party testing. This would be a group for helping the project cores by helping ourselves and hopefully improving overall CI rollout. Some topics to discuss: I'd at least like to get a standard tag that would help with email filtering, but we could also build a FAQ and documentation contributions to improve the content of the 3rd party testing. We could also document different use cases and best practices for each on how different testers solved problems they encountered for their environment. I don't know how long we would be able to meet, so this may just be an organizational meeting, focusing on how to best share this info. I started an etherpad for discussion topics and eventual agenda here: https://etherpad.openstack.org/p/3rdPartyTesting I have not worked out all the details for when and where to meet, but I would be happy to set it up and facilitate the discussion. I wanted to see if there was any interest before I took it any further. Any interest? Kurt Taylor (krtaylor) OpenStack Development Lead - PowerKVM CI IBM Linux Technology Center ___ OpenStack-Infra mailing list openstack-in...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Infra] [3rd party testing] Atlanta meetup for 3rd party testing?
Anita Kuno wrote on 04/15/2014 09:41:17 AM: > On 04/15/2014 10:20 AM, Kurt Taylor wrote: > > > > > > Sorry if you get this twice. > > > > Since summit is approaching quickly, I wanted to see if anyone had interest > > in forming a meetup for 3rd party testing. This would be a group for > > helping the project cores by helping ourselves and hopefully improving > > overall CI rollout. > > > > Some topics to discuss: I'd at least like to get a standard tag that would > > help with email filtering, but we could also build a FAQ and documentation > > contributions to improve the content of the 3rd party testing. We could > > also document different use cases and best practices for each on how > > different testers solved problems they encountered for their environment. I > > don't know how long we would be able to meet, so this may just be an > > organizational meeting, focusing on how to best share this info. > > > > I started an etherpad for discussion topics and eventual agenda here: > > https://etherpad.openstack.org/p/3rdPartyTesting > > > > I have not worked out all the details for when and where to meet, but I > > would be happy to set it up and facilitate the discussion. I wanted to see > > if there was any interest before I took it any further. > > > > Any interest? > > > There is a summit design session proposed to address this: > http://summit.openstack.org/cfp/details/59 > > Entitled: Improving Third Party Testing > > If you would like to add the information you would like to cover as a > comment to the proposal that would help ensure the content gets covered. Thanks for your response. I did not know about this and I am glad this is proposed. It was my intention originally to propose this type of discussion, but after bringing this up in -infra, it was not something the team wanted to discuss in a design session. They suggested a BOF or meetup at the infra table in developer's lounge. I do not know yet if that location is still a possibility or not, as I indicated in my email. > > Since the purpose of the design summit is to cover material like this, I > encourage people to get familiar with the summit sessions that are > already proposed: http://summit.openstack.org/ and to propose sessions > that you would like covered if you don't see a current proposal for your > topic of interest. > > Since most of what I saw in the Neutron design summit sessions last year > is counter to how most other programs use their design summit sessions, > I encourage you to consider using the design summit session format. > Neutron design summit sessions end up being more like conference > presentations and that is not what the design summit was meant to be at all. > > Design summit sessions are meant to be group discussion chaired by > either the proposer of the session or someone else but equally discussed > by all participants. They are not meant to be a presentation with a > passive audience. Yes, I am very familiar with UDS-style design summits and have lead several design sessions in the past on other projects. I think this is a big factor in the enormous success of the OpenStack project. There is probably some overlap in the proposed design session and the meetup. But, I actually see the meetup as more of a organizational meeting to pull together the developers with experience in CI to share ideas and how we got past the problems we found. Maybe we can wait for the outcome of the session discussion and determine next steps after summit? Thanks again! Kurt Taylor (krtaylor) OpenStack Development Lead - PowerKVM CI IBM Linux Technology Center___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra] Welcome three new members to project-config-core
Congratulations everyone, well deserved! Kurt Taylor (krtaylor) On Tue, Sep 30, 2014 at 9:54 AM, Jeremy Stanley wrote: > With unanimous consent[1][2][3] of the OpenStack Project > Infrastructure core team (infra-core), I'm pleased to welcome > Andreas Jaeger, Anita Kuno and Sean Dague as members of the > newly-formed project-config-core team. Their assistance has been > invaluable in reviewing changes to our project-specific > configuration data, and I predict their addition to the core team > for the newly split-out openstack-infra/project-config repository > represents an immense benefit to everyone in OpenStack. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Third-party] Third-party CI WG Meeting
Hi, Reminder: the Third-party Work Group meeting for this week (November 3) has been cancelled due to Summit. We will resume our normal time next week. The meeting details are here: https://wiki.openstack.org/wiki/Meetings/ThirdParty Kurt Taylor (krtaylor) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] 3rd Party CI vs. Gerrit
Dan Smith wrote on 06/27/2014 12:33:48 PM: > > > What if 3rd Party CI didn't vote in Gerrit? What if it instead > > published to some 3rd party test reporting site (a thing that > > doesn't yet exist). Gerrit has the facility so that we could inject > > the dashboard content for this in Gerrit in a little table > > somewhere, but the data would fundamentally live outside of Gerrit. > > It would also mean that all the aggregate reporting of 3rd Party CI > > that's being done in custom gerrit scripts, could be integrated > > directly into such a thing. > > If it really does show up right in Gerrit as if it were integrated, > then that would be fine with me. I think the biggest problem we have > right now is that a lot of the CI systems are very inconsistent in > their reporting and we often don't realize when one of them *hasn't* > voted. If the new thing could fill out the chart based on everything > we expect to see a vote from, so that it's very clear that one is > missing, then that's a net win right there. There is a similar old bug for that, with a good suggestion for how it could possibly be done: https://bugs.launchpad.net/openstack-ci/+bug/1251758 Kurt Taylor (krtaylor) OpenStack Development Lead - PowerKVM CI IBM Linux Technology Center ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] 3rd Party CI vs. Gerrit
Sean Dague wrote on 06/30/2014 06:03:50 AM: > From: > > Sean Dague > > To: > > "OpenStack Development Mailing List (not for usage questions)" > , > > Date: > > 06/30/2014 06:09 AM > > Subject: > > Re: [openstack-dev] [all] 3rd Party CI vs. Gerrit > > On 06/29/2014 09:39 AM, Joshua Hesketh wrote: > > On 6/28/14 10:40 AM, James E. Blair wrote: > >> An alternate approach would be to have third-party CI systems register > >> jobs with OpenStack's Zuul rather than using their own account. This > >> would mean only a single report of all jobs (upstream and 3rd-party) > >> per-patchset. It significantly reduces clutter and makes results more > >> accessible -- but even with one system we've never actually wanted to > >> have Jenkins results in comments, so I think one of the other options > >> would be preferred. Nonetheless, this is possible with a little bit of > >> work. > > > > I agree this isn't the preferred solution, but I disagree with the > > little bit of work. This would require CI systems registering with > > gearman which would mean security issues. The biggest problem with this > > though is that zuul would be stuck waiting from results from 3rd parties > > which often have very slow return times. > > Right, one of the other issues is the quality of the CI results varies > as well. Agreed. After last summit, Anita, Jay and I decided to start gathering a team of 3rd party testers that have the goal of improving the quality of the third party systems. We are starting with gathering global unwritten requirements, improving documentation and reaching out to new projects that will have third party testing needs. We are still in the early stages but now have weekly meetings to discuss what needs to be done and track progress. https://wiki.openstack.org/wiki/Meetings/ThirdParty > I think one of the test result burn out issues right now is based on the > fact that they are too rolled up as it is. For instance, a docs only > change gets Tempest results, which humans know are irrelevant, but > Jenkins insists they aren't. I think that if we rolled up more > information, and waited longer, we'd be in a worse state. Maybe it could promptly timeout and then report the system that did not complete? That would also have the benefit of enforcing a time limit on reporting results. Kurt Taylor (krtaylor) OpenStack Development Lead - PowerKVM CI IBM Linux Technology Center ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Do we need to have a mid-cycle?
On Wed, Nov 11, 2015 at 11:16 AM, Ruby Loo wrote: > On 10 November 2015 at 12:08, Dmitry Tantsur wrote: > >> On 11/10/2015 05:45 PM, Lucas Alvares Gomes wrote: >> >>> Hi, >>> >>> In the last Ironic meeting [1] we started a discussion about whether >>> we need to have a mid-cycle meeting for the Mitaka cycle or not. Some >>> ideas about the format of the midcycle were presented in that >>> conversation and this email is just a follow up on that conversation. >>> >>> The ideas presented were: >>> >>> 1. Normal mid-cycle >>> >>> Same format as the previous ones, the meetup will happen in a specific >>> venue somewhere in the world. >>> >> >> I would really want to see you all as often as possible. However, I don't >> see much value in proper face-to-face mid-cycles as compared to improving >> our day-to-day online communications. > > > +2. > > My take on mid-cycles is that if folks want to have one, that is fine, I > might not attend :) > > My preference is 4) no mid-cycle -- and try to work more effectively with > people in different locations and time zones. > I was hoping to suggest that we have a mid-cycle co-located with neutron, but they are not having a mid-cycle. So, my preference would be 4) no mid cycle. I would like for us to try a few virtual sprints on targeted subjects. I did one for CI documentation and the hardest part about setting that up was picking the time. https://wiki.openstack.org/wiki/VirtualSprints Kurt Taylor (krtaylor) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [ironic] third party CI systems - vendor requirement milestones status
We are in the final stretch for requiring CI testing for ironic drivers. I have organized the CI teams that I know about and their current status into the following wiki page: https://wiki.openstack.org/wiki/Ironic/Drivers#3rd_Party_CI_required_implementation_status I have already heard from a few folks with edits, but please review this info and let me know if you have any changes. You can make needed changes yourself, but let me know so I can keep track. Thanks! Kurt Taylor (krtaylor) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [ironic] third party driver CI testing m-2 milestone reminder
A reminder, Since M-2 milestone has now passed (Mitaka-2, January 21st), your third party CI driver testing system should have completed the following: "Mitaka-2 milestone: Driver teams will have registered their intent to run CI by creating system accounts and identifying a point of contact for their CI team." [1] The CI test system should be entered at the Third Party Systems wiki. [2] Note: this entry will also need to show the current status of your system, see how to indicate that at the bottom of that page. See the Third Party Testing requirements for more information. [3] Let me know if you have any questions. [1] https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/third-party-ci.html [2] https://wiki.openstack.org/wiki/ThirdPartySystems [3] http://docs.openstack.org/infra/system-config/third_party.html Kurt Taylor (krtaylor) __ OpenStack Development Mailing 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] [third-party] Third party CI working group chair
The amount of time I am able to spend on third party CI efforts has been on the decline over the last release cycle, so it's time for me to step back from chairing the working group and let someone else take over. Ramy Asselin has agreed to take over chairing the working group starting with this weeks meeting, Tuesday, Sept. 15th, 1700UTC in #openstack-meeting. I'm really proud of what we have accomplished since the formation of the working group. Please join us on Tuesday and get involved, there is still much more to do. Thanks! Kurt Taylor (krtaylor) https://wiki.openstack.org/wiki/Meetings/ThirdParty https://wiki.openstack.org/wiki/ThirdPartyCIWorkingGroup __ OpenStack Development Mailing 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] [third-party] Weekly Third Party CI Working Group meeting Wednesday June 10th 1500UTC
Hi all, The weekly Third Party CI Working Group team meeting is at 1500UTC this Wednesday, June 10th in #openstack-meeting-4. The agenda for the meeting is here: https://wiki.openstack.org/wiki/Meetings/ThirdParty We will be discussing the CI systems monitoring dashboard, among other things. Please try to attend if at all possible. As always, feel free to add items to the agenda and we will get to them as time permits. Thanks! Kurt Taylor (krtaylor) __ OpenStack Development Mailing 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] [third-party] Weekly Third Party CI Working Group meeting change
Following feedback for increasing working group participation from Vancouver summit[1] and discussions in the weekly meetings[2], we have decided to move the Wednesday working group meeting times and reduce their frequency. The Monday Office Hours meetings will remain unchanged. The options for moving the meeting so that it would no longer conflict with Neutron and Cinder meetings, and still be in accessible hours for those that participate, were very few. The proposal is to move the working group meeting from Wednesday to Tuesday, and to drop the 0400 UTC meeting. For our APAC friends seeking assistance, there is still the Monday Office Hours meeting at 0800 UTC. The proposed time is bi-weekly (every other week) on even weeks, Tuesdays at 1700 UTC. I have already reserved that time since our options were so limited.[3] Unless there is major objection, the meetings will start on Tuesday, June 23rd. Note that this skips next week since we are dropping the 0400 meeting time. The meetings will continue bi-weekly: June 23rd, July 7th, July 21st, August 4th... I will send out reminders to make sure that everyone remembers this transition. Thanks! Kurt Taylor (krtaylor) [1] https://etherpad.openstack.org/p/liberty-ci-loops-bof [2] https://wiki.openstack.org/wiki/Meetings/ThirdParty [3] https://review.openstack.org/#/c/190221 __ OpenStack Development Mailing 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] [third-party] Third Party CI Working Group Meeting Tuesday June 23 1700UTC
Hi all, The Third Party CI Working Group is meeting at the new time this week - 1700UTC Tuesday, June 23rd in #openstack-meeting. The agenda for the meeting is here: https://wiki.openstack.org/wiki/Meetings/ThirdParty We will be working on the CI systems monitoring dashboard hosting spec and preparing for the common CI virtual sprint, among other things. Please try to attend if at all possible. As always, feel free to add items to the agenda and we will get to them as time permits. Thanks! Kurt Taylor (krtaylor) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Clarifications about ThirdParty CI deadlines
On Mon, Mar 7, 2016 at 1:48 PM, Thiago Paiva wrote: > Hello folks, > > My project is in need of some clarifications about the deadlines for the > CI deployment on [1]. If you can kindly answer these questions to help us > consider changes on our sprint planning to address the community > requirements, would be very very helpful: > > 1) In the point 2, what do we mean by "receive events"? Is is about > reading from the event stream of Gerrit and take the appropriate actions? > Act upon "check experimental" or "check " comments are > considered valid to fulfill this requirement? > Just be able to connect to gerrit and receive events - see: http://docs.openstack.org/infra/system-config/third_party.html#reading-the-event-stream > > 2) We are a little confused with the phrase "post comments in the > sandbox". By that we mean commenting on the "openstack-infra/ci-sandbox" > project? Do we need to keep commenting on sandbox even when we have already > set-up the job to read events and comment results for the > "openstack/ironic" project? > > This is just a way to test your CI system without posting garbage to the ironic project patch comments. The sandbox is a place to post comments on a test pass and verify that it all llooks good and satisfies the requirements. See: http://docs.openstack.org/infra/system-config/third_party.html#testing-your-ci-setup Kurt Taylor (krtaylor) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Keystone] PowerKVM CI reporting
Just FYI, in case there was any questions, In addition to testing and reporting on Nova, the IBM PowerKVM CI system is now also testing against Keystone patches. We are happy to also be testing keystone patches on PowerKVM, and will be adding other projects soon. Regards, Kurt Taylor (krtaylor) __ OpenStack Development Mailing 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] PowerKVM CI reporting
Thanks Morgan, That's why I wanted to email. We will gladly come to a meeting and formally request to comment and will turn off commenting on Keystone until then. Thanks, Kurt Taylor (krtaylor) On Mon, Feb 2, 2015 at 3:43 PM, Morgan Fainberg wrote: > I assumed [my mistake] this was not commenting/reporting, just running > against Keystone. I expect a more specific request to comment rather than a > “hey we’re doing this” if commenting is what is desired. > > Please come to our weekly meeting if you’re planning on commenting/scoring > on keystone patches. > > -- > Morgan Fainberg > > On February 2, 2015 at 1:41:08 PM, Anita Kuno (ante...@anteaya.info) > wrote: > > On 02/02/2015 02:16 PM, Morgan Fainberg wrote: > > Thank you for the heads up. > > > > —Morgan > > > > -- > > Morgan Fainberg > > > > On February 2, 2015 at 1:15:49 PM, Kurt Taylor (kurt.r.tay...@gmail.com) > wrote: > > > > Just FYI, in case there was any questions, > > > > In addition to testing and reporting on Nova, the IBM PowerKVM CI system > is now also testing against Keystone patches. > > > > We are happy to also be testing keystone patches on PowerKVM, and will > be adding other projects soon. > > > > Regards, > > Kurt Taylor (krtaylor) > > > __ > > OpenStack Development Mailing 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 > > > Requesting permission to comment on a new repo is best done at the > weekly meeting of the project in question, not the mailing list. > > 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 > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] PowerKVM CI reporting
On Mon, Feb 2, 2015 at 4:07 PM, Matt Riedemann wrote: > > > On 2/2/2015 3:52 PM, Kurt Taylor wrote: > >> Thanks Morgan, That's why I wanted to email. We will gladly come to a >> meeting and formally request to comment and will turn off commenting on >> Keystone until then. >> >> Thanks, >> Kurt Taylor (krtaylor) >> >> On Mon, Feb 2, 2015 at 3:43 PM, Morgan Fainberg >> mailto:morgan.fainb...@gmail.com>> wrote: >> >> I assumed [my mistake] this was not commenting/reporting, just >> running against Keystone. I expect a more specific request to >> comment rather than a “hey we’re doing this” if commenting is what >> is desired. >> >> Please come to our weekly meeting if you’re planning on >> commenting/scoring on keystone patches. >> >> -- >> Morgan Fainberg >> >> On February 2, 2015 at 1:41:08 PM, Anita Kuno (ante...@anteaya.info >> <mailto:ante...@anteaya.info>) wrote: >> >> On 02/02/2015 02:16 PM, Morgan Fainberg wrote: >>> > Thank you for the heads up. >>> > >>> > —Morgan >>> > >>> > -- >>> > Morgan Fainberg >>> > >>> > On February 2, 2015 at 1:15:49 PM, Kurt Taylor ( >>> kurt.r.tay...@gmail.com <mailto:kurt.r.tay...@gmail.com>) wrote: >>> > >>> > Just FYI, in case there was any questions, >>> > >>> > In addition to testing and reporting on Nova, the IBM PowerKVM CI >>> system is now also testing against Keystone patches. >>> > >>> > We are happy to also be testing keystone patches on PowerKVM, and >>> will be adding other projects soon. >>> > >>> > Regards, >>> > Kurt Taylor (krtaylor) >>> >>> > Sorry for being naive, but what in Keystone is arch-specific such that it > could be different on ppc64 vs x86_64? Or is there more to PowerKVM CI > than the name implies? > > No, it's a good question. We plan on testing many different repos or components in L1 and beyond. It is a quality statement really, to assure anyone wanting to run OpenStack on a different platform that some set of tests against some set of core components had been run. We were starting with the L1 components with Nova first (as you know) and adding from there. However, I of all people should know better than to turn on comments for this new component without discussing it at the component's meeting. I'm on the agenda for Keystone, please feel free to attend and discuss. https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting Thanks, Kurt Taylor (krtaylor) -- > > Thanks, > > Matt Riedemann > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing 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] Hypervisor support matrix now in GIT
On Thu, Feb 5, 2015 at 4:31 AM, Daniel P. Berrange wrote: > Hi Team Nova, > > This is a message to alert everyone to the fact that the old hypervisor > support matrix on the wiki[1], should really be considered obsolete. > > The canonical location for it going forward will be > >http://docs.openstack.org/developer/nova/support-matrix.html > > That URL shows current GIT snapshot, releases will get their own URL > when the time comes. > > The source for this document is part of Nova GIT in the path > >doc/source/support-matrix.ini > > The docs are auto-generated from that ini file using a sphinx extension > >doc/ext/support_matrix.py > > The CSS styling is in > >doc/source/_static/support-matrix.css > > Some things to note here > > - The new doc was populated based on the contents of the old wiki page > from >about two months ago, so if there have been additions to the wiki in > that >time, they might not all have been captured - depends how good I was at >figuring out changes. > > - Improvements to the content and/or HTML styling should obviously be sent >as patches to Nova GIT in the files mentioned above, via normal Gerrit >review practice. > > - Since it is in GIT, the support matrix is now able to record information >per release branch of Nova. So users can be clear about what features >their release of Nova supports, as opposed to playing guessing games. > > - The in-tree document only covers features of the in-tree Nova drivers. >As such it does not include information about Docker or PowerKVM or >the (now deleted) BareMetal drivers. My currently suggestion is that >people maintaining out of tree drivers, should reuse the sphinx > extension >to format their own support matrix ini file in their local GIT repo. > I think that maybe you have confused PowerKVM with PowerVM. The PowerVM driver was removed, but PowerKVM support is in tree with libvirt. > >I've not deleted the wiki page, since in the short term it is the >only place with info about Docker/PowerKVM. > > - When submitting a new virt driver for merge in Nova, you should add >it to the docs/source/support-matrix.ini file. This clearly shows >reviewers what feature set your initial code submission supports > >For example, the Parallels team who have been adding Parallels support >to Libvirt for Kilo should submit a patch to update this matrix prior >to Kilo release. > >Likewise people working on making libvirt KVM run on Arm and PPC >should update the matrix, since it only records x86 support status >for Libvirt currently. > I will push a patch to update the matrix shortly. > > - When adding support for new APIs to existing drivers, rememeber to >update the docs/source/support-matrix.ini file to list the new >capability for the driver you changed. > > - If adding new public API features, consider whether to add a new >feature line item to the docs/source/support-matrix.ini if it is >likely users need to know about support status across drivers. > > - Against each line item feature, there is note about whether the >feature is considered mandatory to support in all drivers. The >current support matrix only lists 2 features as mandatory - start >and stop of instances. Everything else was left as optional on the >basis that at least one existing in-tree driver doesn't support >the feature. > >It is very important to note that this is a *tentative* list. The >decision about mandatory vs optional features is subject to change >as it has *not* undergone detailed critique by Nova core team at >this time. IOW, we might make more features mandatory to support >in the future. TBD. > > - There is clear scope for making the existing feature list more >fine grained. For example there are many different ways to configure >block storage for guests and only a few of them are captured in the >current support matrix. Likewise for networking, and many other >aspects of guest configuration. > > > Sean has added the support matrix as a discussion item for today's > Nova meeting, to evaluate what if any changes we need to make to it > in the near term to better capture the current thoughts of Nova team > about support status. > > https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting > > So either send questions in this thread or join the IRC meeting > > Regards, > Daniel > > [1] https://wiki.openstack.org/wiki/HypervisorSupportMatrix > -- > |: 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 Mai
Re: [openstack-dev] [nova] Hypervisor support matrix now in GIT
On Thu, Feb 5, 2015 at 10:22 AM, Matt Riedemann wrote: > > > On 2/5/2015 4:49 AM, Daniel P. Berrange wrote: > >> On Thu, Feb 05, 2015 at 11:40:46AM +0100, Andreas Jaeger wrote: >> >>> On 02/05/2015 11:31 AM, Daniel P. Berrange wrote: >>> >>>> This is a message to alert everyone to the fact that the old hypervisor >>>> support matrix on the wiki[1], should really be considered obsolete >>>> [...] >>>> >>> >>> In that case, I suggest to remove it's contents and just leave a pointer >>> to the new location, >>> >> >> See my point about it being the only place with info about the out of >> tree Docker & PowerKVM drivers. I want to give them time to setup a >> support matrix in their own GIT repo before removing the only source >> of info about them. >> >> I will be updating the wiki page to warn people about the new location >> though. >> >> Regards, >> Daniel >> >> > There might be some confusion on PowerKVM here, the pKVM support is in > tree in the libvirt driver, that's what the PowerKVM third party CI is > running against. > > The new as of last week PowerVM driver in stackforge [1] (and older > PowerVC driver in stackforge [2]) are different and shouldn't be in the > hypervisor support matrix wiki or the in-tree hypervisor support table. > > I can't wait for the day when there will be one power driver to rule them > all and Frodo will have to destroy it in Mount Doom to avoid confusion. > > The only thing I'd say about the pKVM support in the in-tree matrix is > what it's distro support is, i.e. if I have latest Fedora ppc64 will nova > libvirt/qemu work with it? How about Ubuntu? > > [1] http://git.openstack.org/cgit/stackforge/nova-powervm/ > [2] http://git.openstack.org/cgit/stackforge/powervc-driver/ > > -- > > Thanks, > > Matt Riedemann > > > ______ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > Thanks Matt, I'll include that in the patch. Kurt Taylor (krtaylor) __ OpenStack Development Mailing 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] Hypervisor support matrix now in GIT
On Thu, Feb 5, 2015 at 10:46 AM, Daniel P. Berrange wrote: > On Thu, Feb 05, 2015 at 10:24:24AM -0600, Kurt Taylor wrote: > > On Thu, Feb 5, 2015 at 4:31 AM, Daniel P. Berrange > > wrote: > > > > > Hi Team Nova, > > > > > > This is a message to alert everyone to the fact that the old hypervisor > > > support matrix on the wiki[1], should really be considered obsolete. > > > > > > The canonical location for it going forward will be > > > > > >http://docs.openstack.org/developer/nova/support-matrix.html > > > > > > That URL shows current GIT snapshot, releases will get their own URL > > > when the time comes. > > > > > > The source for this document is part of Nova GIT in the path > > > > > >doc/source/support-matrix.ini > > > > > > The docs are auto-generated from that ini file using a sphinx extension > > > > > >doc/ext/support_matrix.py > > > > > > The CSS styling is in > > > > > >doc/source/_static/support-matrix.css > > > > > > Some things to note here > > > > > > - The new doc was populated based on the contents of the old wiki page > > > from > > >about two months ago, so if there have been additions to the wiki in > > > that > > >time, they might not all have been captured - depends how good I > was at > > >figuring out changes. > > > > > > - Improvements to the content and/or HTML styling should obviously be > sent > > >as patches to Nova GIT in the files mentioned above, via normal > Gerrit > > >review practice. > > > > > > - Since it is in GIT, the support matrix is now able to record > information > > >per release branch of Nova. So users can be clear about what > features > > >their release of Nova supports, as opposed to playing guessing > games. > > > > > > - The in-tree document only covers features of the in-tree Nova > drivers. > > >As such it does not include information about Docker or PowerKVM or > > >the (now deleted) BareMetal drivers. My currently suggestion is that > > >people maintaining out of tree drivers, should reuse the sphinx > > > extension > > >to format their own support matrix ini file in their local GIT repo. > > > > > > > I think that maybe you have confused PowerKVM with PowerVM. The PowerVM > > driver was removed, but PowerKVM support is in tree with libvirt. > > Ok, so the wiki page was indeed referring to the libvirt impl. That wasn't > obvious since it didn't mention libvirt in the heading as all the other > libvirt columns did ! Sorry for not copying across your data then. > > Regards, > Daniel > No problem at all, here's the patch to add it: https://review.openstack.org/#/c/153342/ Kurt Taylor (krtaylor) __ OpenStack Development Mailing 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] [third-party][infra] Third-Party CI Operators: Let's use a common CI Solution!
Thanks Ramy! I'd suggest that we use the cross-project session I proposed [1] for Liberty summit as a working session primarily focused on this work [2]. [1] https://docs.google.com/spreadsheets/d/1vCTZBJKCMZ2xBhglnuK3ciKo3E8UMFo5S5lmIAYMCSE/edit?usp=sharing [2] https://etherpad.openstack.org/p/liberty-third-party-ci-working-group On Mon, Apr 20, 2015 at 8:40 AM, Jay Pipes wrote: > You rock, Ramy. Seriously, awesome work. > > -jay > > > On 04/20/2015 01:17 AM, Asselin, Ramy wrote: > >> All Third-Party CI operators: >> >> We’ve got 85 Third Party CI systems registered in the wiki[1], all of >> them running a variety of closed & open-source solutions. >> >> Instead of individually maintaining all those similar solutions, let’s >> join together and collectively maintain a single solution. >> >> If that sounds good to you, there’s an Infra-spec that’s been approved >> [2] to refactor much of what the Infrastructure team uses for the >> upstream “Jenkins” CI to be more easily reusable by many of us. >> >> We’ve got stories defined [3], and a few patches submitted. We’re using >> the gerrit-topic “downstream-puppet” [4]. >> >> For example, we’ve got the first part under review for the “Log Server”, >> which creates your own version of http://logs.openstack.org/ >> >> If anyone is interested in migrating towards a common solution, reply, >> or ping me IRC (asselin) on Freenode #openstack-infra, or join some of >> the third party ci meetings [5]. >> >> Thanks! >> >> Ramy >> >> [1] https://wiki.openstack.org/wiki/ThirdPartySystems >> >> [2] >> >> http://specs.openstack.org/openstack-infra/infra-specs/specs/openstackci.html >> >> [3] https://storyboard.openstack.org/#!/story/2000101 >> >> [4] https://review.openstack.org/#/q/topic:downstream-puppet,n,z >> >> [5] >> >> https://wiki.openstack.org/wiki/Meetings/ThirdParty#Weekly_Third_Party_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 > __ OpenStack Development Mailing 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] [third-party][infra] Third-Party CI Operators: Let's use a common CI Solution!
On Tue, Apr 21, 2015 at 12:14 PM, Lenny Verkhovsky wrote: > Hi Ramy, > > Will there be any discussions of this issue on the Vancouver Summit? > See previous email in this thread, I have proposed a cross-project session to discuss third party CI topics. > > > *Lenny Verkhovsky* > > SW Engineer, Mellanox Technologies > > > > *From:* Nikolay Fedotov (nfedotov) [mailto:nfedo...@cisco.com] > *Sent:* Tuesday, April 21, 2015 8:10 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [third-party][infra] Third-Party CI > Operators: Let's use a common CI Solution! > > > > Hello Ramy > > > > Take me in account J > > We used puppet modules located in system-config to install zuul and > nodepool. Also there were a lot manual configuration. > > Maybe someday there will be a “green button” to set it up in moment. > > > > Thanks! > > > > *From:* Asselin, Ramy [mailto:ramy.asse...@hp.com ] > *Sent:* Monday, April 20, 2015 8:17 AM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* [openstack-dev] [third-party][infra] Third-Party CI Operators: > Let's use a common CI Solution! > > > > All Third-Party CI operators: > > > > We’ve got 85 Third Party CI systems registered in the wiki[1], all of them > running a variety of closed & open-source solutions. > > Instead of individually maintaining all those similar solutions, let’s > join together and collectively maintain a single solution. > > > > If that sounds good to you, there’s an Infra-spec that’s been approved [2] > to refactor much of what the Infrastructure team uses for the upstream > “Jenkins” CI to be more easily reusable by many of us. > > > > We’ve got stories defined [3], and a few patches submitted. We’re using > the gerrit-topic “downstream-puppet” [4]. > > > > For example, we’ve got the first part under review for the “Log Server”, > which creates your own version of http://logs.openstack.org/ > > > > If anyone is interested in migrating towards a common solution, reply, or > ping me IRC (asselin) on Freenode #openstack-infra, or join some of the > third party ci meetings [5]. > > > > Thanks! > > Ramy > > > > [1] https://wiki.openstack.org/wiki/ThirdPartySystems > > [2] > http://specs.openstack.org/openstack-infra/infra-specs/specs/openstackci.html > > [3] https://storyboard.openstack.org/#!/story/2000101 > > [4] https://review.openstack.org/#/q/topic:downstream-puppet,n,z > > [5] > https://wiki.openstack.org/wiki/Meetings/ThirdParty#Weekly_Third_Party_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
[openstack-dev] [third-party] Announcing Third Party CI Tools Repo
Hi all, The third party CI working group[1] have been discussing a way to share tools, configurations, and plugins best practices. This was an idea that started at the Paris summit because teams that are operating external CI systems have each created tools that make their life as CI operators easier. Now we have a way to share them[2]. Since this new repo[3] is created, I am proposing the following CI operators as initial cores. They have consistently attended the working group meetings and pushed to move work items[4] forward in the community. Ramy Asselin (asselin) Patrick East (patrickeast) Steve Weston (sweston) Mikhail Medvedev (mmedvede) We will discuss at this weeks meeting[5], but if there are no objections, I will add them immediately following. If you are interested in sharing something you have written that makes your CI life easier, please come to a working group meeting and discuss, or just submit a patch. Thanks! Kurt Taylor (krtaylor) [1] https://wiki.openstack.org/wiki/ThirdPartyCIWorkingGroup [2] https://review.openstack.org/#/c/175520 [3] https://github.com/stackforge/third-party-ci-tools [4] https://wiki.openstack.org/wiki/ThirdPartyCIWorkingGroup#Development_Priorities [5] https://wiki.openstack.org/wiki/Meetings/ThirdParty#4.2F29.2F15_1500_UTC __ OpenStack Development Mailing 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] [kolla] Documentation restructure and refresh
At Queens PTG in Denver, we worked on getting the documentation refreshed, as well as incorporating the new format laid out by the documentation team. To get this started, I have pushed a WIP ToC patch(1) that incorporates all the points we discussed. Also, here is the start for the queens doc restructuring etherpad(2). There are links there for all the related work and the PTG topic discussion etherpad. I have also created a blueprint(3) for us to track work. Feel free to jump in on the etherpad, and please add your nic for work you want to do. This is the place for brainstorming/discussion points before deciding on work for the BP. I'll add an agenda topic to the weekly meeting to make sure this work moves along. Note: the list in the etherpad is not a complete work list, we need to break down the ToC into chapters and get volunteers to write or migrate/refresh that content. Thanks in advance to anyone that wants to help. Kurt Taylor (krtaylor) (1) https://review.openstack.org/#/c/504801 (2) https://etherpad.openstack.org/p/kolla-queens-doc-restructure (3) https://blueprints.launchpad.net/kolla/+spec/queens-doc-restructure __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ironic] About third-party CI
On Wed, Aug 10, 2016 at 8:21 AM, Jim Rollenhagen wrote: > Hi Ironicers, > > This email serves as a reminder (and a bit of a call to action) about our > third party CI policy: > http://specs.openstack.org/openstack/ironic-specs/specs/ > not-implemented/third-party-ci.html > > 1) When I went to find a link to the policy, I realized that it isn't in > our >developer docs, but only in our specs repo. Can someone volunteer to >document this in our dev docs? > This will be documented as a part of this patch: https://review.openstack.org/#/c/353102/ > > 2) A number of drivers do not have third-party CI up, let alone reporting >on patches. Unless someone moves quickly, I strongly suspect the > following >drivers will be dropped from our tree before the end of Newton. These > are >the setup.cfg names. > > agent_amt > pxe_amt > fake_amt > agent_iboot > pxe_iboot > fake_iboot > agent_wol > pxe_wol > fake_wol > agent_vbox > fake_vbox > pxe_vbox > pxe_seamicro > fake_seamicro > pxe_drac > fake_drac > pxe_snmp > fake_snmp > pxe_msftocs > fake_msftocs > >It's important to note that some ironic folks have taken the burden of >maintaining some untested drivers in an out-of-tree repo, however this >is not an official OpenStack project, and not part of the ironic > governance. >https://git.openstack.org/cgit/openstack/ironic-staging-drivers > > 3) The SSH drivers (pxe_ssh and agent_ssh) that we use for some testing >currently are planned to be dropped. First, we need to update >project-config to make sure all of those jobs are moved to an equivalent >*_ipmitool job, and drop the _ssh jobs. Then we can go ahead and remove >the drivers. I'd like a volunteer for this as well, but am happy to take >it on as needed. > > 4) The drivers that use pyghmi (pxe_ipminative and agent_pyghmi) currently > are >not tested in ironic's CI. We have multiple jobs for each of the > ipmitool >drivers. Instead of making new jobs, we could just move one of the > ipmitool >drivers to use the pyghmi drivers (since they both use IPMI, it should > be >simple to do so). As with above, I'm happy to do this if there are no >volunteers. > > Thanks for reading (and hopefully volunteering!). > > // jim > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ironic] Driver removal policies - should we make it softer?
In my opinion, we have to be careful about the "supported" label. Saying that third-party tested drivers are community supported implies a commitment that may have not been intended. Personally, I see no problem with leaving everything just as planned. Drivers that are in tree are either tested upstream in infra, or they are tested against the third-party requirements that we defined. We have communicated the plan to move drivers out of tree for more than a release. And, I am absolutely against shipping a driver that has not been tested, regardless of if it was previously in tree or not, regardless of the deprecation policy. Nova takes an even harder position on this by simply stating that if a driver is not tested in upstream infra, it is unsupported, regardless of where the driver lives or how good (or not) the third-party system testing it has done their job. kurt (krtaylor) On Mon, Aug 22, 2016 at 1:48 PM, Loo, Ruby wrote: > Hi, > > > > I admit, I didn't read the entire thread [0], but did read the summary > [1]. I like this, except that I'm not sure about #3. What's the rationale > of adding a new config option 'enable_unsupported_drivers' that defaults to > False. Versus not having it, and "just" logging a warning if they are > loading an unsupported (in-tree) driver? > > > > If I understand this... > > > > If we have 'enable_unsupported_drivers': since it defaults to False, the > conductor will fail on startup, if an unsupported driver is in the > enabled_drivers config. (The conductor will emit a warning in the logs, or > maybe it won't?) The operator (if they haven't changed it), will now change > it to True if they want to use any unsupported drivers. The conductor will > start up and emit a warning in the logs. > > > > If we don't have an enable_unsupported_drivers config, will the conductor > start up and emit a warning in the logs? > > > > I was also wondering, where is the value for the 'supported' flag for each > driver going to be kept? Hard-coded in the driver code? > > > > --ruby > > > > > > On 2016-08-19, 10:15 AM, "Jim Rollenhagen" wrote: > > > > Hi Ironickers, > > > > There was a big thread here[0] about Cinder, driver removal, and standard > > deprecation policy. If you haven't read through it yet, please do before > > continuing here. :) > > > > The outcome of that thread is summarized well here.[1] > > > > I know that I previously had a different opinion on this, but I think we > > should go roughly the same route, for the sake of the users. > > > > 1) A ``supported`` flag for each driver that is True if and only if the > driver > >is tested in infra or third-party CI (and meets our third party CI > >requirements). > > 2) If the supported flag is False for a driver, deprecation is implied (and > >a warning is emitted at load time). A driver may be removed per standard > >deprecation policies, with turning the supported flag False to start the > >clock. > > 3) Add a ``enable_unsupported_drivers`` config option that allows enabling > >drivers marked supported=False. If a driver is in enabled_drivers, has > >supported=False, and enable_unsupported_drivers=False, ironic-conductor > >will fail to start. Setting enable_unsupported_drivers=True will allow > >ironic-conductor to start with warnings emitted. > > > > It is important to note that (3) does still technically break the standard > > deprecation policy (old config may not work with new version of ironic). > > However, this is a much softer landing than the original plan. FWIW, I do > > expect (but not hope!) this part will be somewhat contentious. > > > > I'd like to hear thoughts and get consensus on this from the rest of the > > ironic community, so please do reply whether you agree or disagree. > > > > I'm happy to do the work required (update spec, code patches, doc updates) > > when we do come to agreement. > > > > // jim > > > > [0] http://lists.openstack.org/pipermail/openstack-dev/2016- > August/101428.html > > [1] http://lists.openstack.org/pipermail/openstack-dev/2016- > August/101898.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 > > __ OpenStack Development Mailing 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] [kolla] role change and introductions
My downstream responsibilities have shifted over the last few months and it probably comes as no surprise that I am not going to be able to be as involved in the kolla project, including being the doc liaison. I'm having to remove myself from that role and will also not be attending PTG. The Kolla team has made great strides in improving the documentation, keep it going! Second, there will be 2 others from my ppc64le team getting involved in Kolla, Mark Hamzy and Ed Leafe. Ed will be attending PTG and will try to get a chance to meet a few of you there. Kurt Taylor (krtaylor) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [ironic] Ironic-qa meeting canceled this week (Nov 23rd)
Hey everyone, due to projected low turnout for this weeks ironic-qa meeting, it will be canceled. I will update the wiki meeting page to reflect this. FYI, I brought up a proposal last week to merge this meeting back into the main Monday ironic meeting, and handle any work via sub team reports. Comments? Kurt Taylor (krtaylor) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
