Create Virtual Machine functionality
by Marek Libra
Hi,
as a next step for the cockpit-machines, I plan to implement the "Create
VM" functionality.
Before doing that, I would like to collect ideas, agreement on scope and
preferably on design.
The long term vision is support for (almost) all features as virt-manager
has.
Definitely, path to this goal has to be splited into smaller steps,
starting with something generic enough but providing just the minimum and
useful functionality.
The component will be reusable for both "New VM" and "Edit VM" flows.
Will be implemented as a wizard, user can navigate back and forth, maybe
even "jump" into a step of his choice.
Wizard can be canceled in every step.
All write operations are postponed until final "submit".
Optional "external provider" will be able to extend the wizard dialogs and
will handle the "Submit".
Initial implementation:
Wizard dialog 1: Basic props
- VM name
- vcpus
- memory
- qemu connection (whether session or system)
Wizard dialog 2: Disks
- single disk's params
Wizard dialog 3: Boot order
- cdrom iso file
- from an associated disk
Wizard dialog 4: Consoles
- select none or any combination from
- SPICE
- VNC
- address and port can be specified, defaults provided
Wizard dialog 5: Summary
- All entered details are listed (tree-list component?)
- User can navigate back, cancel or submit
High-priority follow-ups:
- User can select multiple existing disks and/or create multiple new ones
- "Networks" wizard dialog plus PXE boot
- "submit and run" functionality
- "Edit VM"
- cdrom iso from network source (URL)
Later on, new wizard dialogs can be added or existing ones extended.
So far I considered but rejected these other concepts:
- single complex dialog (no wizard, sort of "functionality grouping"
would be still required)
- "Edit" functionality mixed with the recent presentation components
(nightmare for more complex configuration)
I'm looking for feedback - e.g. UX, extensibility, scope or whatever to be
taken for consideration.
Thanks,
Marek
--
Marek Libra
senior software engineer
Red Hat Czech
<https://www.redhat.com>
6 years, 11 months
Remotable Libvirt
by Peter
Hi Everyone,
We are working towards building on the virtualization management
functionality in cockpit (http://cockpit-project.org/) and wanted to get
some feedback on the best way to integrate with libvirt.
As a quick overview, cockpit aims to talk to existing remotable system
APIs. Usually these API’s take the form of dbus, REST or executable
commands. The majority of cockpit is implemented in javascript. There is
no cockpit backend that knows how to change a hostname for example. The
cockpit backend knows how to handle a dbus payload. The javascript
running in the users browser knows how to use the systemd dbus API at
org.freedesktop.hostname1 to manage the system hostname.
Right now some of the basics have been implemented by spawning commands
on the system. This isn't ideal because it involves parsing / screen
scraping output and doesn't support receiving events so we have to poll
(ei run the command again) to keep the UI up to date.
As far as I know libvirt doesn't currently have a remoteable API. It
does have a daemon that communicates with clients via a XDR RPC.
(https://libvirt.org/internals/rpc.html) However from what I'm hearing
the RPC is considered an internal implementation and shouldn't be used
by external applications. Is that still the case? Is there any chance of
getting talking the daemon directly using the XDR standard for a subset
of methods blessed as part of the externally supported API?
An alternative is to implement a standards based remotable API, using
something like dbus or REST, that can be used by external applications.
I imagine that this would be at a bit of a higher level than the current
RPC and contain at least some of the logic around the actions it
performs rather than being a direct passthrough to the daemon.
Of course that is a pretty big undertaking and would, in my opinion,
only be worth it if there is broader interest in the community and use
cases beyond what cockpit would like to.
6 years, 11 months
No login and password field. Cannot login in.
by Fujisan
Hello,
I'm running cockpit 137 on a fedora 25 server and when I go to the cockpit
login page on port 9090, I get this: http://i.imgur.com/12ucNiY.png
The cockpit service becomes inactive after a few seconds when I restart it:
# systemctl status cockpit
● cockpit.service - Cockpit Web Service
Loaded: loaded (/usr/lib/systemd/system/cockpit.service; static; vendor
preset: disabled)
Active: inactive (dead) since Wed 2017-05-31 11:39:35 CEST; 2min 11s ago
Docs: man:cockpit-ws(8)
Process: 25616 ExecStart=/usr/libexec/cockpit-ws (code=exited,
status=0/SUCCESS)
Process: 25613 ExecStartPre=/usr/sbin/remotectl certificate --ensure
--user=root --group=cockpit-ws --selinux-type=etc_t (code=exited,
status=0/SUCCESS)
Main PID: 25616 (code=exited, status=0/SUCCESS)
May 31 11:38:05 systemd[1]: Starting Cockpit Web Service...
May 31 11:38:05 systemd[1]: Started Cockpit Web Service.
May 31 11:38:05 cockpit-ws[25616]: Using certificate:
/etc/cockpit/ws-certs.d/~self-signed.cert
6 years, 11 months
Weekly meeting
by Marius Vollmer
=================
#cockpit: meeting
=================
Meeting started by mvollmer at 13:00:52 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/cockpit/2017-05-29/meeting.2017-05-29-1...
.
Meeting summary
---------------
* Agenda (mvollmer, 13:03:09)
* Server Applications update (mvollmer, 13:05:51)
* libvirt (mvollmer, 13:24:57)
* Any other business (mvollmer, 13:42:43)
Meeting ended at 13:44:02 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* mvollmer (47)
* petervo (43)
* zodbot (9)
* pitti (8)
* dperpeet (5)
* mlibra (3)
* garrett (1)
* larsu (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
6 years, 11 months
Remotable Libvirt
by Peter Volpe
Hi Everyone,
We are working towards building on the virtualization management
functionality in cockpit (http://cockpit-project.org/) and wanted to get
some feedback on the best way to integrate with libvirt.
As a quick overview, cockpit aims to talk to existing remotable system
APIs. Usually these API’s take the form of dbus, REST or executable
commands. The majority of cockpit is implemented in javascript. There is
no cockpit backend that knows how to change a hostname for example. The
cockpit backend knows how to handle a dbus payload. The javascript
running in the users browser knows how to use the systemd dbus API at
org.freedesktop.hostname1 to manage the system hostname.
Right now some of the basics have been implemented by spawning commands
on the system. This isn't ideal because it involves parsing / screen
scraping output and doesn't support receiving events so we have to poll
(ei run the command again) to keep the UI up to date.
As far as I know libvirt doesn't currently have a remoteable API. It
does have a daemon that communicates with clients via a XDR RPC.
(https://libvirt.org/internals/rpc.html) However from what I'm hearing
the RPC is considered an internal implementation and shouldn't be used
by external applications. Is that still the case? Is there any chance of
getting talking the daemon directly using the XDR standard for a subset
of methods blessed as part of the externally supported API?
An alternative is to implement a standards based remotable API, using
something like dbus or REST, that can be used by external applications.
I imagine that this would be at a bit of a higher level than the current
RPC and contain at least some of the logic around the actions it
performs rather than being a direct passthrough to the daemon.
Of course that is a pretty big undertaking and would, in my opinion,
only be worth it if there is broader interest in the community and use
cases beyond what cockpit would like to.
6 years, 11 months
Call for testing/feedback: Cockpit OS update feature
by Martin Pitt
Hello all,
I've been drafting and implementing a new Cockpit feature for providing a
"Software Updates" page for "classic" yum/dnf/apt based systems (the current
one is for Atomic OSTree only). This uses PackageKit to retrieve update
information and install packages, and I've now tested it on Fedora 25, CentOS
7, Debian 8, Debian testing, and Ubuntu 16.04. It looks like [2] for me on
Fedora 25 or like [3] on a Debian testing installation from a few weeks ago
(thus there are tons of updates available, and Debian changelogs tend to be
much more detailled).
This is now sufficiently useful and robust for getting some wider feedback and
testing. For easier and faster development it's currently a standalone
project/repository [4], it includes a README how to install it:
mkdir -p ~/.local/share/cockpit
cd ~/.local/share/cockpit
git clone https://github.com/martinpitt/cockpit-os-updates.git
npm install
npm run compile
If you don't have "npm", you need to install it first with "sudo yum install npm".
Feedback I'm looking for:
- How does the UI and update process work and feel for you? Does it cause
bad appearance/rendering or visual glitches or even actual upgrade failures
for you? (please include screenshots).
- Is there some missing feature which is crucial for a first public
version/inclusion into Cockpit? Note that the spec talks about configuring
automatic updates, but that will not be in the first version.
- I'm *very* new to React and JS at large, so I'd appreciate some commentary
on the code for bad patterns/style.
Known issues:
- The tooltips for package names (package summary) and CVEs (CVE description)
are not Cockpit-styled. This is a limitation of being a standalone module (I
can't use Cockpit's tooltip React component) and will be fixed when
including this into the Cockpit tree.
- Applying updates currently looks a bit simple-minded. This hasn't gone
through a Garret-level design process yet, I just threw something initial
together (progress bar and currently processed package).
- On Ubuntu 16.04 or Debian 8 (sorry, forgot which one) there are no
changelogs. That's a limitation of what PackageKit can give us.
Thank you in advance!
Pitti
[1] https://github.com/cockpit-project/cockpit/wiki/Feature:-System-Updates-f...
[2] http://piware.de/tmp/os-updater-20170523.png
[3] http://picpaste.com/pics/updates-debian-POB2UySL.1495548975.png
[4] https://github.com/martinpitt/cockpit-os-updates
[5] https://github.com/martinpitt/cockpit-os-updates/blob/master/os-updates.jsx
6 years, 11 months
Unblocking port 9090 for Atomic Hosts
by Josh Berkus
Cockpit folks:
Both openshift-ansible and most Kubernetes installers cause port 9090 to
be blocked or routed to the orchestration system. For that matter, I
expect that a default firewalld also blocks it.
Is there some way we can unblock the port as part of install of the
cockpit/ws container?
--
--
Josh Berkus
Project Atomic
Red Hat OSAS
6 years, 12 months
Automated Fedora update testing
by Adam Williamson
Hi folks! I thought this might be of interest to the Cockpit community,
so I thought I'd write it up here in case anyone missed it elsewhere.
I work on the Fedora QA team, and we have been using the openQA
automated test system (developed by our friends at SUSE) to run various
functional tests on Fedora composes for the last couple of years.
As Cockpit is considered a critical part of Fedora Server, we run a few
tests that exercise Cockpit. They're nowhere near as extensive as
Cockpit's own test suite, but they run in a somewhat different context:
they run on the Fedora packaged Cockpit, against the rest of a Fedora
environment. They also test in a somewhat different way from Cockpit's
own test suite: openQA tests a lot like a human, by booting up a
virtual machine and then effectively "looking at the screen" and
sending mouse and keyboard input events (via VNC). The test boots a
full Fedora system, runs Firefox, and interacts with Cockpit like a
human being would. For both of these reasons, it can sometimes catch
problems Cockpit's own tests would not (it also sometimes goes wonky in
ways that Selenium-based tests don't, but never mind, that's my job to
deal with :>)
Until recently we ran these tests only on Fedora's nightly development
release distribution composes. Recently, though, we deployed some
enhancements to our openQA setup that let us run tests on Fedora
distribution updates as well, and have the results made visible through
the Fedora update system (Bodhi). I have just made it so that, from now
on, these tests will run on any update that contains the 'cockpit'
package. They also run on any critical path update.
This means that for any Fedora update containing cockpit or any
critical path package, Fedora's openQA cockpit tests should run, and
you should see the results in the Fedora update system (Bodhi). You can
see the results in Bodhi by clicking the Automated Updates tab for any
update. For instance, here's a recent Firefox update for Fedora 25:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-31c64a0bbf
If you look at the Automated Tests tab, you can see passes for:
update.server_cockpit_basic
update.server_cockpit_default
update.realmd_join_cockpit
indicating that this Firefox update didn't cause any problems for
Cockpit. Clicking on any test result will take you to the openQA page
for the test, where you can diagnose failures and so on (explaining how
to do this is a bit beyond the scope of this mail, please do ask me if
you're interested!)
I hope this stuff will help us avoid shipping updates that break
Cockpit (and other key components). If you have any questions,
concerns, comments, or suggestions, please do ask!
To anticipate one question: you can cause *all* the tests for an update
to be re-run by editing the update in any way (you don't have to change
the package loadout, just changing a single character in the
description or something will do). If you think just one test result is
bogus and want it re-run, currently, you'll have to ask someone with
the necessary power - either me or Jan Sedlak (garretraziel on IRC).
I'm in North America and he's in Europe, so we should have most
timezones covered between us. We're hoping to set up a better mechanism
for this in future.
Note, if you're interested in the results for the nightly Fedora
distribution composes, an email summary of the results for those is
sent each time they're run to the Fedora test@ and devel@ lists, look
for mails with "compose check report" in the subject. Any time any of
the cockpit tests fails, the failure will be listed in the mail (passed
tests are not specifically listed, just a count of them). I usually
keep an eye on those results and analyze failures and file bugs,
though.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
7 years
