Hi all, I''m in the throes of the REST conversion and I''m wondering: How important is it to retain backward compatibility? The language will clearly be consistent between the two, but it looks like it''s going to be a heckuva lot more complicated to keep compatibility for all network services (as in, for each of them, I''ll have to write a shell that talks to the new services but provides the old API). The only real complication for people is that they''d have to run two servers temporarily, one for the new clients and one for the old clients. I could *possibly* also just freeze the existing code and throw warnings when it''s used, but I haven''t yet looked into how complicated that''s going to be. This (in addition to refactoring the RAL) is, IMO, one of the major steps toward 1.0, because it will provide a published, constant API. Comments? -- The Microsoft Exchange Information Store service depends on the Microsoft Exchange Directory service which failed to start because of the following error: The operation completed successfully. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
> > The only real complication for people is that they''d have to run two > servers temporarily, one for the new clients and one for the old > clients. >you mean with the same puppet recipe ? Two servers using the same files for the recipes ? -- Cordialement, Ghislain _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On 9/4/07, Luke Kanies <luke@madstop.com> wrote:> Hi all, > > I''m in the throes of the REST conversion and I''m wondering: How > important is it to retain backward compatibility? The language will > clearly be consistent between the two, but it looks like it''s going > to be a heckuva lot more complicated to keep compatibility for all > network services (as in, for each of them, I''ll have to write a shell > that talks to the new services but provides the old API).I can see going either way. On the one hand, it''s nice to have puppet around to upgrade puppet. ;) On the other, changing between XML-RPC and REST is a huge change, and not having to keep the back compat code around will greatly simplify puppet faster. If you do provide back compat support, I think it needs to have a timeline where it will be removed entirely. What if it was only supported in the client? Then you could use puppet to manage your puppet client upgrade with the old server, upgrade to the new server, and you''re done? Adam -- HJK Solutions - We Launch Startups - http://www.hjksolutions.com Adam Jacob, Senior Partner T: (206) 508-4759 E: adam@hjksolutions.com
On Sep 4, 2007, at 11:24 AM, Adam Jacob wrote:> > I can see going either way. On the one hand, it''s nice to have puppet > around to upgrade puppet. ;) On the other, changing between XML-RPC > and REST is a huge change, and not having to keep the back compat code > around will greatly simplify puppet faster. > > If you do provide back compat support, I think it needs to have a > timeline where it will be removed entirely.Definitely. This next release will clearly need to be 0.24.0, and the RAL refactor (hopefully) will be 0.25.0. By 0.26.0, which should be the release candidate for 1.0, I''d expect to have deprecated XMLRPC, and possibly by 0.25.0.> What if it was only supported in the client? Then you could use > puppet to manage your puppet client upgrade with the old server, > upgrade to the new server, and you''re done?Unfortunately, that doesn''t change the complexity of it by much, and the real problem is how you upgrade the hundreds or thousands of clients, rather than how you upgrade the couple of servers. Hrm. I''ll update later when I have a more realistic idea of what this kind of shell will look like. Maybe it''ll be easy to just freeze the existing code and not even connect it to the new code. You want new functionality, upgrade your clients. -- Always behave like a duck - keep calm and unruffled on the surface but paddle like the devil underneath. -- Jacob Braude --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Sep 4, 2007, at 11:10 AM, ADNET Ghislain wrote:> you mean with the same puppet recipe ? Two servers using the same > files for the recipes ?Yes. The files shouldn''t need to be different, just the processes. Of course, I say this, but I''m plannin on adding a couple of new functions to Puppet''s language, and they''d only be in the new process. Drat. -- Today I dialed a wrong number...The other person said, "Hello?" and I said, "Hello, could I speak to Joey?"... They said, "Uh...I don''t think so...he''s only 2 months old." I said, "I''ll wait." -- Steven Wright --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On 9/4/07, Luke Kanies <luke@madstop.com> wrote:> Hrm. I''ll update later when I have a more realistic idea of what > this kind of shell will look like. Maybe it''ll be easy to just > freeze the existing code and not even connect it to the new code. > You want new functionality, upgrade your clients.That makes total sense to me. Adam -- HJK Solutions - We Launch Startups - http://www.hjksolutions.com Adam Jacob, Senior Partner T: (206) 508-4759 E: adam@hjksolutions.com
Luke Kanies a écrit :> On Sep 4, 2007, at 11:10 AM, ADNET Ghislain wrote: > > >> you mean with the same puppet recipe ? Two servers using the same >> files for the recipes ? >> > > Yes. The files shouldn''t need to be different, just the processes. > > Of course, I say this, but I''m plannin on adding a couple of new > functions to Puppet''s language, and they''d only be in the new > process. Drat. >i think this is not an issue as if you flag them and everybody is aware that those NEW things should work only in the new client/server then no issue. I think the sooner the API is stable and documented the better. I plan to use puppet at the core of my system and if the API is not stable you cannot think of doing any work of fear it would break and be useless on the next release :) Running two server is really easy and puppet can, with facter, recover the version and manage automaticaly the client configuration to go on the good server using a simple fact case so i see no issue here. -- Cordialement, Ghislain _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 04 September 2007, Adam Jacob wrote:> On 9/4/07, Luke Kanies <luke@madstop.com> wrote: > > Hrm. I''ll update later when I have a more realistic idea of what > > this kind of shell will look like. Maybe it''ll be easy to just > > freeze the existing code and not even connect it to the new code. > > You want new functionality, upgrade your clients. > > That makes total sense to me.+1 Regards, DavidS - -- The primary freedom of open source is not the freedom from cost, but the free- dom to shape software to do what you want. This freedom is /never/ exercised without cost, but is available /at all/ only by accepting the very different costs associated with open source, costs not in money, but in time and effort. - -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG3k0O/Pp1N6Uzh0URAs1FAJ94Awb4ne2OfcZRARIfgfIK4jwL6wCgkJQN ZqoP7QO3rJe5ThjVX4o6WaA=tX/D -----END PGP SIGNATURE-----
> > I''m in the throes of the REST conversion and I''m wondering: How > important is it to retain backward compatibility?We were discussing this only yesterday. In the _general_ case it''s VITAL. Yes, I''m shouting: VITAL. The case in point was a change to a method that broke the way we do nfs mounts (I''ll leave the guys working on it to detail it if they are so inclined). That required a lot of work to fix (I guess at least 6 person days) and every time something like that happens we end up questioning whether Puppet is an economically viable tool. In the particular case of the REST/XMLRPC change however the change is so great that it actually makes more sense to me not to provide backwards compatibility. My reasoning is that we can formulate the change as a mini-project and do the whole thing properly whereas if things are left we''ll be stung a couple of point releases down the line when the compatibility is (sensibly) dropped. Matthew ------------------------------------------------------------------ Visit Guardian Unlimited - the UK''s most popular newspaper website http://guardian.co.uk http://observer.co.uk ------------------------------------------------------------------ The Newspaper Marketing Agency Opening Up Newspapers http://www.nmauk.co.uk ------------------------------------------------------------------ This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News & Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News & Media Limited A member of Guardian Media Group PLC Registered Office Number 1 Scott Place, Manchester M3 3GG Registered in England Number 908396
David Schmitt wrote:> On Tuesday 04 September 2007, Adam Jacob wrote: >> On 9/4/07, Luke Kanies <luke@madstop.com> wrote: >>> Hrm. I''ll update later when I have a more realistic idea of what >>> this kind of shell will look like. Maybe it''ll be easy to just >>> freeze the existing code and not even connect it to the new code. >>> You want new functionality, upgrade your clients. >> That makes total sense to me. > > +1+2 Regards James Turnbull -- James Turnbull <james@lovedthanlost.net> --- Author of Pro Nagios 2.0 (http://www.amazon.com/gp/product/1590596099/) Hardening Linux (http://www.amazon.com/gp/product/1590594444/) --- PGP Key (http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0C42DF40) _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
Couldn''t you provide an ''Upgrade Guide'' and a recipe that does the following: 1) Install new client into some alternate path using old client 2) Stop (but don''t remove) old client 3) Use new client to pull from new server 4) New manifest replaces old puppet client and removes alternate path client 5) (In theory) Done The details might be a bit complicated, but it seems like it should work and would let you jettison the old code all at once. Trevor On 9/4/07, Luke Kanies <luke@madstop.com> wrote:> On Sep 4, 2007, at 11:10 AM, ADNET Ghislain wrote: > > > you mean with the same puppet recipe ? Two servers using the same > > files for the recipes ? > > Yes. The files shouldn''t need to be different, just the processes. > > Of course, I say this, but I''m plannin on adding a couple of new > functions to Puppet''s language, and they''d only be in the new > process. Drat. > > -- > Today I dialed a wrong number...The other person said, "Hello?" and > I said, "Hello, could I speak to Joey?"... > They said, "Uh...I don''t think so...he''s only 2 months old." > I said, "I''ll wait." -- Steven Wright > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >
On Sep 5, 2007, at 2:53 AM, matthew.malthouse@guardian.co.uk wrote:>> >> I''m in the throes of the REST conversion and I''m wondering: How >> important is it to retain backward compatibility? > > We were discussing this only yesterday. > > In the _general_ case it''s VITAL. Yes, I''m shouting: VITAL. > > The case in point was a change to a method that broke the way we do > nfs > mounts (I''ll leave the guys working on it to detail it if they are so > inclined). That required a lot of work to fix (I guess at least 6 > person > days) and every time something like that happens we end up questioning > whether Puppet is an economically viable tool.I''d really like to avoid this, and I do everything I can to, but I can''t always tell when a change is going to have backward- compatibility implications. Certainly one of the significant problems in the community is a lack of pre-release testing. I do what I can, but my test configurations can''t come close to approaching people''s real-world configurations, so I inevitably miss things. I agree, though, that backward compatibility is critical, and I do what I can. I either need help from the community in finding these problems before release, or I need about a million bucks to build a testing lab.> In the particular case of the REST/XMLRPC change however the change > is so > great that it actually makes more sense to me not to provide backwards > compatibility. My reasoning is that we can formulate the change as a > mini-project and do the whole thing properly whereas if things are > left > we''ll be stung a couple of point releases down the line when the > compatibility is (sensibly) dropped.Yeah, that''s what caused me to ask this question. What I''d like to do is just leave the existing code for as long as possible in the refactoring process, and see what happens in the end. If I can leave it there as static, and just throw warnings left and right (which should be easy), I''ll probably do that, but I''m not sure it''s worth either arbitrarily killing the old interface or spending the effort porting it. We''ll see, I guess. -- I have lost friends, some by death... others through sheer inability to cross the street. -- Virginia Woolf --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Sep 5, 2007, at 6:12 AM, Trevor Vaughan wrote:> Couldn''t you provide an ''Upgrade Guide'' and a recipe that does the > following: > > 1) Install new client into some alternate path using old client > 2) Stop (but don''t remove) old client > 3) Use new client to pull from new server > 4) New manifest replaces old puppet client and removes alternate > path client > 5) (In theory) Done > > The details might be a bit complicated, but it seems like it should > work and would let you jettison the old code all at once.That wouldn''t really work in situations where the package system you''re using doesn''t support multiple installs, and I expect most people are using packages. It looks like it''s worth hoping for the frozen code, and moving on from there. -- I also realize I can no longer spell "pseudo". My fingers have now hard-wired "sudo". Thanks, Unix! I also cannot uppercase "cat" for the life of me. --Jonathan Rentzsch --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On 9/5/07, Luke Kanies <luke@madstop.com> wrote:> I''d really like to avoid this, and I do everything I can to, but I > can''t always tell when a change is going to have backward- > compatibility implications. > > Certainly one of the significant problems in the community is a lack > of pre-release testing. I do what I can, but my test configurations > can''t come close to approaching people''s real-world configurations, > so I inevitably miss things. > > I agree, though, that backward compatibility is critical, and I do > what I can. I either need help from the community in finding these > problems before release, or I need about a million bucks to build a > testing lab.What we need is a testing poo in EC2. We can just pull up 50 EC2 instances and test a huge set of common configurations, then pull it down again. This would cost $5 if the run completes in an hour. A fun project for all our spare time, eh? Adam -- HJK Solutions - We Launch Startups - http://www.hjksolutions.com Adam Jacob, Senior Partner T: (206) 508-4759 E: adam@hjksolutions.com
On Sep 5, 2007, at 12:19 PM, Adam Jacob wrote:> What we need is a testing poo in EC2. We can just pull up 50 EC2 > instances and test a huge set of common configurations, then pull it > down again. This would cost $5 if the run completes in an hour. > > A fun project for all our spare time, eh?Yeah, exactly, although you''re discounting the (admittedly small) S3 costs of leaving the VMs lying around. This is something I''ve been meaning to do for ages, and my VMware filesystem on my local box seems to have decided to go elsewhere indefinitely, so I''m suddenly reduced to no testing VMs, which means I need to do *something* before the next release. If anyone''s willing to volunteer to help build and maintain a test infrastructure on EC2 + S3, I''ll fund it (unless, of course, someone else is interested in funding it) and do everything I can to help. What I''d really like to see is a per-platform advocate willing to maintain appropriate images for their platform. I don''t think it''s enough to have a Debian image, for instance, I need a Debian image as a Debian user might use it, or Red Hat, or FreeBSD or whatever. OTOH, I think we also need to get the tests in good-enough shape that they should always pass on all platforms, so we can have everyone in the community run nightly build tests on their particular platform and email any failures to the dev list or open a new ticket or something. I think we''re long past the point where we need continuous integration tests. -- Criminal: A person with predatory instincts who has not sufficient capital to form a corporation. --Howard Scott --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 05 September 2007, Luke Kanies wrote:> On Sep 5, 2007, at 2:53 AM, matthew.malthouse@guardian.co.uk wrote: > >> I''m in the throes of the REST conversion and I''m wondering: How > >> important is it to retain backward compatibility? > > > > We were discussing this only yesterday. > > > > In the _general_ case it''s VITAL. Yes, I''m shouting: VITAL. > > > > The case in point was a change to a method that broke the way we do > > nfs > > mounts (I''ll leave the guys working on it to detail it if they are so > > inclined). That required a lot of work to fix (I guess at least 6 > > person > > days) and every time something like that happens we end up questioning > > whether Puppet is an economically viable tool. > > I''d really like to avoid this, and I do everything I can to, but I > can''t always tell when a change is going to have backward- > compatibility implications. > > Certainly one of the significant problems in the community is a lack > of pre-release testing. I do what I can, but my test configurations > can''t come close to approaching people''s real-world configurations, > so I inevitably miss things.That might become easier with environments too ... [git] masterport = 8141 I tried to run my production puppetmasterd from svn/git, but it became too big a burden to track down new things every few days. I really would like to help here though. The last few releases, I didn''t notice your regular announcements at all (perhaps because i was offline huge amounts) and those before were like 24 hours before the release, which was not very comfortable either. Regards, David - -- The primary freedom of open source is not the freedom from cost, but the free- dom to shape software to do what you want. This freedom is /never/ exercised without cost, but is available /at all/ only by accepting the very different costs associated with open source, costs not in money, but in time and effort. - -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG3vKo/Pp1N6Uzh0URAlbTAJ9kymEp2k4G+wsJJsa4vLUTsRr3LQCdFwhD qyVFcvGPRLsQ7BrnMXEC6HM=PmWl -----END PGP SIGNATURE-----
On Sep 5, 2007, at 1:17 PM, David Schmitt wrote:> I tried to run my production puppetmasterd from svn/git, but it > became too big > a burden to track down new things every few days. I really would > like to help > here though. The last few releases, I didn''t notice your regular > announcements at all (perhaps because i was offline huge amounts) > and those > before were like 24 hours before the release, which was not very > comfortable > either.Yeah, I''ve recently gotten better about announcing releases more than 24 hours in advance, but I know I haven''t been the best at it. It''s kind of a repeating cycle, though -- I preannounce by a week, get no response, so I don''t bother preannouncing by much the next time. I''ll make sure people have more time to test in the future, and I''ll especially start making more announcements as I''m going through the ticket-closing process, as that''s the best time for people to start testing. In general, though, if you see a bunch of tickets closed in quick succession, it''s usually a sign that I''m working toward a release. -- Susskind''s Rule of Thumb: Don''t ask what they think. Ask what they do. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com