vishvananda

I totally agree. This is just one of the options I outline for standardizing networking in my blog post[1] and this one probably involves a little too much magic to be generally applicable.

It is interesting to note that most of the frameworks that are trying to solve the the rest of the problem have moved along similar lines. For example Kubernetes provides both the ability to launch containers in the same namespace and also provides a proxy. Openshift uses iptables rewriting via GearD.

[1] https://medium.com/@vishvananda/standard-components-not-stan...

FWIW I agree that reactive infrastructure is fairly limited in scope. The traditional model of infrastructure is everything running in a single server. If your unit of deployment is a vm, then orchestration, service discovery, security policy must be done within the vm image or via a configuration management system. If your unit of deployment is a container, then these pieces can be done outside of the container system. A standard interface for the way the container communicates with the outside world allows these systems to be shared and reused and perhaps one day standardized.

The point of hand waving orchestration, configuration management, etc. is to separate the concern of what is running from the concern of how it is connected to other things. My hope is that container builders could simply focus on dependencies and application code and that the act of connecting components together can be handled by a different layer in the system.

The ipsec implementation just configures ipsec in the kernel using a go netlink library[1]. It is similar to how it would be accomplished using iproute2 via `ip xfrm policy` and `ip xfrm state`.

[1] https://github.com/vishvananda/netlink

Thanks, author here.

I've been thinking about what we need to simplify distributed applications for the past few years, and we really need reusable components[1]. Anything we can do to make containers more consistent and easier to build is important.

[1] https://medium.com/@vishvananda/standard-components-not-stan...

Since you seem to have some kernel expertise, do you know if there is an easy way (via an iptables/ebtables plugin or some such) to get packets to switch namespaces? It seems like you could do a whole lot with just simple kernel packet rewriting if you could have an in-container-namespace rule to jump into another namespace before routing. You could do some analog of this with a veth device, but it seems like it would be much faster to just switch the namespace.

I've used bpython for quite a while and this is definitely an upgrade.

Pretty neat stuff. Looks like the move generator is missing a few features like underpromotion but it is very concise. I wrote a rudimentary engine + move generator[1] using bitboards[2] a couple of years ago. Unfortunately python poorly suited for bitmath optimizations because it doesn't support fixed width integers. Once I saw how slow my movegen went compared to a c version, I gave up on finishing up the minimax search to complete the engine. It does run quite a bit faster in pypy but still no easy way to force 64 bit integers.

[1] https://github.com/vishvananda/ivory [2] https://chessprogramming.wikispaces.com/Bitboards

I really like cffi for interacting with external c libraries. See for example my post on talking to openssl using cffi:

http://unchainyourbrain.com/using-openssl-from-python-with-p...

This is true if the application needs to talk to the slaves directly. If the application doesn't care, then you could do the smarts in the proxy layer underneath the application. I see three scenarios:

* Stateless or Transparent master/master backend

  Example: Memcached cluster

  Use load balancing in the proxy layer

* Failover backend with failover on server side

  Examples: Mysql master/slave

  Use failover logic in the proxy layer

* Failover backend with failover on the client side

  Example: HA RabbitMQ cluster

  Above suggestion from polvi is needed

This is some pretty interesting stuff. I've been working on something similar in my spare time. The cost of running everything through a proxy can be mitigated by having the proxy do other smart things like load balancing and/or autoscaling.

Hey Van!

How much did you guys pay for them? :p

> No, from what I see they are not. CRUD relates to "Create, Remove, Update, Delete"

Minor correction: create, READ, update, delete

This is definitely possible, it is called block migration. Here is an example of someone showing usage (note the bug he mentioned has been fixed):

http://www.sebastien-han.fr/blog/2012/07/12/openstack-block-...

Note that there are some reliability issues using versions prior to qemu-1.4 and libvirt 1.0.2

To enable "true" block migration where the server remains live the whole time instead of being paused, you need to modify a config option:

block_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_NON_SHARED_INC,VIR_MIGRATE_LIVE

(this adds VIR_MIGRATE_LIVE to the default flags)

Also, keep in mind the same caveats to regular live migration with this flag in that there are edge cases where the i/o in the guest is so great that the migration will never complete.

This is an insightful post. Deploying production applications in containers with an auto-updating kernel underneath still has to be proven in the real world. I do want to quibble with one point, however:

"On top of that, by using such a specialized system to run your apps, you lose all the flexibility of having a full linux OS to troubleshoot and debug from. You now have to rely on them building on all the components that already exist in regular Linux world, like debuggers, tracers, sniffers, profilers, etc. You'll have to slip all that into your application deploy to troubleshoot a weird one-off bug."

