Perl 6 - the future is here, just unevenly distributed

IRC log for #puppet-openstack, 2013-09-23

| Channels | #puppet-openstack index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:09 ianw joined #puppet-openstack
00:43 dprince joined #puppet-openstack
01:07 michchap joined #puppet-openstack
01:22 xingchao joined #puppet-openstack
01:58 rcrit joined #puppet-openstack
02:17 nightfly joined #puppet-openstack
02:17 Hunner joined #puppet-openstack
03:35 openstackgerrit Paul Belanger proposed a change to stackforge/puppet-openstack: Expose debug parameter  https://review.openstack.org/47778
04:18 michchap_ joined #puppet-openstack
04:28 michchap joined #puppet-openstack
04:45 michchap joined #puppet-openstack
06:39 rcrit joined #puppet-openstack
07:49 mmagr joined #puppet-openstack
07:55 pabelanger joined #puppet-openstack
07:55 pabelanger joined #puppet-openstack
08:24 openstackgerrit François Charlier proposed a change to stackforge/puppet-ceilometer: Allow to set full url for endpoints  https://review.openstack.org/47406
08:55 qba73 joined #puppet-openstack
12:08 markvoelker joined #puppet-openstack
12:40 bcrochet joined #puppet-openstack
13:01 prad joined #puppet-openstack
13:03 dprince joined #puppet-openstack
13:14 rcrit joined #puppet-openstack
13:31 openstackgerrit Chris Ricker proposed a change to stackforge/puppet-openstack: Configurable admin for Swift proxy authtoken class  https://review.openstack.org/47834
13:33 openstackgerrit Chris Ricker proposed a change to stackforge/puppet-openstack: Configurable admin for Swift proxy authtoken class  https://review.openstack.org/47834
13:46 dmsimard joined #puppet-openstack
13:50 mjeanson joined #puppet-openstack
13:56 fc__ joined #puppet-openstack
13:56 michchap joined #puppet-openstack
14:00 michchap joined #puppet-openstack
14:26 openstackgerrit Emilien Macchi proposed a change to stackforge/puppet-nova: Add Nova Cells support  https://review.openstack.org/41908
14:29 dprince joined #puppet-openstack
14:39 otherwiseguy joined #puppet-openstack
14:48 openstackgerrit Matthew J Black proposed a change to stackforge/puppet-openstack: Allow passing keystone_host to controller class  https://review.openstack.org/47852
14:49 mmagr joined #puppet-openstack
14:53 technolo-g joined #puppet-openstack
14:53 mjblack joined #puppet-openstack
15:03 openstackgerrit Salvatore Orlando proposed a change to stackforge/puppet-neutron: Execute DB migrations when setting up Neutron DB  https://review.openstack.org/47854
15:07 mmagr joined #puppet-openstack
15:10 openstackgerrit Matthew J Black proposed a change to stackforge/puppet-openstack: Allow passing keystone_host to controller class  https://review.openstack.org/47852
15:21 mgagne joined #puppet-openstack
15:22 mgagne bodepd: ping
15:35 openstackgerrit Sebastien Badia proposed a change to stackforge/puppet-nova: fix stackforge web link  https://review.openstack.org/47858
16:02 openstackgerrit Mathieu Gagné proposed a change to stackforge/puppet-nova: Pin to posgresql 2.5 module  https://review.openstack.org/47870
16:05 ari_ joined #puppet-openstack
16:13 openstackgerrit Mathieu Gagné proposed a change to stackforge/puppet-nova: Pin to posgresql 2.5 module  https://review.openstack.org/47870
16:23 ari__ joined #puppet-openstack
16:31 mjeanson joined #puppet-openstack
16:43 mjeanson joined #puppet-openstack
16:49 iwi hi there, what is the best approach to install havana using puppet ? will simple change of package repositories work with https://github.com/stackforge/puppet-openstack?
16:57 mjeanson joined #puppet-openstack
17:03 openstackgerrit Mathieu Gagné proposed a change to stackforge/puppet-nova: Pin to posgresql 2.5 module  https://review.openstack.org/47870
17:26 openstackgerrit A change was merged to stackforge/puppet-nova: Pin to posgresql 2.5 module  https://review.openstack.org/47870
17:29 mgagne bodepd: ping
17:30 openstackgerrit Sebastien Badia proposed a change to stackforge/puppet-nova: fix stackforge web link  https://review.openstack.org/47858
17:31 ari joined #puppet-openstack
17:34 openstackgerrit A change was merged to stackforge/puppet-nova: fix stackforge web link  https://review.openstack.org/47858
17:35 badiane_ka joined #puppet-openstack
17:37 hogepodge joined #puppet-openstack
17:40 openstackgerrit Mathieu Gagné proposed a change to stackforge/puppet-nova: Pin to posgresql 2.5 module  https://review.openstack.org/47887
17:42 bodepd mgagne: pong
17:42 mgagne bodepd: good news everyone!
17:43 bodepd bodepd: yes ? :)
17:43 mgagne "Small" size OpenStack setup (puppet-keystone patches)
17:43 mgagne Before: 380.24 seconds
17:43 mgagne With 47673/2: 322.64 seconds
17:43 mgagne With 47673/2 and 47696/1: 203.62 seconds
17:43 bodepd I started working on a patch for the user_role stuff
17:43 bodepd but that code is a bit of a mess
17:44 mgagne small: ~100 users/tenants
17:46 dprince joined #puppet-openstack
17:47 bodepd mgagne: does that include any keystone_user_role resources?
17:47 mgagne bodepd: yes it does. admin and all services.
17:48 bodepd iwi: you need to ensure that you install the master braches of everything and update the package repos
17:48 bodepd iwi:  and it *should* work
17:49 mgagne bodepd: was working on testing havana 2 weeks ago but changed focus ^^'
17:52 bodepd mgagne: I started testing it last week, but the upstream packages didn't work
17:53 mgagne bodepd: which upstream?
17:53 bodepd ubuntut precise proposed and updates havana
17:53 bodepd (uca)
17:53 bodepd updates were close to working (just nova-novnc package was broken)
17:54 bodepd ovs did not compile correctly on proposed
17:54 mgagne bodepd: oh, I though that "didn't work' meant "isn't working at all"
17:54 bodepd or was not compiled correctly
17:54 bodepd mgagne: I didn't really distiguish b/c my test systems are kind of treating the the same atm :)
17:54 mgagne =)
17:55 bodepd (partial failures as complete failures)
17:55 mgagne bodepd: damn, puppet-keystone was pin to 4821c6420d8566ef5e93453e3b2952259e0f225a on my side :-/
17:56 mgagne very old version :-/
17:56 bodepd mgagne: If I chuck this user_role code out there, do you have any interest in finishing it?
17:56 bodepd mgagne: I was trying to finish it over the weekend, but I ran out of time
17:56 mgagne bodepd: my work today is testing your patches and optimize it
17:57 bodepd mgagne: cool!
17:57 mgagne bodepd: mainly testing
17:57 bodepd I will send you one more
17:57 bodepd that *may* work
17:57 bodepd or at least seemed to late last night :)
17:57 openstackgerrit A change was merged to stackforge/puppet-nova: Pin to posgresql 2.5 module  https://review.openstack.org/47887
18:01 openstackgerrit Dan Bode proposed a change to stackforge/puppet-keystone: Refactor keystone_user_role to be lazier  https://review.openstack.org/47891
18:01 openstackgerrit Dan Bode proposed a change to stackforge/puppet-keystone: Do not set tenant description in cache  https://review.openstack.org/47673
18:02 bodepd mgagne: https://review.openstack.org/#/c/47891/1
18:03 mgagne will test asap
18:03 mgagne bodepd: working on updating puppet-keystone
18:08 bodepd mgagne: even with that patch, I was seeing some duplicated get tenant calls
18:18 hogepodge joined #puppet-openstack
18:32 mgagne bodepd: 40.32 seconds
18:33 mgagne bodepd: vs 200 seconds
18:38 otherwiseguy joined #puppet-openstack
18:43 mgagne bodepd: would you mind referencing bug #1224179 ?
18:44 bodepd mgagne: yeah, I never quite sorted all of those out
18:44 bodepd mgagne: that is where I finished last night. It seemed to work,but I still saw those calls
18:44 mgagne bodepd: cool thanks. patches seem to work fine. I don't know how to test corner cases
18:45 mgagne bodepd: which calls? there will be calls for managed users/tenants/roles
18:45 mgagne bodepd: are you telling results aren't cached properly?
18:45 bodepd mgagne: the extra tenant calls
18:45 bodepd mgagne: I'm not sure. I have a lot of faith that the other patches are perfect
18:45 bodepd mgagne: not so much for the last one
18:45 bodepd mgagne: I remember seeing extra tenant get (or list, I forgot) calls
18:46 bodepd mgagne: and, in general, the code was a bit complicated to be certain about
18:46 mgagne bodepd: I would have to enable debug and see what goes through
18:46 bodepd 400 to 40 seconds with all patches?
18:46 mgagne bodepd: yes
18:47 bodepd awesome!
18:47 bodepd mgagne: I'm curious how that would reduce your 10 minute run from Friday
18:47 mgagne thanks a lot! my coworker will sleep better now and stop hunting you ;)
18:47 bodepd mgagne: no worries, sorry for pestering  you during the weekend
18:47 mgagne bodepd: will check later today, testing staging
18:48 mgagne bodepd: it's ok, I don't mind ;)
18:48 bodepd mgagne: when I get into coding mode,it sometime overrides my etiquette sensors
18:48 mgagne bodepd: welcome to the club ;)
18:50 bodepd mgagne: I thought your production use case was 250 exist, 10 are managed?
18:50 bodepd mgagne: you just tested a subset of that?
18:50 mgagne bodepd: built-in users (nova, cinder), admin and 2 more users
18:50 mgagne bodepd: atm, I'm testing with a env. with only 100 users
19:03 mgagne bodepd: somehow, it went back to 200s o_O
19:04 openstackgerrit Mark T. Voelker proposed a change to stackforge/puppet-openstack: Add force_config_drive to openstack::all  https://review.openstack.org/47905
19:07 mgagne bodepd: forget it, misapplied a patch =)
19:35 ari joined #puppet-openstack
19:36 openstackgerrit Emilien Macchi proposed a change to stackforge/puppet-nova: Add Nova Cells support  https://review.openstack.org/41908
19:47 bodepd mgagne: the only thing I see is: closes bug
19:47 bodepd mgagne: is there not a syntax for referencing a bug?
19:47 mgagne bodepd: https://wiki.openstack.org/wiki/GitCommitMessages#Including_external_references
19:48 mgagne bodepd: Partial-Bug or Related-Bug
20:00 openstackgerrit Dan Bode proposed a change to stackforge/puppet-keystone: Make tenant name lookup for keystone user lazy  https://review.openstack.org/47696
20:01 openstackgerrit Dan Bode proposed a change to stackforge/puppet-keystone: Make tenant name lookup for keystone user lazy  https://review.openstack.org/47696
20:02 openstackgerrit Dan Bode proposed a change to stackforge/puppet-keystone: Do not set tenant description in cache  https://review.openstack.org/47673
20:03 mgagne bodepd: 907.49 seconds vs 53.48 seconds
20:04 openstackgerrit Dan Bode proposed a change to stackforge/puppet-keystone: Refactor keystone_user_role to be lazier  https://review.openstack.org/47891
20:05 bodepd mgagne: tee-hee-hee
20:05 bodepd mgagne: are you seeing duplicate calls still?
20:05 bodepd mgagne: did you check --debug to ensure there are not more calls we can trim out?
20:06 mgagne bodepd: I can check
20:06 bodepd I have a feeling I was not caching everything for the user_role stuff
20:06 bodepd I still think I can trim out N more tenant list of get calls
20:09 mgagne bodepd: I see the duplicate
20:10 mgagne bodepd: keystone_user_role get_users ?
20:10 mgagne bodepd: or get_tenants?
20:12 openstackgerrit Paul Belanger proposed a change to stackforge/puppet-openstack: Fix typo with vncserver_listen and internal_address  https://review.openstack.org/47916
20:21 mgagne bodepd: IMO, there is no "duplicate" due to the way data is stored
20:22 mgagne bodepd: double checking
20:25 mgagne bodepd: what's the purpose of get_users? is it a hash of tenants where values are the members (users) of it?
20:38 bodepd mgagne: it returns the users per tenant
20:38 mgagne bodepd: ok, how is it indexed?
20:38 bodepd mgagne: in the form of name -> id
20:38 bodepd mgagne: let me double check that
20:39 mgagne name of user? tenant?
20:39 bodepd mgagne: it is used in two contexts (which is probably part of the issue)
20:40 bodepd mgagne: when self.instances queries for all, it returns a hash of each user
20:42 bodepd mgagne: I'll put together what a fix might look like
20:43 mgagne bodepd: IMO, the issue is that the result is never cached
20:44 mgagne I might be wrong
20:46 bodepd mgagne: https://gist.github.com/bodepd/6676691
20:46 bodepd mgagne: I meant to write that code, but never finished
20:46 bodepd mgagne: I haven't tested that, but that is what a fix could look like
20:47 bodepd mgagne: let me know if you haveany questions
20:47 mgagne bodepd: checking
20:47 bodepd I'll run a quick test
20:47 bodepd and see if I can get you something that I at least think works :)
20:48 bodepd I'm also pretty sure that I need to index both the tenant and user
20:48 bodepd even though it seems a but odd
20:55 mgagne bodepd: http://paste.openstack.org/show/47396/
20:56 blkperl bodepd: mgagne: started discussion on puppet-dev about the release branches, https://groups.google.com/forum/#!topic/puppet-dev/xIMkS2GrZtw
20:57 ari joined #puppet-openstack
20:57 blkperl hopefully ashp and Hunner and hogepodge can weigh in too :)
20:58 hogepodge We want the release cycle to start ramping up.
20:59 hogepodge :blkperl
20:59 hogepodge I'm working on internal CI testing right now so we can have some assurance internally that the modules aren't breaking.
21:00 bodepd hogepodge: upsteam testing has alerted us of every single breakage
21:01 blkperl hogepodge: yeah thats great but its a seperate issue from whether or not to have release branches :)
21:01 bodepd hogepodge: based on upstream changes, and usually within hours of breakages
21:01 bodepd blkperl: or don't forget the possibility of just forking
21:01 mgagne hogepodge: IMO, there is confusion as to how/what to test in general.
21:01 bodepd blkperl: we can come back to upstream when it stabilizes at a later date
21:02 bodepd mgagne: there was a bug in that code
21:02 blkperl bodepd: forking is wasted effort though... some other project is going to have the same problem
21:02 blkperl like the foreman installer, openshift module, etc
21:03 mgagne hogepodge: Modulefile supports forge only, Puppetfile supports forge and git. .fixtures supports git only. When running rspec, against what should you be testing? And to some extend, if puppet-openstack wants to pin to 2.5, what happens if the end user installs an other module which requires 3.0?
21:03 openstackgerrit Dan Bode proposed a change to stackforge/puppet-keystone: Refactor keystone_user_role to be lazier  https://review.openstack.org/47891
21:03 blkperl mgagne: bodepd: hogepodge: make sure you send your comments to the list too, I don't want it lost in irc scrollback
21:04 bodepd mgagne: I updated that patch
21:04 mgagne bodepd: ok
21:05 bodepd mgagne: I ran some super-simple-naive tests on it. I have to move on for the day
21:05 mgagne bodepd: ok, will continue testing.
21:07 * mgagne hates Google groups interface
21:08 hogepodge The issues here. We're tracking head on the forge. That's a bug in the modules, and we need to release updated modules to fix those bugs.
21:09 hogepodge If we require 2.5, we require 2.5. We can update the modules to use 3. It's a bit annoying to blame the PL release cycle for our failure to accurately capture dependencies.
21:10 hogepodge Not releasing forge openstack modules is another issue. I'm completely to blame for the slowness on that. So beat away at me.
21:10 mgagne hogepodge: I do understand that PL can't track every projects using its module.
21:11 mgagne hogepodge: my concern is about the "ecosystem" in place to test modules.
21:11 hogepodge I want to find a solution to this, and there's no nefarious plotting over here at PL.
21:11 tvb joined #puppet-openstack
21:11 hogepodge So what I can I do to help address that?
21:12 mgagne hogepodge: I have no solution atm.
21:12 mgagne hogepodge: tracking master of upstream is not a good idea unless we (puppet-openstack) have a clear policy on what to do in case of failure
21:14 openstackgerrit Paul Belanger proposed a change to stackforge/puppet-openstack: Fix typo with vncserver_listen and internal_address  https://review.openstack.org/47916
21:14 blkperl so... I thought that we were going to track a major release of each module dependency for each major version of the openstack modules, so we need to update the modulefiles, puppetfiles, and .fixtures to track a major release.
21:14 mgagne how to bypass google groups interface: download raw message, open with thunderbird, reply all
21:15 bodepd hogepodge: all I've heard is puppetlabs folks complain about what we should fix
21:15 blkperl and that it would be nice to have a release branch for each major release of the dependencies
21:15 ryanycoleman joined #puppet-openstack
21:15 bodepd hogepodge: how many times has puppetlabs either informed us that they were going to introduce backwards incompat changes
21:15 hogepodge bodepd: tracking upstream is stupid
21:15 bodepd hogepodge: or volunteered to help
21:15 bodepd hogepodge: then help
21:15 hogepodge bodepd: expect breakage
21:15 bodepd hogepodge: then help
21:15 mgagne hogepodge: nobody is prepared for breakage
21:16 blkperl guys.... stop pointing fingers... we need to come up with a process that works for all of us
21:16 hogepodge bodepd: semver is a future announcement of breaking changes.
21:17 bodepd hogepodge: and in a real release cycle, you would also maintain a branch to allow changes on past versions
21:17 Hunner Hi. I'm kind of late to the party... is it modules that are the problem, or puppet? Which changes did we release? We try to correctly semver all module releases...
21:17 bodepd Hunner: a couple of issues.
21:18 bodepd Hunner: 1. it would be nice to get notice of expected backwards compat changes
21:18 bodepd Hunner: we are still tracking master of some modules for testing
21:18 bodepd Hunner: which is less than ideal, but the move towards more specific versioning is effort no one quite has the time for
21:18 bodepd Hunner: and if we are going to pin revisions for unit tests against modules
21:19 bodepd Hunner: having major version branches to pin to woudl be great
21:19 blkperl hence my email to puppet-dev
21:19 bodepd Hunner: so that we can apply patches to those branches and run against master
21:19 Hunner bodepd: Okay... we try to denote all backwards-incompat changes in the changelog during a release, but don't usually do it for PRs. We could leave comments in the merge commit that describe it's state, I guess
21:20 bodepd Hunner: aren't you guys all in the same buiding?
21:20 Hunner bodepd: We're also looking at doing major-version branches for the larger modules. (One of the main difficulties is smaller modules are often just so little code that "backporting" fixes usually means doing a rewrite)
21:20 bodepd Hunner: maybe a bigger question that I have is whether the internal teams can help with the specific compatibilty issues intternally
21:21 Hunner bodepd: Not all. I work from home often, ashp lives in boston...
21:21 bodepd Hunner: I guess the main thing I was hoping for is a 2.x release branch for postgresql
21:21 bodepd Hunner: which is not that big of a deal for that module
21:22 Hunner bodepd: How would you like the major version branches be tracked with respect to patches to the master branch? ATM we still don't have the manpower to actually backport changes... which has been our primary hold-out I think
21:22 bodepd Hunner: but in other cases it could be useful
21:22 bodepd Hunner: I haven't had to backport any patches yet (is that true...)
21:22 bodepd Hunner: but at least it's possible.
21:23 bodepd Hunner: and we can change out Modulefile, Puppetfile, and fixtures to one value
21:23 Hunner bodepd: Actually postgresql was one we were thinking about experimenting with major version branches on :) (because of the refactor that ken did)
21:23 bodepd Hunner: and not have to update them for each fix that needs to be ported
21:23 bodepd Hunner: postgresql is not that big of a deal (b/c I'mnot even sure if the code that depends on it is maintained atm)
21:24 ryanycoleman bodepd: how long would you expect us to maintain the last major version of a given module?
21:24 Hunner bodepd: Hmm... Modulefile and fixtures being conjoined would be nice. We don't control anything other than r10k that reads the Puppetfile (that was created by rodjek)... so that has kind of become a "de facto" standard for declaring modules
21:24 Hunner ryanycoleman: Oh hai :)
21:24 ashp ryanycoleman is everywhere ;)
21:25 ryanycoleman ...and his evil eye is always watching.
21:25 bodepd ryanycoleman: I don't have specific expectations in terms of how long I expect support
21:25 bodepd ryanycoleman: in my ideal world,I would probably just upgrade modules when there is a compelling reason to
21:26 bodepd ryanycoleman: but major version branches seems like it becomes a necessity when supported puppet version becomes an issue (ie: data in modules)
21:27 bodepd ryanycoleman: there is an additional issue I can't even think about atm which is if we choose major version of modules
21:27 bodepd ryanycoleman: and users want to use the latest, how does that work.
21:27 bodepd ryanycoleman: b/c I have no idea
21:29 Hunner bodepd: Our 2-man team can't realistically do major branches for ~70 modules, but it's something that we *want* to do and could/should happen in the future...
21:30 bodepd Hunner: the community can't realistically keep up with modules that constantly break backwards compat, and that are intended to target features only available in the lastest version of Puppet
21:30 kpaz joined #puppet-openstack
21:30 bodepd Hunner: I do understant your concern though
21:31 bodepd Hunner: from my perspective, I don't care if the major version branhces follow what one would typically expect in terms of backporting CVEs and what-not
21:31 ryanycoleman bodepd: I'm interested in supporting the latest stable major version for features/bugs/security and previous stable for bugs/security. Supporting the previous stable for 6 months or until the next stable major comes out - whichever is longer. If the logistics of that include maintaining branches for those two major supported versions, as Hunner said, we'll have to figure out when we can take that on.
21:31 bodepd Hunner: I just prefer them to exist so that occassional patches have a place to be backported to
21:31 Hunner bodepd: Yeah :( backwards-breaks suck. We're honestly trying to break them to "step-ladder" up to more stable branches, though!
21:32 ashp we just need to clone hunner 71 times
21:32 ashp and we're golden
21:32 Hunner False
21:32 bodepd ryanycoleman: I'm concerned about how that will work with changes like data-in-module refactors
21:33 bodepd ryanycoleman: changes like that that require a certain version is going to be extremely hard
21:33 bodepd ryanycoleman: to be able to switch every 6 months
21:33 ryanycoleman bodepd: if we shipped a PL module that depended on data-in-module refactors, that's a major breaking change that would be supported for 6 months or until we ship a new stable major release, whichever is longer. So, you'd have (at least) six months to change what your modules depend on.
21:33 mgagne bodepd: it isn't hard. deprecate the parameter for a couple of versions. It shouldn't vanish in the dark.
21:34 bodepd mgagne: I lost track of what you are referring to
21:34 mgagne bodepd: removing a parameter without deprecation could have serious consequences
21:34 ryanycoleman bodepd: that said, it's not like we're jumping all in on experimental Puppet versions like data-in-modules, so that example is maybe less applicable than shifting to major language features like iteration.
21:34 mgagne bodepd: data-in-module, parameter and stuff
21:34 ryanycoleman though that's also still experimental.
21:34 Hunner mgagne: Agreed. Though looking at the refactors of ntp/apache/mysql/postgresql... it's kind of hard to deprecate parameters when they don't have a matching endpoint after a refactor
21:35 mgagne Hunner: why is that?
21:35 bodepd Hunner: we try really hard to support deprecations
21:35 bodepd Hunner: and have been somewhat successful
21:35 mgagne this ^
21:35 Hunner mgagne: Usually because a rewrite happens all-at-once, not as a slow process
21:35 mgagne bodepd: I DO rely on this deprecation process
21:35 bodepd Hunner: once you start supporting stable code, and have users,it changes how you have to develop
21:36 Hunner mgagne: But we *do* try and only deprecate as much as possible, and that only if we can't stay compat
21:36 bodepd Hunner: part of the issue is that we're rediculously early adopters on all of this stuff at a time when it is being rewritten
21:36 Hunner bodepd: Yep. That's probably the friction we're hitting here :)
21:36 ryanycoleman bodepd: there's a key point there -- when we start supporting stable code. TBH, most of what we've been doing since the team formed in July is catch-up on crusty modules to get to a point where we have well-tested, supportable code.
21:37 Hunner crusty? Some of them are fossilised :)
21:37 bodepd Hunner: I don't mind updating to changed interfaces
21:38 bodepd Hunner: my main issue there is #1 who is going to do the work #2 how does it effect backwards compatibility of the modules
21:38 bodepd Hunner: I also have a feeling that more breakages are coming
21:38 bodepd Hunner: and I don't want to have to redo the effort every few months
21:38 mgagne Hunner: doing massive rewrite without a single line of "warning, please use this instead" is not trying to me
21:38 mgagne Hunner: https://github.com/puppetlabs/puppetlabs-postgresql/commit/cada1d7f1c54c6e3962a82b7d5047aa2ccdeb1f1
21:39 bodepd Hunner: you guys did this with ntp
21:39 bodepd Hunner: I've seen those deprecation warning on some parameter we are using
21:39 Hunner mgagne: That's in master branch... a major branch would def have helped there :/
21:40 mgagne Hunner: refactors have been done in the same way each time.
21:40 mgagne Hunner: a huge refactor in a single commit.
21:40 mgagne Hunner: how are we supposed to handle that?
21:40 ryanycoleman mgagne: can't you use the latest stable version instead of the master branch?
21:41 mgagne ryanycoleman: can you tell me how?
21:41 Hunner <and we're back to tooling>
21:41 ryanycoleman mgagne: pin via librarian-puppet or r10k or tell the module tool to install specific versions. checkout the relevant git tags.
21:42 mgagne ryanycoleman: how do I do this with rspec?
21:42 ryanycoleman mgagne: or as we're discussing, we could potentially maintain branches for the current and last stable releases. though, i'd still like to understand where the above fall over.
21:42 ryanycoleman mgagne: see ^
21:42 Hunner mgagne: The fixtures can take a ref
21:42 mgagne Hunner: back to square one
21:42 ryanycoleman mgagne: how so?
21:42 bodepd Hunner: we can't do massive refactors in a single commit
21:43 bodepd Hunner: b/c it's too hard to maintain backwards compat
21:43 bodepd Hunner: and it's too hard to track the changes
21:43 bodepd Hunner: well, we have some massive commits for massive non-backwards-compat breaking changes
21:43 mgagne bodepd: sorry, incoming wall of text.
21:43 mgagne bodepd: What should be our policy regarding dependencies?
21:43 mgagne bodepd: Should we only support released versions? We could therefore track tags instead of master in .fixtures.
21:43 mgagne bodepd: This would also imply that upstream would have to release more even and not let bug fixes rot in master for months.
21:43 mgagne bodepd: They would also have to tag all releases.
21:43 mgagne bodepd: This could however become cumbersome to maintain as there is no way to tell .fixtures.yml to track minor versions.
21:43 mgagne bodepd: Someone or something would have to update .fixtures.yml every time a release is done.
21:43 mgagne bodepd: However our modules wouldn't get a change to test against the next minor version (or major) until its released.
21:44 bodepd mgagne: we can't just track released versions
21:44 ryanycoleman bodepd: similarly, we can't just keep master stable
21:44 bodepd mgagne: actually, let me think about that
21:44 mgagne bodepd: "or something" could be a script IF upstream tags their releases
21:44 mgagne ryanycoleman: no no no
21:44 ari joined #puppet-openstack
21:44 bodepd ryanycoleman: again, that is why our ask has been stable branches
21:45 mgagne ryanycoleman: that is being lazy
21:45 kpaz hi all - should i be concerned about these warning when running through the various manifests: Warning: Failed to match dpkg-query line "No packages found matching cinder-volume.\n"    i get that note for 10-15 different packages during an install.....
21:45 ryanycoleman for PL modules, you can absolutely expect tags that match releases.
21:45 ryanycoleman bodepd: cool, that's a reasonable ask though a bit labor intensive.
21:45 mgagne ryanycoleman: go tell that to openstack that shouldn't expect master to be stable.
21:45 ryanycoleman mgagne: sorry
21:45 bodepd ryanycoleman: having us track master has never been on the table AFAIK
21:45 Hunner mgagne: I expect master to be functional. (I don't know if that's what you mean by "stable")
21:46 blkperl kpaz: sounds like a puppet 3.3.0 regression
21:46 bodepd kpaz: that sounds concerning. You probably did not set up the package repos
21:46 mgagne kpaz: make sure you have a repo with openstack packages available
21:46 ari joined #puppet-openstack
21:47 bodepd ryanycoleman: mgagne baby steps ;)
21:47 bodepd kpaz: https://github.com/stackforge/puppet-openstack/tree/master/manifests/repo
21:47 kpaz i'm on puppet 3.3.0 and i setup my repo as follows: echo "deb http://ubuntu-cloud.archive.canonical.com/ubuntu precise-updates/grizzly main" > /etc/apt/sources.list.d/grizzly.list      should i try a different puppet version?
21:48 mgagne Hunner: how should we handle dependencies? what is the "right way" to do it?
21:48 mgagne kpaz: does it work after apt-get update?
21:48 bodepd kpaz: yeah,you may want to try with PUppet 3.2.x and see if it goes away
21:49 mgagne Hunner: we (as most puppet dev) use .fixtures.yml to manage our fixtures and dependencies in rspec tests.
21:49 * blkperl is fairly certain that its a known puppet 3.3.0 bug that will be fixed in 3.3.1
21:49 kpaz i do an apt-get update before kicking off any of the puppet bits....  the weird thing is that the packages it complains about seem to be installed after the run
21:49 kpaz sounds good - thanks all
21:49 Hunner mgagne: I'd love the fixtures to support the forge :). Here's a PR that is adding mercurial support... https://github.com/puppetlabs/puppetlabs_spec_helper/pull/41
21:50 mgagne Hunner: forge would be a "good start" IF upstream release (much more) often.
21:50 bodepd Hunner: mgagne I would be a bit concerned about fixtures working against the forge
21:50 mgagne Hunner: I had to do release myself as bug fixes were rotting in master
21:50 bodepd Hunner: mgagne what about the case where something is broken?
21:50 bodepd Hunner: mgagne we need to be able to recover teh build system ASAP
21:51 Hunner bodepd: Thanks for the input though. I imagine that we can try to be more aware of how downstreams can handle this in the future :)
21:51 Hunner mgagne: We're mosdef trying to get more frequent releases!
21:51 bodepd and honestly, maybe we need to just be able to target stable released from the forge from fixtures...
21:51 bodepd and Puppetfile
21:51 ryanycoleman ++
21:51 blkperl +1 to that
21:51 mgagne Hunner: my concern is that I do know how it should be done. I feel the ecosystem is lacking workflow or "features" in that regard
21:52 Hunner mgagne: Poke us when you need releases! Usually we just lose track of when various things are released... and we don't have a mechanism for auto-releasing yet (but it's in the works)
21:52 ryanycoleman mgagne: if we can solve problems with improved tools (like fixtures.yml grabbing stable versions from forge or github to test against), that's simply what we need to build for you!
21:52 Hunner blkperl++ pokes us a lot ;)
21:53 bodepd ryanycoleman: if fixtures and Puppetfile supported getting stable releases from the forge, that would probably work
21:53 Hunner mgagne: Also, I don't think I've met you in person. What's your relation to OS? Do you work with dan or what?
21:53 bodepd ryanycoleman: that seems like it requires the branches that we are asking for
21:53 ashp yeah just copy blkperl and shout loudly if you see we're missing something
21:54 ashp it mostly just comes down to ~70 modules, 2 people, and no system that lives in front of github to manage it all
21:54 ryanycoleman bodepd: ok, cool. seems like a decent place to start anyway.
21:54 mgagne Hunner: I'm an OpenStack user/dev/admin who happens to use puppet modules to maintain the infra. I found out modules had a lot to be improved and contributed back.
21:55 Hunner mgagne: Work with clarkb at all?
21:55 Hunner or cboylan... I don't know his freenode nick
21:55 bodepd clarkb
21:55 mgagne Hunner: I "know" clarkb like most people involved in stackforge projects "knows" him.
21:56 mgagne Hunner: I do happen to contribute if it falls in my field of expertise.
21:57 bodepd mgagne: I'm still seeing quite a few issues with that last patch
21:57 Hunner I know clarkb from uni and met jtopjian at one of the OS summits... just trying to draw lines :)
21:57 mgagne Hunner: I'm a stranger =)
21:57 openstackgerrit Emilien Macchi proposed a change to stackforge/puppet-neutron: Add Neutron service_plugins support  https://review.openstack.org/46351
21:57 mgagne ryanycoleman: I'm under the (false?) impression that PL should handle that part. I mean, it's their "product" and I kind of feel those tools should be provided/contributed by PL. It is why I feel disappointed when I can't find answers to my problems/challenges.
21:58 ryanycoleman mgagne: which part? fixtures.yml?
21:58 mgagne ryanycoleman: regarding testing, dependency management and that sort of things.
21:58 mgagne ryanycoleman: regarding how a "good puppet module author" should handle those things.
21:59 ryanycoleman mgagne: yeah, i agree.
21:59 Hunner bodepd: Oh! I get why master is so interesting... "git flow" style means only tagged releases are merged to master
21:59 mgagne Hunner: no
22:00 mgagne Hunner: well, I don't care about git flow tbh
22:00 Hunner mgagne: In the git-flow diagram on http://nvie.com/posts/a-successful-git-branching-model/ we could probably have their "master" be our "stable" and their "develop" be our "master"
22:00 mgagne Hunner: here at openstack/stackforge, everything is merged in master after a review on gerrit. There is no major refactor breaking everything allowed.
22:00 Hunner mgagne: I'm just looking for something to model against instead of re-inventing the wheel. I can't expect GH PRs to be submitted to non-master branches, unfortunately :(
22:01 mgagne Hunner: why not?
22:01 Hunner mgagne: github defaults to master and I can't change the community (since it's pretty loose-knit)
22:01 mgagne Hunner: https://help.github.com/articles/using-pull-requests#changing-the-branch-range-and-destination-repository
22:02 Hunner :o
22:02 mgagne Hunner: you can change the default branch
22:02 mgagne Hunner: but that's not the issue. could be named baboon and I couldn't care less.
22:03 Hunner mgagne: Would you be strongly opposed to using master as develop and having a "stable" branch that only receives tagged releases?
22:03 Hunner (it's just a semantics thing)
22:03 mgagne Hunner: I'm interested in HOW downstream can better handle dependencies. Git workflow in upstream is an other problem in itself.
22:03 Hunner (since as you point out it is possible to change the default branch)
22:04 mgagne Hunner: amplified by the fact we don't know how to properly handle dependencies/fixtures.
22:04 Hunner mgagne: (fwif, We've looked at using something like gerrit and decided it's a bit too much overhead to get going atm)
22:04 mgagne Hunner: dude, it changed my life for the best.
22:05 Hunner I know! It looks awesome! But again, two-man-team and lack of cohesive testing frameworks...
22:08 mgagne Hunner: bathroom gets me idea
22:08 mgagne Hunner: what about
22:09 mgagne Hunner: 2 sets of tests. One against "stable" (the latest released version on forge) and an other against "unstable" (master) which could be non-voting. (on gerrit)
22:10 mgagne Hunner: someone, a monkey or just a script would update the stable fixtures every times a release is made.
22:10 Hunner mgagne: I like that :)
22:10 mgagne Hunner: non-voting will start to fail once a refactor/commit-bomb is done.
22:11 mgagne Hunner: the challenge is training a monkey to update .fixtures.yml
22:11 blkperl mgagne: don't you need 3 sets of tests? 1) agaisnt "module dep", "lastest forge", "unstable"
22:11 mgagne Hunner: and maybe make rspec tests support multiple "fixture groups"
22:11 mgagne blkperl: that too. don't complicate things =)
22:12 blkperl :D
22:12 mgagne blkperl: https://bugs.launchpad.net/puppet-openstack/+bug/1209431
22:12 ryanycoleman joined #puppet-openstack
22:12 mgagne ryanycoleman: you missed everything
22:13 mgagne Hunner: and to some extend, my concern is also about the forge ecosystem itself.
22:14 mgagne Hunner: how can we publish "unreleased" artifact to forge (or somewhere) and be able to test against it before it's released?
22:20 blkperl mgagne: I don't think the forge supports that
22:20 blkperl but yes I would like to see the abilty to push RC releases without them being the default
22:21 ryanycoleman mgagne: :( I need to get my znc bouncer going again.
22:21 mgagne blkperl: this would help us test against potential future release and maybe use it ourselves to test our modules
22:22 ryanycoleman blkperl: with a modern PMT version (3.0+ iirc), you can push releases that comply with SemVer expressions of a pre-release or RC and the module tool will not prefer it over 'stable' versions -- you'd have to explicitly ask for it. That said, I don't think librarian-puppet respects the same rule.
22:23 ryanycoleman I would like to offer a non-production Forge that people can throw any release at for testing, tinkering or whatever else. We're not terribly far from being able to do that.
22:24 blkperl ryanycoleman: why isn't that a decision made by the forge webapp?
22:24 blkperl that way it would be backwards compatible...
22:24 mgagne ryanycoleman: shouldn't be hard to do tbh.
22:25 ryanycoleman blkperl: because legacy?
22:25 blkperl :S
22:26 mgagne who cares about legacy? ;)
22:26 ryanycoleman yeah.. long-story short, we're a bit limited by the v1 API that PMT conforms to but yeah, obviously we'd like to shift logic like that onto the Forge service where it can be more intelligently managed.
22:31 mgagne ryanycoleman, Hunner: if we want to use tags for fixtures, we would REALLY need PL to tag all releases. In my experience, it has not always been the case.
22:33 ryanycoleman mgagne: from this point forward, you should expect us to tag all releases. historically, i agree that it's not always been the case. Sometimes it just gets forgotten but Hunner and ashp kick ass and get to do this all day every day.
22:33 mgagne ryanycoleman: cool thanks
22:34 mgagne ryanycoleman: it probably got fixed recently but it's a pain to have such thing in a Puppetfile:
22:34 mgagne # v3.2.0
22:34 mgagne mod "stdlib",
22:34 mgagne :git => "https://github.com/puppetlabs/puppetlabs-stdlib.git",
22:34 mgagne :ref => "e1f2a932883c71038d78938efd46cdb30c01da6d"
22:35 ryanycoleman mgagne: the pain is the reference instead of git tag?
22:36 mgagne ryanycoleman: sure, at first glance, which version is this ref referring too? I have to add a comment. and I can't automate that process if I wanted.
22:37 bodepd I was in a meeting.
22:37 bodepd what did I miss?
22:37 ryanycoleman mgagne: cool. i wasn't aware that fixtures couldn't do tags. agreed, that sucks. we ought to be able to add that in, though some exploration is needed before I can be sure.
22:37 mgagne ryanycoleman: it can do tag
22:37 bodepd ryanycoleman: mgagne they can
22:37 mgagne ryanycoleman: when they are there!
22:37 ryanycoleman mgagne: oh, then i'm still confused. what does it need to do?
22:37 ryanycoleman just that they're not usually there?
22:37 mgagne ryanycoleman: tag releases so I don't have to use the ref
22:38 mgagne ryanycoleman: the SHA1
22:38 mgagne ryanycoleman: summary: please keep tagging, otherwise it's a pain (sha1 in puppetfile being one of the reason)
22:39 ryanycoleman mgagne: ah. so the only change required is that we just have accurate tags? Holy crap that's doable.
22:39 bodepd mgagne: I'm still a little on the fence about that
22:39 bodepd mgagne: it would be at the least inconsistent with how we manage the Modulefile
22:40 bodepd mgagne: where we use '~'
22:40 mgagne bodepd: the script/monkey could be aware of Modulefile too
22:40 bodepd bodepd: and it uses that as the version to pullin for testing?
22:41 * mgagne waits bodepd to answer himself
22:42 ryanycoleman sounds to me like there are still situations where we'd want branches for the latest stable release and so on. between those two options, I think we'd be in a much better state.
22:42 mgagne ryanycoleman: that is doable too. but other 3rd party modules won't depend on that version for long.
22:43 mgagne ryanycoleman: one day or an other, you will have version conflicts
22:46 ryanycoleman yeah
22:47 mgagne Hunner: poke poke https://github.com/puppetlabs/puppetlabs-mongodb
22:51 mgagne ryanycoleman: mind tagging this release? https://github.com/puppetlabs/puppetlabs-rabbitmq/commit/36f37c6c57728f4313ec678ae1fc6e3a2f758425
22:52 bodepd so, are we talking about somethign that automatically updates fixtures?
22:52 bodepd I lost what the decision was
22:52 mgagne bodepd: I don't mind giving it a try if you don't mind
22:52 bodepd ryanycoleman: by the way, I got GTA V over the weekend :)
22:52 ashp i'll tag it, it's my screwup anyway, let me check
22:52 ryanycoleman ashp++
22:53 ryanycoleman bodepd: yeah? 360? i spent effectively the whole weekend with that.
22:53 ashp done!
22:53 mgagne thanks!
22:53 bodepd ryanycoleman: I had a 360 that I thought was broken, but it lives on!
22:53 ryanycoleman woot!
22:53 bodepd sorry, I missed the decision
22:54 bodepd would someone mind summarizing
22:54 bodepd are we talking about forge support for .fixtures?
22:54 mgagne bodepd: I suggested having 2 sets of test: one against latest and greatest (same thing as before) and one against latest stable/released version
22:54 blkperl hogepodge: you don't seem to be in #puppet
22:55 mgagne bodepd: latest and greatest don't have to be voting
22:55 mgagne bodepd: any breakage will be "soft"
22:55 bodepd mgagne: do the tests consume hte Modulefile for the breaking tests?
22:55 bodepd mgagne: they are always going to be failing
22:55 hogepodge mgagne: astute observation
22:55 mgagne bodepd: anything is possible at zombo.com
22:56 bodepd mgagne: so what is the point of having tests that always fail
22:56 mgagne bodepd: the objective is to have a warning until we can fix stuff
22:56 Hunner mgagne: Poking for a release, or for PRs?
22:56 mgagne bodepd: we can't depend on 2.x forever
22:56 mgagne Hunner: checking if it's still alive ;)
22:57 bodepd mgagne: can we fix stuff without breaking backwards compat?
22:57 mgagne bodepd: I don't know. To me, it's 2 separated problems.
22:57 bodepd mgagne: if we are maintaining a bunch of code that cares about backwards compat,then updating to master of something that doesn't, and constantly changes, won't work
22:58 bodepd mgagne: it seems like there will be periods of sweeping changes where we choose to update dependencies
22:58 mgagne bodepd: 1) tracking master which has no guaranty to always be the same major version. 2) Refactor/commit-bomb. It's an upstream "problem".
22:58 bodepd mgagne: it seems like it's only going to get worse
22:59 mgagne bodepd: don't be too negative =)
22:59 bodepd ryanycoleman: wasn't that the concensus? you guys want to use the latest and greatest features, move fase, and break things?
22:59 bodepd mgagne: not meaning to be nagative
22:59 ryanycoleman bodepd: no, that's not exactly how I'd characterize it.
22:59 bodepd mgagne: that was my understanding
23:00 bodepd mgagne: I don't understand what you mean by #2
23:01 mgagne bodepd: updating .fixtures.yml by hand is a pain. lets fix that. We want to be informed of breakages without having our gates blocked, lets make it non-voting then and rely on the latest stable version.
23:01 mgagne bodepd: I don't have much control on how stuff gets merged upstream.
23:01 bodepd mgagne: fix that by creating an automated process?
23:01 mgagne bodepd: yes
23:02 bodepd mgagne: what does this process do?
23:02 mgagne bodepd: We can give advices on how to improve the process however they can do whatever they want with our advices.
23:02 bodepd mgagne: (I have a feeling it does the same as a major release branch )
23:02 mgagne bodepd: could be a script we manually run which tries to find the latest released version on forge and update the ref accordingly.
23:03 mgagne bodepd: and it could use Modulefile to limit itself to a range of supported versions.
23:03 mgagne bodepd: breakage will occur but in a controlled way.
23:03 bodepd mgagne: why not just not have a ref? and have it parse the Modulefile?
23:03 mgagne bodepd: breakage in a minor version will still be a bug.
23:04 bodepd mgagne: to get the tag to use
23:04 mgagne bodepd: that could be a solution too.
23:04 bodepd ryanycoleman: is that a forge API?
23:04 bodepd ryanycoleman: I give you a range: ie: ~2, and it gives me back a version?
23:04 mgagne bodepd: or no tag at all. download from forge and use it.
23:05 bodepd mgagne: do we want to use it's dependency managemnt stuff?
23:05 mgagne bodepd: forge's dependency management?
23:05 mgagne bodepd: I guess it would bring its own challenges
23:05 bodepd yeah, if you download a module from the forge,it wants to bring in all of its friends
23:05 bodepd surely this would not work
23:05 ryanycoleman bodepd: i don't think it's currently capable of doing that exact operation. we are working on a ruby library to work with the upcoming v3 Forge API that will (amongst other things) let you off-load dependency management to the library.
23:06 bodepd ryanycoleman: I don't think we would want to use dependency management
23:06 mgagne bodepd: you can change this behavior
23:06 bodepd ryanycoleman: at least initially
23:06 mgagne bodepd: you can ignore dependencies
23:06 mgagne bodepd: or you can point to the tarball directly
23:06 bodepd so, then what is the syntax in the fixtures file?
23:06 ryanycoleman bodepd: i thought we had roughly settled on ensuring that we're always tagging releases in git (no brainer), exploring maintaining branches for the latest major version and the one previous (perhaps just for a few big modules, not all 70+) and referencing specific versions where applicable.
23:07 bodepd ryanycoleman: oh
23:07 bodepd ryanycoleman: if you support major version branhces when you breack backwards compat
23:07 ryanycoleman I suppose you could tack a script on top that would update fixtures to reflect the minor and patch versions
23:07 bodepd ryanycoleman: then, we don't need anything else
23:07 bodepd ryanycoleman: we can just target those branches and call it a day
23:07 bodepd mgagne: then why are we talking about this :) perhaps b/c I am just behind :)
23:08 bodepd ryanycoleman: ashp Hunner is that fair, you guys don't need to support major version branches on all modules,just the ones where you choose to break backwards compat ?
23:08 mgagne bodepd: I'm not counting on that. updating fixtures will always be a reaction to a release and will result in the same pain as today: damn, they broke it again, I have to update the f**king fixtures again.
23:08 ryanycoleman bodepd: man, i'm re-typing everything from a couple hours ago, but we had discussed the latest major version and the previous major version having branches. The previous major would be supported for six months or until a new major version is released, whichever is longest. Though, we aren't ready to do all this yet, need to work towards it.
23:09 bodepd ryanycoleman: sorry, so much was said, I wasn't sure if anything was agreed upon
23:09 mgagne ryanycoleman: bodepd was in a meeting.
23:09 bodepd mgagne: not if we can just target major releases
23:09 bodepd mgagne: or am I missing something...
23:10 mgagne bodepd: when will that branch appear? after a major refactor? after a release? and when will you find out about it? after a breakage in gate?
23:10 bodepd mgagne:  hopefully before a breakage in backwards compat
23:11 bodepd mgagne: honestly, I don't mind if we just react to breakages by targetting a major release branch
23:11 bodepd mgagne: our stumbling block was that upstream said no
23:11 mgagne bodepd: then statu quo is the answer. we already have branch for major modules.
23:11 * ryanycoleman is going afk for a few
23:12 mgagne bodepd: but I feel it won't ease the pain.
23:12 bodepd mgagne: it's no different than what you proposed.
23:12 bodepd mgagne: except it doesn't involve any new code
23:12 mgagne bodepd: a tag doesn't break by itself
23:12 mgagne bodepd: a new refactor would break non-voting jobs first
23:12 bodepd mgagne: we are not talking about immutable tags, but mutable branches
23:13 mgagne bodepd: I'm talking about both
23:13 bodepd mgagne: why tags?
23:13 mgagne bodepd: to target specific released versions
23:13 bodepd mgagne: why would we ever want to target specific releaed versions?
23:13 bodepd released
23:13 bodepd mgagne: even the modulefile targets a range
23:14 bodepd mgagne: (which should be the slowest moving target)
23:14 mgagne bodepd: to avoid HEAD which can break at anything.
23:14 bodepd mgagne: I wasnt talking about HEAD,but about stable branches
23:14 bodepd mgagne: stable branches vs. tags
23:15 bodepd mgagne:  if your only issue the question of where do the braches?
23:15 bodepd mgagne: ideally, the would be created by upstream before the breack backwards compat
23:15 bodepd mgagne: and even more ideally, we would be informed when it happens
23:15 bodepd mgagne: s/when/before/
23:15 mgagne bodepd: we are always reacting and screaming about it!
23:16 bodepd mgagne: this discussion was started b/c they said no to major branches
23:16 bodepd mgagne: (AFAIK)
23:16 bodepd mgagne: I agree that switching to major branches does not solve one problem
23:17 bodepd mgagne: the case where a module goes from master to the branch that does not yet exist
23:17 mgagne bodepd: I'm proposing a solution which I feel could answer some needs. I don't mind contributing to a solution which could involve work on our side.
23:18 bodepd mgagne: ah,which is the .fixtures to consume the Modulefile to figure out what version to use?
23:18 bodepd mgagne: ideally, it would say:
23:18 mgagne bodepd: yes...
23:18 bodepd 1. check version in modulefile
23:18 bodepd 2. check to see if there is a matching major release branch
23:19 bodepd 3. if not, use master?
23:19 mgagne bodepd: everything is possible
23:19 mgagne bodepd: they have 70 modules to maintain and they are only 2 maintaining it. We just can't impose them a workflow.
23:19 bodepd then
23:19 bodepd 1. check version in Modulefile
23:19 bodepd 2. chekc to see if there is a matching major release branch
23:20 bodepd 3. get the tag that mathcs the latest acceptable version
23:20 mgagne bodepd: tags don't care about branches
23:20 mgagne afaik
23:21 bodepd I dont understand
23:21 bodepd if we use the Modulefile, and it targets a range
23:21 bodepd that either targets a branch (ideally)
23:21 bodepd master
23:21 bodepd or a tag
23:21 bodepd there is nothing else it could target that we can programatically consume
23:22 mgagne bodepd: just have a script to handle it. (your proposition) test against HEAD of master with non-voting jobs to be proactively informed of breakage.
23:23 mgagne bodepd: with that, you have tests against stable versions and unstable versions.
23:23 bodepd mgagne: ok
23:23 bodepd sound like a plan
23:23 bodepd I;ll responsd with this to the lizt
23:24 mgagne bodepd: updating fixtures will have to be done via gerrit anyway (being a script, a monkey or a banana) so you won't be able to update to a tag if tests aren't passing.
23:25 bodepd I was thinking about the rake task using .fixtures and figuring that part out
23:26 mgagne bodepd: could be an env variable too or whatever
23:26 mgagne bodepd: you mean the update? lets experiment with a poc
23:26 mgagne bodepd: I want to find time this week to experiment.
23:40 mgagne bodepd: I'll test your patch tomorrow. I have to go now. I want to get it merged tomorrow and backported.
23:40 ryanycoleman joined #puppet-openstack
23:47 Hunner mgagne: I think mongodb is one of the "lesser" modules that we hope to defer to the community on to lighten our load
23:52 badiane_ka joined #puppet-openstack
23:57 dmsimard joined #puppet-openstack

| Channels | #puppet-openstack index | Today | | Search | Google Search | Plain-Text | summary