By "start a second container in a service" you mean bringing up a second instance of the same image, for scaling purposes? (Or in your case to possibly test scaling?) How are you composing your stack, docker-compose? What are you storing in your data volume? If it's like database files, there's a different way to do what you're trying to do which is to mount your database container to have a host volume and just link the db container to service containers. Are you trying to use a container as an actual shared volume store for a bunch of service containers?
We're using docker cloud (https://cloud.docker.com/) which is like 99% docker compose (just a few differences in supported features) with a gui on top and manages nodes, containers, etc. on any number of actual cloud hosting services. In our case, AWS. So you slide the little slider for number of containers on the service over to 2, hit apply, then redeploy and theoretically you get two containers.
So what we had was an nginx service, a django service, a datacontainer service. We need a shared volume so that django can write user uploaded files, create files used across multiple django instances, store static css/js/images, etc. and have nginx serve them. For now they are being hosted locally rather than using s3 or whatnot for a variety of reasons. The separate data only container was based on what all of the docker docs seemed to be recommending for a shared persistent volume like that. I could ditch the data only container and have the volume on the nginx container, but as far as "volumes_from" failing there should be no difference.
I could start the stack with the three services and one container each just fine. Flip the switch to scale the django service to 2 containers, redeploy, and get the useless error "ERROR: 'volumes_from' data not found for django-2" displayed in docker cloud's logs with no other details anywhere. As best as I can guess that means the second container there can't see the volumes from our data container, but there's no reason why that would be made clear anywhere.
For now I have gone ahead and just dropped the data only container and each service which needs the shared volume will just have to explicitly specify volume and use the same host directory source. It's a tiny bit more to maintain, but it functions properly. I think it will also actually work better if we need to run multiple nodes (separate EC2 instances) for the same stack. Using volumes_from, every container has to be on the same node (enforced automatically by docker cloud), which ties you to a single EC2 instance. By just directly mapping each one to the same host directory we could shove that on EBS and share that between multiple EC2 instances and it should keep chugging along happily.
Did you try chaining the volume-froms? Instead of django-1 <-> data, django-2 <-> data, do django-1 <-> data, django-2 <-> django-1. This is normally how I see data volumes used, through chaining. I'll admit I don't use volume-from a lot, so I can't be a ton of help beyond that. From reading the documentation your setup should just work with or without chaining.
Docker supports named volumes now, instead of volume containers. You can do this:
$ docker run --name container1 -it -v test:/test ubuntu:wily /bin/bash
$ docker run --name container2 -it -v test:/test ubuntu:wily /bin/bash
And the two containers will share a named data volume.
0
Options
KakodaimonosCode fondlerHelping the 1% get richerRegistered Userregular
I never noticed this before but our bug tracker has both "Can't reproduce" and "Won't reproduce" for bug status.
Shit. I just cleared my entire backlog in 3 minutes. :P
So question for those of you familiar with ES6 (or anyone who has a better idea how to do this that I'm not thinking of):
One of our client orgs needs custom form fields in addition to the standard questions we normally ask with our evaluations. They have four different types of forms they want to implement. This is a PHP/Javascript based app, and currently, the process for selecting and filling out a form goes like:
* Select Milestone Type
* Select Milestone
* Complete form.
Each type has a list of milestones. For some of those milestones, I need to inject up to dozens of new form fields. Ideally I'd like to store those fields in separate files per form and import them as needed. ES6 seemed like a great answer for this, except you have to call imports at the very start of a file, which means I can't determine which set of forms to import based off a variable once the milestone is selected.
I feel like I'm missing a really dumb, easy solution for this but just don't see it.
Visual studio was like "hey man... that looks like a lot of text, why not just type this?"
And I was all like "... bwah?"
"oh I mean.. yeah."
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
Someone discovered the Elvis operator. Don't tell him about immutable type support, primary constructors and auto-property initializers...his head will explode.
So question for those of you familiar with ES6 (or anyone who has a better idea how to do this that I'm not thinking of):
One of our client orgs needs custom form fields in addition to the standard questions we normally ask with our evaluations. They have four different types of forms they want to implement. This is a PHP/Javascript based app, and currently, the process for selecting and filling out a form goes like:
* Select Milestone Type
* Select Milestone
* Complete form.
Each type has a list of milestones. For some of those milestones, I need to inject up to dozens of new form fields. Ideally I'd like to store those fields in separate files per form and import them as needed. ES6 seemed like a great answer for this, except you have to call imports at the very start of a file, which means I can't determine which set of forms to import based off a variable once the milestone is selected.
I feel like I'm missing a really dumb, easy solution for this but just don't see it.
Not sure how you're really thinking ES6 is going to help here? I guess because of the CommonJS module support? If that's the case, think of import like a function, You can actually use it just about anywhere, even way post-load.
So question for those of you familiar with ES6 (or anyone who has a better idea how to do this that I'm not thinking of):
One of our client orgs needs custom form fields in addition to the standard questions we normally ask with our evaluations. They have four different types of forms they want to implement. This is a PHP/Javascript based app, and currently, the process for selecting and filling out a form goes like:
* Select Milestone Type
* Select Milestone
* Complete form.
Each type has a list of milestones. For some of those milestones, I need to inject up to dozens of new form fields. Ideally I'd like to store those fields in separate files per form and import them as needed. ES6 seemed like a great answer for this, except you have to call imports at the very start of a file, which means I can't determine which set of forms to import based off a variable once the milestone is selected.
I feel like I'm missing a really dumb, easy solution for this but just don't see it.
Not sure how you're really thinking ES6 is going to help here? I guess because of the CommonJS module support? If that's the case, think of import like a function, You can actually use it just about anywhere, even way post-load.
Babel is giving me an error and failing when I'm trying to transpile it. But yes I was hoping to store the relevant form bits in a module as a function to import/export when needed based off what form was being called. Rather than having an extra 200 lines or so of code in browser. I guess I could just stick it in an HTML file and AJAX and paste it in?
Someone discovered the Elvis operator. Don't tell him about immutable type support, primary constructors and auto-property initializers...his head will explode.
Someone discovered the Elvis operator. Don't tell him about immutable type support, primary constructors and auto-property initializers...his head will explode.
Why is it called the Elvis operator?
?: <-- elvis' hair
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Someone discovered the Elvis operator. Don't tell him about immutable type support, primary constructors and auto-property initializers...his head will explode.
So question for those of you familiar with ES6 (or anyone who has a better idea how to do this that I'm not thinking of):
One of our client orgs needs custom form fields in addition to the standard questions we normally ask with our evaluations. They have four different types of forms they want to implement. This is a PHP/Javascript based app, and currently, the process for selecting and filling out a form goes like:
* Select Milestone Type
* Select Milestone
* Complete form.
Each type has a list of milestones. For some of those milestones, I need to inject up to dozens of new form fields. Ideally I'd like to store those fields in separate files per form and import them as needed. ES6 seemed like a great answer for this, except you have to call imports at the very start of a file, which means I can't determine which set of forms to import based off a variable once the milestone is selected.
I feel like I'm missing a really dumb, easy solution for this but just don't see it.
Not sure how you're really thinking ES6 is going to help here? I guess because of the CommonJS module support? If that's the case, think of import like a function, You can actually use it just about anywhere, even way post-load.
Babel is giving me an error and failing when I'm trying to transpile it. But yes I was hoping to store the relevant form bits in a module as a function to import/export when needed based off what form was being called. Rather than having an extra 200 lines or so of code in browser. I guess I could just stick it in an HTML file and AJAX and paste it in?
The `import` keyword is for static imports only, meaning the module path must be a string literal. (I thought it also had to be at the outermost scope too, but maybe not.) Dynamic imports are currently pending finalization of the spec, so every transpiler or module loader is going to implement them a little differently.
Personally, I use SystemJS as a module loader, because it handles loading CJS modules and it aims to be spec-compliant for ES modules. There's also just the ES6 Module Loader polyfill (which SystemJS uses internally) if you don't need CJS/AMD/etc. support and you just want something to handle dynamic ES module imports.
With that said, if you're worried about deferring loading for a few hundred lines of code, you probably don't need or want the overhead of a full module loader polyfill. Your best bet is probably just good old XHR for .js + eval (if the forms really need logic to back them up) or just XHR for .json + JSON.parse (if the forms are really just sets of data and all the logic resides in the main module).
+1
Options
jaziekBad at everythingAnd mad about it.Registered Userregular
Getting an old VB.Net "Web Site" dynamically compiled App_Code folder to work with a c# unit test project took like an entire work day, but I feel like it was worth it.
Now starting on the gigantic refactor to turn this from one giant file full of static functions into something thats actually readable / extendable / testable.
So question for those of you familiar with ES6 (or anyone who has a better idea how to do this that I'm not thinking of):
One of our client orgs needs custom form fields in addition to the standard questions we normally ask with our evaluations. They have four different types of forms they want to implement. This is a PHP/Javascript based app, and currently, the process for selecting and filling out a form goes like:
* Select Milestone Type
* Select Milestone
* Complete form.
Each type has a list of milestones. For some of those milestones, I need to inject up to dozens of new form fields. Ideally I'd like to store those fields in separate files per form and import them as needed. ES6 seemed like a great answer for this, except you have to call imports at the very start of a file, which means I can't determine which set of forms to import based off a variable once the milestone is selected.
I feel like I'm missing a really dumb, easy solution for this but just don't see it.
Not sure how you're really thinking ES6 is going to help here? I guess because of the CommonJS module support? If that's the case, think of import like a function, You can actually use it just about anywhere, even way post-load.
Babel is giving me an error and failing when I'm trying to transpile it. But yes I was hoping to store the relevant form bits in a module as a function to import/export when needed based off what form was being called. Rather than having an extra 200 lines or so of code in browser. I guess I could just stick it in an HTML file and AJAX and paste it in?
The `import` keyword is for static imports only, meaning the module path must be a string literal. (I thought it also had to be at the outermost scope too, but maybe not.) Dynamic imports are currently pending finalization of the spec, so every transpiler or module loader is going to implement them a little differently.
Personally, I use SystemJS as a module loader, because it handles loading CJS modules and it aims to be spec-compliant for ES modules. There's also just the ES6 Module Loader polyfill (which SystemJS uses internally) if you don't need CJS/AMD/etc. support and you just want something to handle dynamic ES module imports.
With that said, if you're worried about deferring loading for a few hundred lines of code, you probably don't need or want the overhead of a full module loader polyfill. Your best bet is probably just good old XHR for .js + eval (if the forms really need logic to back them up) or just XHR for .json + JSON.parse (if the forms are really just sets of data and all the logic resides in the main module).
Yeah it was mostly "If it was there an available" I'd do it and use it. Mostly making sure I wasn't missing something dumb before I changed gears. Just went back to doing an AJAX request and appending the result.
Do any of you have any experience with using Selenium to test websites? A lot of what I do is programming ASP.NET web pages, would Selenium be usable in a C# test project as a way to write unit tests against the UI?
Like when the user clicks a button, did this element unhide itself, etc.? I don't have much experience with testing because my company runs REALLY lean and they don't value testing very much, but this might save us some headaches.
The only thing I'm worried about with Selenium is O365 and SharePoint authentication, hopefully they have a way to handle that.
It does exactly what you want, but you shouldn't use it for "testing"(let alone unit testing). Limited monitoring and regression prevention is where we've found it does an ok job. Start light and adjust based on hotspots/critical parts of the UI or as post mortem actions.
zeeny on
0
Options
admanbunionize your workplaceSeattle, WARegistered Userregular
Do any of you have any experience with using Selenium to test websites? A lot of what I do is programming ASP.NET web pages, would Selenium be usable in a C# test project as a way to write unit tests against the UI?
Like when the user clicks a button, did this element unhide itself, etc.? I don't have much experience with testing because my company runs REALLY lean and they don't value testing very much, but this might save us some headaches.
The only thing I'm worried about with Selenium is O365 and SharePoint authentication, hopefully they have a way to handle that.
I have gone through the full O365 auth process in Selenium. It is... not super pleasant, but it works well enough.
Totally for testing and not to make production software work, that's for sure!
jaziekBad at everythingAnd mad about it.Registered Userregular
We're using it for regression testing, and just for general alerting.
It is super easy to get up and running, you can even just record actions in a browser and convert that to your language of choice.
Rather than just having a nagios script which checks that the site is up, it runs through a selenium script to test certain features of the site every so often.
Posts
Well, yes. I was asking rhetorically.
Rube Goldberg machine out of html form elements.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
Docker supports named volumes now, instead of volume containers. You can do this:
And the two containers will share a named data volume.
Shit. I just cleared my entire backlog in 3 minutes. :P
One of our client orgs needs custom form fields in addition to the standard questions we normally ask with our evaluations. They have four different types of forms they want to implement. This is a PHP/Javascript based app, and currently, the process for selecting and filling out a form goes like:
* Select Milestone Type
* Select Milestone
* Complete form.
Each type has a list of milestones. For some of those milestones, I need to inject up to dozens of new form fields. Ideally I'd like to store those fields in separate files per form and import them as needed. ES6 seemed like a great answer for this, except you have to call imports at the very start of a file, which means I can't determine which set of forms to import based off a variable once the milestone is selected.
I feel like I'm missing a really dumb, easy solution for this but just don't see it.
if (SaveClick != null) { SaveClick(this, EventArgs.Empty); }What is this wizardry C#?!
And I was all like "... bwah?"
"oh I mean.. yeah."
Not sure how you're really thinking ES6 is going to help here? I guess because of the CommonJS module support? If that's the case, think of import like a function, You can actually use it just about anywhere, even way post-load.
Babel is giving me an error and failing when I'm trying to transpile it. But yes I was hoping to store the relevant form bits in a module as a function to import/export when needed based off what form was being called. Rather than having an extra 200 lines or so of code in browser. I guess I could just stick it in an HTML file and AJAX and paste it in?
Yet another QoL feature I wish would make its way to C++. ?. and ?-> aren't even syntactically valid in any context so it couldn't break anything
What does IsVowel() accept as argument? Who cares!
Once C++ gets string interpolation life will be good. Something without sprintf/boost/<< would be nice.
I would be surprised if that ever really happens
Languages that don't have string interpolation should probably have string interpolation.
?: <-- elvis' hair
Turn it on its side.
it has to accept whatever letters is an IEnumerable of, though
I use this shit all the time though in order to have one-liners
I love the look of a method that is just
public SomeObject DoesAThing(List<SomeOtherObject> objects) { return objects.Select(MapSomeObject).FirstOrDefault(); }Yeah, when I discovered that I refactored the shit out of some code into a bunch of methods that were max 3-4 lines each.
In C# 6 this can be
Even more concise.
yeah, I can't use C#6.0 yet. Sadly.
I also have to keep doing
etc
The `import` keyword is for static imports only, meaning the module path must be a string literal. (I thought it also had to be at the outermost scope too, but maybe not.) Dynamic imports are currently pending finalization of the spec, so every transpiler or module loader is going to implement them a little differently.
Personally, I use SystemJS as a module loader, because it handles loading CJS modules and it aims to be spec-compliant for ES modules. There's also just the ES6 Module Loader polyfill (which SystemJS uses internally) if you don't need CJS/AMD/etc. support and you just want something to handle dynamic ES module imports.
With that said, if you're worried about deferring loading for a few hundred lines of code, you probably don't need or want the overhead of a full module loader polyfill. Your best bet is probably just good old XHR for .js + eval (if the forms really need logic to back them up) or just XHR for .json + JSON.parse (if the forms are really just sets of data and all the logic resides in the main module).
Now starting on the gigantic refactor to turn this from one giant file full of static functions into something thats actually readable / extendable / testable.
I've got a month, this is doable.
gonna use the hell out of all of the new features
Yeah it was mostly "If it was there an available" I'd do it and use it. Mostly making sure I wasn't missing something dumb before I changed gears. Just went back to doing an AJAX request and appending the result.
Like when the user clicks a button, did this element unhide itself, etc.? I don't have much experience with testing because my company runs REALLY lean and they don't value testing very much, but this might save us some headaches.
The only thing I'm worried about with Selenium is O365 and SharePoint authentication, hopefully they have a way to handle that.
I have gone through the full O365 auth process in Selenium. It is... not super pleasant, but it works well enough.
Totally for testing and not to make production software work, that's for sure!
It is super easy to get up and running, you can even just record actions in a browser and convert that to your language of choice.
Rather than just having a nagios script which checks that the site is up, it runs through a selenium script to test certain features of the site every so often.