[PATCH 0/6 conductor] Integrates new common header
by Matt Wagner
Hi all,
This mammoth patchset implements task 3030, or at least Phase 1[1] thereof. We switch to a common header and footer with Katello (though styled a little differently.) The wiki page linked below contains a screenshot of how it should look as well, plus an explanation of why we're doing this. (The short version: so that our application looks similar to Katello.)
Please note that patches 4 and 5 are from Brian McLaughlin, and represent his first patches sent to the list[2]. So if this is ACKed, he should be given commit privileges per [3]. To give credit where due, most of the initial design came from Andy Fitzsimon based on mocks from the Red Hat UX team. I worked on weaving it into our existing layout, and Brian picked up the ongoing UI work.
Also note that this was a tough patch to send, and maybe a tough patch to apply. The reason is that there's an uberlong line, which exceeds the 998-character line limit that MIME allows, and git freaks out. The line gets chopped up in sending the email out, which breaks the patch unless you manually rejoin it. (And mutt unhelpfully "marks" this by adding an exclamation point on the end of the line, which isn't intuitive. You need to remove that.) The uberlong line is a base64 image, so its length is legitimate -- jsut annoying when trying to email it. It should be fairly easy to tweak before applying the patch, but let me know if it's a giant disaster and I can just push this to a branch somewhere for review that way. (Ultimately, the offending line is removed by Brian's patch, but I had added it earlier, so it shows up twice. Since it spans patches by different authors, I didn't want to try to obliterate references to it.)
-- Matt
[1] https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Shared_UI_with...
[2] I'm sending them only because we had been working on a branch because this was a fairly long-running task, and because I wanted to reorder history on the branch.
[3] https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Git_Commit_Acc...
12 years
I possibly fixed Redmine...
by Matt Wagner
Howdy,
I meant to send this email out on Friday, but got distracted with other
tasks.
For my ongoing task to look into moving Redmine to OpenShift in order to
make it not unbearably slow[1], I logged into the Rails VM powering
Redmine today and tried to figure out what was so horribly broken. I had
in the past observed that it was using swap, but on Friday, it wasn't.
In fact, it had a lot of free RAM. So why in the world were page loads
taking so long?!
I _think_ I identified the problem and fixed it. I noticed that Google
was crawling our site, and that serving certain pages from the
repository browser were taking about 30 seconds to load. What was more
remarkable was that it would load the 30-second page, followed
immediately by a bunch of <200ms pages.
Then I hit a wiki page, which the logs claimed was taking <100ms to
process, and watched as it just sat in my browser, "Waiting for
www.aeolusproject.org." And then, tailing the log, I saw another repo
browser request finish processing, and right then, my page loaded.
This makes me think that the repo browser was somehow blocking thin. I
confess to not knowing the specifics of what does/doesn't block thin,
but my theory is that something it was doing to call out to disk as it
compared git repos was causing thin to block, causing other requests to
back up.
I tried throwing up a robots.txt to keep Google out of the repo browser,
but it didn't pick up the change immediately, and this happened to come
on the heels of me having questioned whether anyone actually used the
repo browser anyway. So I temporarily disabled the repo browser module.
Redmine feels fast now. It's still sometimes taking a couple of seconds,
but that's more in line with a normal website. I'm yet to see any pages
take an absurd amount of time to load, and I haven't sit a single Apache
timeout error.
This does somewhat undermine my push for us to move to OpenShift, which
was largely in response to our current solution being unacceptably slow.
I still think there's value, but I think the issue is somewhat (pardon
the pun) clouded now, since we did identify some downsides to switching
away from our current system. The pros ("Redmine is usable") really
outweighed the cons (IMHO), but now that Redmine is potentially usable
again, I think it's less clear-cut.
Let me know how things work, and if anyone actually misses the repo
browser. I suspect that GitHub presents a better browser, and that if
anyone actually wanted to use the ability to link Redmine issues to
commits, we could write a Redmine plugin that just received a
post-receive hook from GitHub:
http://help.github.com/post-receive-hooks/ as opposed to continually
mirroring the entire codebase and serving absurdly-slow blocking
pages.
-- Matt
[1]
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Moving_Redmine...
12 years
RFC: OpenStack feature planning
by Matt Wagner
Hi all,
I've been remiss in sending this out sooner, but another feature on my
planning plate has been getting OpenStack support into Conductor.
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Implementing_O...
is the feature description page. I won't reproduce it here.
Deltacloud already supports OpenStack, so what's left is:
- Get Image Factory to support building and pushing to OpenStack. It
sounds like it may be possible to take advantage of OpenStack's
ability to present itself as an Amazon-like interface so we don't
necessarily need to be blocked on this, though I haven't verified this.
- Get Conductor to support OpenStack providers. David Busby sent out a
patch for this a bit over a week ago, which has been accepted and
pushed to master:
http://lists.fedorahosted.org/pipermail/aeolus-devel/2012-March/009772.html
- See what, if anything, we need to get aeolus-configure doing to set
this up for new users.
- End-to-end testing along the way.
I'd started to test the end-to-end stuff a week or two ago, but ran into
unrelated obstacles and then got distracted. I would love to come back
and revisit this shortly, though I would also love some help. Perhaps
some folks on the Infra team have an interest in this too?
In any case, please feel free to weigh in on the tasks.
-- Matt
12 years
Interesting article on how we work
by Jason Guiditta
I posted this to irc the other day, but I think everyone's attention
was too splintered for it to be noticed, so I thought I'd try sending
to list.
http://blogs.hbr.org/schwartz/2012/03/the-magic-of-doing-one-thing-a.html
LinkedIn sent me this link 2 times before I bothered to read it, but I
found it definitely applies to me, and I suspect many of us. In
particular, I find myself spending a lot more time reading and
responding to emails and irc conversations than focusing on the task I
want to be working on. I am going to try out some of the ideas
outlined in this article, possibly setting aside certain blocks of
time during the day to focus on irc/email, but am not sure yet how
that gets scheduled without making me unavailable for discussions.
Perhaps they can be a bit more scheduled and less adhoc? Anyway, if I
am unresponsive in irc, it is likely because I am trying to focus for
a block of time ;)
-j
12 years
RFC: All provider config to reside in Conductor
by Richard Su
Hi all,
I welcome your comments on this feature.
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/All_provider_c...
This contents of the wiki page is included below.
# Summary
Users should be asked to enter provider credentials and information
once. Currently users are asked to enter credentials in two places, once
in config files used by Configure and then again in Conductor when
creating a provider account. This can be confusing. We wil move all
provider creditials and information into a single place and that will be
Conductor.
Historically, Configure needed to know the provider credentials in order
to create private cloud definition files that are later used by
imagefactory (rhevm.json and vsphere.json). Credentials are no longer
needed in these private cloud definition files because of oauth. But the
private cloud definition files are still needed and the additional
provider parameters entered into Configure will need to be moved to
Conductor.
For RHEV, Configure also does additional validation to check the export
mount point is correctly specified, and if it is correct, mounts it.
This will need to be moved into Conductor as part of validation checks
Conductor performs when creating provider accounts.
Since all provider information will be moved out of Configure, Configure
will also stop creating providers in Configure for RHEV and vSphere.
Users will now create the providers and provider accounts. EC2 is
unaffected.
# Owner
Richard Su (rwsu)
and others who are interested
# Status
Planning phase.
# Screencast Demo
* Show Configure does not ask for credentials.
* Show Conductor asks for additional provider information used to create
private cloud definition files (rhevm.json and vsphere.json)
* Show provider validation logic performed by Configure has been moved
to Conductor.
# Tasks
This is being tracked as #2094.
* Remove credentials and provider information from Configure.
* Remove rhevm and vsphere profiles from Configure.
* In Conductor, add additional provider information needed by RHEV: nfs
server, nfs export, nfs mount point, and push timeout.
* In Conductor, add additional provider information needed by vSphere:
datastore and network name.
* Conductor creates rhevm.json and vsphere.json.
* RHEV export validation is moved to Conductor as part of provider
account validation before the account is created.
* Verify default configure profile works with RHEV and vSphere.
# Additional Details
The implementation needs to work with a head-less Conductor, that is a
Conductor environment where the user choses to only use the API and not
the UI. In this case, the API should ask for all information that is
needed to create the provider, provider account, json files and that is
need to perform provider specific validation.
It may also be worth investigating if we can eliminate the json files.
Imagefactory and/or Image Warehouse may be able to now just read the
information that used to reside in those files directly from Conductor.
# Open Questions
Configure mounts the RHEV nfs export. Should Conductor now be
responsible for mounting it? Or should it simply check the mount exist
and ask the user to mount it if it doesn't? And perhaps provide a
command to perform the mount in a warning message.
12 years
RFC: Moving Redmine to OpenShift (and adding a blog!)
by Matt Wagner
Hi all,
I've been planning out (and tinkering with) what it would take to move
Redmine to OpenShift. You can see the planning page here:
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Moving_Redmine...
The reason for this proposed change is two-fold. First, our current
Redmine instance is unbearably slow. (Rumor has it that it's running on
this[1].) The second reason for this proposed change is that it would
alleviate us from having to manage the VM instance powering this. From
asking around, it sounds like the VM where this is running doesn't
really have RAM to spare, so bumping us up from 1GB to 2GB is unlikely
to be feasible.
I have a demo Redmine site running here:
https://redminetest-mattydubs.rhcloud.com/
I'm seeing average page load times around 1 second. Sometimes it's
closer to 250ms, and sometimes it's 3 seconds, but the average is
somewhere around 1 second. With the existing site... Well, when I didn't
get an Apache error about the connection to thin timing out, 5-25
seconds is more the norm. Truthfully I find an average load time around
1 second to be disappointing, but it's in keeping with most other sites.
(Pingdom's "Full Page Test" says it's "faster than 72% of all tested
websites.")
While OpenShift supports HTTPS, they don't allow custom certificates
(yet?), so we would have to run on the .rhcloud.com domain, or not use
HTTPS if we wanted to use a CNAME for an aeolusproject.org subdomain.
However, because we were likely going to end up on some sort of new
subdomain to make this work anyway, I would argue that the domain we're
on doesn't matter a bunch -- people will either follow a link, or
they'll go from bookmarks / their browser's history.
If people are so inclined, what we should do is set up an account on
OpenShift that's not in an individual's name (perhaps using the
aeolus-devel list like we did on some other sites), and share the
password with a handful of maintainers. You can attach multiple public
keys, allowing everyone to use their own ssh key for management. (This
means that access to the web interface isn't strictly necessary; you
could get someone to add your key and work from the CLI tools.)
If you can believe it, this is not the full version; there's more
information on the wiki feature page linked above. This should hit most
of the high points, though. Please let me know what you think.
As a tangent, I also set up WordPress on OpenShift, as I referenced in a
previous email. It ended up being pretty easy; I would really like to
make it official. I think all we need to do to get that working is set
up a CNAME (if we want one), since there's no need for SSL for
non-management stuff, and maybe customize the theme to not look so
"default". This isn't the main focus of this, though.
-- Matt
[1] http://hackaday.com/2012/03/28/building-the-worst-linux-pc-ever/
12 years
RFC: Dbomatic testability and performance
by Richard Su
Hello,
Here's a start of a feature outline. Contents of the wiki page is listed
below.
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Dbomatic_testa...
What I am unsure of is which part of dbomatic performance needs
addressing? From my limited experience, I have seen potential issues
with RHEV and the speed in which it starts instances. But that may have
been specific to the environment I was using.
If you have experienced issues with dbomatic, this would be a great time
to get them out in the open so that we may include them in this
refactoring of dbomatic.
Thanks.
----
# Summary
Dbomatic is currently responsible for updating instance statuses and ip
addresses and updating realms. It also starts freshly created RHEV
instances.
We do not have any test coverage for dbomatic and it is written in a way
that makes testing it difficult. We would like to refactor dbomatic to
make it more readable and in a way that allows us to plug in tests.
As part of the refactoring, we should also explore ways to improve its
performance. For example, there is currently a 30 second time window
allocated for each provider account where dbomatic communicates with
deltacloud to perform status update, launch instances, etc. This 30
second window may be too short especially if dbomatic is asked to launch
a large number of RHEV instances.
# Owner
Richard Su (rwsu)
and others who have interest
# Current status
Planning phase
# Screencast Demo
Run dbomatic tests.
Demonstrate dbomatic can handle status updates and launches where they
are a large number of instances. This can be through a unit test.
# Implementation tasks
This feature is being tracked at task #3094.
Tests to add
* State change reported by deltacloud is then reported in dbomatic
* Verify extraction and population of public and private ip addresses
* For RHEV, verify instance that is in STOPPED state and had previously
not been in running state is then started
* Realms refresh
* When provider is unavailable, dbomatic stays up and doesn't fail and exit
Performance related tasks
* Dbomatic should not timeout if is asked to launch a large number of
RHEV instances. Mock out a delay to simulate RHEV instance starts.
Eliminate the 30 second deltacloud timeouts.
* Profile RHEV instance launch performance from dbomatic, and optimize
code where needed.
# Open Questions
* Which part of dbomatic performance are we worried about?
12 years
RFC: Consistent UI with Katello
by Matt Wagner
Hi all,
Please take a look at this feature page:
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Shared_UI_with...
It describes our efforts to develop a common look-and-feel with Katello.
Katello is sort of a sister project of ours, but right now we're more
like distant relatives that have only met a couple times at family
reunions. This feature describes our efforts to implement a common UI.
I've broken this task out into three rough "phases" which you may have
seen referenced elsewhere:
1.) Add a common header and footer that looks similar to the one Katello
is using. This is a quick (FSDO "quick") cosmetic similarity only, and
is tracked by #3066. I hope to have it wrapped up this week. There is a
screenshot of this at the bottom of the linked wiki feature page. (It
somehow got named "50.png")
2.) Actually use the common template, so that our layout is consistent.
Katello does use HAML and SASS and whatnot like we do. Nonetheless, I
expect this to be a larger undertaking. This is hopefully in scope for
the next major (several-month) iteration that is coming up. We should
also pay attention to planning for Phase 3 at this point.
3.) After we are using the common template, we want to move things over
to an actually-shared repository / package with Katello. We will
hopefully be using consistent stylesheets, graphics, JavaScript, and
possibly even a common application.haml. (We will, of course, have local
overrides for Conductor-specific tweaks.) The intention is to separate
this out as an RPM that we both depend on, and to use git submodules for
local development. If done right, this should eliminate duplications and
inadvertent deviations from common standards, but still leave us the
flexibility to do things differently when we want to do so on purpose.
This is likely to be a long-running task and might not be in place for
the next major iteration, though I do think it lends itself to small
steps.
The wiki page on this is still a little bit sparse; I'm kind of curious
what people think should be expanded upon. I do have more subtasks
entered for #3030; see https://www.aeolusproject.org/redmine/issues/3030
if you're so inclined.
-- Matt
12 years
