Prototype: Puppet Platform Manager
Luke Kanies
I've just published an interesting prototype. It's a tool I'm currently calling 'puppet platform manager', because the idea is it could manage your infrastructure at the "platform" level (where I'm using 'platform' in how people usually differentiate Platform as a Service from Infrastructure as a Service).
Anyway, the readme is pretty thorough, and it's still very raw, but feel free to check it out:
https://github.com/lak/Puppet-Platform-Manager
I'm definitely curious if anyone's interested in it or if anyone has any ideas on it.
--
Life is like playing a violin in public and learning the instrument as
one goes on. -- Samuel Butler
---------------------------------------------------------------------
Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199
Nigel Kersten
> Hi all,
>
> I've just published an interesting prototype. It's a tool I'm currently calling 'puppet platform manager', because the idea is it could manage your infrastructure at the "platform" level (where I'm using 'platform' in how people usually differentiate Platform as a Service from Infrastructure as a Service).
>
> Anyway, the readme is pretty thorough, and it's still very raw, but feel free to check it out:
>
> https://github.com/lak/Puppet-Platform-Manager
>
> I'm definitely curious if anyone's interested in it or if anyone has any ideas on it.
I don't love doing this, but ... bump?
We'd love more feedback on this.
donavan
> > I've just published an interesting prototype. It's a tool I'm currently calling 'puppet platform manager', because the idea is it could manage your infrastructure at the "platform" level (where I'm using 'platform' in how people usually differentiate Platform as a Service from Infrastructure as a Service).
>
a larger inclusive graph is ++1. I also do get envious every time I
see something like 'chef knife' for deployment.
However, I would definitely down vote this for now. Puppet since ~0.25
era has seemed to pick up way too many half baked features because
they looked cool. Its been mentioned in discussion of #5046, but users
spent way too much time finding out the working way to do something
out of all the available options. Chatting at work the unanimous
opinion was that we'd rather have nothing but bug fixes and removal of
broken 'features' for the 2.7 release.
Daniel Pittman
...and somehow it still didn't turn up as the topmost item in my
Google "Priority Inbox". Clearly you need to bribe your former
colleagues more to bump up the priority of your messages. ;)
More seriously, while I am super-interested in this I have not really
had much chance to look into it earlier in the picture and I didn't
want to do a half-baked job of it all...
So, my feedback:
To me the most obvious thing that the profile should be doing is
collecting an arbitrary set of facts and allowing both direct matching
and some degree of conditional matching on them; for example, I would
have had a deployment profile that looked like this:
profile { "app-reliable": reliable_disk => 'true', perl_appserver => '5.10' }
profile { "app-unreliable": reliable_disk => 'false', perl_appserver => '5.10' }
profile { "app-legacy": reliable_disk => 'true', perl_appserver =>
['5.10' or '5.8'] }
I would also want to match on location – in some cases "data center
one or data center two" – and ideally to set priority – legacy app
server should prefer 5.8 machines, but accept 5.10 to meet the
constraints.
Which leans toward a constraint language, frankly, to solve the
resource allocation problem, especially because I would like it to
automagically balance load and remove services from nodes for me too.
;) (Also, a pony would be nice, thanks.)
Of those I think the "and" and "or" operators in matching are the most
pressing, and the ability to use arbitrary custom facts is essential
to real-world deployments. (Most every scale deploying is going to
have some sort of pooling of machines, I predict, most easily
represented as a custom fact.)
Previously discussed is the idea of "proxy" nodes to represent
database systems; one of the routine requirements we would have had of
this code would be to deploy database instances to the systems, so
some solution there would be ideal.
For configuring tools like load balancers it would be *wonderful* to
be able to get data like "an array of hostnames for the {apache,
mysql, etc} component of Y", so you can have a template that can build
the list of application servers automatically.
OTOH, we can just document how to do that with exported and imported
resources, and the third party concat module (or collecting on the
puppet master and reading files on disk inside a template / generate)
to work around that for the moment.
We would have wanted, ideally, to have this tool manage scheduling for
us. On deployment this doesn't matter too much, because you can
usually live with deploying the load balancer configuration before the
app server, or whatever – because you don't tell the client before you
have the system running and tested.
What we really, really would have wanted was to have it handle updates
for us. Scheduling updates to the database servers before the app
servers, for example, would have been good. Scheduling an operation
on *one* of the database server to do schema changes, automatically,
would have been absolutely ideal!
The code itself looks sound, but I have not tested it or reasoned too
hard about it internally.
Regards,
Daniel
--
✉ Daniel Pittman <dan...@rimspace.net>
⌨ dan...@rimspace.net (XMPP)
☎ +1 503 893 2285
♻ made with 100 percent post-consumer electrons
Luke Kanies
I sympathize, especially with the 2.6 release. I personally added a bunch of complicated features to it (and, for the record, fixed a ton of bugs), but many of them were not as complete as they needed to be. I apparently did not sufficiently shift my development style toward the maturity that the current Puppet usage requires. :/
Rest assured that the team (i.e., not me) is working hard on a lot of those bugs, and, even better, when they add features now they make sure they're actually complete.
One of the reasons you're starting to see these prototypes from me is that I'm not working on creating new bugs in the system but am instead largely focusing on exploring features, which someone else would normally implement while thinking more maturely about the complications.
So, I don't think 2.7 will be entirely bug fixes, but I also don't think it'll be anywhere near as painful in future upgrades. 2.6 and 0.25 were primarily developed by me, but I don't think 2.7 will include any commits of mine. I'm not saying I'm at fault for everything, just that the team size is much larger, and the maturity of our development style has changed quite a bit.
--
Sabbagh's Second Law:
The biggest problem with communication is the illusion that it
has occurred.
Nigel Kersten
> On Jan 12, 2011, at 7:51 PM, donavan wrote:
>
>> On Jan 12, 7:14 pm, Nigel Kersten <ni...@puppetlabs.com> wrote:
>>> On Wed, Dec 29, 2010 at 12:20 PM, Luke Kanies <l...@puppetlabs.com> wrote:
>>>> I've just published an interesting prototype. It's a tool I'm currently calling 'puppet platform manager', because the idea is it could manage your infrastructure at the "platform" level (where I'm using 'platform' in how people usually differentiate Platform as a Service from Infrastructure as a Service).
>>>
>>> I don't love doing this, but ... bump?
>>
>> Conceptually, this is awesome. Moving towards platform management and
>> a larger inclusive graph is ++1. I also do get envious every time I
>> see something like 'chef knife' for deployment.
>>
>> However, I would definitely down vote this for now. Puppet since ~0.25
>> era has seemed to pick up way too many half baked features because
>> they looked cool. Its been mentioned in discussion of #5046, but users
>> spent way too much time finding out the working way to do something
>> out of all the available options. Chatting at work the unanimous
>> opinion was that we'd rather have nothing but bug fixes and removal of
>> broken 'features' for the 2.7 release.
>
> I sympathize, especially with the 2.6 release. I personally added a bunch of complicated features to it (and, for the record, fixed a ton of bugs), but many of them were not as complete as they needed to be. I apparently did not sufficiently shift my development style toward the maturity that the current Puppet usage requires. :/
>
> Rest assured that the team (i.e., not me) is working hard on a lot of those bugs, and, even better, when they add features now they make sure they're actually complete.
I'd also reiterate here that while the new parameterized class
features have exposed some inconsistencies, we have fixed an awful lot
of bugs, and there's nothing *forcing* you to use the new features.
You can actually just treat 2.6.x as a more stable 0.25.x and ignore
the new features if you want. There are some regressions, but we've
improved significantly in that regard with each release, and bringing
some consistency and clarity to parameterized classes is very
important to us all for the next major release.
Donovan, where would you consider fixing Puppet scoping to sit in
terms of your wishlist?
It seems to be something that the community as a whole is clamoring
for, and would significantly improve usability.
>
> One of the reasons you're starting to see these prototypes from me is that I'm not working on creating new bugs in the system but am instead largely focusing on exploring features, which someone else would normally implement while thinking more maturely about the complications.
>
> So, I don't think 2.7 will be entirely bug fixes, but I also don't think it'll be anywhere near as painful in future upgrades. 2.6 and 0.25 were primarily developed by me, but I don't think 2.7 will include any commits of mine. I'm not saying I'm at fault for everything, just that the team size is much larger, and the maturity of our development style has changed quite a bit.
>
> --
> Sabbagh's Second Law:
> The biggest problem with communication is the illusion that it
> has occurred.
> ---------------------------------------------------------------------
> Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
> To post to this group, send email to puppe...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
>
>
donavan
> One of the reasons you're starting to see these prototypes from me is that I'm not working on creating new bugs in the system but am instead largely focusing on exploring features, which someone else would normally implement while thinking more maturely about the complications.
like this, the indirector applications, and Brices network device
Types are Awesome.
I think my primary concern with FEs is that HEAD and release seem very
close. Merges into the mainline give the impression they they're good
to go. People start using them and fall into edge cases and non
obvious errors. I think that's detrimental to Puppet as a community &
a tool.
Is a further out experimental/feature release set plausible? Or
releasing more bits as optional/modular components? I realize that
this may well be treading into PE territory.
On Jan 13, 11:25 am, Nigel Kersten <ni...@puppetlabs.com> wrote:
> I'd also reiterate here that while the new parameterized class
> features have exposed some inconsistencies, we have fixed an awful lot
> of bugs, and there's nothing *forcing* you to use the new features.
comments related to #5046 are really what got me. Deprecating include
without functional (today) parameterized classes? Moving to Class[foo]
-> Class[bar] and graph edge doom?
> Donovan, where would you consider fixing Puppet scoping to sit in
> terms of your wishlist?
of the community it's definitely near, or at, the top. I think it may
be OT bu my wishlist is multisite inventory/storeconfig, prepackage/
example puppet infrastructure (PE?), more accessible testing (cucumber-
puppet), better environment support, and better deployment tools (yes,
like Lukes). But I also care about stupid things like working regexs
and being able to install rpms.
My comment on broken 'features' probably does come down to scoping and
style. We're past a lot of problems because we use fully qualified
class statements ( class foo::distro inherits foo::base ) instead of
implied (foo { distro {} }). Cross class variables are rare, and fully
qualified. Nodes *only* declare class membership, and single inherit a
basenode. Etc.
Seeing posts to puppet-users with implied class namespace, resources/
classes in nodes, dynamic inheritance variables, giant site.pp, & a
lack of modules always make me wince. A lot of this seems to known
bad, so why do new users keep falling in to the same traps?
Nigel Kersten
> Seeing posts to puppet-users with implied class namespace, resources/
> classes in nodes, dynamic inheritance variables, giant site.pp, & a
> lack of modules always make me wince. A lot of this seems to known
> bad, so why do new users keep falling in to the same traps?
Honestly, because I don't think we document the existing behavior,
pitfalls and workarounds sufficiently.
Nick F, our awesome tech writer raised this last night inside Puppet
Labs, and we're planning to do this exact thing. We're going to make a
start on such a document and seek community input on the workarounds
and pitfalls.
Luke Kanies
>> On Thu, Jan 13, 2011 at 10:21 AM, Luke Kanies <l...@puppetlabs.com> wrote:
>> One of the reasons you're starting to see these prototypes from me is that I'm not working on creating new bugs in the system but am instead largely focusing on exploring features, which someone else would normally implement while thinking more maturely about the complications.
>
> I'm not saying these are wrong, please don't take it that way. Things
> like this, the indirector applications, and Brices network device
> Types are Awesome.
> I think my primary concern with FEs is that HEAD and release seem very
> close. Merges into the mainline give the impression they they're good
> to go. People start using them and fall into edge cases and non
> obvious errors. I think that's detrimental to Puppet as a community &
> a tool.
This is something we've never really figured out how to handle. We have a small development community, even with the team of developers at Puppet Labs, so having people working on both a stable branch and an experimental branch ends up not working. We've tried it a few times, and it always ends up really messy.
So, for now, we're still trying to figure it out, and for now the dev team is mostly producing features and bugfixes that we think should qualify as stable. And, ftr, they are producing much more stable code. The majority of the big features in 2.6 were still independently developed by me, and there's a big difference now.
> Is a further out experimental/feature release set plausible? Or
> releasing more bits as optional/modular components? I realize that
> this may well be treading into PE territory.
No, none of this is about PE - Puppet will always be essentially the same between them (and I say "essentially" only because the timing of the releases won't always be synchronized; our expectation is that PE will always include a publicly released version of Puppet, not some unique commercial edition or whatever. It might include some plugins that aren't available publicly, but not a different version of the main product.
> On Jan 13, 11:25 am, Nigel Kersten <ni...@puppetlabs.com> wrote:
>> I'd also reiterate here that while the new parameterized class
>> features have exposed some inconsistencies, we have fixed an awful lot
>> of bugs, and there's nothing *forcing* you to use the new features.
>
> Yes, and picking on parameterized classes may be too easy. Some of the
> comments related to #5046 are really what got me. Deprecating include
> without functional (today) parameterized classes? Moving to Class[foo]
> -> Class[bar] and graph edge doom?
That was just a proposal, not a final decision. I don't think it will work, for mutliple reasons.
>> Donovan, where would you consider fixing Puppet scoping to sit in
>> terms of your wishlist?
>
> Personally, scoping hasn't bothered me since ~.24 days. For the good
> of the community it's definitely near, or at, the top. I think it may
> be OT bu my wishlist is multisite inventory/storeconfig, prepackage/
> example puppet infrastructure (PE?), more accessible testing (cucumber-
> puppet), better environment support, and better deployment tools (yes,
> like Lukes). But I also care about stupid things like working regexs
> and being able to install rpms.
Sounds like there are quite a few features you want, too. :) And many of them are indeed our priorities.
> My comment on broken 'features' probably does come down to scoping and
> style. We're past a lot of problems because we use fully qualified
> class statements ( class foo::distro inherits foo::base ) instead of
> implied (foo { distro {} }). Cross class variables are rare, and fully
> qualified. Nodes *only* declare class membership, and single inherit a
> basenode. Etc.
> Seeing posts to puppet-users with implied class namespace, resources/
> classes in nodes, dynamic inheritance variables, giant site.pp, & a
> lack of modules always make me wince. A lot of this seems to known
> bad, so why do new users keep falling in to the same traps?
Some of these clear usability issues are our real priority - what things can people do that they really shouldn't? We've found quite a few areas that experienced Puppet users always know to avoid but newbies consistently get hung up on; we want to trim those so that only the reasonable solutions are used and the stupid things are gone.
Of course, again, this is all done with a small team, so it isn't always pretty, but we're continuing to grow our team so it'll keep getting better.
--
It is a mistake to think you can solve any major problems just with
potatoes. --Douglas Adams
Luke Kanies
There's no question that a constraint system is by far the best way to handle resource allocation.
Heh, that was enough of a response that I don't really know how to reply. :)
The short answer is, yes, that's a lot of what we're thinking about. This is clearly just a bit of a demo, but it is sufficient to bring up a lot of those questions.
I think this is a bit throw-away, but as we try to actually get some of these ideas into code, it should be interesting.
--
Meeting, n.:
An assembly of people coming together to decide what person or
department not represented in the room must solve a problem.
Daniel Pittman
> On Jan 12, 2011, at 9:54 PM, Daniel Pittman wrote:
>> On Wed, Jan 12, 2011 at 19:14, Nigel Kersten <ni...@puppetlabs.com> wrote:
>>> On Wed, Dec 29, 2010 at 12:20 PM, Luke Kanies <lu...@puppetlabs.com> wrote:
[...]
>> Which leans toward a constraint language, frankly, to solve the
>> resource allocation problem, especially because I would like it to
>> automagically balance load and remove services from nodes for me too.
>> ;) (Also, a pony would be nice, thanks.)
>
> There's no question that a constraint system is by far the best way to handle resource allocation.
*nod* I also have complete sympathy for the idea that delivering one,
especially a complete constraint system, is a hard job, and not one
that might make the first cut.
While we are there, though, I was thinking more about this and how I
would want to use this system in a flexible resource environment,
like a company that was happy to buy Amazon EC2 resources to run
services.
I think in that environment one of the most important features that
this code could have is a set of hooks into whatever constraint system
it ships (that is, the very basic one prototyped here, or a better
solver) to allow it to grow the network through whatever interface we
used.
So, being able to hook third party code in at, say,
lib/platform_manager/allocator.rb:41 would be ideal, where it
currently just raises a "capacity missing" exception. I should
probably hack some sort of prototype together, but I don't think I
have spare "fun things" capacity tonight to do that.
[...]
> Heh, that was enough of a response that I don't really know how to reply. :)
>
> The short answer is, yes, that's a lot of what we're thinking about. This is clearly just a bit of a demo, but it is sufficient to bring up a lot of those questions.
I am not surprised that I am the second person to ask those questions,
but since they were not obvious in the code or documentation as it
stands I figured better said than missed. In terms of a reply what I
wanted was, basically, to say that these were the things that stood
out to me and to discuss any that you felt were interesting enough.
I don't actually have a direct use-case that I could put the code to,
so my contributions are mostly theoretical at this stage. Especially
because I am wasting my night on a graph simplification problem that
annoyed me first. :)
Which is a long way of saying that a response of "thanks, noted" is
more than sufficient to satisfy me.
Regards,
Daniel
Luke Kanies
> On Mon, Jan 17, 2011 at 21:53, Luke Kanies <lu...@puppetlabs.com> wrote:
>> On Jan 12, 2011, at 9:54 PM, Daniel Pittman wrote:
>>> On Wed, Jan 12, 2011 at 19:14, Nigel Kersten <ni...@puppetlabs.com> wrote:
>>>> On Wed, Dec 29, 2010 at 12:20 PM, Luke Kanies <lu...@puppetlabs.com> wrote:
>
> [...]
>
>>> Which leans toward a constraint language, frankly, to solve the
>>> resource allocation problem, especially because I would like it to
>>> automagically balance load and remove services from nodes for me too.
>>> ;) (Also, a pony would be nice, thanks.)
>>
>> There's no question that a constraint system is by far the best way to handle resource allocation.
>
> *nod* I also have complete sympathy for the idea that delivering one,
> especially a complete constraint system, is a hard job, and not one
> that might make the first cut.
I don't think it's all that hard, but if you look in the code, you'll notice I didn't do *anything* involving the profiles. It just didn't add that much information to my main test, which was whether I could model cross-host apps in Puppet, and what doing so would look like.
> While we are there, though, I was thinking more about this and how I
> would want to use this system in a flexible resource environment,
> like a company that was happy to buy Amazon EC2 resources to run
> services.
>
> I think in that environment one of the most important features that
> this code could have is a set of hooks into whatever constraint system
> it ships (that is, the very basic one prototyped here, or a better
> solver) to allow it to grow the network through whatever interface we
> used.
>
> So, being able to hook third party code in at, say,
> lib/platform_manager/allocator.rb:41 would be ideal, where it
> currently just raises a "capacity missing" exception. I should
> probably hack some sort of prototype together, but I don't think I
> have spare "fun things" capacity tonight to do that.
Yeah, I agree.
> [...]
>
>> Heh, that was enough of a response that I don't really know how to reply. :)
>>
>> The short answer is, yes, that's a lot of what we're thinking about. This is clearly just a bit of a demo, but it is sufficient to bring up a lot of those questions.
>
> I am not surprised that I am the second person to ask those questions,
> but since they were not obvious in the code or documentation as it
> stands I figured better said than missed. In terms of a reply what I
> wanted was, basically, to say that these were the things that stood
> out to me and to discuss any that you felt were interesting enough.
>
> I don't actually have a direct use-case that I could put the code to,
> so my contributions are mostly theoretical at this stage. Especially
> because I am wasting my night on a graph simplification problem that
> annoyed me first. :)
>
> Which is a long way of saying that a response of "thanks, noted" is
> more than sufficient to satisfy me.
Cheers.
--
It's a small world, but I wouldn't want to paint it.
-- Stephen Wright
Daniel Pittman
> On Jan 17, 2011, at 10:35 PM, Daniel Pittman wrote:
>> On Mon, Jan 17, 2011 at 21:53, Luke Kanies <lu...@puppetlabs.com> wrote:
>>> On Jan 12, 2011, at 9:54 PM, Daniel Pittman wrote:
>>>> On Wed, Jan 12, 2011 at 19:14, Nigel Kersten <ni...@puppetlabs.com> wrote:
>>>>> On Wed, Dec 29, 2010 at 12:20 PM, Luke Kanies <lu...@puppetlabs.com> wrote:
>>
>> [...]
>>
>>>> Which leans toward a constraint language, frankly, to solve the
>>>> resource allocation problem, especially because I would like it to
>>>> automagically balance load and remove services from nodes for me too.
>>>> ;) (Also, a pony would be nice, thanks.)
>>>
>>> There's no question that a constraint system is by far the best way to handle resource allocation.
>>
>> *nod* I also have complete sympathy for the idea that delivering one,
>> especially a complete constraint system, is a hard job, and not one
>> that might make the first cut.
>
> I don't think it's all that hard, but if you look in the code, you'll notice I didn't do *anything* involving the profiles. It just didn't add that much information to my main test, which was whether I could model cross-host apps in Puppet, and what doing so would look like.
Perhaps we have a different idea of what information you were after: I
actually tried this out to model the systems I used at my previous
job, and that was the first thing that I ran across as a challenge in
trying to model it: we wanted a little bit more of a constraint system
than you provided.
I can share the rough "end user code" that I probably still have
sitting around in my hacked together pile if that would be of more
value that my trying to extract the system requirements and describe
them?
Regards,
Daniel
--
⎋ Puppet Labs Developer – http://puppetlabs.com
✉ Daniel Pittman <dan...@rimspace.net>
✆ Contact me via gtalk, email, or phone: +1 (503) 893-2285
♲ Made with 100 percent post-consumer electrons
Luke Kanies
Please.
--
He attacked everything in life with a mix of extraordinary genius and
naive incompetence, and it was often difficult to tell which was
which. -- Douglas Adams