We've run into an issue with travis where adding new make files causes
the tests to fail with an "write error" when running distclean.
For example: https://travis-ci.org/cockpit-project/cockpit/jobs/76408030.
We haven't been able to reproduce these failures anywhere else. In
addition their new container based infrastructure that they are moving
towards doesn't support sudo which we need for our reauthorize tests. So
we are looking at replacing travis with a different CI service.
I looked at semaphoreci and circleci. I was eventually able to get our
test suite to pass on both systems. Both seems to have most of the same
github integration / badges but Circleci is based on Ubuntu 12 and we'd
really like to be able to use something newer.
You can see my cockpit fork on semaphoreci here:
https://semaphoreci.com/petervo/cockpit
PROS:
- It works and uses a newer OS (Ubuntu 14)
- Allows you to ssh into instances to run / debug tests.
CONS:
- There is only one configuration per project that is configured via
their website. So you can't change the commands on a per branch / PR
basis. Additionally the webui has some bugs and usability issues that
end up requiring a few tries before it gets the commands in the right
order and in the right threads.
- We have to run on their container based beta platform as their normal
platform doesn't fully support inotify and causes tests to fail.
- Doesn't do IRC notifications out of the box. Though we could probably
implement something using webhooks if we wanted to.
What does everyone think about switching? Worth doing or should we keep
looking at other options?
================
#cockpit Meeting
================
Meeting started by stefw at 13:02:41 UTC. The full logs are available at
http://meetbot.fedoraproject.org/cockpit/2015-08-24/cockpit.2015-08-24-13.0…
.
Meeting summary
---------------
* Agenda (stefw, 13:02:47)
* travis/semaphore/... (stefw, 13:05:12)
* mvollmer will file a bug on travis, and try to help find the source
of the issue (stefw, 13:15:39)
* mvollmer will also install a workaround for us (mvollmer, 13:16:08)
* Continuous Delivery (stefw, 13:20:32)
* Generic Service API (stefw, 13:26:15)
* We won't imagine the general service API is stable yet (stefw,
13:32:23)
* SSH agent code (stefw, 13:32:37)
* Accessing non-localhost from bridge (stefw, 13:38:09)
* Code to access non-local addresses from TCP channels are merged into
master (stefw, 13:41:59)
* Open Floor (stefw, 13:43:54)
Meeting ended at 13:54:14 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* stefw (136)
* mvollmer (86)
* petervo (16)
* zodbot (4)
* github (1)
* fche2 (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
Peter and I have been working on doing Cockpit releases for a while now.
Since we release every week, we'd like to make this more automatic. And
since we actually do full integration tests against various (so far
Fedora and CentOS) operating systems, we have a pretty good chance of
making continuous delivery be a reality.
I think we can get to the point where.
a) Whenever a tag appears in git
* Tarballs are built
* Koji builds are done for unreleased Fedoras
* Copr builds are done
* Cockpit Web Service container builds are done
b) Whenever a Koji build is done
* It's tested against the full integration test suite
* And if it passes all checks, gets turned into an update
For now we're working on part (a) ... and just working on the scripts to
automate the process. For now this runs on personal machines, and we'll
be using the scripts manually for the next few releases.
The scripts are here:
https://github.com/cockpit-project/cockpituous
Hope this makes sense.
What about other non-Fedora operating systems? Well, the first step
would be to have them running the integration tests, which is no small
feat ... but possible if we have an interested contributor.
Cheers,
Stef
On Mon, 2015-08-10 at 12:00 -0500, Paola Bás wrote:
> Stephen, I want to know if Cockpit Management Console used to close
> specific processes of another user from administrator account or log
> out another user. If so, what documentation should I check or which
> package is recommended for you to Fedora 22
>
> Thank you for help me
I'm CCing the cockpit developer list; please keep that in the loop.
I realize that this is probably a language-barrier issue, but I'm not
really sure what you're trying to ask.
Are you asking if it is possible to terminate specific processes from
Cockpit? The answer is basically "no". You can start, stop, enable or
disable system services, but not user processes.
To the best of my knowledge, Cockpit does not do any kind of session
-tracking at the moment, but I believe systemd can, so this might be an
interesting addition to the Cockpit UI. It would probably be a good
idea to file an enhancement request for it at
https://github.com/cockpit-project/cockpit/issues
=================
#cockpit: Cockpit
=================
Meeting started by stefw at 13:02:26 UTC. The full logs are available at
http://meetbot.fedoraproject.org/cockpit/2015-08-10/cockpit.2015-08-10-13.0…
.
Meeting summary
---------------
* Agenda (stefw, 13:03:27)
* No merge without docs (stefw, 13:05:37)
* http://files.cockpit-project.org/guide/latest/ (stefw, 13:07:07)
* ACTION: dperpeet will start a review criteria section in wiki and
add documentation there (stefw, 13:10:40)
* Feature OpenConnect VPN Server (stefw, 13:13:33)
* https://github.com/cockpit-project/cockpit/wiki/Feature:-Ocserv
(stefw, 13:13:52)
* https://github.com/cockpit-project/cockpit/pull/2550 (stefw,
13:14:05)
* cockpit-ocserv as an optional subpackage ... which does not prevent
later refactor into separate code repo (stefw, 13:20:26)
* Wait for design from andreasn and feature plan to be more well
rounded before merging ocserv subpackage (stefw, 13:22:53)
* Internet Explorer (stefw, 13:24:11)
* Moving things out of shell (stefw, 13:30:15)
* Open Floor (stefw, 13:40:45)
Meeting ended at 13:57:21 UTC.
Action Items
------------
* dperpeet will start a review criteria section in wiki and add
documentation there
Action Items, by person
-----------------------
* dperpeet
* dperpeet will start a review criteria section in wiki and add
documentation there
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* stefw (71)
* dperpeet (60)
* mvollmer (54)
* sgallagh (21)
* zodbot (5)
* TonyBoston (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
By default loads compressed minified javascript, CSS and HTML files.
These load fast, but are hard to use for debugging or hacking. In case
you want to use the debug files then you can do the following. Keep in
mind they're *much* slower to load than the optimized files.
If you're hacking from the source tree ...
... then debug files will be used. You symlinked the code into
~/.local/share/cockpit and that code contains debug info.
eg: http://bit.ly/1htaC7E [link to stef.thewalter.net]
If you're building from source ...
... then use the --enable-debug autogen.sh or configure argument to
enable installation of debug files at install time.
eg: http://bit.ly/1gX9idi [link to github.com]
If you're installing from Fedora packages ...
... then install cockpit-debuginfo to use debug files.
If you're building packages ...
... and want to build your own debuginfo packages, then you can find
the debug sources in /usr/src/debug. Create a sub-package which installs
those files into /usr/share/cockpit next to the optimized files.
Poke someone on #cockpit if you run into problems.
Cheers,
Stef
Hello
Just wanted to check in and see if there has been any progress on the
cockpit-bridge management agent for managing and monitoring RHEL/CentOS 6.6
servers.
We still have several hundred VM's that are CentOS 6.6 servers in our cloud
that we would want to monitor and manage via Cockpit.
Please let me know if there is a time line or if anyone has had success I
know last I heard from Stef there was the issue of docker and systemd which
is holding up the development of such integration because they are not
supported in RHEL/CentOS 6.6.
Let me know and thank you!
Regards,
Donald R. D'Avanzo Jr
*Chief Technology OfficerRed Rock Tech LLC. / Sin City Cloud*
*Office:* (702) 660-1500 | *Direct:* (702) 302-9432
10161 Park Drive, Ste 150 | Las Vegas, Nevada 89145
<http://www.linkedin.com/in/donalddavanzo>
<https://www.facebook.com/SinCityCloudHosting>
*www.sincitycloud.com <http://www.sincitycloud.com/>*
<http://www.sincitycloud.com/>