Upload files to machines
by S. Sara
Hi everybody,
I am working on a cockpit plugin. Among some features, I would like to be able to upload some heavy binary files (# 500MB) to remote machines through cockpit web page.
Do you have some advices on how to do this ?
I am not sure the cockpit.file API is suitable for this.
Good job with this software.
Best Regards
S.
3 years, 5 months
React-Cockpit tools question - cockpit.spawn().stream() execution
by Simon Pichugin
Hi guys,
I have a React-Cockpit question. I kind of stuck with no good idea of
how to implement one thing...
The scenario I want to execute:
1. User clicks a button 'Run Full Report';
2. It creates a promise and checks through '.stream()' if the execution
requires user input;
3. If it requires - Show the input modal and wait for the user press
Confirm Button;
4. When the user enters the data (which I store in state) and confirms -
continue the execution in the existing '.stream()';
5. Repeat as many times as it requires (and it is dynamic because it
depends on the actual network state)
I have a few options but I am not sure which exactly React-Cockpit tools
I can use for that...
- Can I wait inside of cockpit.stream('here') for some state change? I
can wait for the React componentDidUpdate() but I am not sure how I
can connect this with exacting cockpit.stream('here') code.
- I have an ugly option with spawning a lot of promises to fetch user
data and then using it in the final report execution... But it looks
so ugly that I'd rather search for a 'smart' way...
If you can somehow direct me to a solution, it'll be most
appreciated. I've tried to search for the solution from different
angles but apparently I miss some React-Cockpit capabilities.
Kind Regards,
Simon
3 years, 7 months
Cockpit issue autumn cleaning
by Martin Pitt
Hello all,
as discussed in this week's meeting, it's time again [1] to garden our issue
tracker and clean up obsolete issues. We want to find the important and easy
issues that just fell through the cracks, clean up the noise that makes the
issue tracker less useful, and generally get an up to date impression about
what users have trouble with.
I [2] tagged all issues which haven't been updated in the last 90 days with the
"review-2019-10" label:
https://github.com/cockpit-project/cockpit/labels/review-2019-10
Let's please collectively go through them, and re-triage them:
* For bug reports, make sure that they still apply to current master. If they
do, just drop the review label. If they are fixed, close the issue. If they
need more information how to reproduce, please ask the reporter for clearer
instructions, or whatever else is necessary, label the issue with "question"
and also drop the review label.
* For enhancement reports, also check if they still make sense for Cockpit.
Some of them have been open for years, and we realistically won't get to
them. Some of them may also be too big to be tracked in an issue, and they
need an entire epic about them (and then they need to be reviewed whether we
want to do it at all -- so most likely "no" for most of them).
* At least in the last review round we also had a lot of feature requests for
entirely new pages. Almost all of them should become their own project.
Point to starter-kit and our documentation, and that we are glad to help
anyone with setting up a project, CI, etc., but we can't do all that work
ourselves -- we don't want to become experts and take responsibility for
everything!
If everyone can triage 5-10 every day, we should be through in about two weeks.
Of course in the beginning we'll look at the "easy" ones and be faster, and the
pace will go down towards the end -- but then we'll already have a much better
overview.
Thanks!
Martin
[1] Similar to what we did in January:
https://lists.fedorahosted.org/archives/list/cockpit-devel@lists.fedoraho...
[2] Well, our bots' issues-review script, of course
3 years, 7 months
Re: VM states
by Andreas Nilsson
Ran git blame on it, and it seems Marek was the one who initially wrote
this. Added him to cc.
https://github.com/cockpit-project/cockpit/commit/4665e79d18fa9b5bf1bc954...
Marek: Do you recall what the "dying" state does?
- Andreas
On 10/10/19 9:57 AM, Дмитрий Астанков wrote:
>
> Still, none of the links contain any info about "dying" state.
>
> 09.10.2019 18:39, Andreas Nilsson пишет:
>>
>> Hi!
>> Hopefully the RHEL documentation can give you some context:
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/...
>>
>> You can also get some context from the libvirtd documentation:
>> https://wiki.libvirt.org/page/VM_lifecycle
>>
>> Hope it helps!
>> - Andreas
>>
>>
>> On 10/9/19 5:04 PM, Дмитрий Астанков wrote:
>>>
>>> Greetings!
>>>
>>>
>>> I am currently translating Cockpit UI into Russian and the last
>>> thing that's left is virtual machine states (strings can be found in
>>> cockpit/pkg/machines/helpers.js):
>>>
>>> vmStates: {
>>> running: _("running"),
>>> idle: _("idle"),
>>> paused: _("paused"),
>>> shutdown: _("shutdown"),
>>> 'shut off': _("shut off"),
>>> crashed: _("crashed"),
>>> dying: _("dying"),
>>> pmsuspended: _("suspended (PM)")
>>>
>>>
>>> Can you please explain these to me or provide a link where I can
>>> read about them? I can't find any reliable resources which would
>>> contain *all* of the above so I can't be sure I get them right.
>>>
>>> --
>>> Best wishes,
>>> Dmitry Astankov (BaseALT Translation Team)
>>>
>>> _______________________________________________
>>> cockpit-devel mailing list --cockpit-devel(a)lists.fedorahosted.org
>>> To unsubscribe send an email tocockpit-devel-leave(a)lists.fedorahosted.org
>>> Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives:https://lists.fedorahosted.org/archives/list/cockpit-devel@lists...
>>
>> _______________________________________________
>> cockpit-devel mailing list --cockpit-devel(a)lists.fedorahosted.org
>> To unsubscribe send an email tocockpit-devel-leave(a)lists.fedorahosted.org
>> Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:https://lists.fedorahosted.org/archives/list/cockpit-devel@lists...
> --
> Best wishes,
> Dmitry Astankov (BaseALT Translation Team)
3 years, 7 months
VM states
by Дмитрий Астанков
Greetings!
I am currently translating Cockpit UI into Russian and the last thing
that's left is virtual machine states (strings can be found in
cockpit/pkg/machines/helpers.js):
vmStates: {
running: _("running"),
idle: _("idle"),
paused: _("paused"),
shutdown: _("shutdown"),
'shut off': _("shut off"),
crashed: _("crashed"),
dying: _("dying"),
pmsuspended: _("suspended (PM)")
Can you please explain these to me or provide a link where I can read
about them? I can't find any reliable resources which would contain
*all* of the above so I can't be sure I get them right.
--
Best wishes,
Dmitry Astankov (BaseALT Translation Team)
3 years, 7 months
Re: Question
by Martin Pitt
Hello Jonathan,
Jonathan Aquilina [2019-10-06 5:39 +0000]:
> I have a question. I understand that cockpit is still in its infancy
Software is never "done", but I daresay Cockpit is a rather mature project by
now. It has shipped in all major distros
(https://cockpit-project.org/running.html) for quite a while :-)
> but are there plans to add more apps that can be managed through cockpit?
Indeed the "cockpit ecosystem" in the sense of "other people writing
extensions" can be called infancy stage. There's UIs for composer, podman,
session-recording, Leapp, RHEL's subscription-manager, and OSTree, and some
PoCs for installing Fleet Commander and FreeIPA server through Cockpit's
Applications page (i. e. they are/were in Fedora for a while, but not e. g. in
RHEL or other distros).
The cockpit team itself doesn't currently have plans to write more, but that's
also not our primary goal. We don't want to become experts in everything, but
want to provide the tools and help for *other* teams to provide cockpit UIs for
their technology. For that we offer the Starter Kit
(https://github.com/cockpit-project/starter-kit), documentation like
https://cockpit-project.org/external/wiki/Contributing.html and the blog posts
linked from there, and are happy to get in personal touch to help teams with
coding struggles, CI setup, etc.
> Also what is the best way to start contributing to the project?
There's no general answer to that, as it really depends on who wants to get
involved and why. Usually in FOSS, someone has an "itch", a bug they want to
fix, or a feature they want, or some Cockpit UI they want/need in their
environment. For these cases, reporting a GitHub issue (bug/feature in the
cockpit project itself), or tinkering with the starter-kit and forking it to
your own UI (see above) is a great way to start.
Others want to learn JavaScript/HTML or just programming in general. If you
don't have a specific itch to scratch, we have plenty of things to do that are
suitable for beginners, i. e. which don't require a comprehensive and deep
understanding of the whole cockpit project:
https://github.com/cockpit-project/cockpit/issues?q=is%3Aopen+is%3Aissue+...
In either case, you are always welcome to discuss particular ideas or questions
on IRC in #cockpit, or here on the mailing list, or in GitHub.
Thanks,
Martin
3 years, 7 months
Question
by Jonathan Aquilina
Good Morning,
I have a question. I understand that cockpit is still in its infancy, but are there plans to add more apps that can be managed through cockpit? Also what is the best way to start contributing to the project?
Regards,
Jonathan
3 years, 7 months