by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Kyle Barnes
    @kylbarnes
    but we are looking into the HA story. A HA Etcd cluster is probably what we will go with initially
    Wei Liao
    @wliao008
    hi guys, im trying to get blox running locally, all containers seems to be running ok, but hitting localhost:2000 returns 404, i've got golang, go-swagger setup as well, any thought?
    Kyle Barnes
    @kylbarnes
    @wliao008 what happens when you run curl http://localhost:2000/v1/environments?
    Wei Liao
    @wliao008
    @kylbarnes that returns {"items":[]}, so it's...ok?
    Kyle Barnes
    @kylbarnes
    yup, the reason you got a 404 is probably because you were just calling /. All URIs start with /v1.
    the swagger.json file should show you all available URIs. let me know if you have any questions.
    Wei Liao
    @wliao008
    ah, i'll be dang, lol thanks!
    Nare Hayrapetyan
    @narehayrapetyan
    @jhmartin cluster state service also performs bootstrapping and reconciliation from ecs so it will restore the state in etcd if etcd goes down
    Wei Liao
    @wliao008
    another question: if im to run 2 copies of blox on aws on 2 hosts to prevent a single point of failure (vs the 1 host setup by CF template), would the event messages get properly load balanced, or would both blox get the message and start up 2 containers in case of my target service going down?
    Kyle Barnes
    @kylbarnes
    @wliao008 we have an issue blox/blox#47 to address Blox HA. I think it would work fine if the 2 Blox copies were managing 2 different ECS clusters. But if they are both managing the same ECS cluster, i think you would see some undesirable race conditions.
    aaronkao
    @aaronkao
    Webinar for Blox happening right now: https://connect.awswebcasts.com/blox2016/
    William Thurston
    @jhspaybar
    Will there be a recording available afterwards? I forgot this was happening today but would like to see it.
    aaronkao
    @aaronkao
    yes, recording will be available in a few days
    the first half talks about the upcoming Task Placement Engine we are launching
    second half will be about event stream and Blox
    Anthony Suarez
    @simplycloud
    should be same talk / slides as available here: https://youtu.be/evYcLW3TLcQ
    William Thurston
    @jhspaybar
    Thanks
    Wei Liao
    @wliao008
    @aaronkao any read on when the placement engine is launching?
    Anthony Suarez
    @simplycloud
    wei: we can't comment on the specific timing, but can say that we are excited to get this into our customer's hands as soon as possible. expect to hear more very soon.
    Michael Kala
    @mkala1
    Hey guys!
    Anybody knows any relevance of Blox with another apache project called Apache Oozie?
    Kyle Barnes
    @kylbarnes
    hey @mkala1, i've used Oozie quite a bit. Apache Oozie is an orchestration engine for Hadoop jobs. Are you asking how we are similar or different?
    aaronkao
    @aaronkao
    @jhspaybar Here is the recording of the Blox webinar: https://www.youtube.com/watch?v=tLVs_q1L9FQ
    William Thurston
    @jhspaybar
    Thanks
    Michael Kala
    @mkala1
    @kylbarnes
    Thanks for the response. I guess my question was from the standpoint of capabilities. I know Oozie is created to operate within the Apache Hadoop ecosystem and Blox may be more EC2 based workload focused. Since Blox is open source under apache license, I was of any relevance with Oozie. May it be any similarities or striking differences.
    Kyle Barnes
    @kylbarnes

    Hey @mkala1, good questions.

    Oozie is really an orchestration framework. A common use case being, at 2am wake up and launch a MapReduce job, which then launches a Hive query, which then runs a bash script, which then sends out a completion email. Blox is a scheduling framework for Docker containers on ECS. A common use case being, schedule a metrics daemon across all instances in your ECS cluster. Blox would then monitor your metrics daemon ensuring it stays up, and automatically schedule the daemon as new instances come online.

    So I would say they are similar in that they both schedule things. But Oozie is more focused on workflows, whereas Blox is more focused on launching long-lived Docker daemons right now.

    Dale Shin
    @bofoy
    Excuse my ignorance but if I am writing my own scheduler what benefits does querying the cluster state service provide over just calling the ECS api like ListContainerInstances and such? Also what benefits does storing the cluster state in a data store provide?
    Kyle Barnes
    @kylbarnes
    Hey @dshin192. The data store (Etcd) is just where the cluster-state-service stores the local ECS state. As to your question about why cluster-state-service over calling ECS APIs directly, there are a number of reasons:
    • The cluster-state-service consumes the ECS event stream instead of polling. This means it is in near real-time sync with changes to your ECS clusters.
    • It exposes the ECS event stream via a REST API method that you can consume. For example, by consuming this streaming API, you would be notified immediately as a new ECS instance comes online or a task unexpectedly stops. No polling needed.
    • Avoids any ECS API rate limits that you would probably run into if you were continuously polling everything every few seconds.
    Let me know if you have any follow-up questions.
    Dale Shin
    @bofoy
    @kylbarnes ah makes more sense now. Thanks for the response!
    Kyle Barnes
    @kylbarnes
    np. let me know if you have any more questions.
    Kyle Barnes
    @kylbarnes
    We've just released Blox v0.2.0. Check out https://github.com/blox/blox/blob/master/CHANGELOG.md for a list of new features and bug fixes included in this release.
    Kyle Barnes
    @kylbarnes
    For anyone updating from v0.1.0, please be aware that the cluster-state-service API response objects have changed in this release.
    Arunav Sanyal
    @Khalian
    blox/blox#174
    Pooja Kalpana Prakash
    @poojamaiya
    Thanks for the PR @Khalian. The PR has been approved and merged in.
    Kyle Barnes
    @kylbarnes
    We've just released Blox v0.2.1 with a number of important bug fixes. Check out https://github.com/blox/blox/blob/master/CHANGELOG.md for a list of bugs fixed in this release. We strongly encourage anyone running Blox v0.2.0 to update to v0.2.1.
    Kyle Barnes
    @kylbarnes
    We've just released Blox v0.3.0. A list of new features included in this release can be found at https://github.com/blox/blox/blob/master/CHANGELOG.md
    Jeremy Cowan
    @jicowan
    Will the daemon scheduler always start the container defined for an environment before other containers are scheduled on the instance? Is there a way to create a reservation for the CPU, memory, and port resources for the daemon so that it will always start?
    Kyle Barnes
    @kylbarnes
    @jicowan Good question. The Blox daemon-scheduler does not get any priority over tasks started by other schedulers. However, you could accomplish that by starting the daemon-scheduler before calling start task to start any additional tasks. Also, the daemon-scheduler is usually pretty quick to launch the task when a new instance comes online. So it will probably beat anything else for starting new tasks when new instances joins your cluster because it actions directly on the ECS event stream.
    Jeremy Cowan
    @jicowan
    @kylbarnes it would be nice to have a mechanism to reserve the necessary resources to start the daemon container or set the start order for tasks. I'm concerned about when a container instance fails as the cluster is nearing capacity. If there are insufficient resources to reschedule the tasks from the failed container instance, the scheduler will put the tasks in a pending state until the new container instance comes online. In this condition, which tasks will be scheduled first? The pending tasks or the daemon?
    Kyle Barnes
    @kylbarnes
    @jicowan Can you elaborate on what you’re asking? If a container instance fails, any running tasks that were running on it are not automatically rescheduled. It is up to the scheduler that launched them to notice that they are no longer running, and reschedule them. The Blox daemon-scheduler does this. Also, the ECS service scheduler does this (launching a task by creating a service). But anything you launched by manually calling run-task or start-task does not automatically get restarted. So, assuming a container instance crashed and was restarted, the Blox daemon-scheduler is listening to the ECS event stream, and would launch tasks almost immediately after it comes back online. Is your question about how to dictate the order of what tasks the Blox scheduler launches in order? Or how to dictate the task launch order between multiple different schedulers, such as Blox daemon-scheduler vs ECS service scheduler? Also, please note that our AWS deployment of Blox has it running on it’s own dedicated cluster. So it wouldn’t contend for resources with other tasks being launched. However, you may run into this if you deploy Blox onto a shared cluster.
    Jeremy Cowan
    @jicowan
    @kylbarnes Thanks for the clarification Kyle. I meant to say the scheduler will restart the tasks of your ECS service. I am really asking about how to dictate the task launch order between different schedulers. I know you say that the Blox daemon scheduler will quickly launch the daemon on a new container instance, but I'm concerned about when there are multiple schedulers all trying to schedule tasks on an instance at once. It would be nice to be able to assign a scheduler or task a priority value so it always starts before other tasks are scheduled on the instance. Or, if you can't assign a priority, then add the capability to reserve the resources (CPU, memory, and port) for the daemon so the daemon can always be scheduled on the instance.
    Kyle Barnes
    @kylbarnes
    Gotcha. I think I understand what you're asking now. So this is really around multiple schedulers competing for the same resources once an instance gets restarted. Since all schedulers will probably try to relaunch their own tasks as soon as the instance comes up. Knowing the way the Blox daemon-scheduler is written, it would probably be the first scheduler to launch tasks once the instance comes online, since it acts on the event stream, which is typically faster than other schedulers that act by polling. But I think you're asking in a more generic sense, right? How to guarantee that some portion of the container instances resources are reserved for a particular scheduler, regardless of the scheduler, correct? Or are you asking specifically about the Blox scheduler?
    Jeremy Cowan
    @jicowan
    Ideally it would be regardless of scheduler, but I'm particularly interested in the daemon scheduler.
    Kyle Barnes
    @kylbarnes
    Gotcha. So I can tell you that it's not possible right now, since that would require the schedulers to orchestrate with each other, which different schedulers typically won't do. The only real practical way I can see to do this is to allow partitioning of the container instance resources into groups. And allow a scheduler to own a particular group. This is an interesting idea. I'll bring it up for discussion over here with our ECS PMs. You can also create a Blox issue for this, but I think this relates more to ECS than to Blox, since the resource partitioning would happen on the ECS side, not with the Blox daemon-scheduler.
    tiny
    @Tiny-wlx
    Hi, i have install Blox in localhost, when i access http://localhost:2000, it showed 404, what the correct way to access it ?
    Nare Hayrapetyan
    @narehayrapetyan
    @Tiny-wlx which API are you trying to call? You can either use the swagger client to not have to deal with constructing paths or depending on the API you have to construct the path like this http://localhost:2000/v1/environments (replace environments with the route of the API you want) . Here are the routes: https://github.com/blox/blox/blob/dev/daemon-scheduler/pkg/api/v1/router.go
    Nick Brandaleone
    @nbrandaleone
    Hi guys. I was curious if anyone can point me at the template and demo-cli mentioned in the post: https://aws.amazon.com/blogs/compute/introducing-blox-from-amazon-ec2-container-service/ They seem to be dead links. I would like try out the product in the easiest way possible. Thanks!
    Nare Hayrapetyan
    @narehayrapetyan
    @nbrandaleone We've moved the 0.3 release into its own branch - v0.3. Here are links to the template(https://github.com/blox/blox/blob/v0.3/deploy/docker/conf/cloudformation_template.json) and the demo-cli (https://github.com/blox/blox/tree/v0.3/deploy/demo-cli). You can read more about the move on the readme and the faq (https://github.com/blox/blox/blob/dev/docs/faq.md) of the main repo.