cockpit-devel May 2017

cockpit-devel@lists.fedorahosted.org

16 participants
11 discussions

Some upcoming events to think about for Cockpit talks
by Josh Berkus 15 Sep '17

15 Sep '17

Cockpit Devs: As we talked about earlier, we need to expose more Linux users to Cockpit. As such, I wanted to let you know about a few upcoming conferences which are heavily patronized by Linux admins and would be a good place to start: Usenix LISA https://www.usenix.org/conference/lisa17 Deadline Monday, April 24, 2017, 11:59 pm PDT Open Source Summit (was LinuxCon) http://events.linuxfoundation.org/events/open-source-summit-north-america Deadline May 6, 2017 Open Source Summit Prague http://events.linuxfoundation.org/events/open-source-summit-europe Deadline July 8, 2017 ... there will be others as the calendar progresses (as well as Meetups). If anyone is interested in presenting to external audiences about Cockpit, please let me know ... I can help with reviewing conference submissions, travel funding and more. -- -- Josh Berkus Project Atomic Red Hat OSAS

3 4

Create Virtual Machine functionality
by Marek Libra 14 Jun '17

14 Jun '17

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>

2 1

Remotable Libvirt
by Peter 07 Jun '17

07 Jun '17

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.

9 22

No login and password field. Cannot login in.
by Fujisan 31 May '17

31 May '17

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

1 0

Weekly meeting
by Marius Vollmer 29 May '17

29 May '17

================= #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-13.… . 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

1 0

Remotable Libvirt
by Peter Volpe 25 May '17

25 May '17

1 0

Call for testing/feedback: Cockpit OS update feature
by Martin Pitt 24 May '17

24 May '17

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-for… [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

4 4

Unblocking port 9090 for Atomic Hosts
by Josh Berkus 19 May '17

19 May '17

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

2 1

Weekly meeting
by Marius Vollmer 09 May '17

09 May '17

================= #cockpit: meeting ================= Meeting started by mvollmer at 13:00:44 UTC. The full logs are available at https://meetbot.fedoraproject.org/cockpit/2017-05-08/meeting.2017-05-08-13.… . Meeting summary --------------- * Agenda (mvollmer, 13:02:42) * image pruning on servers / distributed storage (mvollmer, 13:05:40) * application manager, next steps (mvollmer, 13:26:12) * LINK: https://www.youtube.com/watch?v=Pmi6AJanRtk (andreasn, 13:27:10) * LINK: http://dep.debian.net/deps/dep11/ (pitti, 13:36:49) * LINK: http://appstream.ubuntu.com/ too (pitti, 13:38:38) Meeting ended at 13:42:33 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * stefw (79) * mvollmer (54) * dperpeet (36) * pitti (13) * zodbot (8) * andreasn (5) * garrett (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

Automated Fedora update testing
by Adam Williamson 08 May '17

08 May '17

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

3 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

cockpit-devel May 2017