It also seems pretty much the same as ansible (which suffers the same problems as you mentioned).
I pretty much agree with you, they should of provided 2 entrypoints IMHO, they can make there DSL and all that and make it (eventually) turing complete and at the same time they should just provide composeable objects in <some> language as well.
I've never quite figured out who the target audience is for these kind of DSL(s), is it people that can't program, or people that can't program well/at all (without adult supervision)?
I don't know either. Puppet, ansible, salt, and friends are in the same boat. The best part is that the special syntax doesn't buy them anything. They just end up being gimped languages for expressing some kind of dependency graph.
They all suck in equal measure, but each in a different fashion. You can only try to pick the one tool that sucks the least for your particular use-case and hope that two years down the line you made the right choice.
This isn't much of an argument. That's like saying all programming languages suck and it's a crapshoot. It's not. There are design principles that work and scale to large scale systems and then there are things that don't.
As far as I'm concerned Chef is the right way to do configuration management. Everyone else with their YAML DSLs is doing it wrong. Expressing dependencies between resources does not require specialized external DSLs and sometimes you need to do imperative things to get to the end which is either impossible or just horribly convoluted with any tool that tries to hide complexity behind a markup/serialization language.
Apparently these people think it makes it "simpler". Well I'm sorry but me looking up how to format things with yaml and no autoformat and no intellisense just isnt good and doesnt make things simple.
Even xml with a backing xsd would be better than that, but that's apparently not cool enough anymore.
I forgot about the lack of auto-complete and the horrible error messages. At least with a library when I have a syntax error or something blows up I have a debugger and the actual language at my disposal to figure stuff out. No such things are remotely available with all these external DSLs. If even there is any semblance of error reporting.
Several human centuries of effort have been spent on improving these things (syntax highlighting, auto-complete, stack traces, error messages, interactive debuggers, etc.) and then all these DSL authors decide to just chuck it all out. Boggles the mind.
More than a few times Terraform has wrapped an error message from AWS in the hopes of being helpful while hiding all the details of the actual error message and no hints how to rectify things in the DSL.
I had the same experience with ansible. It also wraps the responses in some ultra verbose json. I really just want to see the remote commands being executed, if you return them wrapped in some kind of format then you need to provide a gui for it. Otherwise it's all worse than before.
Would you know a recent tool based on XML + XSD (or RNG) in the space (I believe IBM had one like 10 years ago, but it got sacked because XML)? I've never been a fan of using markup languages for things other than text/semistructured data, but yaml/toml/json is such a huge step backwards that I'm having trouble recommending it.
So being a PTL in OpenStack I have some various comments and questions that would be nice to have your thoughts on.
In terms of looking at OpenStack hard; and reaching decisions based on various <things> did you do any reach out to the OpenStack community to actually communicate the things you found or heard or concluded so that the group there (including myself) can actually work on improving itself (or perhaps some of the reasons you stated aren't even correct and the community could have helped you clarify those)? If not then it concerns me that you may have reached conclusions without actually talking with that community (but I don't want to jump to any conclusions without getting your thoughts/input).
So far from looking outwards in on the CNCF and seeing how it compares to the OpenStack community (which I am more involved with, including other small side-communities that I also work in) I've yet to understand what exactly the CNCF is targeting. It seems to be a body that is just adopting various projects that align to some mission (?); I have personally a hard time understanding the reasoning some of the projects have been adopted, maybe you can shed some light on that (what is true north for the CNCF, where is it written down, what is the TOC actually making adoption yes/no decisions on? what criteria? what is the technical taste you talk about, where is it written down?)
The nice thing about OpenStack is that they are writing most/all of this down and agreeing on those kinds of questions in public:
A fair point. One thing worth remembering is that this was a point in time thing. I have seen a lot of movement and some very positive signals around convergence of OpenStack, and a real focus on the end user community. When I was doing the digging things felt different and there is a decent chance that were open stack where it is now I would have taken a different position.
The mission of CNCF is the promotion of 'cloud native technologies' -- specifically container packaged, dynamically scheduled, micro-services oriented workloads. It isn't about picking winners, it is about establishing a safe space for innovation and bringing to bear the collective communities. We have legitimately taken some time in getting the identity of the foundation established, but I feel like Dan Kohn (our new ED) is doing super work in creating a collaborative space for new projects.
Thanks for the part of the response though I'm still concerned at the 'felt' part though, especially if that felt part didn't involve talking with much/any(?) of that community in a public forum. Is there anything I can do to help you understand it better, I'd at least like to be able to echo whatever concerns you had to that community, because at that point it can be actual data that made the decision to go with CNCF creation and not just feelings or thoughts of movement or positive signals (all very fluffy things IMHO).
So in the CNCF, are competing implementations allowed / encouraged?
For me that would have repercussions for what other tech a CNCF project supports (e.g. is all stats monitoring based on Prometheus, or can 2 projects in the CNCF support different technologies)
to elaborate for @hueving @mugsie et al., consider that OpenStack is organised around Nova, the scheduler++ that is at the heart of any OpenStack deployment. If the CNCF was "like OpenStack" then it could mandate that all projects are organised around Kubernetes, playing a role analogous to Nova. But we didn't want to be solely a "Kubernetes foundation". The market is early stage, and there are other valid approaches to orchestration, including Docker Swarmkit, Hashicorp Nomad, Mesos & DCOS templates like Marathon, and others. So, we need a different approach.
Of course there are people who want a KubeStack that is like OpenStack, for better or worse. That's fine too! We just don't want that to be the ONLY choice for customers.
Do you allow competing APIs for the same service? If not, how is that any different from OpenStack? If so, how do you address the issue of fragmentation across deployments?
You said it yourself in another comment on here: "It's never blatant, it's always calls for seemingly good things like extra pluggable points to make sure we don't favor particular solutions. Then it's making sure that any decision is brought to a huge vote by a giant committee that spends weeks arguing about if it's something they should even decide on, etc."
This kind of premature generalisation by committee is what has pulled OpenStack down; a situation from which it is now apparently recovering. CNCF seeks to avoid this, by encouraging projects towards interop but not in mandated ways.
Projects can do what they like. We believe that users, communities, market pressures, and so on, will drive good outcomes here. For example to date, all projects have worked to interoperate of their own volition. No committees were formed to achieve this.
From an analysis of all commits in the k8s (main) repo this is the data I am getting about domains and the breakup of which users under which domains commit/author the most.
Btw you (google?) should really invest in something like http://stackalytics.com/ if the community wants to have good transparency around this type of data.
In my experience, the question of who the contributors are and how much they may contribute is less important than the question of who has control of the project.
If you're claiming that Google has delegated authority over Kubernetes to the open-source community, and therefore is not in a position to place its needs over those of the community, please say so explicitly here.
Why quibble over statistics when we can get an official statement?
We, Google, have contributed 100% of Kubernetes to the Cloud Native Compute foundation, and, therefore, are not in position to place our needs over those of the community.[1]
That is not to say we (Google) do not continue to be deeply invested in its success (it's the core of our Google Container Engine), and, further, human beings who are also employed at Google _are_ core contributors to the project, but Google is not associated with the project.
So out of curiosity, what did you see about OpenStack that made you go this route?
I myself am a PTL (project technical lead) in one of the OpenStack projects and although I do understand where you are coming from I wonder what the gist of the experience you had was...
Care to share what experiences you have that made you think 'total dumpster fire'?
I know the software isn't perfect, but then what software is? Also I've seen that the OpenStack 'having a bad time experience' is as much of a cultural change as it is a software change; ie, OSS in general isn't a take and not contribute kind of thing, that's not how it really works/gets better.
So is there ongoing work to replace borg with K8s (afaik the adoption of omega pretty much stalled and/or died)?
I myself would feel more confidence in K8s if there was usage of K8s outside of GKE and the dogfood being created was eaten by the rest of google as well (or at least there was a publicized plan to make that happen), because otherwise it feels more like K8s is a experiment that google folks are waiting to see what happens before the rest of google adopts it.
Has anyone figured out how to debug and/or analyze deep ANN?
That's the problem I always had, you may get them into a trained state, but good luck figuring out any reason 'why' they ended up in that state (or even what that state really is).
IMO that's not really the point of deep learning. I'm not saying no efforts have been made to work towards better understanding, but the types of problems deep learning is good at I do not believe have easily explainable answers.
There are machine learning methods out there that are much better at explaining why, but fail hard on problems that DNN is good at.
IMHO, this is the nature of the problem, not the solution.
> That's the problem I always had, you may get them into a trained state, but good luck figuring out any reason 'why' they ended up in that state (or even what that state really is).
Can you give a specific example of what you mean? I ask because I see this sentiment often, but primarily from people who are very new to deep learning.
You can definitely debug a neural network. You mostly want to look at metrics from training such as gradient norms or try adjusting parameters to see if you can get a gain in overall performance as measured by cross validation performance.
You can definitely analyze a neural network. You do so by forming hypotheses, preparing datasets that reflect those hypotheses, and running them through your trained models, noting cross validation performance. It's also possible to visualize the weights in various ways, there are many papers written about it.
So what do you mean exactly when you say no one has figured out how to debug or analyze DNNs?
You cannot say: "This image was classified as a stop sign, because this part recognized the shape and this part recognized the color, and this part the text", which you could do with other approaches.
When it doesn't discover that it's a stop sign, how do you debug it? Did it recognize the shape.. who knows?
> When it doesn't discover that it's a stop sign, how do you debug it? Did it recognize the shape.. who knows?
Barring other analytic tools (like looking at which parts contribute the most to the wrong result), the same way you test other things when you have a (somewhat) black box:
Form hypotheses and test them.
Maybe it didn't recognise the shape, so try adjusting the image to clean it up, and once you have one it recognises, try to reduce and alter the difference between them. Maybe it turns out the image e.g. has the stop sign slightly covered, making the shape look wrong, and there's nothing in the training set like that.
Maybe the hue or brightness is off and the training set is mostly all lit a certain way. Test it by adjusting hue and brightness of the test image and see if it gets recognised.
And so on.
There are plenty of other areas where we are similarly constrained from taking apart that which we're observing, so it's not like this isn't something scientists are dealing with all the time.
Within comp.sci. we're just spoiled in that so much of what we do can be easily instrumented, isolated and tested in ways that often lets us determine clear, specific root causes through analysis.
They tweak the input to maximize the response of specific neurons somewhere in the middle of the network to figure out what those neurons actually "learned".
Docs:
https://docs.openstack.org/infra/jenkins-job-builder/
Reviews:
https://review.openstack.org/#/q/project:openstack-infra/jen...
Code:
https://git.openstack.org/cgit/openstack-infra/jenkins-job-b...