You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by ASF IRC Services <as...@wilderness.apache.org> on 2013/06/12 19:55:36 UTC
Summary of IRC meeting in #cloudstack-meeting, Wed Jun 12 17:08:56 2013
Members present: Animesh, sudhap, dahn, topcloud, kelveny, chipc, ke4qqq, jzb
----------------
Meeting summary:
----------------
1. Preface
2. Active Feature Release: Overall Status
3. Active Feature Release QA Status
4. Active Feature Release: Doc Status
5. Active Feature Release: Additional Issues
6. Active Bug Fix Release: 4.1.1
7. Master Branch
8. Infra
9. Other topics?
IRC log follows:
# 1. Preface #
# 2. Active Feature Release: Overall Status #
17:09:36 [jzb]: what do we have on the 4.2.0 status?
17:09:43 [dahn]: chipc: thanks, will read it
17:09:56 [kelveny]: we are targeting to merge vmsync branch
17:09:56 [Animesh]: On 4.2 there are many open defects
17:10:04 [Animesh]: kelven go ahead
17:10:25 [kelveny]: code changes is targeted to complete by the end of this week
17:10:42 [kelveny]: after that official merge request will be sent to the list
17:11:06 [kelveny]: actually merge may happen at next week if no objections
17:11:26 [chipc]: kelveny: I'm curious about what testing is happening on that branch
17:11:44 [ke4qqq]: BVT at least?
17:11:51 [kelveny]: we will try to setup BVT test on the branch
17:12:16 [chipc]: that seems like a pre-requisite to merge, when I look at the complexity of the work
17:12:22 [chipc]: so +1 to that!
17:12:41 [kelveny]: most of infrastructure tests are already done through unit tests
17:13:18 [chipc]: sweet!
17:13:38 [kelveny]: but we do have refactoring changes in areas that is not possible for unit test, will rely on BVT for integration test
17:13:43 [chipc]: BTW - that's a really good FS... it made it possible to grok the changes
17:13:58 [chipc]: (or at least most of them)
17:15:13 [kelveny]: that's pretty much the update from my side
17:15:21 [jzb]: thanks kelveny
17:15:28 [jzb]: Animesh: did you have more?
17:15:56 [Animesh]: yes the defect resolution rate has been more than the incoming defects so looks like we are getting better
17:16:39 [Animesh]: but still we have large number of open defects, Sudha will also share test results to help everyone guage our readiness
17:17:37 [dahn]: newbee question about defects, please
17:17:58 [Animesh]: dahn: sure what's the question?
17:18:14 [dahn]: If i use an api in master, and it breaks after an update do I report a defect in jira ?
17:18:22 [dahn]: or talk to someone off line
17:18:27 [dahn]: or the list?
17:18:40 [Animesh]: filing a defect is best
17:18:53 [jzb]: dahn: is it an API that also works in a release?
17:19:11 [jzb]: I wouldn't necessarily say something's a defect if an API changes in master.
17:19:17 [jzb]: that isn't in a release.
17:19:35 [dahn]: jzb: I have to investigate. I think so
17:19:43 [dahn]: Animesh: does that mean jira?\
17:19:54 [jzb]: dahn: OK. then what Animesh said. :-)
17:19:59 [Animesh]: dahn: yes we use JIRA for defect tracking
17:20:00 [topcloud]: that should be a bug. comparing it to a previous release provides details to a bug.
17:20:21 [topcloud]: we shouldn't treat master different.
17:20:49 [dahn]: thanks, all
17:20:56 [dahn]: you will hear of me
17:22:13 [Animesh]: continuing on the release, I will encourage folks to check on 4.2 Release dashboard
17:22:44 [Animesh]: I will send out my weekly reminder today on status and include Sudha's test results
17:23:28 [topcloud]: one thing that concerns me is that the bvt continues to be at < 100% pass rate
17:23:41 [topcloud]: is there anything we're doing about this?
17:23:47 [Animesh]: After the feature freeze date 6/28 i will send out daily emails since we need focused activity to resolve and close our back log of defects
17:24:44 [Animesh]: topcloud: on bvt issues rayees and other have been filing defects that are triaged daily
17:25:20 [chipc]: topcloud: was BVT ever at 100% ?
17:25:32 [chipc]: (real question, not sarcasm)
17:25:44 [topcloud]: chipc: to my understanding, it was at one point >95%
17:26:17 [sudhap]: Yes - they were 100% before 4.1 but since then we never had 100%
17:26:41 [chipc]: once we get it back to 100%, I say we block all changes when it drops to <100%
17:26:49 [topcloud]: +1
17:26:56 [chipc]: anyway, that was a distraction from the 4.2.0 topic
17:26:59 [chipc]: (sort of)
17:27:25 [jzb]: anything else on 4.2.0 overall status?
17:27:37 [topcloud]: not really...I think bvt not being at 100% is a big part of why 4.1 was delayed.
17:27:42 [topcloud]: don't want to see it happen for 4.2.
17:28:07 [Animesh]: agreed bvt also shows progress towards release readines
17:28:07 [chipc]: topcloud: +1
17:28:32 [chipc]: Animesh: BVT should show that master is stable, regardless of release timeframes
17:28:33 [chipc]: IMO that is
17:28:44 [chipc]: master should only see good /tested code
17:28:56 [chipc]: but I'm repeating myself I think... so back to the corner for me!
17:28:57 [Animesh]: one more thing on my side was we had a GTM on object_store, john burwell took the action item to update the dev-list
17:29:23 [jzb]: OK
# 3. Active Feature Release QA Status #
17:29:59 [jzb]: do we need to touch on more w/r/t QA or have we hit on that already?
17:30:01 [jzb]: sudhap: ?
17:30:14 [sudhap]: I am preparing test plan execution summary
17:30:39 [sudhap]: will post it - which should show how much % of existing tests are being covered and feature wise quality status ( based on pass rates)
17:30:43 [sudhap]: will post it soon
17:30:56 [sudhap]: I have sent compatibility matrix for review
17:31:02 [sudhap]: pl do review
17:31:58 [dahn]: sudhap: this is regarding manual testing?
17:32:04 [sudhap]: Those are 2 topics and I guess automation has been covered already
17:32:17 [sudhap]: dahn: Yes
17:32:42 [sudhap]: Regression pass rates are very poor (for automation)
17:32:48 [sudhap]: working to get those also up
17:33:07 [sudhap]: jzb: I am done
17:33:38 [jzb]: groovy - anything else on QA, folks?
# 4. Active Feature Release: Doc Status #
17:34:34 [jzb]: we have a ton of unresolved bugs for docs in 4.2.0 right now
17:34:36 [jzb]: 90, in fact
17:34:59 [jzb]: only 17 are unassigned, though
17:35:31 [jzb]: I still need to start a thread on separating out the docs into their own repo.
17:35:37 [jzb]: mea culpa, have not started that yet.
17:35:43 [jzb]: anything else on docs?
17:36:16 [jzb]: OK
# 5. Active Feature Release: Additional Issues #
17:36:41 [jzb]: any additional issues we need to discuss on 4.2.0 that we haven't hit on yet? Otherwise I'll move on to the 4.1.1 stuff
# 6. Active Bug Fix Release: 4.1.1 #
17:37:53 [chipc]: ok, so serverchief noted that he's going to be limited for time for 4.1.1
17:37:57 [chipc]: so I'm taking it
17:38:30 [chipc]: I'm preparing all of the release version numbers and whatnot within the 4.1 branch now (updating from 4.1.0-SNAPSHOT to 4.1.1-SNAP, etc..)
17:38:41 [chipc]: probably wrap that up today or tomorrow
17:38:55 [jzb]: chipc: do you need any help with that?
17:39:14 [chipc]: if you feel like doing the /docs folder update?
17:39:26 [jzb]: ah, yes. Will do.
17:39:33 [chipc]: rock
17:39:58 [chipc]: we're going to kick out 4.1.1 rather quickly, just to get some critical ones knocked out... so limited regression testing is going to be required...
17:40:11 [chipc]: then I'll hand back off to Ilya for a 4.1.2
17:40:12 [chipc]: that's it!
17:40:30 [jzb]: sweet - thanks, chipc
17:40:42 [jzb]: anything else for 4.1.1 ?
# 7. Master Branch #
17:41:13 [jzb]: anything related to the master branch we need to discuss?
17:41:23 [chipc]: jzb: I suspect that we did that already with 4.2
17:41:28 [jzb]: yeah
17:41:30 [chipc]: since the release branch hasn't been cut
# 8. Infra #
17:41:52 [jzb]: any Infra topics we need to chat about today?
17:42:04 [chipc]: other than the fact that git's back ;-)
17:42:11 [jzb]: that *will* be helpful
17:42:14 [chipc]: ha
17:42:17 [chipc]: yes
17:42:23 [topcloud]: yea!
17:42:29 [dahn]: not for a stable master it won't
17:42:49 [dahn]: (not today that is)
17:43:07 [chipc]: dahn: ha
17:43:20 [chipc]: dahn: I like you already
17:43:21 [chipc]: ;-)
17:43:23 [dahn]: sorry for the sarcasm
17:43:27 [topcloud]: sorry...to bring back this topic but is bvt running on apache infra?
17:43:35 [chipc]: no
17:43:57 [topcloud]: chipc: is there any talk about bringing it into apache infra?
17:44:09 [dahn]: jzb: we all have our faults
17:44:17 [topcloud]: i can't imagine apache wanting bvt to only run inside citrix all the time.
17:44:28 [chipc]: topcloud: not that I'm aware of... but there has been some chatter about breaking more stuff back out of the overloaded asf build infra
17:44:59 [chipc]: topcloud: the problem is that they aren't setup for that type of thing
17:45:05 [chipc]: and by apache, you mean us in this case
17:45:18 [chipc]: the project is free to use what we need to get on with our business in many respects
17:45:29 [topcloud]: chipc: yes. i mean us as oppose to having it housed in citrix.
17:46:15 [chipc]: topcloud: we would have to ask for some improved build infra... Perhaps we start a thread to discuss that. Or have someone broach the question on builds@a.o
17:46:27 [chipc]: but generally, the ASF build infra is a bit overloaded
17:46:51 [jzb]: topcloud: when you say "in Citrix" - it's still visible outside Citrix, yes?
17:46:52 [chipc]: so frankly, CTXS donating an environment to run it, publicly visible to everyone, is quite helpful
17:46:58 [chipc]: jzb: it is
17:47:18 [chipc]: actually, I think it is...
17:47:34 [topcloud]: jzb: yeah it's still visible but it really should be runnable by everyone.
17:47:37 [jzb]: I'm all for building up Apache infra, but I also think having vendors donate publicly visible resources that are usable by the community is acceptable.
17:47:53 [jzb]: in fact, we probably ought to be hitting up some of our ISP friends for more.
17:47:55 [topcloud]: jzb: right now i think only citrix folks can run it. i appreciate it but we shouldn't rely on it.
17:48:27 [jzb]: topcloud: hrm. Yeah, that's non-optimal, then.
17:48:33 [topcloud]: jzb: to me donating has to mean community can have control of it.
17:48:44 [jzb]: topcloud: agreed
17:48:53 [chipc]: topcloud: so then the question is, what are the hardware requirements... and we can work from there
17:49:28 [chipc]: topcloud: and if we have that, we can start fishing for infra
17:49:49 [ke4qqq]: so tsp (along with abayer and roman) are working on a publicly accessible jenkins instance in fremont
17:49:59 [chipc]: rock
17:49:59 [chipc]: ok
17:50:17 [chipc]: builds.a.o 2.0
17:50:19 [chipc]: ;-)
17:50:47 [jzb]: anything else on Infra?
17:51:27 [topcloud]: let's take this to the list. i don't think we can actually resolve it here.
17:51:33 [ke4qqq]: we can't
17:51:47 [ke4qqq]: so good idea to take to the list
# 9. Other topics? #
17:54:04 [jzb]: Any other topics we should discuss this week?
17:54:21 [chipc]: not from me
17:55:17 [jzb]: thanks folks. Same time next week!
17:55:23 [jzb]: ASFBot: meeting end
Re: Summary of IRC meeting in #cloudstack-meeting, Wed Jun 12
17:08:56 2013
Posted by Prasanna Santhanam <ts...@apache.org>.
On Fri, Jun 14, 2013 at 11:24:11AM +0100, Noah Slater wrote:
> While we're talking about bot etiquette... ;) If people used #info and
> #action, important takeaway points would be included at the top of the
> email. As it is, it's a bit hard to read through the logs if you just want
> to get a jist.
Yeah - we usually use them but looks like it was missed this time.
Took some time to glean out the important bits from this meeting.
--
Prasanna.,
------------------------
Powered by BigRock.com
Re: Summary of IRC meeting in #cloudstack-meeting, Wed Jun 12
17:08:56 2013
Posted by Noah Slater <ns...@apache.org>.
While we're talking about bot etiquette... ;) If people used #info and
#action, important takeaway points would be included at the top of the
email. As it is, it's a bit hard to read through the logs if you just want
to get a jist.
On 13 June 2013 15:56, Joe Brockmeier <jz...@zonker.net> wrote:
> On Thu, Jun 13, 2013, at 04:48 AM, Daan Hoogland wrote:
> > Reading the meeting summary, I learned about the [off] directive the hard
> > way. Is there a irc-etiquette for dummies somewhere that handles ASFBot
> > and other things newbees should know?
>
> There's a manual for ASFBot here:
>
> http://wilderness.apache.org/manual.html
>
> Best,
>
> jzb
> --
> Joe Brockmeier
> jzb@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/
>
--
NS
Re: Summary of IRC meeting in #cloudstack-meeting,
Wed Jun 12 17:08:56 2013
Posted by Joe Brockmeier <jz...@zonker.net>.
On Thu, Jun 13, 2013, at 04:48 AM, Daan Hoogland wrote:
> Reading the meeting summary, I learned about the [off] directive the hard
> way. Is there a irc-etiquette for dummies somewhere that handles ASFBot
> and other things newbees should know?
There's a manual for ASFBot here:
http://wilderness.apache.org/manual.html
Best,
jzb
--
Joe Brockmeier
jzb@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/
Re: Summary of IRC meeting in #cloudstack-meeting, Wed Jun 12
17:08:56 2013
Posted by Daan Hoogland <da...@gmail.com>.
Reading the meeting summary, I learned about the [off] directive the hard
way. Is there a irc-etiquette for dummies somewhere that handles ASFBot and
other things newbees should know?
On Wed, Jun 12, 2013 at 7:55 PM, ASF IRC Services <
asfbot@wilderness.apache.org> wrote:
> Members present: Animesh, sudhap, dahn, topcloud, kelveny, chipc, ke4qqq,
> jzb
>
> ----------------
> Meeting summary:
> ----------------
>
> 1. Preface
>
> 2. Active Feature Release: Overall Status
>
> 3. Active Feature Release QA Status
>
> 4. Active Feature Release: Doc Status
>
> 5. Active Feature Release: Additional Issues
>
> 6. Active Bug Fix Release: 4.1.1
>
> 7. Master Branch
>
> 8. Infra
>
> 9. Other topics?
>
> IRC log follows:
>
>
> # 1. Preface #
>
>
> # 2. Active Feature Release: Overall Status #
> 17:09:36 [jzb]: what do we have on the 4.2.0 status?
> 17:09:43 [dahn]: chipc: thanks, will read it
> 17:09:56 [kelveny]: we are targeting to merge vmsync branch
> 17:09:56 [Animesh]: On 4.2 there are many open defects
> 17:10:04 [Animesh]: kelven go ahead
> 17:10:25 [kelveny]: code changes is targeted to complete by the end of
> this week
> 17:10:42 [kelveny]: after that official merge request will be sent to the
> list
> 17:11:06 [kelveny]: actually merge may happen at next week if no objections
> 17:11:26 [chipc]: kelveny: I'm curious about what testing is happening on
> that branch
> 17:11:44 [ke4qqq]: BVT at least?
> 17:11:51 [kelveny]: we will try to setup BVT test on the branch
> 17:12:16 [chipc]: that seems like a pre-requisite to merge, when I look at
> the complexity of the work
> 17:12:22 [chipc]: so +1 to that!
> 17:12:41 [kelveny]: most of infrastructure tests are already done through
> unit tests
> 17:13:18 [chipc]: sweet!
> 17:13:38 [kelveny]: but we do have refactoring changes in areas that is
> not possible for unit test, will rely on BVT for integration test
> 17:13:43 [chipc]: BTW - that's a really good FS... it made it possible to
> grok the changes
> 17:13:58 [chipc]: (or at least most of them)
> 17:15:13 [kelveny]: that's pretty much the update from my side
> 17:15:21 [jzb]: thanks kelveny
> 17:15:28 [jzb]: Animesh: did you have more?
> 17:15:56 [Animesh]: yes the defect resolution rate has been more than the
> incoming defects so looks like we are getting better
> 17:16:39 [Animesh]: but still we have large number of open defects, Sudha
> will also share test results to help everyone guage our readiness
> 17:17:37 [dahn]: newbee question about defects, please
> 17:17:58 [Animesh]: dahn: sure what's the question?
> 17:18:14 [dahn]: If i use an api in master, and it breaks after an update
> do I report a defect in jira ?
> 17:18:22 [dahn]: or talk to someone off line
> 17:18:27 [dahn]: or the list?
> 17:18:40 [Animesh]: filing a defect is best
> 17:18:53 [jzb]: dahn: is it an API that also works in a release?
> 17:19:11 [jzb]: I wouldn't necessarily say something's a defect if an API
> changes in master.
> 17:19:17 [jzb]: that isn't in a release.
> 17:19:35 [dahn]: jzb: I have to investigate. I think so
> 17:19:43 [dahn]: Animesh: does that mean jira?\
> 17:19:54 [jzb]: dahn: OK. then what Animesh said. :-)
> 17:19:59 [Animesh]: dahn: yes we use JIRA for defect tracking
> 17:20:00 [topcloud]: that should be a bug. comparing it to a previous
> release provides details to a bug.
> 17:20:21 [topcloud]: we shouldn't treat master different.
> 17:20:49 [dahn]: thanks, all
> 17:20:56 [dahn]: you will hear of me
> 17:22:13 [Animesh]: continuing on the release, I will encourage folks to
> check on 4.2 Release dashboard
> 17:22:44 [Animesh]: I will send out my weekly reminder today on status and
> include Sudha's test results
> 17:23:28 [topcloud]: one thing that concerns me is that the bvt continues
> to be at < 100% pass rate
> 17:23:41 [topcloud]: is there anything we're doing about this?
> 17:23:47 [Animesh]: After the feature freeze date 6/28 i will send out
> daily emails since we need focused activity to resolve and close our back
> log of defects
> 17:24:44 [Animesh]: topcloud: on bvt issues rayees and other have been
> filing defects that are triaged daily
> 17:25:20 [chipc]: topcloud: was BVT ever at 100% ?
> 17:25:32 [chipc]: (real question, not sarcasm)
> 17:25:44 [topcloud]: chipc: to my understanding, it was at one point >95%
> 17:26:17 [sudhap]: Yes - they were 100% before 4.1 but since then we never
> had 100%
> 17:26:41 [chipc]: once we get it back to 100%, I say we block all changes
> when it drops to <100%
> 17:26:49 [topcloud]: +1
> 17:26:56 [chipc]: anyway, that was a distraction from the 4.2.0 topic
> 17:26:59 [chipc]: (sort of)
> 17:27:25 [jzb]: anything else on 4.2.0 overall status?
> 17:27:37 [topcloud]: not really...I think bvt not being at 100% is a big
> part of why 4.1 was delayed.
> 17:27:42 [topcloud]: don't want to see it happen for 4.2.
> 17:28:07 [Animesh]: agreed bvt also shows progress towards release readines
> 17:28:07 [chipc]: topcloud: +1
> 17:28:32 [chipc]: Animesh: BVT should show that master is stable,
> regardless of release timeframes
> 17:28:33 [chipc]: IMO that is
> 17:28:44 [chipc]: master should only see good /tested code
> 17:28:56 [chipc]: but I'm repeating myself I think... so back to the
> corner for me!
> 17:28:57 [Animesh]: one more thing on my side was we had a GTM on
> object_store, john burwell took the action item to update the dev-list
> 17:29:23 [jzb]: OK
>
>
> # 3. Active Feature Release QA Status #
> 17:29:59 [jzb]: do we need to touch on more w/r/t QA or have we hit on
> that already?
> 17:30:01 [jzb]: sudhap: ?
> 17:30:14 [sudhap]: I am preparing test plan execution summary
> 17:30:39 [sudhap]: will post it - which should show how much % of existing
> tests are being covered and feature wise quality status ( based on pass
> rates)
> 17:30:43 [sudhap]: will post it soon
> 17:30:56 [sudhap]: I have sent compatibility matrix for review
> 17:31:02 [sudhap]: pl do review
> 17:31:58 [dahn]: sudhap: this is regarding manual testing?
> 17:32:04 [sudhap]: Those are 2 topics and I guess automation has been
> covered already
> 17:32:17 [sudhap]: dahn: Yes
> 17:32:42 [sudhap]: Regression pass rates are very poor (for automation)
> 17:32:48 [sudhap]: working to get those also up
> 17:33:07 [sudhap]: jzb: I am done
> 17:33:38 [jzb]: groovy - anything else on QA, folks?
>
>
> # 4. Active Feature Release: Doc Status #
> 17:34:34 [jzb]: we have a ton of unresolved bugs for docs in 4.2.0 right
> now
> 17:34:36 [jzb]: 90, in fact
> 17:34:59 [jzb]: only 17 are unassigned, though
> 17:35:31 [jzb]: I still need to start a thread on separating out the docs
> into their own repo.
> 17:35:37 [jzb]: mea culpa, have not started that yet.
> 17:35:43 [jzb]: anything else on docs?
> 17:36:16 [jzb]: OK
>
>
> # 5. Active Feature Release: Additional Issues #
> 17:36:41 [jzb]: any additional issues we need to discuss on 4.2.0 that we
> haven't hit on yet? Otherwise I'll move on to the 4.1.1 stuff
>
>
> # 6. Active Bug Fix Release: 4.1.1 #
> 17:37:53 [chipc]: ok, so serverchief noted that he's going to be limited
> for time for 4.1.1
> 17:37:57 [chipc]: so I'm taking it
> 17:38:30 [chipc]: I'm preparing all of the release version numbers and
> whatnot within the 4.1 branch now (updating from 4.1.0-SNAPSHOT to
> 4.1.1-SNAP, etc..)
> 17:38:41 [chipc]: probably wrap that up today or tomorrow
> 17:38:55 [jzb]: chipc: do you need any help with that?
> 17:39:14 [chipc]: if you feel like doing the /docs folder update?
> 17:39:26 [jzb]: ah, yes. Will do.
> 17:39:33 [chipc]: rock
> 17:39:58 [chipc]: we're going to kick out 4.1.1 rather quickly, just to
> get some critical ones knocked out... so limited regression testing is
> going to be required...
> 17:40:11 [chipc]: then I'll hand back off to Ilya for a 4.1.2
> 17:40:12 [chipc]: that's it!
> 17:40:30 [jzb]: sweet - thanks, chipc
> 17:40:42 [jzb]: anything else for 4.1.1 ?
>
>
> # 7. Master Branch #
> 17:41:13 [jzb]: anything related to the master branch we need to discuss?
> 17:41:23 [chipc]: jzb: I suspect that we did that already with 4.2
> 17:41:28 [jzb]: yeah
> 17:41:30 [chipc]: since the release branch hasn't been cut
>
>
> # 8. Infra #
> 17:41:52 [jzb]: any Infra topics we need to chat about today?
> 17:42:04 [chipc]: other than the fact that git's back ;-)
> 17:42:11 [jzb]: that *will* be helpful
> 17:42:14 [chipc]: ha
> 17:42:17 [chipc]: yes
> 17:42:23 [topcloud]: yea!
> 17:42:29 [dahn]: not for a stable master it won't
> 17:42:49 [dahn]: (not today that is)
> 17:43:07 [chipc]: dahn: ha
> 17:43:20 [chipc]: dahn: I like you already
> 17:43:21 [chipc]: ;-)
> 17:43:23 [dahn]: sorry for the sarcasm
> 17:43:27 [topcloud]: sorry...to bring back this topic but is bvt running
> on apache infra?
> 17:43:35 [chipc]: no
> 17:43:57 [topcloud]: chipc: is there any talk about bringing it into
> apache infra?
> 17:44:09 [dahn]: jzb: we all have our faults
> 17:44:17 [topcloud]: i can't imagine apache wanting bvt to only run inside
> citrix all the time.
> 17:44:28 [chipc]: topcloud: not that I'm aware of... but there has been
> some chatter about breaking more stuff back out of the overloaded asf build
> infra
> 17:44:59 [chipc]: topcloud: the problem is that they aren't setup for that
> type of thing
> 17:45:05 [chipc]: and by apache, you mean us in this case
> 17:45:18 [chipc]: the project is free to use what we need to get on with
> our business in many respects
> 17:45:29 [topcloud]: chipc: yes. i mean us as oppose to having it housed
> in citrix.
> 17:46:15 [chipc]: topcloud: we would have to ask for some improved build
> infra... Perhaps we start a thread to discuss that. Or have someone
> broach the question on builds@a.o
> 17:46:27 [chipc]: but generally, the ASF build infra is a bit overloaded
> 17:46:51 [jzb]: topcloud: when you say "in Citrix" - it's still visible
> outside Citrix, yes?
> 17:46:52 [chipc]: so frankly, CTXS donating an environment to run it,
> publicly visible to everyone, is quite helpful
> 17:46:58 [chipc]: jzb: it is
> 17:47:18 [chipc]: actually, I think it is...
> 17:47:34 [topcloud]: jzb: yeah it's still visible but it really should be
> runnable by everyone.
> 17:47:37 [jzb]: I'm all for building up Apache infra, but I also think
> having vendors donate publicly visible resources that are usable by the
> community is acceptable.
> 17:47:53 [jzb]: in fact, we probably ought to be hitting up some of our
> ISP friends for more.
> 17:47:55 [topcloud]: jzb: right now i think only citrix folks can run it.
> i appreciate it but we shouldn't rely on it.
> 17:48:27 [jzb]: topcloud: hrm. Yeah, that's non-optimal, then.
> 17:48:33 [topcloud]: jzb: to me donating has to mean community can have
> control of it.
> 17:48:44 [jzb]: topcloud: agreed
> 17:48:53 [chipc]: topcloud: so then the question is, what are the hardware
> requirements... and we can work from there
> 17:49:28 [chipc]: topcloud: and if we have that, we can start fishing for
> infra
> 17:49:49 [ke4qqq]: so tsp (along with abayer and roman) are working on a
> publicly accessible jenkins instance in fremont
> 17:49:59 [chipc]: rock
> 17:49:59 [chipc]: ok
> 17:50:17 [chipc]: builds.a.o 2.0
> 17:50:19 [chipc]: ;-)
> 17:50:47 [jzb]: anything else on Infra?
> 17:51:27 [topcloud]: let's take this to the list. i don't think we can
> actually resolve it here.
> 17:51:33 [ke4qqq]: we can't
> 17:51:47 [ke4qqq]: so good idea to take to the list
>
>
> # 9. Other topics? #
> 17:54:04 [jzb]: Any other topics we should discuss this week?
> 17:54:21 [chipc]: not from me
> 17:55:17 [jzb]: thanks folks. Same time next week!
> 17:55:23 [jzb]: ASFBot: meeting end
>
>
RE: Infra Issues from the IRC meeting (Wed, Jun 12)
Posted by Sudha Ponnaganti <su...@citrix.com>.
Daily automated email with BVT test results would be helpful.
-----Original Message-----
From: Prasanna Santhanam [mailto:tsp@apache.org]
Sent: Friday, June 14, 2013 10:43 PM
To: dev@cloudstack.apache.org
Subject: Infra Issues from the IRC meeting (Wed, Jun 12)
Saw a few infra topics being discussed in the meeting and there was talk of bringing it to the list so I'm taking this opportunity to explain some things behind it.
> 17:22:44 [Animesh]: I will send out my weekly reminder today on status
> and include Sudha's test results
> 17:23:28 [topcloud]: one thing that concerns me is that the bvt
> continues to be at < 100% pass rate
> 17:23:41 [topcloud]: is there anything we're doing about this?
yes - I've fixed most tests. Some have existed because of bugs in packaging, systemvm templates that I see patches for now.
> 17:25:20 [chipc]: topcloud: was BVT ever at 100% ?
> 17:25:32 [chipc]: (real question, not sarcasm)
It was - 100% - when the project was first proposed. But more tests have come in since then.
> 17:26:41 [chipc]: once we get it back to 100%, I say we block all
> changes when it drops to <100%
> 17:26:49 [topcloud]: +1
+1 - this is what I've been driving towards but haven't announced some
changes I've made in the past weeks because it's pointless to have tests fail soon as I announce we are 100%. We shouldn't wait for one run, but at least 10 to ensure that the bvt is indeed stable enough to be trusted as a 'gating' system for master stability.
There's also a couple of issues here -
1. Does everyone know where the tests run?
2. Do people know how to spot the failures?
3. Do people know how to find the logs for the failures?
If the answer is no to all this, I have more documentation on my hands.
> 17:28:07 [Animesh]: agreed bvt also shows progress towards release
> readines
> 17:28:07 [chipc]: topcloud: +1
> 17:28:32 [chipc]: Animesh: BVT should show that master is stable,
> regardless of release timeframes
> 17:28:33 [chipc]: IMO that is
> 17:28:44 [chipc]: master should only see good /tested code
Which is why the BVT runs on master at all times on jenkins.buildacloud.org. There is also ability to run it against a feature branch but I would rather defer that to the release manager for now since it's tied with hardware resources and jenkins schedules.
That feature should strictly be reserved for architecture changes in MERGE requests.
> 17:43:27 [topcloud]: sorry...to bring back this topic but is bvt running on apache infra?
> 17:43:35 [chipc]: no
> 17:43:57 [topcloud]: chipc: is there any talk about bringing it into apache infra?
It was brought up with the ASF infra back in January and the suggestion was to donate hardware to the ASF to manage. So if we're prepared to do that, great! But it certainly can't just be Citrix :)
I'd prefer individual project related test hardware and resources to stay in the control of the project. Infrastructure is constantly changed to allow features and enhancements to be tested so it's best to have it in the core group. Which is why jenkins.buildacloud.org came to existence. This is similar to how cloudbees operates or
(*gasp*) openstack-infra [1][2] operates.
Ideally, I'd like those interested in infra activities to form a separate group for cloudstack-infra related topics. The group's focus will be to maintain, test and add to the infrastructure of this project. But that's in the future. Without such a group, building an IaaS cloud is not much fun :)
> 17:44:17 [topcloud]: i can't imagine apache wanting bvt to only run inside citrix all the time.
It doesn't run within Citrix. It runs in a DC in Fremont. There are other environments within Citrix however that run their own tests for their needs - eg: object_store tests, cloudplatform tests, customer related issue tests etc.
/me beginning to think more doc work is on my way :/
> 17:46:27 [chipc]: but generally, the ASF build infra is a bit
> overloaded
+1000
> 17:46:51 [jzb]: topcloud: when you say "in Citrix" - it's still visible outside Citrix, yes?
> 17:46:52 [chipc]: so frankly, CTXS donating an environment to run it,
> publicly visible to everyone, is quite helpful
> 17:46:58 [chipc]: jzb: it is
We need more people to donate hardware/virtual resources for testing :) CTXS has been gracious to provide quite a few resources already IMO.
> 17:47:18 [chipc]: actually, I think it is...
> 17:47:34 [topcloud]: jzb: yeah it's still visible but it really should be runnable by everyone.
Not quite. It's a gating system. It runs automatically and shouldn't be runnable by everyone at will. I'm still waiting to implement devcloud tests based on that gerrit converstaion (which went nowhere) we had many months back. DevCloud stuff can be run at will.
> 17:47:37 [jzb]: I'm all for building up Apache infra, but I also think
> having vendors donate publicly visible resources that are usable by
> the community is acceptable.
+1
> 17:47:53 [jzb]: in fact, we probably ought to be hitting up some of
> our ISP friends for more.
+1 - who are our ISP friends? Would like to get help on this.
> 17:49:49 [ke4qqq]: so tsp (along with abayer and roman) are working on
> a publicly accessible jenkins instance in fremont
This is basically to dogfood all instances via a hosted puppetmaster.
I've just started so will take time to finish this.
Thoughts are most welcome!
[1] https://jenkins.openstack.org/
[2] http://ci.openstack.org/
--
Prasanna.,
------------------------
Powered by BigRock.com
Re: Infra Issues from the IRC meeting (Wed, Jun 12)
Posted by Prasanna Santhanam <ts...@apache.org>.
On Sat, Jun 15, 2013 at 01:48:57PM -0400, Chip Childers wrote:
> > There's also a couple of issues here -
> > 1. Does everyone know where the tests run?
> Nope
> > 2. Do people know how to spot the failures?
> Nope
> > 3. Do people know how to find the logs for the failures?
> Nope
> >
> > If the answer is no to all this, I have more documentation on my
> > hands.
I'll have the documentation draft up soon. Thanks for pointing this
out. All the logs show up under the test-matrix(-extended) job on the
cloudstack-qa view. You can drill down from the "Test Result" shown by
jenkins to see the stacktrace of the failure. For the management
server log, it's a little hidden - it goes under the profile
(hypervisor, ms-distro). For now I'm pulling in management server
logs. Will expose the kvm agent debug logs too.
> > Ideally, I'd like those interested in infra activities to form a
> > separate group for cloudstack-infra related topics. The group's focus
> > will be to maintain, test and add to the infrastructure of this
> > project. But that's in the future. Without such a group, building an
> > IaaS cloud is not much fun :)
>
> +1 - and at least for now, perhaps we start getting more organized
> around this via dev@cs.a.o using [INFRA] tags.
Will start using the tag as a start.
>
> Some thoughts I have are: I know that some stuff is being put to use for
> the project in Fremont, but I don't know what it is. I also don't
> know what hardware donations might be helpful for the environment, so
> that perhaps I could help find something.
>
Since every $company deploys cloudstack a different way, ideally the
environment should be a small mirror of what is used in production by
$company. That environment can be behind a firewall. What is required
is a jenkins slave that can be either hooked in through jnlp or SSH to
the jenkins.buildacloud.org instance. It will be labelled as a test
slave there and when we need to run tests, we can utilize it for
running tests. The auth keys can be shared among those interested to
work towards maintaining that infra.
> In all seriousness, if there is a need, I could take up the question at
> $dayjob to provide some testing resources within one of our labs as
> well. I actually think this would be easier to do then a "donation" of
> hardware that's not really a "donation" to the ASF. The question is:
> *what's needed* that we don't have already?
>
Right - donations are (IIUC) only reqd if the ASF infra is going to
manage this. But if there's a group of people within the project
managing this infra and not have it flout any infra rules we're good
to go and get started independantly on this.
We have a single dedicated enviornment that I cycle through deployment
styles that are oft used within Citrix. But obviously others are using
it differently. With perhaps RBD /Ceph, Object stores, OVS, Nicira,
etc. These are not tested.
For specifics on setup and internal resources like - NFS, code
repositories, images repositories, pypi mirrors/caches, log gathering
etc - we can start a separate thread if there is interest.
> >
> > > 17:44:17 [topcloud]: i can't imagine apache wanting bvt to only run inside citrix all the time.
> > It doesn't run within Citrix. It runs in a DC in Fremont. There are
> > other environments within Citrix however that run their own tests for
> > their needs - eg: object_store tests, cloudplatform tests, customer
> > related issue tests etc.
> >
> > /me beginning to think more doc work is on my way :/
>
> Well, really, the key is for us to all know about which infra is being
> shared for the use of the project. Stuff that's inside a corp that we
> can't all see isn't worth documenting for the project itself.
>
But it should be if the infra is exposing all troubleshooting tools,
logs to fix cloudstack bugs. If it's running custom builds etc, then I
agree it would not be of much use.
--
Prasanna.,
------------------------
Powered by BigRock.com
Re: Infra Issues from the IRC meeting (Wed, Jun 12)
Posted by Chip Childers <ch...@sungard.com>.
On Sat, Jun 15, 2013 at 11:12:37AM +0530, Prasanna Santhanam wrote:
> Saw a few infra topics being discussed in the meeting and there was
> talk of bringing it to the list so I'm taking this opportunity to
> explain some things behind it.
>
> > 17:22:44 [Animesh]: I will send out my weekly reminder today on status and include Sudha's test results
> > 17:23:28 [topcloud]: one thing that concerns me is that the bvt continues to be at < 100% pass rate
> > 17:23:41 [topcloud]: is there anything we're doing about this?
> yes - I've fixed most tests. Some have existed because of bugs in
> packaging, systemvm templates that I see patches for now.
>
> > 17:25:20 [chipc]: topcloud: was BVT ever at 100% ?
> > 17:25:32 [chipc]: (real question, not sarcasm)
> It was - 100% - when the project was first proposed. But more tests
> have come in since then.
>
> > 17:26:41 [chipc]: once we get it back to 100%, I say we block all changes when it drops to <100%
> > 17:26:49 [topcloud]: +1
> +1 - this is what I've been driving towards but haven't announced some
> changes I've made in the past weeks because it's pointless to have
> tests fail soon as I announce we are 100%. We shouldn't wait for one
> run, but at least 10 to ensure that the bvt is indeed stable enough to
> be trusted as a 'gating' system for master stability.
+1 - that makes sense
>
> There's also a couple of issues here -
> 1. Does everyone know where the tests run?
Nope
> 2. Do people know how to spot the failures?
Nope
> 3. Do people know how to find the logs for the failures?
Nope
>
> If the answer is no to all this, I have more documentation on my
> hands.
Well, perhaps I just haven't looked either! I see some results when I
search for BVT on the wiki (
https://cwiki.apache.org/confluence/dosearchsite.action?where=CLOUDSTACK&spaceSearch=true&queryString=BVT
), but they don't obviously tell me where to look.
>
> > 17:28:07 [Animesh]: agreed bvt also shows progress towards release readines
> > 17:28:07 [chipc]: topcloud: +1
> > 17:28:32 [chipc]: Animesh: BVT should show that master is stable, regardless of release timeframes
> > 17:28:33 [chipc]: IMO that is
> > 17:28:44 [chipc]: master should only see good /tested code
> Which is why the BVT runs on master at all times on
> jenkins.buildacloud.org. There is also ability to run it against a
> feature branch but I would rather defer that to the release manager
> for now since it's tied with hardware resources and jenkins schedules.
> That feature should strictly be reserved for architecture changes in
> MERGE requests.
>
> > 17:43:27 [topcloud]: sorry...to bring back this topic but is bvt running on apache infra?
> > 17:43:35 [chipc]: no
> > 17:43:57 [topcloud]: chipc: is there any talk about bringing it into apache infra?
> It was brought up with the ASF infra back in January and the
> suggestion was to donate hardware to the ASF to manage. So if we're
> prepared to do that, great! But it certainly can't just be Citrix :)
>
> I'd prefer individual project related test hardware and resources
> to stay in the control of the project. Infrastructure is constantly
> changed to allow features and enhancements to be tested so it's best
> to have it in the core group. Which is why jenkins.buildacloud.org
> came to existence. This is similar to how cloudbees operates or
> (*gasp*) openstack-infra [1][2] operates.
>
> Ideally, I'd like those interested in infra activities to form a
> separate group for cloudstack-infra related topics. The group's focus
> will be to maintain, test and add to the infrastructure of this
> project. But that's in the future. Without such a group, building an
> IaaS cloud is not much fun :)
+1 - and at least for now, perhaps we start getting more organized
around this via dev@cs.a.o using [INFRA] tags.
Some thoughts I have are: I know that some stuff is being put to use for
the project in Fremont, but I don't know what it is. I also don't
know what hardware donations might be helpful for the environment, so
that perhaps I could help find something.
In all seriousness, if there is a need, I could take up the question at
$dayjob to provide some testing resources within one of our labs as
well. I actually think this would be easier to do then a "donation" of
hardware that's not really a "donation" to the ASF. The question is:
*what's needed* that we don't have already?
>
> > 17:44:17 [topcloud]: i can't imagine apache wanting bvt to only run inside citrix all the time.
> It doesn't run within Citrix. It runs in a DC in Fremont. There are
> other environments within Citrix however that run their own tests for
> their needs - eg: object_store tests, cloudplatform tests, customer
> related issue tests etc.
>
> /me beginning to think more doc work is on my way :/
Well, really, the key is for us to all know about which infra is being
shared for the use of the project. Stuff that's inside a corp that we
can't all see isn't worth documenting for the project itself.
>
> > 17:46:27 [chipc]: but generally, the ASF build infra is a bit overloaded
> +1000
>
> > 17:46:51 [jzb]: topcloud: when you say "in Citrix" - it's still visible outside Citrix, yes?
> > 17:46:52 [chipc]: so frankly, CTXS donating an environment to run it, publicly visible to everyone, is quite helpful
> > 17:46:58 [chipc]: jzb: it is
> We need more people to donate hardware/virtual resources for testing :)
> CTXS has been gracious to provide quite a few resources already IMO.
>
> > 17:47:18 [chipc]: actually, I think it is...
> > 17:47:34 [topcloud]: jzb: yeah it's still visible but it really should be runnable by everyone.
> Not quite. It's a gating system. It runs automatically and shouldn't
> be runnable by everyone at will. I'm still waiting to implement
> devcloud tests based on that gerrit converstaion (which went nowhere)
> we had many months back. DevCloud stuff can be run at will.
>
> > 17:47:37 [jzb]: I'm all for building up Apache infra, but I also
> > think having vendors donate publicly visible resources that are
> > usable by the community is acceptable.
> +1
>
> > 17:47:53 [jzb]: in fact, we probably ought to be hitting up some of
> > our ISP friends for more.
> +1 - who are our ISP friends? Would like to get help on this.
Several of us. ;-)
>
> > 17:49:49 [ke4qqq]: so tsp (along with abayer and roman) are working
> > on a publicly accessible jenkins instance in fremont
> This is basically to dogfood all instances via a hosted puppetmaster.
> I've just started so will take time to finish this.
>
> Thoughts are most welcome!
>
> [1] https://jenkins.openstack.org/
> [2] http://ci.openstack.org/
> --
> Prasanna.,
>
> ------------------------
> Powered by BigRock.com
>
>
Infra Issues from the IRC meeting (Wed, Jun 12)
Posted by Prasanna Santhanam <ts...@apache.org>.
Saw a few infra topics being discussed in the meeting and there was
talk of bringing it to the list so I'm taking this opportunity to
explain some things behind it.
> 17:22:44 [Animesh]: I will send out my weekly reminder today on status and include Sudha's test results
> 17:23:28 [topcloud]: one thing that concerns me is that the bvt continues to be at < 100% pass rate
> 17:23:41 [topcloud]: is there anything we're doing about this?
yes - I've fixed most tests. Some have existed because of bugs in
packaging, systemvm templates that I see patches for now.
> 17:25:20 [chipc]: topcloud: was BVT ever at 100% ?
> 17:25:32 [chipc]: (real question, not sarcasm)
It was - 100% - when the project was first proposed. But more tests
have come in since then.
> 17:26:41 [chipc]: once we get it back to 100%, I say we block all changes when it drops to <100%
> 17:26:49 [topcloud]: +1
+1 - this is what I've been driving towards but haven't announced some
changes I've made in the past weeks because it's pointless to have
tests fail soon as I announce we are 100%. We shouldn't wait for one
run, but at least 10 to ensure that the bvt is indeed stable enough to
be trusted as a 'gating' system for master stability.
There's also a couple of issues here -
1. Does everyone know where the tests run?
2. Do people know how to spot the failures?
3. Do people know how to find the logs for the failures?
If the answer is no to all this, I have more documentation on my
hands.
> 17:28:07 [Animesh]: agreed bvt also shows progress towards release readines
> 17:28:07 [chipc]: topcloud: +1
> 17:28:32 [chipc]: Animesh: BVT should show that master is stable, regardless of release timeframes
> 17:28:33 [chipc]: IMO that is
> 17:28:44 [chipc]: master should only see good /tested code
Which is why the BVT runs on master at all times on
jenkins.buildacloud.org. There is also ability to run it against a
feature branch but I would rather defer that to the release manager
for now since it's tied with hardware resources and jenkins schedules.
That feature should strictly be reserved for architecture changes in
MERGE requests.
> 17:43:27 [topcloud]: sorry...to bring back this topic but is bvt running on apache infra?
> 17:43:35 [chipc]: no
> 17:43:57 [topcloud]: chipc: is there any talk about bringing it into apache infra?
It was brought up with the ASF infra back in January and the
suggestion was to donate hardware to the ASF to manage. So if we're
prepared to do that, great! But it certainly can't just be Citrix :)
I'd prefer individual project related test hardware and resources
to stay in the control of the project. Infrastructure is constantly
changed to allow features and enhancements to be tested so it's best
to have it in the core group. Which is why jenkins.buildacloud.org
came to existence. This is similar to how cloudbees operates or
(*gasp*) openstack-infra [1][2] operates.
Ideally, I'd like those interested in infra activities to form a
separate group for cloudstack-infra related topics. The group's focus
will be to maintain, test and add to the infrastructure of this
project. But that's in the future. Without such a group, building an
IaaS cloud is not much fun :)
> 17:44:17 [topcloud]: i can't imagine apache wanting bvt to only run inside citrix all the time.
It doesn't run within Citrix. It runs in a DC in Fremont. There are
other environments within Citrix however that run their own tests for
their needs - eg: object_store tests, cloudplatform tests, customer
related issue tests etc.
/me beginning to think more doc work is on my way :/
> 17:46:27 [chipc]: but generally, the ASF build infra is a bit overloaded
+1000
> 17:46:51 [jzb]: topcloud: when you say "in Citrix" - it's still visible outside Citrix, yes?
> 17:46:52 [chipc]: so frankly, CTXS donating an environment to run it, publicly visible to everyone, is quite helpful
> 17:46:58 [chipc]: jzb: it is
We need more people to donate hardware/virtual resources for testing :)
CTXS has been gracious to provide quite a few resources already IMO.
> 17:47:18 [chipc]: actually, I think it is...
> 17:47:34 [topcloud]: jzb: yeah it's still visible but it really should be runnable by everyone.
Not quite. It's a gating system. It runs automatically and shouldn't
be runnable by everyone at will. I'm still waiting to implement
devcloud tests based on that gerrit converstaion (which went nowhere)
we had many months back. DevCloud stuff can be run at will.
> 17:47:37 [jzb]: I'm all for building up Apache infra, but I also
> think having vendors donate publicly visible resources that are
> usable by the community is acceptable.
+1
> 17:47:53 [jzb]: in fact, we probably ought to be hitting up some of
> our ISP friends for more.
+1 - who are our ISP friends? Would like to get help on this.
> 17:49:49 [ke4qqq]: so tsp (along with abayer and roman) are working
> on a publicly accessible jenkins instance in fremont
This is basically to dogfood all instances via a hosted puppetmaster.
I've just started so will take time to finish this.
Thoughts are most welcome!
[1] https://jenkins.openstack.org/
[2] http://ci.openstack.org/
--
Prasanna.,
------------------------
Powered by BigRock.com