Perl 6 - the future is here, just unevenly distributed

IRC log for #fuel-dev, 2016-03-03

| Channels | #fuel-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:06 dims joined #fuel-dev
01:03 xarses joined #fuel-dev
01:07 xarses_ joined #fuel-dev
01:08 xarses_ joined #fuel-dev
01:19 krobzaur_ joined #fuel-dev
01:30 xarses_ joined #fuel-dev
01:32 andreww joined #fuel-dev
01:59 dims joined #fuel-dev
02:01 krobzaur_ joined #fuel-dev
02:15 lezbar__ joined #fuel-dev
02:17 xek_ joined #fuel-dev
02:22 brain461_ joined #fuel-dev
02:23 xarses joined #fuel-dev
02:24 _stowa_ joined #fuel-dev
02:24 xarses joined #fuel-dev
02:26 xarses joined #fuel-dev
02:27 xarses_ joined #fuel-dev
02:28 xarses_ joined #fuel-dev
02:30 andreww joined #fuel-dev
02:31 krobzaur_ joined #fuel-dev
02:50 krobzaur_ joined #fuel-dev
03:23 mwhahaha_ joined #fuel-dev
03:24 ominakov_ joined #fuel-dev
03:25 sovsianikov_ joined #fuel-dev
03:25 Damjanek_ joined #fuel-dev
03:26 igormarnat_ joined #fuel-dev
03:26 nurla joined #fuel-dev
03:26 IvanBerezovskiy1 joined #fuel-dev
03:27 tuvenen joined #fuel-dev
03:27 siwos joined #fuel-dev
03:27 izinovik_ joined #fuel-dev
03:27 pbrzozowski_ joined #fuel-dev
05:27 ogelbukh joined #fuel-dev
06:16 javeriak joined #fuel-dev
06:16 javeriak joined #fuel-dev
06:23 javeriak_ joined #fuel-dev
06:42 dshulyak joined #fuel-dev
06:55 bhaskarduvvuri joined #fuel-dev
07:14 huazhihao joined #fuel-dev
07:15 huazhihao Is "action: disable" deprecated in MOS 8.0
07:30 amnk joined #fuel-dev
07:45 kaliya joined #fuel-dev
07:55 e0ne joined #fuel-dev
08:02 bhaskarduvvuri joined #fuel-dev
08:08 Damjanek_ joined #fuel-dev
08:15 [HeOS] joined #fuel-dev
08:16 _nadya_ joined #fuel-dev
08:30 zubchick joined #fuel-dev
08:31 salmon_ joined #fuel-dev
08:36 e0ne joined #fuel-dev
08:37 fzhadaev joined #fuel-dev
08:48 zubchick joined #fuel-dev
09:06 ekosareva joined #fuel-dev
09:12 amnk joined #fuel-dev
09:18 bhaskarduvvuri joined #fuel-dev
09:24 e0ne joined #fuel-dev
09:30 aglarendil huazhihao: could you please provide more details? which part of Fuel are you actually talking about?
09:31 aglarendil reposting it here:
09:31 aglarendil 12:30:28 <aglarendil> hey, folks
09:31 aglarendil 12:30:38 <aglarendil> if you had issues with noop tests similar to this:
09:31 aglarendil 12:30:46 <aglarendil> roles/enable_compute                           ubuntu neut_vlan.compute.ssl.overridden
09:31 aglarendil 12:30:53 <aglarendil> failed   should not contain Service[nova-compute] with ensure => "running" (expected that the catalogue would not contain Service[nova-compute])
09:31 aglarendil 12:30:57 <aglarendil> you should rebase your code
09:31 ekosareva_ joined #fuel-dev
09:35 huazhihao aglarendil: I mean in the release yaml file.
09:38 huazhihao aglarendil: I am upgrading a fuel plugin from mos7 to mos8. And the plugin includes a separate release.
09:38 aglarendil @vkramskikh @ikalnitsky ^^
09:39 huazhihao @aglarendil : I used to use "action: disable" to disable some options, but now it is not working.
09:41 rmoe joined #fuel-dev
09:47 rvyalov_ joined #fuel-dev
09:52 aglarendil @huazhihao I am not an expert in this part. I think @vkramskikh and @ikalnitsky could be of help here
09:56 huazhihao @aglarendil Ah thank you all the same.
10:02 ikalnitsky huazhihao: i think i didn't get quite well.. what did you mean by "action: disable" ?
10:03 huazhihao @ikalnitsky Sorry. Here is the change I made, https://review.openstack.org/#/c/287097/2/newrelease.yaml
10:04 huazhihao I need to disable some options in Fuel UI wizard. "action: disable" used to work well in Fuel 7.0
10:10 e0ne joined #fuel-dev
10:13 ikalnitsky huazhihao: hm... disable means "hide" ?
10:14 ikalnitsky it'd be better to ping vkramskikh he's a master of that DSL. i don't remember action: disable, never was aware of.
10:14 ikalnitsky huazhihao: but it you want to hide something, it could be done by putting restrictions
10:16 huazhihao Disable mean disable. I can see that in https://github.com/openstack/fuel-web/blob/master/docs/develop/nailgun/customization/settings.rst#restrictions
10:17 huazhihao But yes, I also put "action: disable" under restrictions
10:17 huazhihao In MOS7 it works perfectly well.
10:24 ipolliul joined #fuel-dev
10:29 zubchick joined #fuel-dev
10:38 zerda joined #fuel-dev
11:00 kaliya joined #fuel-dev
11:07 lezbar joined #fuel-dev
11:14 dims joined #fuel-dev
11:14 zinovik joined #fuel-dev
11:27 dims joined #fuel-dev
11:34 ekosareva joined #fuel-dev
11:41 javeriak joined #fuel-dev
12:04 igajsin1 joined #fuel-dev
12:06 igajsin1 left #fuel-dev
12:11 vkramskikh huazhihao: it works fine, but in 8.0 wizard is not driven by wizard config anymore. wizard config was left in the openstack.yaml by error and removed from master: https://bugs.launchpad.net/fuel/+bug/1533765
12:12 vkramskikh you should use components_metadata section instead
12:20 amnk joined #fuel-dev
12:38 zubchick joined #fuel-dev
12:47 fuel-slackbot joined #fuel-dev
12:55 _nadya_ joined #fuel-dev
12:59 bhaskarduvvuri joined #fuel-dev
13:15 zubchick joined #fuel-dev
13:44 amnk joined #fuel-dev
14:12 jaypipes joined #fuel-dev
14:20 _nadya_ joined #fuel-dev
14:54 andreww joined #fuel-dev
14:57 andreww joined #fuel-dev
15:11 yottatsa joined #fuel-dev
15:11 gariveradlt joined #fuel-dev
15:19 krobzaur_ joined #fuel-dev
15:22 zubchick joined #fuel-dev
15:28 ibumarskov joined #fuel-dev
15:31 angdraug joined #fuel-dev
15:39 xarses joined #fuel-dev
15:41 zhsj joined #fuel-dev
15:42 ekosareva_ joined #fuel-dev
15:49 mmalchuk_ joined #fuel-dev
16:00 artem_panchenko_ joined #fuel-dev
16:02 javeriak joined #fuel-dev
16:03 javeriak joined #fuel-dev
16:06 javeriak_ joined #fuel-dev
16:06 grimlock86 joined #fuel-dev
16:14 mmalchuk_ left #fuel-dev
16:21 javeriak joined #fuel-dev
16:36 pumphouse joined #fuel-dev
16:36 yottatsa_ joined #fuel-dev
16:40 grimlock86 joined #fuel-dev
16:41 ddmitriev joined #fuel-dev
16:54 yottatsa joined #fuel-dev
16:55 zubchick joined #fuel-dev
16:58 sbanka joined #fuel-dev
16:59 Topic for #fuel-dev is now Fuel IRC meeting
16:59 angdraug lets resume the FFE discussion from http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-03-03-16.00.html
16:59 dnovakovskyi joined #fuel-dev
16:59 xarses hopefully every one has come in
17:00 angdraug the channel is logged so latecommers will be able to catch up
17:00 mattymo I'm here (and next on agenda)
17:00 Topic for #fuel-dev is now [FFE] FF exception request for Enable UCA repositories for deployment- 1 week (mattymo)
17:00 mattymo (paste warning)
17:00 mattymo Enabling Ubuntu Cloud Archive for OpenStack packages should have minimal impact to the release, since it will not be enabled by default.
17:00 mattymo http://lists.openstack.org/pipermail/openstack-dev/2016-March/088071.html
17:00 mattymo Stability of the feature is a risk, however, because upstream package changes can introduce failures. Right now those are taken care of.
17:00 mattymo The feature didn't land in time because of dealing with surpises from upstream as well as troubleshooting a fuel-ostf hack for nova service-list. MOS packages have this fix already in the package.
17:00 mattymo The base code for the feature takes ~240 LOC, 10 lines for the workaround, and the fuel-qa test case scenario is another 110 LOC.
17:00 mattymo Our options here are to permit FFE, move this back to a plugin, or postpone to Newton release.
17:01 mattymo I should note that it has no impact on regular BVT or existing swarm tests whatsoever
17:01 angdraug I'm fine with risk of upstream breaking this feature
17:01 xarses mattymo: becuase we don't test them?
17:01 angdraug what's the risk of these code changes breaking anything else?
17:01 mattymo I don't see any
17:02 angdraug aglarendil: ikalnitsky: objections?
17:02 mihgen Don't forget folks that if we leave no people to work on bugs, then quality will suffer..
17:02 mattymo we have 5 package workarounds, but they are only enabled when ubuntu cloud archive is enabled
17:02 angdraug mihgen: true, especially if "people" includes mattymo )
17:03 angdraug he's one of our top bug resolvers
17:03 * mattymo coughs... don't worry about my bug numbers
17:03 xarses :)
17:03 angdraug mattymo: how confident are you about wrapping this up in 1 week?
17:03 mattymo really confident! I am hanging on just some fuel-qa nonsense and then it's out the door
17:03 angdraug ok, I'm in favor
17:04 zigo I don't think UCA will be ready in a week though (but I'm still in favor).
17:04 angdraug #info UCA support FFE granted, deadline 3/10
17:04 Topic for #fuel-dev is now [FFE] FF exception request for LCM readiness for all deployment tasks - 1.5 week (sbanka)
17:05 Damjanek We would like to get 1.5 week FFE for this feature.
17:05 Damjanek In total we had more than 20 changes to merge, and 5 are still pending. We expect to have 3 more CRs.
17:05 angdraug Damjanek: usual questions: what are the impacted components, how well isolated are your changes?
17:05 Damjanek Only fuel-library will be affected, it cannot be an experimental feature.
17:05 xarses Damjanek: what's open / missing?
17:06 Damjanek We have still 5 CR pending: https://review.openstack.org/#/c/287063/ and https://review.openstack.org/#/c/287682/ and 3 additional idempotency/ensurability items to resolve (there are no reviews for it yet).
17:06 xarses what's the risk of it not landing?
17:06 sbanka not big risk
17:06 angdraug how well are these changes covered by CI?
17:06 sbanka the work here as about fixing puppet manifest
17:07 sbanka this is still to be done
17:07 angdraug will noop/bvt catch all potential regressions?
17:07 sbanka that is a plan but the work needs to be done in thos area
17:08 bgaifullin joined #fuel-dev
17:08 angdraug who are your reviewers? are they around?
17:09 angdraug aglarendil: mwhahaha: ^?
17:09 aglarendil moment please
17:09 angdraug alex_didenko: ^?
17:09 aglarendil all the regressions will be caught by CI and BVTs along with nightly swarm
17:09 sbanka Vova, Alex S.
17:10 aglarendil vast majority of changes is already merged, while others are tiny and will be automatically covered
17:10 sbanka https://review.openstack.org/#/q/topic:bp/granular-task-idempotency,n,z
17:10 mwhahaha we're also analyzing the results to ensure no new idempotency related items are created
17:10 angdraug 1.5 weeks is not a lot of time, if you're confident that you can finish this by then, and there's good CI coverage, looks good to me
17:11 angdraug if no objections from fuel-library folks, I think we should grant this one
17:11 alex_didenko I'm fine with fixing idempotency after FF
17:11 angdraug #info LCM readiness for all deployment tasks FFE granted, deadline 3/15
17:11 mwhahaha generally idempotency items are more bugs than features
17:11 alex_didenko yep
17:11 sbanka yes
17:12 Topic for #fuel-dev is now [FFE] FF exception request for Add multipath disks support - 1 week (sbanka)
17:12 Damjanek We would like to get 1 week FFE for this feature. Two changes are still on review: https://review.openstack.org/#/c/285340/ and https://review.openstack.org/#/c/282552/
17:12 Damjanek This feature cannot be in experimental. Components affected: nailgun agent (it has 2x +2 already) and fuel agent.
17:12 angdraug what's your testing status? were you able to test this on FC hardware?
17:12 Damjanek Physical hardware kicks in next week
17:12 angdraug agordeev: kozhukalov: can you comment about fuel-agent change?
17:13 Damjanek So we will be able to perform tests next week.
17:13 Damjanek In meantime it's being tested on VMs.
17:13 angdraug can it be tested in the swarm?
17:13 ikalnitsky Sorry guys, I gotta go. Please ping me here if necessary, I should be available via mobile client.
17:13 agordeev angdraug: the patch is the good shape. But still need reviews.
17:13 angdraug ikalnitsky: any objections about remaining FFEs on agenda?
17:13 angdraug agordeev: is it risky/intrusive?
17:13 sbanka we have already discussed patches with Kozhukalov and Gordeev
17:14 sbanka They are fine  with what’s in there...
17:14 sbanka It should be a matter of merging
17:14 angdraug fine before FF != fine after FF :)
17:14 agordeev angdraug: not at all. it's just a couple of fixes here and there.
17:14 angdraug ok then, lets grant this one
17:15 angdraug #info multipath disks support FFE is granted, deadline 3/10
17:15 Damjanek Thanks!
17:15 Topic for #fuel-dev is now [FFE] Use packetary for ISO build process ~03/09/2016 (kozhukalov)
17:16 xarses kozhukalov: ?
17:16 angdraug build process changes always have a chance to block everyone :(
17:16 angdraug what are we going to lose from 9.0 if we postpone this until SCF?
17:17 azvyagintsev yeah, but this changes will help everyone :)
17:17 Damjanek +1
17:17 angdraug azvyagintsev: I do not doubt that, but so can every other feature in our backlog :(
17:18 mihgen just to remind, if we work on FF exceptions, it means that we are not cleaning up our bugs...
17:18 azvyagintsev yup, i know, but this feature got more + then -
17:18 azvyagintsev kozhukalov: ?
17:18 angdraug azvyagintsev: we don't make technical decisions by popular vote, we make them by consensus
17:19 xarses #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/087923.html
17:19 angdraug looks like we've lost kozhukalov in the transition from #openstack-meeting-alt :(
17:19 xarses we should have enough here to review the request
17:19 ikalnitsky Guys , I think fuel-qa aren't ready
17:19 azvyagintsev sure, sry. anyway +1 from for FFE.  lets postpone decision , at least to end of FFE list ?
17:20 ikalnitsky Repo paths will be changed
17:20 azvyagintsev nope
17:20 azvyagintsev why you think so ?
17:20 ikalnitsky Kozhukalov told me so
17:21 azvyagintsev i think it's not an hard-requirement for feature. and mostly related to infrastructure processes
17:21 angdraug azvyagintsev: can you explain what do we gain by doing this now instead of a month later?
17:21 mwhahaha i don't see why this one has to be done for 9.0
17:21 xarses while I'd love to have this, I don't see it as a hard requirement
17:22 ikalnitsky azvyagintsev: the patches are written that way to fix our tech debt
17:22 angdraug I think the same arguments apply here as with docker removal: we postponed it from 8 to 9 and it worked out fine
17:22 ikalnitsky Is
17:22 mwhahaha we've got enough moving pieces that we don't need to also mess with the build process right now as well
17:22 azvyagintsev the most big issue  -  w\o FFE we can't drop build-packaging with ISO build
17:22 ikalnitsky I think e need to postpone
17:22 azvyagintsev asilenkov: ?
17:22 mihgen what is the impact if we don't drop build-packaging with ISO build in 9 ?
17:23 azvyagintsev asilenkov_:
17:23 angdraug https://ci.fuel-infra.org/job/9.0-community.all/buildTimeTrend
17:24 azvyagintsev mostly it's shipping(re-producing of build process on other then our ci) impact. and other part- loss of flexibility for custom build's
17:24 angdraug azvyagintsev: do any other features in 9.0 depend on these capabilities?
17:25 azvyagintsev i guess no. switching process should be smoothly  (Considering fuel-qa and CI teams will work in "together")
17:25 mihgen we've been suffering from this for several releases, so I'm ok to suffer one more - but get it polished and smoothly merged in 10.0
17:25 angdraug sorry, I'm one of the first people to argue in favor of implementing this feature so I really do want to have it sooner rather than later, but we have to be practical here
17:25 azvyagintsev not agree
17:26 azvyagintsev each time it's pain
17:26 xarses sorry, brb
17:26 azvyagintsev okay ;(
17:27 angdraug #info Packetary for ISO build FFE denied
17:27 angdraug it's only xarses' and grimlock86's features left
17:27 angdraug did anyone post an FFE to ML and not add it to the meeting agenda?
17:28 xarses back, sorry about that
17:28 Topic for #fuel-dev is now [FFE] Decouple Fuel and OpenStack tasks (xarses)
17:28 xarses Decouple Fuel and OpenStack tasks feature - While the code change [1] is ready and usually passing CI we have too much churn in the tasks currently which puts the patch set in conflict constantly so it has to be rebased multiple times a day. We need more review and feedback on the change, and a quiet period to merge it
17:28 xarses #link https://blueprints.launchpad.net/fuel/+spec/fuel-openstack-tasks
17:28 xarses #link https://review.openstack.org/#/c/283332/
17:28 xarses risks - impact to fuel-library, regression: low we are moving files around, however it has not received any peer review. Bigest impact is that basically every other change in fuel-libary will have to be rebased after it lands
17:29 angdraug looks like we need to let LCM readyness land first
17:29 angdraug and then it will become quiet enough for this to land?
17:30 angdraug aglarendil: mwhahaha: alex_didenko: comments, objections?
17:30 xarses and any parts of my other spec
17:30 xarses or visevers
17:30 mwhahaha i'm ok with it
17:30 alex_didenko the biggest concern here is affecting other devs
17:31 xarses I can rebuilt the patch set easily, we just need to determine when we want to land it
17:31 angdraug which is why I want other major library changes to land first
17:31 xarses s/rebuilt/rebuild
17:31 alex_didenko also it breaks noops
17:31 xarses alex_didenko: noops works fine with it
17:31 aglarendil I am ok with it, but we need to have devs within short feedback loop, so that affected patches are rebased quickly
17:31 angdraug library folks, please review this soon so that it doesn't have to spend a week in review _after_ other stuff has landed
17:31 mihgen Folks, we need to have *really* good reasons to give exception, not just be Ok with it
17:32 mihgen it's passed FF time
17:32 mwhahaha it's a restructure of the code into a more flexible organization and it's something that really needs ff to be done
17:32 mwhahaha it's not a new feature just a move
17:32 angdraug I'm under impression that all 3 remaining FFEs are interdependent...
17:33 xarses We also cant really complete the move while it impacts others
17:33 mwhahaha and they all are shuffling around of existing code into a more flexible arrangement
17:33 angdraug exactly my point
17:33 mwhahaha they don't add new functionality for fuel-lib
17:33 angdraug and they all have the same problem with merge conflicts
17:33 grimlock86 right. and yes, I agree with them all being interdependent.
17:33 mwhahaha as it relates to existing deployments
17:34 angdraug the problem is that we've got library changes planned in the FFEs we've granted so far
17:34 mihgen how critical this work is for proper puppet master integration?
17:34 angdraug all the way to 3/16
17:34 alex_didenko ok, I've found green noops :) and yes, this particular feature is about moving manifests around
17:35 mwhahaha the openstack task one isn't, that's a 9-kilo item
17:35 xarses its critical to supporting 9-kilo
17:35 xarses as a downstream
17:35 alex_didenko so I see no problems to grant an FFE, because there is no new functionality in it
17:35 angdraug what about CI coverage?
17:35 mwhahaha should be covered by existing
17:36 xarses It passes ci coverage, and when I bugger something, it fails
17:36 angdraug should?
17:36 mwhahaha unless we uncover an issue with existing CI (hard coded paths or something)
17:36 jaypipes joined #fuel-dev
17:36 mwhahaha today's CI/bvt is sufficient
17:36 angdraug mwhahaha: it wouldn't have passed if hardcoded paths were a risk
17:37 mwhahaha right, that's my point :D
17:37 mwhahaha but we should run the task move through bvt prior to merge
17:37 mihgen if exception is given, who will be working on this?
17:37 angdraug ok, so library cores are in favor, there's no functional changes and existing functionality is sufficiently covered by CI
17:38 xarses the current CI catches errors I make in the commit, so I feel CI coverage is good to confirm this
17:38 angdraug it's a library change so it's already covered by bvt in CI
17:38 xarses mihgen: me, and it takes about 5 min to 'rebase' it
17:39 xarses other than daily merge conflicts its complete
17:39 angdraug xarses: how much time per day are you going to spend doing that until it can be merged?
17:39 angdraug how much time on average is it going to take resolving the merge conflicts?
17:39 xarses for my patch set about 5 min
17:39 mihgen as other features depend on it, and will need rebase - I'd suggest to approach this aggressively, with an attempt to get it done asap
17:40 angdraug before making decision on this lets discuss the other 2 FFEs
17:40 xarses for other on my patchset, maybe about the same but they have to figure out the new directory structure
17:40 xarses moving then
17:40 Topic for #fuel-dev is now [FFE] Remove conflicting openstack module parts (xarses)
17:41 xarses Remove conflicting openstack module parts - This is necessary to make the feature Decouple Fuel and OpenStack tasks feature useful [1] , some of the patches are ready for review and some still need to be written [2]. We need 2 - 3 weeks after FF to finish this feature. Risk of not delivering it after 3 weeks is low. This is mostly due to churn of features landing in related code path
17:41 xarses #link https://blueprints.launchpad.net/fuel/+spec/fuel-remove-conflict-openstack
17:41 xarses #link https://review.openstack.org/#/q/topic:bp/fuel-remove-conflict-openstack,n,z
17:41 xarses risks - impact to fuel-library; regression: medium, we are merging and flattening code between files. Spec has positive review; some reviews have feedback; alot aren't passing CI still some from incomplete change. some from churn on master; about 6/10 of these are on review. Changes not ready by end of FFE can miss SCF as they are code refactoring.
17:42 angdraug what's the value of this one?
17:42 angdraug what else exactly depends on it?
17:42 mwhahaha 9-kilo supportability
17:42 xarses mwhahaha: yes
17:43 xarses the main issue is that part of the code coupled to the tasks is 'proxied' by very old tech-debt in the `openstack` module
17:44 angdraug why is this a separate feature then?
17:44 xarses if we can flatten that into the task, it greatly improves the loose coupeling we are trying to add in fuel-openstack-tasks
17:44 xarses because I had talked with several of the fuel-library guys about it, and they asked that I separated it
17:45 xarses both can be completed separately of each other
17:45 angdraug ok, from FFE perspective it still looks like it's both or nothing
17:45 angdraug how soon, aside from churn, can it be made ready for merge?
17:45 xarses if one isn't approved, there is no point in approving the other, yes
17:46 xarses about 1.2 weeks w/o churn
17:46 mwhahaha well you can do the moving openstack tasks w/o killing the openstack module
17:46 angdraug I'm beginning to think that landing both of these is better done over a weekend, e.g. March 12-13
17:46 mwhahaha it just adds more tech-debt into the management of the openstack tasks for 9-kilo around the openstack class
17:46 kozhukalov I'm here again, had some connectivity troubles
17:47 angdraug kozhukalov: sorry, we've denied your FFE without you :(
17:47 mihgen how much time would it take for idempotency-related work to be rebased, if these changes are landed?
17:47 mwhahaha i don't think the idempotency related work is going to be in the openstack module
17:47 xarses mihgen: they conflict with each other thats part of the reason for the long ask on the FFE
17:48 xarses the open idempotency don't overlap much
17:48 angdraug I think idempotency should go in first
17:48 xarses its the NFV features that have been moving it the most
17:48 angdraug most of NFV is due by 3/16
17:49 angdraug so is idempotency
17:49 angdraug so we can try to land all this on 3/17-18, with the weekend 3/19-20 as the fallback
17:49 mihgen What will we lose, if we don't do these exceptions then? How hard would it be to manage these things downstream branches?
17:50 xarses mihgen: the downstream has to fork all of fuel-libary, instead of the openstack_tasks folder
17:50 angdraug mihgen: somebody who works with kilo will have to carry and rebase all these patches on a daily basis
17:50 xarses it becomes much more complicated to rebase and cherry pick patches
17:50 grimlock86 We'll be in the same position we're in at AT&T right now with downstreaming.  We'll have tech debt with Fuel Library forever for the kilo deployments, of which there will be many.
17:51 xarses it also becomes much harder for the downstream to push patches back to us because of the large difference
17:52 mihgen sounds like we better spend X resources now, rather than 10X if we don't do X now
17:52 angdraug yup
17:52 xarses more or less
17:52 angdraug should we move on to grimlock86's FFE before deciding on these two?
17:52 grimlock86 Mine is closely related and the landing time will likely be around the same timeframe so that makes sense
17:53 xarses grimlock86's does accompany, but isn't as strongly related
17:53 angdraug xarses: does it depend on your changes?
17:53 mwhahaha they will be directly impacted
17:53 xarses it would have to be rebased onto it yes, we both touch the tasks manifests
17:53 grimlock86 right. that's what i meant
17:54 angdraug timing has to work 100% for all 3 to land before 3/24
17:54 Topic for #fuel-dev is now [FFE] request for osnailyfacter refactoring for Puppet Master compatibility (grimlock86)
17:54 grimlock86 http://paste.openstack.org/show/489199/
17:54 angdraug if we go with 3/20 deadline for xarses's changes, grimlock86 will have 4 more days to rebase and land
17:55 e0ne joined #fuel-dev
17:55 grimlock86 That should be sufficient time.  My guys have already done all the work for mine, we'd just have to rebase before landing them.  4 days should be sufficient.
17:55 angdraug I suggest you don't waste time continuously rebasing until 3/20, it will just slow you down
17:55 xarses they would have to be pre-chained
17:55 grimlock86 angdraug: I agree with you
17:55 alex_didenko jsut a note, we have 120+ modular manifests
17:55 alex_didenko so we expect 120+ patches, rigth?
17:56 angdraug I hope not!
17:56 grimlock86 yes.
17:56 angdraug as in, 120 commits?
17:56 angdraug no
17:56 angdraug NO!!!11111one
17:56 alex_didenko 127 commits
17:56 grimlock86 We're reviewing based on the directory inside the modular directory.
17:56 angdraug no way we get 127 commits merged in 4 days
17:56 xarses I spoke with the guys working on it, I asked them to do 1 folder at a time so it is easy to review / rebase
17:56 grimlock86 For example, here's the ceph directory: https://review.openstack.org/#/c/287673/
17:57 grimlock86 All we're doing is copying the contents of the modular manifests and wrapping them into a class inside manifests directory so that osnailyfacter becomes a proper puppet module that is consumable by puppet master.
17:57 alex_didenko find osnailyfacter/modular/ -name *pp | wc -l
17:57 alex_didenko yes, a script can do it, it's not a problem
17:57 angdraug one commit per pp is WAY too granular
17:57 xarses there are about 30 folders
17:57 grimlock86 the modular manifest then stays there but inside of it it becomes: 'include ::osnailyfacter::ceph::compute' for example
17:58 angdraug even 30 commits would be a problem
17:58 grimlock86 We can go less granular if you'd like.
17:58 angdraug grimlock86: expect 3-5 hours per commit
17:58 mihgen depends on how many back-and-force expected in terms of review
17:58 angdraug I'm talking worst case
17:58 angdraug it always ends up on the worse side of the spectrum
17:58 xarses angdraug: also, things like this ceph one can land well before me
17:59 mihgen if it's something which will require a lot of -1 and new patches for review for some of the modules, it might be faster to do 120 patchsets,..
17:59 grimlock86 I mean we can do it in one lump sum. Each of these commits is basically going to be identical in what it does.  We verbatim copy the contents of the modular manifest into a file of the same name inside manifests directory
17:59 xarses only the ones that both conflict do we need to order them
17:59 xarses again, we don't want to do 127 commits, we are doing 1 per folder (~30) currently
17:59 alex_didenko guys, but in result those classes - they don't really look like puppet classes
17:59 alex_didenko that's not how you write classes
18:00 grimlock86 It's a glorified profile class.
18:00 grimlock86 It's not intended to be a component module.
18:00 xarses and ~1/2 would not be locked with my changes
18:01 mihgen sounds like we need to agree on design first: https://review.openstack.org/#/c/284853/
18:01 xarses so they merge after LCM
18:01 angdraug lets leave the design discussions out of here for now
18:01 xarses mihgen: we do, but lets pretend that's not an issue currently
18:01 angdraug if there is not consensus on design, obviously this goes nowhere
18:01 grimlock86 The actual functionality as far as upstream library is concerned is that the puppet apply that is run on a manifest now does an include of a wrapper class that runs the same exact contents as it would have otherwise.
18:01 xarses lets focus on schedule and risk first
18:02 grimlock86 All we're doing is shuffling files around basically and I'm dealing with the 3rd party implementation via plugin.  The design is to leave library alone other than the shuffling around. No new feature is implemented.  So I think landing after LCM is where this needs to go.
18:02 angdraug alex_didenko: grimlock86: how long will it take you to reach an agreement on design?
18:02 mihgen how can we assess risks and work on schedule, if we are not yet in agreement on how we approach changes?
18:03 grimlock86 We have a meeting scheduled for tomorrow between the fuel library guys, myself, and the other services architects involved.
18:03 angdraug mihgen: we have to bake in assumptions about the risks into the FFE, if the design can't satisfy those FFE is revoked
18:03 grimlock86 It was supposed to be this morning but PTO issues pushed it to tomorrow. I'd like to come to an agreement at the meeting tomorrow.
18:04 alex_didenko there also could be variable scoping issues
18:04 alex_didenko so I can't say for sure that this feature is only about moving code from one file to another
18:05 grimlock86 any regression will be caught by CI & BVT
18:05 alex_didenko not any
18:05 mwhahaha if we have scoping issues those are bugs in our code
18:05 alex_didenko we don't cover 100% of functionality with CI and BVT
18:05 grimlock86 if we're getting an undef value for something due to variable scoping, that should fail our CI/BVT. If it doesn't our BVT is broken.
18:05 angdraug do we have coverage data for fuel-library?
18:06 mwhahaha it used to get generated via noop but i don't know if it's still in there after all the noop refacters
18:06 alex_didenko no, because there are too many different incoming params
18:07 angdraug I'm beginning to think that we're not going anywhere
18:07 alex_didenko even noops can't show real coverage (due to conditionals that depend on astute.yaml)
18:07 mwhahaha yes it can
18:08 angdraug so no, we don't have coverage data
18:08 angdraug on one hand, it's obvious that this change is going to need FFE to land
18:08 grimlock86 So here's the risk of this not getting FFE because we're going in circles debating whether our CI is any good (of which these changes are passing so far): We have to downstream our own Fuel library and keep that maintained at least at 2 very large corporations that will be using this.  Effort will be phenomenal and we'll have divergent codebases between the orgs downstreaming this for themselves.
18:09 grimlock86 Also, it will break my schedule and we risk an LCM project at a large customer failing.
18:09 angdraug at this scale, it's got the same problem as xarses' changes: it can't land while other people are landing feature changes
18:09 grimlock86 I agree with you there.
18:09 angdraug if we postpone this to Newton, it's going to be stuck due to the code churn all the way until next FF
18:10 xarses and again, this divergence will prevent the downstream from being able to easily push up patches
18:10 xarses angdraug: most likely
18:10 angdraug so we shouldn't be even discussing how much we want this feature
18:10 angdraug we should focus on risks and risk mitigation
18:10 mihgen even though I'm totally dissatisfied to see this being proposed too late in the cycle, I'd still take into account seriously the field /users feedback grimlock86 providing.
18:11 angdraug mihgen: good point
18:11 mihgen so may be there is a compromise somewhere?
18:11 angdraug we need more people from outside of Fuel core team using and contributing to Fuel
18:11 grimlock86 The timeline is on me but I'm also well over-allocated and been in meeting hell and travel with meeting hell included and was unable to get the spec written in time.  The general work for making this possible was already done prior to that being proposed.
18:11 alex_didenko I'm afraid no time for gathering feedback
18:11 mihgen may be we do x/2 changes, so that it's more or less easy in downstream, and not too distruptive in upstream?
18:12 xarses again, lets go back to risk
18:12 alex_didenko x/2 is much worse then 0 or x :)
18:12 alex_didenko it changes the workflow and how-to-contribute guides, so we should stick with one, not try to support both
18:13 angdraug also good point
18:13 xarses and pretend that we can agree on need here (we will follow up on that, and the FFE is of course dependent on it)
18:14 xarses can we acually make land this in the timeline
18:14 mihgen then my take would be to make attempts, get deadline first on design agreement, and accept this as exception. Revoke if we can't agree on design by certain date, or if design requires more work than deadline set
18:14 angdraug design deadline should be 3/16
18:14 angdraug and merge deadline 3/24
18:14 grimlock86 That works for me
18:14 mihgen I want these guys to contribute to upstream later as opposed to their fork
18:15 angdraug grimlock86: so a deal: we grant your FFE, your guys push their changes to Fuel upstream once your feature has landed :)
18:15 javeriak_ joined #fuel-dev
18:15 angdraug what other conditions do we want to impose?
18:16 angdraug for one, by 3/20 the whole patch series must be properly chained in gerrit
18:16 mihgen too late for design deadline to me
18:16 angdraug mihgen: why so?
18:16 mihgen can't we agree within few days.. ?
18:16 grimlock86 angdraug: that works for me.  I'm hoping to have agreement tomorrow.
18:16 grimlock86 Or at the very latest early next week.
18:16 angdraug we can, but why impose additional restrictions when we can't even start landing this until 3/20?
18:16 mihgen sounds like 3/10 would be Ok
18:16 mwhahaha as a side note, it looks like the coverage report functions were pulled from noop :/
18:17 xarses angdraug: we should be able to start landing earlier for non-conflicts
18:17 xarses 1/2 isn't overlapping with me
18:17 xarses to 3/16
18:17 angdraug ok, new plan
18:17 mwhahaha the non-openstack tasks should be able to be migrated eariler
18:17 xarses and some of those won't overlap with others
18:17 angdraug design deadline: 3/10
18:17 angdraug alex_didenko: agree?
18:18 _nadya_ joined #fuel-dev
18:18 angdraug by 3/10, we need to identify changes that can land ahead of xarses
18:18 angdraug land those by 3/16
18:18 alex_didenko I agree to discuss it further
18:18 rvyalov_ joined #fuel-dev
18:18 angdraug alex_didenko: please give it your best effort to complete all discussions by 3/10
18:19 angdraug as in, don't leave it w/o review for more than a day, have frequent design meetings, etc
18:19 alex_didenko sure
18:19 angdraug I think 2-3 meetings and 3-5 patch sets on the spec can be enough to reach consensus
18:19 grimlock86 That seems doable.
18:20 angdraug line up remaining changes by 3/20, land by 3/24
18:20 angdraug everyone agrees?
18:20 grimlock86 Agreed
18:20 xarses +1
18:20 angdraug mihgen?
18:20 mihgen +1 if grimlock86 promises to push code to upstream afterwards ;)
18:20 angdraug he already did
18:20 grimlock86 Well it'd go upstream no later than 3/24
18:21 grimlock86 The work's already been done for weeks.  Just need to upstream it now
18:21 angdraug we mean subsequent changes
18:21 mihgen bugfixes, etc.
18:21 xarses grimlock86: we're talking about bugfixes /etc from the fork
18:21 grimlock86 Yep, that'll be the process.  Once it's in, we'll upstream everything in a co-dev fashion with the users I'm bringing
18:21 angdraug ok then, here goes
18:21 angdraug oh wait
18:22 angdraug do we need to circle back to xarses' changes?
18:22 mihgen that means all three exceptions are getting approved, right?
18:22 angdraug yes
18:22 grimlock86 I think we covered it by saying we're identiying changes that can land ahead of his by 3/10, right?
18:22 mihgen mwhahaha: agree on all three exceptions..?
18:23 mwhahaha yes
18:23 angdraug grimlock86: yes
18:23 angdraug #info Decouple Fuel and OpenStack tasks FFE granted, deadline 3/20
18:23 angdraug #info Remove conflicting openstack module parts FFE granted, deadline 3/20
18:24 angdraug #info osnailyfacter refactoring for Puppet Master compatibility FFE granted, design deadline 3/10, deadline for patches not conflicting this kilo-related changes 3/16, deadline for the rest 3/24
18:24 angdraug missed anything?
18:24 grimlock86 Looks good to me.
18:25 angdraug mihgen: that leaves the exceptions that were requested not ML but not represented in the meeting agenda
18:25 xarses #topic Other exceptions requested in openstack-dev, but not presented here (mihgen)
18:25 Topic for #fuel-dev is now Other exceptions requested in openstack-dev, but not presented here (mihgen)
18:25 mihgen we'd still need to discuss those, I assume?
18:26 angdraug centos7.2 switch got merged yesterday, making it before FF at the 11th hour
18:26 mihgen ok cool then
18:26 zigo Nice! :)
18:26 angdraug as for the rest, I don't think we should grant any of those
18:26 * mihgen keeps fingers crossed
18:27 angdraug objections anyone?
18:27 xarses angdraug: my only comment is on non-root
18:27 angdraug xarses: what about it?
18:28 xarses erm, looks like it all merged, nvm
18:28 angdraug yup
18:28 xarses so the only things outstanding might be CI support
18:28 angdraug wait a second
18:28 angdraug https://review.openstack.org/#/c/286487/
18:29 angdraug yet another commit merged with -1 from Fuel CI
18:29 bookwar left #fuel-dev
18:29 xarses that looks like it was on the broken iso
18:29 bookwar joined #fuel-dev
18:30 angdraug probably
18:30 xarses ya -48
18:30 angdraug considering that it was landed before we got a green bvt yesterday, looks like it's all good now
18:30 angdraug so
18:30 angdraug #info Use RGW as a default object store instead of Swift FFE is denied
18:30 angdraug #info FF exception request for non-root accounts on slave nodes FFE not required: feature is merged
18:31 angdraug #info Reassigning Nodes without Re-Installation FFE is denied
18:31 angdraug #info Component registry improvements FFE is denied
18:31 angdraug #info CentOS-7.2 FFE is not required: feature is merged
18:31 angdraug there, all done
18:31 xarses huzzah!
18:31 angdraug mark the time: 2.5 hours
18:31 zigo \o/
18:31 xarses o/ \o
18:32 xarses any desire to get through the rest of the agenda or bump it to next week?
18:32 geekinutah joined #fuel-dev
18:33 geekinutah Folks there was also an FFE for reasign vs redploy IIRC
18:33 geekinutah let me find the review...
18:33 zigo Do we have some space to discuss *NON* FFE stuff?
18:33 xarses geekinutah:  "Reassigning Nodes without Re-Installation"
18:33 xarses ?
18:34 geekinutah sounds right
18:35 xarses <angdraug> #info Reassigning Nodes without Re-Installation FFE is denied
18:35 xarses unless we need to look at it again
18:36 xarses ok I want to close this down final thoughts?
18:36 angdraug no, lets close it
18:36 geekinutah I would like to look at that again :-), it does not need to be right now though
18:36 angdraug 2.5 hours was enough time for everyone to speak up
18:36 angdraug geekinutah: feel free to look at that again for Newton
18:37 angdraug for 9.0/Mitaka, the case is closed
18:38 Topic for #fuel-dev is now meeting adjourned
18:38 xarses thanks for playing FFE  or die
18:38 mwhahaha cake or death?
18:38 xarses please don't come back next cycle ;)
18:38 Topic for #fuel-dev is now Fuel Development http://wiki.openstack.org/wiki/Fuel | Paste here http://paste.openstack.org/ | IRC logs http://irclog.perlgeek.de/fuel-dev/ | gerrit traffic @ #fuel-tracker
18:39 _nadya_ joined #fuel-dev
18:39 xarses 2.8 hours
18:40 rvyalov_ joined #fuel-dev
18:40 mihgen angdraug: I don't think that non-root access is implemented in full.
18:41 angdraug mihgen: whatever's not implemented will have to wait until Newton
18:41 mihgen yep
18:41 mihgen so in fact, FFE request sent to openstack-dev ML is denied
18:46 dnovakovskyi joined #fuel-dev
18:48 javeriak joined #fuel-dev
18:52 angdraug mwhahaha: cake is a lie
18:52 javeriak_ joined #fuel-dev
18:54 javeriak joined #fuel-dev
19:01 dshulyak left #fuel-dev
19:02 mgariepy joined #fuel-dev
19:08 krobzaur joined #fuel-dev
19:12 * xarses grabs some cake, and eats it too
19:18 rvyalov_ joined #fuel-dev
19:21 _nadya_ joined #fuel-dev
19:24 amnk joined #fuel-dev
19:25 akscram joined #fuel-dev
19:25 amnk joined #fuel-dev
19:41 akscram Guys, we need these changes in 9.0 in some uncommon upgrade procedures: https://review.openstack.org/#/c/280067/
19:41 akscram I'm not actually sure that this change requires FFE because it's a very small change that do not affect any current functionality and has fully backward compatible with the current implementation of the cluster_upgrade extension.
19:42 akscram This change allows to parametrize the current upgrade procedure of nodes and skip the re-provisioning step.
19:42 akscram ikalnitsky, xarses and mihgen ^^
19:44 angdraug akscram: you're 4 hours late for the IRC meeting :(
19:44 angdraug and a day late for FF
19:47 dnovakovskyi joined #fuel-dev
19:48 akscram angdraug: I've created a FFE request for this change request but yes I missed the meeting.
19:48 angdraug yes, and without you here to argue your case your request was denied
19:49 angdraug even without this we've got 12 FFEs
19:49 angdraug and everyone is either small and low-risk or essential or both
20:05 dnovakovskyi joined #fuel-dev
20:12 akscram angdraug: but this one very small and very safe patch, it changes +124, -28 lines including tests :)
20:32 e0ne joined #fuel-dev
21:00 e0ne joined #fuel-dev
21:11 rvyalov_ joined #fuel-dev
21:17 e0ne joined #fuel-dev
21:21 angdraug joined #fuel-dev
21:37 e0ne joined #fuel-dev
21:42 bgaifullin joined #fuel-dev
21:52 dshulyak joined #fuel-dev
22:04 dnovakovskyi joined #fuel-dev
22:32 akscram angdraug: but this one very small and very safe patch, it changes +124, -28 lines including tests :)
23:01 rvyalov_ joined #fuel-dev
23:05 salmon_ joined #fuel-dev
23:08 rvyalov_ joined #fuel-dev
23:10 geekinutah joined #fuel-dev
23:17 gariveradlt joined #fuel-dev

| Channels | #fuel-dev index | Today | | Search | Google Search | Plain-Text | summary