CoreOS is a full fledged linux, and since applications are running in containers, there is no reason you couldn't use debugging tools on the host.

Most production services have strict controls anyway, so it isn't like it is common practice to log in to a production database server and do apt-get/yum install gdb and start banging away.

so that post is clearly an April fools joke. it even says it is at the bottom. They kept the name Luna and I suspect is not based on Darwin either.

I predict that this will lead to a spike in backers from all of the people who wanted to back it but thought $800 was too expensive, but it will quickly level off. Why?

Dan Ariely did some studies[1] showing that people are much more likely to pick something when there is a strictly worse option available. $830 vs. $600 for the exact same thing is just easier for our irrational minds to compare than $695 for a phone next year vs. phones today. I think this was a major motivator for people to "buy" in the early stages of the project, especially since it was a time limited option.

I personally backed at the $600 level, and while I have a lot of reasons for why it was a good idea, I suspect that I was influenced my own irrational behavior and I am just good at justifying my decisions.

[1] http://realityswipe.wordpress.com/tag/dan-ariely/

P.S. If you haven't read any of Dan Ariely's stuff before, he does some fascinating studies showing how irrational humans are.

This is kind of dated now, but I found the old "Code on the Cob" series of articles very enlightening:

http://archive.gamedev.net/archive/reference/list981c.html?c...

> But she did seem to prove that monster is lying when they say the "diversity" options won't hurt you.

I don't think there is any indication that the race/gender option on monster had any effect. If there was any racial bias, then I think it is more likely to be from switching away from a clearly ethnic name than the "diversity" information.

I have to wonder how much of this is just because it was a new account. I assume some recruiters get notifications when new accounts are created that match certain criteria.

I think the problem is that the author has normalized his development standard to proficient coders in the tech industry. I used to do enterprise software in the midwest and there are legions of 1/10th developers out there. Its easy move your baseline far away from the average when you are in the echo-chamber of high-tech startups. Compared to the true average developer there are definitely 10x developers.

This is correct. The switch will continue to work if the x86 hardware fails. In this case the other controllers will take over management of the servers that are plugged in to the controller with the failed x86 hardware.

Outside of nova.

OpenStack provides virtualization, storage and networking services. You have the basic gist, once nebula provisions everything, you can interact immediately with the system, provisioning virtual machines and storing data.

You can use a browser-based web dashboard or REST apis to interact with the system. Object storage (think S3) is exposed externally, block storage is supported, but it isn't currently exposed outside the system (its for vms only). AD integration is in the works.

Hi, I'm a nebula employee and I have been a key contributor to OpenStack since its founding. We have not forked OpenStack and we are committed to making the upstream project a success. We have some proprietary pieces around the control plane, storage and UX, but we will continue to participate heavily in upstream development and plan on integrating more OpenStack pieces as they stabilize.

> Also, I don't have a phone plan. Just an iphone that's used as a wifi device. Now what?

https://voice.google.com

Another great book along these lines is CODE, by charles petzold:

http://www.charlespetzold.com/code/

He starts with electricity and builds all the way up to modern computers. It isn't a hands on guide, but it is a very entertaining read.

This post seems to be missing the point. There is a general misunderstanding that being happy and excited about what you are doing has to do with the activity itself. It has a lot more to do with meeting internal needs.

I've had a pretty wide variety jobs in my life: meditation teacher, chef, poker player, software engineer. I experienced passion and happiness in all of them.

Initially, this seemed to be by chance, but eventually I spent some time trying to identify what made me happy. I discovered my driving needs: the things that inspire me and bring me the most happiness.

Driving needs are unique: everyone needs different things to be satisfied and fulfilled. For some it is acknowledgement and respect, for others it is the thrill of challenge and overcoming obstacles, and for still others it is security and stability.

It is extremely valuable to understand what your individual needs are. If you are clear about them, you can find ways to fulfill those needs in many different professions. You are free to find the optimal "work" to fulfill those needs.

Someone who is fulfilled by challenges is not likely to be fulfilled working a 9-5 job, just like someone who needs security is not going to be fulfilled working at a startup. It isn't the 9-5 job or the startup that is making the person happy, it is the fact that their needs are getting met.

A clear understanding of your driving needs gives you the opportunity to meet them in whatever situation you find yourself in. Additionally, it gives you the flexibility to change your profession if circumstances dictate without sacrificing your happiness.