Support Images

[BrunnerLivio]

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

[alandoherty]

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.

[anthonyloukinas]

Any luck on this? Having access to the images per LXD host would be extremely helpful. I'll also look into contributing.

[alandoherty]

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.

[anthonyloukinas]

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. 👍

[mkg20001]

I've made another module called lxdn which supports all the lxd apis: https://github.com/mkg20001/lxdn

[anthonyloukinas]

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!

[BrunnerLivio]

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..

[SEUH]

You shouldn't be sorry. It isn't your job to this. Every contribution to open source is great.
Yes, 3 lxd clients is not good but the problem is, they are all different. Back in the days i first used the other lxd client but it was really bad and didn't work properly. Then i tried your's but again, not everything was implemented and the biggest problem was remote authentication/+handling. So even i wrote an abstracted lxd client from your one with more impementations but it just was a mess.

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.

[mkg20001]

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

Note that mine doesn't yet support certificate auth because I only needed it for local connections (#worksForMe), but I will add this later this week Support added in lxdn@0.1.5, but it's still untested. Report issues, please

We may should align and find the best solution, unify our solutions..

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).
I like the idea of keeping things autogenerated so catching up with the LXD API isn't so hard.

[BrunnerLivio]

@mkg20001
I really do not know if I am amazed, or disturbed. You actually build the API by parsing your markdown documentation. (?!?) Wow thats ... something hahaha. I love and hate this impmementation at the same time, I’m so conflicted.

[mkg20001]

build the API by parsing your markdown documentation

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 ;)

[mkg20001]

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 .start()/.stop() methods) and would keep the API for most users likely the same.
For naming I think it would be best if the module would simply be named "lxd" (there currently is a module published under that name but it hasn't been update since 3 years and only does certs and config endpoints) so it would be the "offical" merger of all the different modules and all the others could get deperacted with a message to use this one.