[PATCH conductor] BZ 842553 - added charts views into rpm
by Jan Provazník
From: Jan Provaznik <jprovazn(a)redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=842553
---
aeolus-conductor.spec.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/aeolus-conductor.spec.in b/aeolus-conductor.spec.in
index 7908acc..425ae07 100644
--- a/aeolus-conductor.spec.in
+++ b/aeolus-conductor.spec.in
@@ -217,6 +217,7 @@ haml="app/views/hardware_profiles app/views/realm_mappings \
app/views/api \
app/views/images \
app/views/user_groups \
+ app/views/charts \
app/views/api/builds app/views/api/provider_images \
app/views/api/target_images app/views/api/entrypoint \
app/views/api/environments \
--
1.7.10.4
11 years, 9 months
[PATCH 0/1 conductor] RM3509 re-establish providers index page
by Tzu-Mainn Chen
This is an updated patch, with changes based on jtomasek's review. It combines both previous patches into one to ease the understanding of the complete changes.
I implemented most, but not all, of the suggestions. The ones I didn't implement are those relating to the provider edit pages, as I feel that those are out of scope of this particular patch.
To address one of jtomasek's comments: the date filter affects the graph *and* the historical columns of the table.
Mainn
11 years, 9 months
RFC UI annoyances - "quick fixes" and "require design work"
by Jirka Tomasek
Hi all,
so I went through UI Annoyances wikipage and divided the issues between
those that require design work to resolve and those that can be fixed
without design intervention.
The list of UI Annoyances is here:
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/List_of_UI_Ann...
Most of the quickfixes are straightforward.The fixes which I think might
require some discussion are listed below. Feel free to comment on any of
the issues from the list or add the new ones you bump into.
* "Launch with errors" makes it sound like it will cause errors on purpose
- maybe rewording to something like: "Ignore errors during launch"
would do be enough?
* /pool_families uses both "Environments" and "Pool Families"
terminology (DISCUSS)
- I would prefer the Pool Families here to be keep it the same as
model name but I am not really sure on this one. Any recommendations?
* "Xml Deployable XML file doesn't resolve valid XML" is the worst error
ever
** it is {confusingly, awkwardly, poorly} worded and uses the word "XML"
three times in one sentence
** it doesn't actually indicate what's wrong with the XML -- we might as
well just say "Your XML is no good! Try again!"
- change the validation message to more reasonable one and include the
link to edit deployable xml?
I would like to start implementing the quick fixes by tomorrow.
Jirka
11 years, 9 months
[PATCH conductor] BZ 833767 Fixed css in deployment#launch_time_params view
by jzigmund@redhat.com
From: Jozef Zigmund <jzigmund(a)redhat.com>
---
src/app/views/deployments/launch_time_params.html.haml | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/src/app/views/deployments/launch_time_params.html.haml b/src/app/views/deployments/launch_time_params.html.haml
index d50781e..f5e080b 100644
--- a/src/app/views/deployments/launch_time_params.html.haml
+++ b/src/app/views/deployments/launch_time_params.html.haml
@@ -14,7 +14,8 @@
%section.services
.labels
- @services.each do |service, assembly_name|
- %h4.service{:id => service.id}= service.name.titleize
+ - binding.pry
+ %h4.service{:id => service.name}= service.name.titleize
%p.hidden.description= service.description
%header
@@ -23,9 +24,9 @@
.params-container
- @services.each do |service, assembly_name|
- .parameters{:id => service.id}
+ .parameters{:id => service.name}
- service.parameters.each do |parameter|
- .parameter
+ .parameter.field
- if not parameter.reference?
- id = "deployment[launch_parameters][#{assembly_name}][#{service.name}][#{parameter.name}]"
= label_tag id, parameter.name.titleize + ':'
@@ -33,9 +34,11 @@
- if parameter.type == "password"
= password_field_tag id, (parameter.value or value)
- elsif (parameter.value or value).to_s.include?("\n")
- = text_area_tag id, (parameter.value or value), :class => 'long'
+ .input
+ = text_area_tag id, (parameter.value or value), :class => 'long'
- else
- = text_field_tag id, (parameter.value or value)
+ .input
+ = text_field_tag id, (parameter.value or value)
- else
= t('.reference', :assembly => parameter.reference_assembly, :parameter => parameter.reference_parameter)
--
1.7.10.4
11 years, 9 months
Debugging Conductor
by Greg Blomquist
I recently was trying to track down an issue that jclift was seeing in
his environment, and really wanted to see what was going on line by
line. And really _didn't_ want to add a million print statements only
to have to figure out which of the seven log files I need to monitor to
see the output.
Enter ruby-debug. First though, I had to be able to run the processes
in the foreground and not as services.
Preamble
0) yum install rubygem-ruby-debug -y
1) add "gem ruby-debug" to the default section of
/usr/share/aeolus-conductor/Gemfile.in
Run Aeolus Conductor in the foreground:
0) Create a ~/bin directory
1) cp /etc/init.d/aeolus-conductor ~/bin
2) reduce the ~/bin/aeolus-conductor file to loading external vars and
running thin (in debugger mode, and don't daemonize)...something like:
http://pastebin.test.redhat.com/97293
3) chmod 755 ~/bin/aeolus-conductor
4) service aeolus-conductor stop
5) aeolus-conductor
Run delayed_job in the foreground:
0) cd /usr/share/aeolus-conductor
1) RAILS_ENV=production rake jobs:work
Now, if you add the word "debugger" (which adds a breakpoint for rdebug)
to any ruby file under /usr/share/aeolus-conductor/app, you should hit
the breakpoint in either conductor or delayed_job. Now you can do all
the fancy debugging that you like.
Hope that helps someone other than me.
----
Greg
11 years, 9 months
Re: [katello-devel] where to get required katello gems
by Hugh O. Brock
On Mon, Jul 16, 2012 at 05:57:04PM +0200, Petr Chalupa wrote:
> I am the osx user so I have to speak out ;)
>
> I think this is not just my issue. Not everybody is running on
> fedora, this affects all debian-based distributions as well. I think
> it should be solved satisfactory not to discourage potential
> contributors.
>
> I think they like theirs tweaked machines, they are used to theirs
> tools and They want to use them as I do. To do so you need run
> katello app locally against a VM with services (db, pulp,
> candlepin).
>
> I may have a compromise:
> - If all gems are in rpm repos, with the .gem files actualized.
> - Then a developer can do 'bundle package' on the VM to get
> vendor/cache with all needed gems including theirs CVE patches.
> - Then he can run 'bundle install --locally' on any development
> machine and he is good to go.
>
> We can later decide to add a repo with vendor/cache to make it even easier.
>
> To sumarize: I think the main issue for non fedora development
> machines are not updated .gem files in rubygem rpms.
>
> Petr
I've made the mistake before of trying to dictate what happens
upstream to the upstream team, so I'm not going to do that this
time. :).
However, my view, and the view of most of the folks I've talked to on
the Aeolus team, is that RPM packaging and installing from RPM or
using any other distro tools is an unnatural act for a ruby
developer and that it is (one of the many things) impeding our
progress with building an upstream community.
Now, it goes without saying that we will need to package our upstreams
as RPMs in order to productize. However my personal opinion is that it
will be better for our upstream community health, and development
time, if we can stop the packaging tail from wagging the software dog
and let the upstream be a pure Ruby project.
One way we could minimize the inevitable package proliferation pain
we'll incur by doing this is by pitching in to maintain a shared gem
repo across projects. I had even thought about a rubygems.org fork
that would provide a bit more of a gate than straight upstream, I
don't know what others would think of this. It sounds like Petr has
suggested something similar above, but I would skip the RPM step
even.
Anyway, obviously Katello upstream is free to do what it wants, but I
believe Aeolus is going to move away from knee-jerk RPM packaging and
instead plan to package our upstream releases as tarball + gems +
Gemfile, as you would expect a Ruby project to do.
Take care,
--Hugh
>
> On 16.07.12 16:23, Lukas Zapletal wrote:
> >The issue is not about how to work with bundler. If we package all the
> >build deps as RPMs, we dont need bundler anymore. So installing
> >development setup would be just like installing one metapackage via yum.
> >That's it. And we are not far from that!
> >
> >Rubygems in Red Hat's world are evil. Just like JAR files. Our customer
> >do deliver using RPMs. We should do the same. I can understand it is
> >very comfortable to have ability to run rvm or bunlder, but this is
> >fight that every developer must do its own. Especially those with MacOS
> >;-)
> >
> >My point is - instead of providing rubygem repos or fighting with
> >bundler configurations, let's just package devel only dependencies as
> >RPMs so devs can install them just like any other software they use. And
> >then handle bunlder the usual way (deleting lock file, generating lock
> >file in RPM post trans script, every team has its own way).
> >
> >Bundler is something we don't need. Actually, it's an obstacle we should
> >rather get rid of. JBoss folks could tell stories (Maven)...
> >
> >LZ
> >
> >On Mon, Jul 16, 2012 at 09:28:44AM -0400, Michael Orazi wrote:
> >>
> >>
> >>----- Original Message -----
> >>>
> >>>
> >>>----- Original Message -----
> >>>>From: "Bryan Kearney" <bkearney(a)redhat.com>
> >>>>To: katello-devel(a)redhat.com
> >>>>Sent: Monday, July 16, 2012 8:23:25 AM
> >>>>Subject: Re: [katello-devel] where to get required katello gems
> >>>>
> >>>>On 07/16/2012 07:26 AM, Petr Chalupa wrote:
> >>>>>I have a counter proposal which is more from Ruby world then the
> >>>>>solution described in previous emails.
> >>>>>
> >>>>>- remove source
> >>>>>'http://repos.fedorapeople.org/repos/katello/gems/'
> >>>>>and
> >>>>>other sources from Gemfile
> >>>>>- store all needed gems in vendor/cache as .gem files (directly
> >>>>>in
> >>>>>katello master or a git-submodule) (all versions for f16 and
> >>>>>RHEL)
> >>>>>- install gems with bundle install (without source specified
> >>>>>bundler
> >>>>>picks up gems from vendor/cache)
> >>>>>
> >>>>>Advantages:
> >>>>>- you can install all required gems on any platform: fedora,
> >>>>>ubuntu
> >>>>>or
> >>>>>osx (which I need)
> >>>>>- faster installation
> >>>>>- you can switch between fedora/RHEL env by replacing
> >>>>>Gemfile.lock
> >>>>>(lets
> >>>>>say we would have Gemfile.lock.f16 and Gemfile.lock.rhel in our
> >>>>>git
> >>>>>for
> >>>>>this purpose)
> >>>>>- easy access to and updates of gem versions
> >>>>>- you can include gems with CVE patches from fedora, everybody
> >>>>>would
> >>>>>have correct versions of gems (which I currently don't have)
> >>>>>
> >>>>>Disadvantages
> >>>>>- rubygem-* rpms are not being correctly packed. The included
> >>>>>.gem
> >>>>>files
> >>>>>are not containing CVE patches. We would need to come up with a
> >>>>>workaround to build updated .gem files or fix the issue. If this
> >>>>>is
> >>>>>fixed, all you have to do to store gems in vendor/cache is
> >>>>>'bundle
> >>>>>package' [1].
> >>>>>- other possible problems i do not see, any ideas?
> >>>>>
> >>>>>[1] http://gembundler.com/bundle_package.html
> >>>>>
> >>>>>What do you think?
> >>>>>
> >>>>>Petr
> >>>>>
> >>>>
> >>>>Could we do this model for DEV, and then work on proper packaging
> >>>>for
> >>>>each distro? I think it would help alot if we could be more
> >>>>friendly
> >>>>to
> >>>>DEVs.
> >>>>
> >>>>-- bk
> >>>>
> >>>>_______________________________________________
> >>>>katello-devel mailing list
> >>>>katello-devel(a)redhat.com
> >>>>https://www.redhat.com/mailman/listinfo/katello-devel
> >>>>
> >>>
> >>>I said half jokingly on IRC the other day that we should have a
> >>>'katello-configure --developer' which would install everything for
> >>>use with a git checkout. This would make it completely simple for
> >>>anyone to get up and going with a dev setup. Perhaps they would just
> >>>point to the git checkout:
> >>>
> >>>% katello-configure --developer /home/dudette/katello
> >>>
> >>>_______________________________________________
> >>>katello-devel mailing list
> >>>katello-devel(a)redhat.com
> >>>https://www.redhat.com/mailman/listinfo/katello-devel
> >>>
> >>
> >>There have been some similar discussions on aeolus-devel as well. Perhaps we could put our heads together and come up with a common solution for both projects since we are dealing with similar concerns.
> >>
> >>Adding John Eckersberg and Jason Guiditta to the cc as they have been thinking a bit about both of these problems. John has been pretty focussed on possible integrations in aeolus-configure and Jason has been working quite a bit about how to handle bundler such that it will act as one would expect regardless of whether they are an 'rpm based' developer or a 'pure ruby' developer.
> >>
> >>Mike
> >>
> >>_______________________________________________
> >>katello-devel mailing list
> >>katello-devel(a)redhat.com
> >>https://www.redhat.com/mailman/listinfo/katello-devel
> >
>
> _______________________________________________
> katello-devel mailing list
> katello-devel(a)redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel
--
== Hugh Brock, hbrock(a)redhat.com ==
== Engineering Manager, Cloud BU ==
== Aeolus Project: Manage virtual infrastructure across clouds. ==
== http://aeolusproject.org ==
"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey
11 years, 9 months