-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Images #10
Comments
I’m planning on doing some more work on the project early March, but gonna focus on some of the older issues such as checkpoints first. So you’re free to fork and PR. |
Any luck on this? Having access to the images per LXD host would be extremely helpful. I'll also look into contributing. |
BrunnerLivio submitted a request, but it was inconsistent so couldn't approve it. If you could look into replicating his work and fixing the issues in his pull request that might be quicker. |
Alright I'll take a look. Thanks for the update. This is off-topic to this issue, but I didn't see anything in your documentation about it.. Do you natively support snapshot management at all? I may look to add that as well. There's also the new 3.0 Storage API that could prove useful, even at a basic level. Allowing me to choose a certain storage pool to dump a container on. Just some thoughts. Not sure if you are still contributing to this project anymore or not. I'm actually using this API to build an openstack replacement at my company, so kudos to you for putting this out. 👍 |
I've made another module called lxdn which supports all the lxd apis: https://github.com/mkg20001/lxdn |
Wow, that looks great. I'm not much using LXD as I've somewhat migrated to Docker, but I'm going to give this a go. Thank you for contributing! |
Sorry for lack of communication. The problem was, I needed an interface to access data with the LXD API as soon as possible back then, but while I was working on the PR I realized because of some of the architecture decisions of this library, it will be hard to integrate properly in my TypeScript application. Because time was pushing I quickly created node-lxd-client, so I can accept my code changes quicker in case something was needed and not having to rely on other persons approval. NEVER do something as I did. The problem was; my LXD project was part of my final project of my school, and I had only 80 hours to finish it. So time was really pushing. That is why I did not want to rely on PR and third party approvals. Now at this point we're having three LXD client in Node, which is an absolute no-no. We may should align and find the best solution, unify our solutions.. |
You shouldn't be sorry. It isn't your job to this. Every contribution to open source is great. I haven't looked at the one written by @mkg20001 but if this is the one which covers all api endpoints and has remote authentication, he should propose it to the lxd team. |
The reason why I was able to write this client so quickly was because I simply thought from a lazy guy's prespective: I would never be able to write code for all api endpoints without giving up somewhere midway. So I opted for the other way: Write code that writes code. I quickly hacked together https://github.com/mkg20001/lxdn/blob/master/api/build.js which takes the LXD api doc md file as input and generates the api client code. The only part I had to write myself was the client itself (that part that actually sends requests and parses the responses) https://github.com/mkg20001/lxdn/blob/master/src/client.js
Definitively. While my client should support all api calls, the APIs used to access those aren't very ergonomic (but they're the best I could come up with that weren't too hard to autogenerate). |
@mkg20001 |
No, I just used the original https://github.com/lxc/lxd/blob/master/doc/rest-api.md#api-structure. I'm waaaay to lazy to write my own docs for LXD ;) |
I've just had a great idea how we can merge both modules: While my module does all API calls, it's still not very ergonomic. Maybe it can be used as a low-level api on top of which this module gets rebuilt? This would remove a lot of the complexity as this module currently tries to do both the low level (direct calls) and high level (those nice objects with |
As far as I know, there's no support for
/1.0/images/*
-requests.These requests should be supported:
/1.0/images
/1.0/images/<fingerprint>
*
/1.0/images/<fingerprint>/export
*
/1.0/images/<fingerprint>/refresh
*
/1.0/images/<fingerprint>/secret
/1.0/images/aliases
*
/1.0/images/aliases/<name>
More information: https://github.com/lxc/lxd/blob/master/doc/rest-api.md
If no one's working on this yet, I can consider making it by myself and then create a PR
The text was updated successfully, but these errors were encountered: