We've got the following major changes that I was considering blockers
for Foreman 1.4, but aren't yet complete. I think we'll probably need
to bump our expected RC/branch date of Thursday somewhat to accommodate
them, or drop them. Thoughts?
#3178/##1119 - hardware profiles, very close to being merged
> We've got the following major changes that I was considering blockers
> for Foreman 1.4, but aren't yet complete. I think we'll probably need
> to bump our expected RC/branch date of Thursday somewhat to accommodate
> them, or drop them. Thoughts?
>
> - #3178/##1119 - hardware profiles, very close to being merged
>
must have, should also look into effort to add api support, so later hammer
could have that functionality too.
> - #3912/##1105 - taxonomy inheritance, mid-review
>
I would like it in even if its less than fully featured without the follow
up feature of removing the requirement for location / org specific
attributes in hostgroups.
> - replacing SCL packages with RHSCL/CentOS SCL etc
> waiting on https://github.com/theforeman/puppet-foreman/pull/138 an
> then some untagging + rebuilding
> - #812 - authorization rewrite, in progress, unsure of % completion
>
Marek, how far away are we on this? is it possible?
>
> I think we can get profiles and SCL changes in if we do Thursday, maybe
> also inheritance. Anything else is nice to have?
>
I am very sorry to say that without #3513 being address and other
improvement to EC2 support in the feature request list, going forward we
will be dropping Foreman from our tool set here and I can see anyone else
with remotely serious AWS needs being able to consider Foreman as a useful
provisioning tool.
Jim
···
On 8 January 2014 08:51, Dominic Cleal wrote:
We’ve got the following major changes that I was considering blockers
for Foreman 1.4, but aren’t yet complete. I think we’ll probably need
to bump our expected RC/branch date of Thursday somewhat to accommodate
them, or drop them. Thoughts?
#3178/##1119 - hardware profiles, very close to being merged
We plan now to branch for 1.4 later today or tomorrow. Compute profiles
(#3178) were merged, taxonomy inheritance (#3912) and parameters (#3099)
should be merged too. SCL changes made it in last week.
#812 auth rewrite has missed 1.4, but we'll merge it ASAP after
branching once some important issues with it have been resolved, and aim
to test it thoroughly in develop + nightlies. We may bring 1.5 forwards
in order to release this sooner, rather than later.
Lastly #3991 (dnscmd support) and #3906 (Junos) should make it into 1.4 too.
There are quite a few bug fix PRs which will start to be merged into 1.4
once we've branched, but features are our current priority.
Thanks all!
···
On 08/01/14 08:51, Dominic Cleal wrote:
> We've got the following major changes that I was considering blockers
> for Foreman 1.4, but aren't yet complete. I think we'll probably need
> to bump our expected RC/branch date of Thursday somewhat to accommodate
> them, or drop them. Thoughts?
>
> - #3178/##1119 - hardware profiles, very close to being merged
> - #3912/##1105 - taxonomy inheritance, mid-review
> - replacing SCL packages with RHSCL/CentOS SCL etc
> waiting on https://github.com/theforeman/puppet-foreman/pull/138 an
> then some untagging + rebuilding
> - #812 - authorization rewrite, in progress, unsure of % completion
>
> I think we can get profiles and SCL changes in if we do Thursday, maybe
> also inheritance. Anything else is nice to have?
> >
> >
> >
> >
> > We've got the following major changes that I was considering blockers
> > for Foreman 1.4, but aren't yet complete. I think we'll probably
> need
> > to bump our expected RC/branch date of Thursday somewhat to
> accommodate
> > them, or drop them. Thoughts?
> >
> > - #3178/##1119 - hardware profiles, very close to being merged
> >
> > must have, should also look into effort to add api support, so later
> > hammer could have that functionality too.
>
> I'd be happy including API support post-branching, since it's low risk.
>
> > - #3912/##1105 - taxonomy inheritance, mid-review
> >
> > I would like it in even if its less than fully featured without the
> > follow up feature of removing the requirement for location / org
> > specific attributes in hostgroups.
> >
> > - replacing SCL packages with RHSCL/CentOS SCL etc
> > waiting on https://github.com/theforeman/puppet-foreman/pull/138an
> > then some untagging + rebuilding
> > - #812 - authorization rewrite, in progress, unsure of % completion
> >
> > Marek, how far away are we on this? is it possible?
> >
> >
> > I think we can get profiles and SCL changes in if we do Thursday,
> maybe
> > also inheritance. Anything else is nice to have?
> >
> >
> > I would also include:
> > #3927 - Use user-data instead of SSHProvision on Openstack / EC2
> > <Feature #3927: Use user-data instead of SSHProvision on Openstack / EC2 - Foreman;
>
> Okay.
>
> > #3709 - update the environments pages to display puppet environments
> > rather then just plain env <Feature #3709: update the environments pages to display puppet environments rather then just plain env - Foreman;
> > (its a oneliner).
>
> Marked for 1.4.0.
>
> > #3592 - Lazily load compute resource VM details through AJAX for
> > performance <Feature #3592: Lazily load compute resource VM details through AJAX for performance - Foreman; (needs to be
> > refactored for BS3).
>
> Amos, can you prepare this in time?
>
> > #3099 - Adding parameters to locations
> > <Feature #3099: Adding parameters to locations - Foreman; (should also be a very
> > small / trivial patch)
>
> No PR for this yet, so we'll need to exclude it or move the date. This,
> SCL and the authorisation changes are the most problematic ones then.
3099 says that it depends on 3912, which has an open PR here:
Looks like it's being actively work on right now. What would be the next
steps for 3099 then? I want location parameters as well, and have time in
my work schedule now.
···
On Wed, Jan 8, 2014 at 1:15 AM, Dominic Cleal wrote:
> On 08/01/14 09:02, Ohad Levy wrote:
> > On Wed, Jan 8, 2014 at 10:51 AM, Dominic Cleal > > wrote:
>
>
>
>
> We've got the following major changes that I was considering blockers
> for Foreman 1.4, but aren't yet complete. I think we'll probably need
> to bump our expected RC/branch date of Thursday somewhat to accommodate
> them, or drop them. Thoughts?
>
> - #3178/##1119 - hardware profiles, very close to being merged
>
> must have, should also look into effort to add api support, so later
> hammer could have that functionality too.
I'd be happy including API support post-branching, since it's low risk.
> - #3912/##1105 - taxonomy inheritance, mid-review
>
> I would like it in even if its less than fully featured without the
> follow up feature of removing the requirement for location / org
> specific attributes in hostgroups.
>
> - replacing SCL packages with RHSCL/CentOS SCL etc
> waiting on https://github.com/theforeman/puppet-foreman/pull/138 an
> then some untagging + rebuilding
> - #812 - authorization rewrite, in progress, unsure of % completion
>
> Marek, how far away are we on this? is it possible?
>
>
> I think we can get profiles and SCL changes in if we do Thursday, maybe
> also inheritance. Anything else is nice to have?
>
>
> I would also include:
> #3927 - Use user-data instead of SSHProvision on Openstack / EC2
> <Feature #3927: Use user-data instead of SSHProvision on Openstack / EC2 - Foreman>
> > - #812 - authorization rewrite, in progress, unsure of % completion
>
> Marek, how far away are we on this? is it possible?
I wanted to show the progress on today demo. In short - we're able to create
filters and specify scoped_search conditions. I finished adapting all UI
controllers and views to this new system. Today I'm rebasing the PR so I could
fix tests (not sure how much effort will be needed on this yet). I hope Daniel
will join my effort soon and will convert all API controllers (should be much
easier than UI part). Then we need a migration for existing data and removing
old code. Also some small refactorings and improvements should be done after I
have green tests.
I think we should be able to finish it before 1.4 (during another sprint),
supposing [1] won't get merged since it would bring a lot of new issues to
permission systems.
One risk with is that new permissions (and all related stuff) won't be tested
too much in time of releasing a new stable version of foreman. To reduce the
risk I think it would help if other devs tested PR branch. Anyway I think the
status will be clearer after today's demo.
>
> Hello all,
>
> I am very sorry to say that without #3513 being address and other
improvement to EC2 support in the feature request list, going forward we
will be dropping Foreman from our tool set here and I can see anyone else
with remotely serious AWS needs being able to consider Foreman as a useful
provisioning tool.
Jim,
I'm truly sad to hear that, I hope that someone in the development
community could address your issues sooner than later.
I know you have been patiently waiting and I'll try to find some free time
to hack something myself… Maybe at worse we could find some time around
fosdem to get you back on a happy path
Ohad
>
> Jim
>
>
>>
>> We've got the following major changes that I was considering blockers
>> for Foreman 1.4, but aren't yet complete. I think we'll probably need
>> to bump our expected RC/branch date of Thursday somewhat to accommodate
>> them, or drop them. Thoughts?
>>
>> - #3178/##1119 - hardware profiles, very close to being merged
>> - #3912/##1105 - taxonomy inheritance, mid-review
>> - replacing SCL packages with RHSCL/CentOS SCL etc
>> waiting on https://github.com/theforeman/puppet-foreman/pull/138 an
>> then some untagging + rebuilding
>> - #812 - authorization rewrite, in progress, unsure of % completion
>>
>> I think we can get profiles and SCL changes in if we do Thursday, maybe
>> also inheritance. Anything else is nice to have?
>>
>> The following features would not make 1.4:
>> Issues - Foreman
>>
>> –
>> Dominic Cleal
>> Red Hat Engineering
>>
>> –
>> You received this message because you are subscribed to the Google
Groups "foreman-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-dev+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> –
> You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
···
On Jan 8, 2014 4:57 PM, "James Bailey" wrote:
> On 8 January 2014 08:51, Dominic Cleal wrote:
> For more options, visit https://groups.google.com/groups/opt_out.
I looked at issue #3513 but don't understand fully the use case. Can you explain further.
Thanks,
Joseph
···
----- Original Message -----
> From: "Ohad Levy"
> To: "foreman-dev"
> Sent: Wednesday, January 8, 2014 8:02:03 PM
> Subject: Re: [foreman-dev] Foreman 1.4 blockers
>
> On Jan 8, 2014 4:57 PM, "James Bailey" wrote:
> >
> > Hello all,
> >
> > I am very sorry to say that without #3513 being address and other
> improvement to EC2 support in the feature request list, going forward we
> will be dropping Foreman from our tool set here and I can see anyone else
> with remotely serious AWS needs being able to consider Foreman as a useful
> provisioning tool.
>
> Jim,
>
> I'm truly sad to hear that, I hope that someone in the development
> community could address your issues sooner than later.
>
> I know you have been patiently waiting and I'll try to find some free time
> to hack something myself.. Maybe at worse we could find some time around
> fosdem to get you back on a happy path :)
>
> Ohad
> >
> > Jim
> >
> >
> > On 8 January 2014 08:51, Dominic Cleal wrote:
> >>
> >> We've got the following major changes that I was considering blockers
> >> for Foreman 1.4, but aren't yet complete. I think we'll probably need
> >> to bump our expected RC/branch date of Thursday somewhat to accommodate
> >> them, or drop them. Thoughts?
> >>
> >> - #3178/##1119 - hardware profiles, very close to being merged
> >> - #3912/##1105 - taxonomy inheritance, mid-review
> >> - replacing SCL packages with RHSCL/CentOS SCL etc
> >> waiting on https://github.com/theforeman/puppet-foreman/pull/138 an
> >> then some untagging + rebuilding
> >> - #812 - authorization rewrite, in progress, unsure of % completion
> >>
> >> I think we can get profiles and SCL changes in if we do Thursday, maybe
> >> also inheritance. Anything else is nice to have?
> >>
> >> The following features would not make 1.4:
> >>
> http://projects.theforeman.org/projects/foreman/issues?utf8=%E2%9C%93&set_filter=1&f[]=fixed_version_id&op[fixed_version_id]=%3D&v[fixed_version_id][]=38&f[]=status_id&op[status_id]=o&f[]=tracker_id&op[tracker_id]=%3D&v[tracker_id][]=2&f[]=&c[]=tracker&c[]=status&c[]=priority&c[]=subject&c[]=author&c[]=assigned_to&c[]=updated_on&c[]=category&c[]=fixed_version&group_by=
> >>
> >> --
> >> Dominic Cleal
> >> Red Hat Engineering
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups "foreman-dev" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an email to foreman-dev+unsubscribe@googlegroups.com.
> >> For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
I would really like to stay with Foreman and we have parts of are app stack
making api calls to configure services. Which is work that will have to be
redone. But our VPCs between different environments and even live between
regions share the same subnets. It worked great when we just had one VPC
with this worked fine but now Foreman will provison into a Random VPC. For
example;
I want to provision an app server in our production VPC in eu-west. Without
being able to select the VPC that app server could be provisioned in
us-east or Singapore or in one of our dev or test environments. For us
there here is currently only a 20% chance of a provisioning request
arriving in the correct VPC.
The reason we have the same subnets across many environment is we want our
multiple production and dev/qa environments to be as close to each other as
possible.
I would love to be able to do the work myself but I don't have either time
or skills to complete the work.
For foreman to be useful in a VPC environment the following items need to
be addressed.
The following would be nice to have but less important
#3522 <Feature #3522: Attach a instance to an AWS ELB - Foreman> Attach a instance to an
AWS ELB Around 70% of our instances end up attached to ELBs (Elastic Load
Balncers) after provisoning a 1 step provision and attach would be great.
All of these features are available in Fog as I have checked the fog docs
and code but are not exposed through Foreman's Console, API or CLI.
Thanks for caring people, Foreman is a wonderful tool and it worked
brilliantly in my last place which was a bare metal shop but here we are
90% AWS cloud and it is struggle for us to use it effectively.
Jim
···
On 9 January 2014 07:33, Joseph Magen wrote:
Hi Jim,
I looked at issue #3513 but don’t understand fully the use case. Can you
explain further.
I am very sorry to say that without #3513 being address and other
improvement to EC2 support in the feature request list, going forward we
will be dropping Foreman from our tool set here and I can see anyone else
with remotely serious AWS needs being able to consider Foreman as a
useful
provisioning tool.
Jim,
I’m truly sad to hear that, I hope that someone in the development
community could address your issues sooner than later.
I know you have been patiently waiting and I’ll try to find some free
time
to hack something myself… Maybe at worse we could find some time around
fosdem to get you back on a happy path
We’ve got the following major changes that I was considering blockers
for Foreman 1.4, but aren’t yet complete. I think we’ll probably need
to bump our expected RC/branch date of Thursday somewhat to
accommodate
them, or drop them. Thoughts?
#3178/##1119 - hardware profiles, very close to being merged
I might be wrong, but can't you use multiple compute resources for that?
All with the same credentials, but different VPC setting. Then depending
on the compute resource you select, a VPN will be also selected?
Struggling with these lack of features for EC2 as well. I love Foreman and
new company uses EC2 extensively so I am trying to figure out how to get
around some of the issues listed by Jim.
Not a Rails programmer so I am not sure how hard would it be to add
something to the Gui to do the following?
···
On Thursday, January 9, 2014 6:57:22 AM UTC-5, Paradoxbound wrote:
>
> Hello all,
>
> I would really like to stay with Foreman and we have parts of are app
> stack making api calls to configure services. Which is work that will have
> to be redone. But our VPCs between different environments and even live
> between regions share the same subnets. It worked great when we just had
> one VPC with this worked fine but now Foreman will provison into a Random
> VPC. For example;
>
> I want to provision an app server in our production VPC in eu-west.
> Without being able to select the VPC that app server could be provisioned
> in us-east or Singapore or in one of our dev or test environments. For us
> there here is currently only a 20% chance of a provisioning request
> arriving in the correct VPC.
>
> The reason we have the same subnets across many environment is we want our
> multiple production and dev/qa environments to be as close to each other as
> possible.
>
> I would love to be able to do the work myself but I don't have either time
> or skills to complete the work.
>
> For foreman to be useful in a VPC environment the following items need to
> be addressed.
>
> #3513 This is the killer for
> us see above currently we have to create a instance through the AWs console
> or API before handing over to Foreman, it is messy and slow.
>
> #3521 Assign a specific IP
> to instance created inside VPC, This is similar to a static IP assignment
> in physical environment. The same work around as above.
>
> The following would be nice to have but less important
>
> #3522 Attach a instance to
> an AWS ELB Around 70% of our instances end up attached to ELBs (Elastic
> Load Balncers) after provisoning a 1 step provision and attach would be
> great.
>
> #3022 Set
> disk size of an ec2 instance sometimes the default 8GB just isn't enough.
>
>
> All of these features are available in Fog as I have checked the fog docs
> and code but are not exposed through Foreman's Console, API or CLI.
>
> Thanks for caring people, Foreman is a wonderful tool and it worked
> brilliantly in my last place which was a bare metal shop but here we are
> 90% AWS cloud and it is struggle for us to use it effectively.
>
> Jim
>
>
> On 9 January 2014 07:33, Joseph Magen <jma...@redhat.com >wrote:
>
>> Hi Jim,
>>
>> I looked at issue #3513 but don't understand fully the use case. Can you
>> explain further.
>>
>> Thanks,
>>
>> Joseph
>>
>>
>> ----- Original Message -----
>> > From: "Ohad Levy" <ohad...@gmail.com >
>> > To: "foreman-dev" <forem...@googlegroups.com >
>> > Sent: Wednesday, January 8, 2014 8:02:03 PM
>> > Subject: Re: [foreman-dev] Foreman 1.4 blockers
>> >
>> > On Jan 8, 2014 4:57 PM, "James Bailey" <parado...@gmail.com> >> wrote:
>> > >
>> > > Hello all,
>> > >
>> > > I am very sorry to say that without #3513 being address and other
>> > improvement to EC2 support in the feature request list, going forward we
>> > will be dropping Foreman from our tool set here and I can see anyone
>> else
>> > with remotely serious AWS needs being able to consider Foreman as a
>> useful
>> > provisioning tool.
>> >
>> > Jim,
>> >
>> > I'm truly sad to hear that, I hope that someone in the development
>> > community could address your issues sooner than later.
>> >
>> > I know you have been patiently waiting and I'll try to find some free
>> time
>> > to hack something myself.. Maybe at worse we could find some time around
>> > fosdem to get you back on a happy path :)
>> >
>> > Ohad
>> > >
>> > > Jim
>> > >
>> > >
>> > > On 8 January 2014 08:51, Dominic Cleal <dcl...@redhat.com> >> wrote:
>> > >>
>> > >> We've got the following major changes that I was considering blockers
>> > >> for Foreman 1.4, but aren't yet complete. I think we'll probably
>> need
>> > >> to bump our expected RC/branch date of Thursday somewhat to
>> accommodate
>> > >> them, or drop them. Thoughts?
>> > >>
>> > >> - #3178/##1119 - hardware profiles, very close to being merged
>> > >> - #3912/##1105 - taxonomy inheritance, mid-review
>> > >> - replacing SCL packages with RHSCL/CentOS SCL etc
>> > >> waiting on https://github.com/theforeman/puppet-foreman/pull/138an
>> > >> then some untagging + rebuilding
>> > >> - #812 - authorization rewrite, in progress, unsure of % completion
>> > >>
>> > >> I think we can get profiles and SCL changes in if we do Thursday,
>> maybe
>> > >> also inheritance. Anything else is nice to have?
>> > >>
>> > >> The following features would not make 1.4:
>> > >>
>> >
>> http://projects.theforeman.org/projects/foreman/issues?utf8=%E2%9C%93&set_filter=1&f[]=fixed_version_id&op[fixed_version_id]=%3D&v[fixed_version_id][]=38&f[]=status_id&op[status_id]=o&f[]=tracker_id&op[tracker_id]=%3D&v[tracker_id][]=2&f[]=&c[]=tracker&c[]=status&c[]=priority&c[]=subject&c[]=author&c[]=assigned_to&c[]=updated_on&c[]=category&c[]=fixed_version&group_by=
>> > >>
>> > >> --
>> > >> Dominic Cleal
>> > >> Red Hat Engineering
>> > >>
>> > >> --
>> > >> You received this message because you are subscribed to the Google
>> > Groups "foreman-dev" group.
>> > >> To unsubscribe from this group and stop receiving emails from it,
>> send
>> > an email to foreman-dev...@googlegroups.com .
>> > >> For more options, visit https://groups.google.com/groups/opt_out.
>> > >
>> > >
>> > > --
>> > > You received this message because you are subscribed to the Google
>> Groups
>> > "foreman-dev" group.
>> > > To unsubscribe from this group and stop receiving emails from it,
>> send an
>> > email to foreman-dev...@googlegroups.com .
>> > > For more options, visit https://groups.google.com/groups/opt_out.
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "foreman-dev" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to foreman-dev...@googlegroups.com .
>> > For more options, visit https://groups.google.com/groups/opt_out.
>> >
>>
>
>
It gets around the Multi-region issue but not the same region VPC issue.
Our standard IAMs for Foreman see all instances and services for a given
account. If we start creating lots of different IAMs roles for access to
this VPC but not that VPC + these services we move the mess from
provisioning to identity management.
Jim
···
On 9 January 2014 13:17, Lukas Zapletal wrote:
Hey,
#3513http://projects.theforeman.org/issues/3513 This is the killer
for
us see above currently we have to create a instance through the AWs
console
or API before handing over to Foreman, it is messy and slow.
I might be wrong, but can’t you use multiple compute resources for that?
All with the same credentials, but different VPC setting. Then depending
on the compute resource you select, a VPN will be also selected?
I have experimented some more and updated the ticket, A commute resource is
for a region and see all resources for a region all VPCs and the classic
instances. I went against my own gut instinct and best practice tried to
create custom IAMs that could only access a given VPC. this didn't solve
the problem as the call still sees everything but rather than creating and
inaccessible instance it gives a permission denied error.
Jim
···
On 9 January 2014 13:17, Lukas Zapletal wrote:
Hey,
#3513http://projects.theforeman.org/issues/3513 This is the killer
for
us see above currently we have to create a instance through the AWs
console
or API before handing over to Foreman, it is messy and slow.
I might be wrong, but can’t you use multiple compute resources for that?
All with the same credentials, but different VPC setting. Then depending
on the compute resource you select, a VPN will be also selected?
I read the AWS documentation and will look into implementing :block_device_mapping through fog.
Joseph
···
----- Original Message -----
> From: "OmarH5G"
> To: foreman-dev@googlegroups.com
> Cc: "Joseph Magen"
> Sent: Thursday, February 6, 2014 5:21:30 PM
> Subject: Re: [foreman-dev] Foreman 1.4 blockers
>
> Struggling with these lack of features for EC2 as well. I love Foreman and
> new company uses EC2 extensively so I am trying to figure out how to get
> around some of the issues listed by Jim.
>
> Not a Rails programmer so I am not sure how hard would it be to add
> something to the Gui to do the following?
>
> #3022
> Set
> disk size of an ec2 instance sometimes the default 8GB just isn't enough.
>
> Create a Option in the Web Gui for DeviceName and VolumeSize
>
> https://github.com/theforeman/foreman/blob/develop/app/models/compute_resources/foreman/model/ec2.rb#L125-L129
>
> 125 def vm_instance_defaults
> 126 super.merge(
> 127 :flavor_id => "m1.small",
> 128 :key_pair => key_pair,
> 129 :block_device_mapping => [ {:DeviceName => '/dev/xvda',
> 'Ebs.VolumeSize' => 20 } ],
> 130 )
> 131 end
>
>
>
> On Thursday, January 9, 2014 6:57:22 AM UTC-5, Paradoxbound wrote:
> >
> > Hello all,
> >
> > I would really like to stay with Foreman and we have parts of are app
> > stack making api calls to configure services. Which is work that will have
> > to be redone. But our VPCs between different environments and even live
> > between regions share the same subnets. It worked great when we just had
> > one VPC with this worked fine but now Foreman will provison into a Random
> > VPC. For example;
> >
> > I want to provision an app server in our production VPC in eu-west.
> > Without being able to select the VPC that app server could be provisioned
> > in us-east or Singapore or in one of our dev or test environments. For us
> > there here is currently only a 20% chance of a provisioning request
> > arriving in the correct VPC.
> >
> > The reason we have the same subnets across many environment is we want our
> > multiple production and dev/qa environments to be as close to each other as
> > possible.
> >
> > I would love to be able to do the work myself but I don't have either time
> > or skills to complete the work.
> >
> > For foreman to be useful in a VPC environment the following items need to
> > be addressed.
> >
> > #3513 This is the killer for
> > us see above currently we have to create a instance through the AWs console
> > or API before handing over to Foreman, it is messy and slow.
> >
> > #3521 Assign a specific IP
> > to instance created inside VPC, This is similar to a static IP assignment
> > in physical environment. The same work around as above.
> >
> > The following would be nice to have but less important
> >
> > #3522 Attach a instance to
> > an AWS ELB Around 70% of our instances end up attached to ELBs (Elastic
> > Load Balncers) after provisoning a 1 step provision and attach would be
> > great.
> >
> > #3022
> > Set
> > disk size of an ec2 instance sometimes the default 8GB just isn't enough.
> >
> >
> > All of these features are available in Fog as I have checked the fog docs
> > and code but are not exposed through Foreman's Console, API or CLI.
> >
> > Thanks for caring people, Foreman is a wonderful tool and it worked
> > brilliantly in my last place which was a bare metal shop but here we are
> > 90% AWS cloud and it is struggle for us to use it effectively.
> >
> > Jim
> >
> >
> > On 9 January 2014 07:33, Joseph Magen > >wrote:
> >
> >> Hi Jim,
> >>
> >> I looked at issue #3513 but don't understand fully the use case. Can you
> >> explain further.
> >>
> >> Thanks,
> >>
> >> Joseph
> >>
> >>
> >> ----- Original Message -----
> >> > From: "Ohad Levy" <ohad...@gmail.com >
> >> > To: "foreman-dev" <forem...@googlegroups.com >
> >> > Sent: Wednesday, January 8, 2014 8:02:03 PM
> >> > Subject: Re: [foreman-dev] Foreman 1.4 blockers
> >> >
> >> > On Jan 8, 2014 4:57 PM, "James Bailey" > >> > <parado...@gmail.com> > >> wrote:
> >> > >
> >> > > Hello all,
> >> > >
> >> > > I am very sorry to say that without #3513 being address and other
> >> > improvement to EC2 support in the feature request list, going forward we
> >> > will be dropping Foreman from our tool set here and I can see anyone
> >> else
> >> > with remotely serious AWS needs being able to consider Foreman as a
> >> useful
> >> > provisioning tool.
> >> >
> >> > Jim,
> >> >
> >> > I'm truly sad to hear that, I hope that someone in the development
> >> > community could address your issues sooner than later.
> >> >
> >> > I know you have been patiently waiting and I'll try to find some free
> >> time
> >> > to hack something myself.. Maybe at worse we could find some time around
> >> > fosdem to get you back on a happy path :)
> >> >
> >> > Ohad
> >> > >
> >> > > Jim
> >> > >
> >> > >
> >> > > On 8 January 2014 08:51, Dominic Cleal > >> > > <dcl...@redhat.com> > >> wrote:
> >> > >>
> >> > >> We've got the following major changes that I was considering blockers
> >> > >> for Foreman 1.4, but aren't yet complete. I think we'll probably
> >> need
> >> > >> to bump our expected RC/branch date of Thursday somewhat to
> >> accommodate
> >> > >> them, or drop them. Thoughts?
> >> > >>
> >> > >> - #3178/##1119 - hardware profiles, very close to being merged
> >> > >> - #3912/##1105 - taxonomy inheritance, mid-review
> >> > >> - replacing SCL packages with RHSCL/CentOS SCL etc
> >> > >> waiting on https://github.com/theforeman/puppet-foreman/pull/138an
> >> > >> then some untagging + rebuilding
> >> > >> - #812 - authorization rewrite, in progress, unsure of % completion
> >> > >>
> >> > >> I think we can get profiles and SCL changes in if we do Thursday,
> >> maybe
> >> > >> also inheritance. Anything else is nice to have?
> >> > >>
> >> > >> The following features would not make 1.4:
> >> > >>
> >> >
> >> http://projects.theforeman.org/projects/foreman/issues?utf8=%E2%9C%93&set_filter=1&f[]=fixed_version_id&op[fixed_version_id]=%3D&v[fixed_version_id][]=38&f[]=status_id&op[status_id]=o&f[]=tracker_id&op[tracker_id]=%3D&v[tracker_id][]=2&f[]=&c[]=tracker&c[]=status&c[]=priority&c[]=subject&c[]=author&c[]=assigned_to&c[]=updated_on&c[]=category&c[]=fixed_version&group_by=
> >> > >>
> >> > >> --
> >> > >> Dominic Cleal
> >> > >> Red Hat Engineering
> >> > >>
> >> > >> --
> >> > >> You received this message because you are subscribed to the Google
> >> > Groups "foreman-dev" group.
> >> > >> To unsubscribe from this group and stop receiving emails from it,
> >> send
> >> > an email to foreman-dev...@googlegroups.com .
> >> > >> For more options, visit https://groups.google.com/groups/opt_out.
> >> > >
> >> > >
> >> > > --
> >> > > You received this message because you are subscribed to the Google
> >> Groups
> >> > "foreman-dev" group.
> >> > > To unsubscribe from this group and stop receiving emails from it,
> >> send an
> >> > email to foreman-dev...@googlegroups.com .
> >> > > For more options, visit https://groups.google.com/groups/opt_out.
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> Groups
> >> > "foreman-dev" group.
> >> > To unsubscribe from this group and stop receiving emails from it, send
> >> an
> >> > email to foreman-dev...@googlegroups.com .
> >> > For more options, visit https://groups.google.com/groups/opt_out.
> >> >
> >>
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
We have found a work around for the VPC-id issue if you have multiple VPCs
with the same subnet in all. when you provision a new instance you will see
the same subnet repeated. Select a subnet. Now check the ssecurity groups
offered. If like us you have used CloudFormation to build your infra you
have unique IDs for security groups. If those match the VPC you want you
are going to provision in the correct place, if not try another. If your
security group are the same sorry youa re still fscked.
We looked at alternatives to Foreman but found different but equally nasty
problems in other solutions. So we are currently trying to get Foreman
working for us again.
Jim
···
On 6 February 2014 15:21, OmarH5G wrote:
Struggling with these lack of features for EC2 as well. I love Foreman
and new company uses EC2 extensively so I am trying to figure out how to
get around some of the issues listed by Jim.
Not a Rails programmer so I am not sure how hard would it be to add
something to the Gui to do the following?
On Thursday, January 9, 2014 6:57:22 AM UTC-5, Paradoxbound wrote:
Hello all,
I would really like to stay with Foreman and we have parts of are app
stack making api calls to configure services. Which is work that will have
to be redone. But our VPCs between different environments and even live
between regions share the same subnets. It worked great when we just had
one VPC with this worked fine but now Foreman will provison into a Random
VPC. For example;
I want to provision an app server in our production VPC in eu-west.
Without being able to select the VPC that app server could be provisioned
in us-east or Singapore or in one of our dev or test environments. For us
there here is currently only a 20% chance of a provisioning request
arriving in the correct VPC.
The reason we have the same subnets across many environment is we want
our multiple production and dev/qa environments to be as close to each
other as possible.
I would love to be able to do the work myself but I don’t have either
time or skills to complete the work.
For foreman to be useful in a VPC environment the following items need to
be addressed.
#3513http://projects.theforeman.org/issues/3513 This is the killer
for us see above currently we have to create a instance through the AWs
console or API before handing over to Foreman, it is messy and slow.
#3521http://projects.theforeman.org/issues/3521 Assign a specific IP
to instance created inside VPC, This is similar to a static IP assignment
in physical environment. The same work around as above.
The following would be nice to have but less important
#3522http://projects.theforeman.org/issues/3522 Attach a instance to
an AWS ELB Around 70% of our instances end up attached to ELBs (Elastic
Load Balncers) after provisoning a 1 step provision and attach would be
great.
All of these features are available in Fog as I have checked the fog docs
and code but are not exposed through Foreman’s Console, API or CLI.
Thanks for caring people, Foreman is a wonderful tool and it worked
brilliantly in my last place which was a bare metal shop but here we are
90% AWS cloud and it is struggle for us to use it effectively.
I am very sorry to say that without #3513 being address and other
improvement to EC2 support in the feature request list, going forward
we
will be dropping Foreman from our tool set here and I can see anyone
else
with remotely serious AWS needs being able to consider Foreman as a
useful
provisioning tool.
Jim,
I’m truly sad to hear that, I hope that someone in the development
community could address your issues sooner than later.
I know you have been patiently waiting and I’ll try to find some free
time
to hack something myself… Maybe at worse we could find some time
around
fosdem to get you back on a happy path
–
You received this message because you are subscribed to the Google
Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to foreman-dev...@googlegroups.com.
···
On Thursday, February 6, 2014 10:44:30 AM UTC-5, Joseph Magen wrote:
>
> Hi Omar,
>
> I read the AWS documentation and will look into implementing
> :block_device_mapping through fog.
>
> Joseph
>
>
> ----- Original Message -----
> > From: "OmarH5G" <allg...@gmail.com >
> > To: forem...@googlegroups.com
> > Cc: "Joseph Magen" <jma...@redhat.com >
> > Sent: Thursday, February 6, 2014 5:21:30 PM
> > Subject: Re: [foreman-dev] Foreman 1.4 blockers
> >
> > Struggling with these lack of features for EC2 as well. I love Foreman
> and
> > new company uses EC2 extensively so I am trying to figure out how to get
> > around some of the issues listed by Jim.
> >
> > Not a Rails programmer so I am not sure how hard would it be to add
> > something to the Gui to do the following?
> >
> > #3022
> > <
> http://projects.theforeman.org/issues/3022>Set
> > disk size of an ec2 instance sometimes the default 8GB just isn't
> enough.
> >
> > Create a Option in the Web Gui for DeviceName and VolumeSize
> >
> >
> https://github.com/theforeman/foreman/blob/develop/app/models/compute_resources/foreman/model/ec2.rb#L125-L129
> >
> > 125 def vm_instance_defaults
> > 126 super.merge(
> > 127 :flavor_id => "m1.small",
> > 128 :key_pair => key_pair,
> > 129 :block_device_mapping => [ {:DeviceName => '/dev/xvda',
> > 'Ebs.VolumeSize' => 20 } ],
> > 130 )
> > 131 end
> >
> >
> >
> > On Thursday, January 9, 2014 6:57:22 AM UTC-5, Paradoxbound wrote:
> > >
> > > Hello all,
> > >
> > > I would really like to stay with Foreman and we have parts of are app
> > > stack making api calls to configure services. Which is work that will
> have
> > > to be redone. But our VPCs between different environments and even
> live
> > > between regions share the same subnets. It worked great when we just
> had
> > > one VPC with this worked fine but now Foreman will provison into a
> Random
> > > VPC. For example;
> > >
> > > I want to provision an app server in our production VPC in eu-west.
> > > Without being able to select the VPC that app server could be
> provisioned
> > > in us-east or Singapore or in one of our dev or test environments. For
> us
> > > there here is currently only a 20% chance of a provisioning request
> > > arriving in the correct VPC.
> > >
> > > The reason we have the same subnets across many environment is we want
> our
> > > multiple production and dev/qa environments to be as close to each
> other as
> > > possible.
> > >
> > > I would love to be able to do the work myself but I don't have either
> time
> > > or skills to complete the work.
> > >
> > > For foreman to be useful in a VPC environment the following items need
> to
> > > be addressed.
> > >
> > > #3513 This is the killer
> for
> > > us see above currently we have to create a instance through the AWs
> console
> > > or API before handing over to Foreman, it is messy and slow.
> > >
> > > #3521 Assign a specific
> IP
> > > to instance created inside VPC, This is similar to a static IP
> assignment
> > > in physical environment. The same work around as above.
> > >
> > > The following would be nice to have but less important
> > >
> > > #3522 Attach a instance
> to
> > > an AWS ELB Around 70% of our instances end up attached to ELBs
> (Elastic
> > > Load Balncers) after provisoning a 1 step provision and attach would
> be
> > > great.
> > >
> > > #3022
> > > <
> http://projects.theforeman.org/issues/3022>Set
> > > disk size of an ec2 instance sometimes the default 8GB just isn't
> enough.
> > >
> > >
> > > All of these features are available in Fog as I have checked the fog
> docs
> > > and code but are not exposed through Foreman's Console, API or CLI.
> > >
> > > Thanks for caring people, Foreman is a wonderful tool and it worked
> > > brilliantly in my last place which was a bare metal shop but here we
> are
> > > 90% AWS cloud and it is struggle for us to use it effectively.
> > >
> > > Jim
> > >
> > >
> > > On 9 January 2014 07:33, Joseph Magen > > >wrote:
> > >
> > >> Hi Jim,
> > >>
> > >> I looked at issue #3513 but don't understand fully the use case. Can
> you
> > >> explain further.
> > >>
> > >> Thanks,
> > >>
> > >> Joseph
> > >>
> > >>
> > >> ----- Original Message -----
> > >> > From: "Ohad Levy" <ohad...@gmail.com >
> > >> > To: "foreman-dev" <forem...@googlegroups.com >
> > >> > Sent: Wednesday, January 8, 2014 8:02:03 PM
> > >> > Subject: Re: [foreman-dev] Foreman 1.4 blockers
> > >> >
> > >> > On Jan 8, 2014 4:57 PM, "James Bailey" > > >> > <parado...@gmail.com> > > >> wrote:
> > >> > >
> > >> > > Hello all,
> > >> > >
> > >> > > I am very sorry to say that without #3513 being address and other
> > >> > improvement to EC2 support in the feature request list, going
> forward we
> > >> > will be dropping Foreman from our tool set here and I can see
> anyone
> > >> else
> > >> > with remotely serious AWS needs being able to consider Foreman as a
> > >> useful
> > >> > provisioning tool.
> > >> >
> > >> > Jim,
> > >> >
> > >> > I'm truly sad to hear that, I hope that someone in the development
> > >> > community could address your issues sooner than later.
> > >> >
> > >> > I know you have been patiently waiting and I'll try to find some
> free
> > >> time
> > >> > to hack something myself.. Maybe at worse we could find some time
> around
> > >> > fosdem to get you back on a happy path :)
> > >> >
> > >> > Ohad
> > >> > >
> > >> > > Jim
> > >> > >
> > >> > >
> > >> > > On 8 January 2014 08:51, Dominic Cleal > > >> > > <dcl...@redhat.com> > > >> wrote:
> > >> > >>
> > >> > >> We've got the following major changes that I was considering
> blockers
> > >> > >> for Foreman 1.4, but aren't yet complete. I think we'll
> probably
> > >> need
> > >> > >> to bump our expected RC/branch date of Thursday somewhat to
> > >> accommodate
> > >> > >> them, or drop them. Thoughts?
> > >> > >>
> > >> > >> - #3178/##1119 - hardware profiles, very close to being merged
> > >> > >> - #3912/##1105 - taxonomy inheritance, mid-review
> > >> > >> - replacing SCL packages with RHSCL/CentOS SCL etc
> > >> > >> waiting on
> https://github.com/theforeman/puppet-foreman/pull/138an
> > >> > >> then some untagging + rebuilding
> > >> > >> - #812 - authorization rewrite, in progress, unsure of %
> completion
> > >> > >>
> > >> > >> I think we can get profiles and SCL changes in if we do
> Thursday,
> > >> maybe
> > >> > >> also inheritance. Anything else is nice to have?
> > >> > >>
> > >> > >> The following features would not make 1.4:
> > >> > >>
> > >> >
> > >>
> http://projects.theforeman.org/projects/foreman/issues?utf8=%E2%9C%93&set_filter=1&f[]=fixed_version_id&op[fixed_version_id]=%3D&v[fixed_version_id][]=38&f[]=status_id&op[status_id]=o&f[]=tracker_id&op[tracker_id]=%3D&v[tracker_id][]=2&f[]=&c[]=tracker&c[]=status&c[]=priority&c[]=subject&c[]=author&c[]=assigned_to&c[]=updated_on&c[]=category&c[]=fixed_version&group_by=
> > >> > >>
> > >> > >> --
> > >> > >> Dominic Cleal
> > >> > >> Red Hat Engineering
> > >> > >>
> > >> > >> --
> > >> > >> You received this message because you are subscribed to the
> Google
> > >> > Groups "foreman-dev" group.
> > >> > >> To unsubscribe from this group and stop receiving emails from
> it,
> > >> send
> > >> > an email to foreman-dev...@googlegroups.com .
> > >> > >> For more options, visit https://groups.google.com/groups/opt_out.
>
> > >> > >
> > >> > >
> > >> > > --
> > >> > > You received this message because you are subscribed to the
> Google
> > >> Groups
> > >> > "foreman-dev" group.
> > >> > > To unsubscribe from this group and stop receiving emails from it,
> > >> send an
> > >> > email to foreman-dev...@googlegroups.com .
> > >> > > For more options, visit https://groups.google.com/groups/opt_out.
>
> > >> >
> > >> > --
> > >> > You received this message because you are subscribed to the Google
> > >> Groups
> > >> > "foreman-dev" group.
> > >> > To unsubscribe from this group and stop receiving emails from it,
> send
> > >> an
> > >> > email to foreman-dev...@googlegroups.com .
> > >> > For more options, visit https://groups.google.com/groups/opt_out.
> > >> >
> > >>
> > >
> > >
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups
> > "foreman-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an
> > email to foreman-dev...@googlegroups.com .
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
>
that is great, we have made some minor work around here and are looking at
getting a dev resource assigned to fix some of the issues we are
experiencing.
Jim
···
On 6 February 2014 15:44, Joseph Magen wrote:
Hi Omar,
I read the AWS documentation and will look into implementing
:block_device_mapping through fog.
Struggling with these lack of features for EC2 as well. I love Foreman
and
new company uses EC2 extensively so I am trying to figure out how to get
around some of the issues listed by Jim.
Not a Rails programmer so I am not sure how hard would it be to add
something to the Gui to do the following?
On Jan 8, 2014 4:57 PM, “James Bailey” > > >> > <parado...@gmail.com<javascript:>> > > >> wrote:
Hello all,
I am very sorry to say that without #3513 being address and other
improvement to EC2 support in the feature request list, going
forward we
will be dropping Foreman from our tool set here and I can see anyone
else
with remotely serious AWS needs being able to consider Foreman as a
useful
provisioning tool.
Jim,
I’m truly sad to hear that, I hope that someone in the development
community could address your issues sooner than later.
I know you have been patiently waiting and I’ll try to find some
free
time
to hack something myself… Maybe at worse we could find some time
around
fosdem to get you back on a happy path
Ohad
Jim
On 8 January 2014 08:51, Dominic Cleal > > >> > > <dcl...@redhat.com<javascript:>> > > >> wrote:
We’ve got the following major changes that I was considering
blockers
for Foreman 1.4, but aren’t yet complete. I think we’ll probably
need
to bump our expected RC/branch date of Thursday somewhat to
accommodate
them, or drop them. Thoughts?
#3178/##1119 - hardware profiles, very close to being merged
–
You received this message because you are subscribed to the Google
Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send
···
On Thursday, February 6, 2014 2:39:10 PM UTC-5, OmarH5G wrote:
>
> Thats great news. Could you also include a option for ephemeral ?
>
>
> http://stackoverflow.com/questions/17220697/how-to-run-aws-instances-with-attached-ephemeral-disks-with-the-fog-library
>
> compute = Fog::Compute.new(...)
>
> compute.servers.create(
> :block_device_mapping => [
> { 'deviceName' => '/dev/sdb', 'virtualName' => 'ephemeral0' },
> { 'deviceName' => '/dev/sdc', 'virtualName' => 'ephemeral1' },
> { 'deviceName' => '/dev/sdd', 'virtualName' => 'ephemeral2' },
> { 'deviceName' => '/dev/sde', 'virtualName' => 'ephemeral3' },
> ],
> :image_id => 'ami-xxxxxxxx'
> )
>
>
> On Thursday, February 6, 2014 10:44:30 AM UTC-5, Joseph Magen wrote:
>>
>> Hi Omar,
>>
>> I read the AWS documentation and will look into implementing
>> :block_device_mapping through fog.
>>
>> Joseph
>>
>>
>> ----- Original Message -----
>> > From: "OmarH5G"
>> > To: forem...@googlegroups.com
>> > Cc: "Joseph Magen"
>> > Sent: Thursday, February 6, 2014 5:21:30 PM
>> > Subject: Re: [foreman-dev] Foreman 1.4 blockers
>> >
>> > Struggling with these lack of features for EC2 as well. I love Foreman
>> and
>> > new company uses EC2 extensively so I am trying to figure out how to
>> get
>> > around some of the issues listed by Jim.
>> >
>> > Not a Rails programmer so I am not sure how hard would it be to add
>> > something to the Gui to do the following?
>> >
>> > #3022
>> > <
>> http://projects.theforeman.org/issues/3022>Set
>> > disk size of an ec2 instance sometimes the default 8GB just isn't
>> enough.
>> >
>> > Create a Option in the Web Gui for DeviceName and VolumeSize
>> >
>> >
>> https://github.com/theforeman/foreman/blob/develop/app/models/compute_resources/foreman/model/ec2.rb#L125-L129
>> >
>> > 125 def vm_instance_defaults
>> > 126 super.merge(
>> > 127 :flavor_id => "m1.small",
>> > 128 :key_pair => key_pair,
>> > 129 :block_device_mapping => [ {:DeviceName => '/dev/xvda',
>> > 'Ebs.VolumeSize' => 20 } ],
>> > 130 )
>> > 131 end
>> >
>> >
>> >
>> > On Thursday, January 9, 2014 6:57:22 AM UTC-5, Paradoxbound wrote:
>> > >
>> > > Hello all,
>> > >
>> > > I would really like to stay with Foreman and we have parts of are app
>> > > stack making api calls to configure services. Which is work that will
>> have
>> > > to be redone. But our VPCs between different environments and even
>> live
>> > > between regions share the same subnets. It worked great when we just
>> had
>> > > one VPC with this worked fine but now Foreman will provison into a
>> Random
>> > > VPC. For example;
>> > >
>> > > I want to provision an app server in our production VPC in eu-west.
>> > > Without being able to select the VPC that app server could be
>> provisioned
>> > > in us-east or Singapore or in one of our dev or test environments.
>> For us
>> > > there here is currently only a 20% chance of a provisioning request
>> > > arriving in the correct VPC.
>> > >
>> > > The reason we have the same subnets across many environment is we
>> want our
>> > > multiple production and dev/qa environments to be as close to each
>> other as
>> > > possible.
>> > >
>> > > I would love to be able to do the work myself but I don't have either
>> time
>> > > or skills to complete the work.
>> > >
>> > > For foreman to be useful in a VPC environment the following items
>> need to
>> > > be addressed.
>> > >
>> > > #3513 This is the
>> killer for
>> > > us see above currently we have to create a instance through the AWs
>> console
>> > > or API before handing over to Foreman, it is messy and slow.
>> > >
>> > > #3521 Assign a specific
>> IP
>> > > to instance created inside VPC, This is similar to a static IP
>> assignment
>> > > in physical environment. The same work around as above.
>> > >
>> > > The following would be nice to have but less important
>> > >
>> > > #3522 Attach a instance
>> to
>> > > an AWS ELB Around 70% of our instances end up attached to ELBs
>> (Elastic
>> > > Load Balncers) after provisoning a 1 step provision and attach would
>> be
>> > > great.
>> > >
>> > > #3022
>> > > <
>> http://projects.theforeman.org/issues/3022>Set
>> > > disk size of an ec2 instance sometimes the default 8GB just isn't
>> enough.
>> > >
>> > >
>> > > All of these features are available in Fog as I have checked the fog
>> docs
>> > > and code but are not exposed through Foreman's Console, API or CLI.
>> > >
>> > > Thanks for caring people, Foreman is a wonderful tool and it worked
>> > > brilliantly in my last place which was a bare metal shop but here we
>> are
>> > > 90% AWS cloud and it is struggle for us to use it effectively.
>> > >
>> > > Jim
>> > >
>> > >
>> > > On 9 January 2014 07:33, Joseph Magen > > > >wrote:
>> > >
>> > >> Hi Jim,
>> > >>
>> > >> I looked at issue #3513 but don't understand fully the use case.
>> Can you
>> > >> explain further.
>> > >>
>> > >> Thanks,
>> > >>
>> > >> Joseph
>> > >>
>> > >>
>> > >> ----- Original Message -----
>> > >> > From: "Ohad Levy" <ohad...@gmail.com >
>> > >> > To: "foreman-dev" <forem...@googlegroups.com >
>> > >> > Sent: Wednesday, January 8, 2014 8:02:03 PM
>> > >> > Subject: Re: [foreman-dev] Foreman 1.4 blockers
>> > >> >
>> > >> > On Jan 8, 2014 4:57 PM, "James Bailey" >> > >> > <parado...@gmail.com> >> > >> wrote:
>> > >> > >
>> > >> > > Hello all,
>> > >> > >
>> > >> > > I am very sorry to say that without #3513 being address and
>> other
>> > >> > improvement to EC2 support in the feature request list, going
>> forward we
>> > >> > will be dropping Foreman from our tool set here and I can see
>> anyone
>> > >> else
>> > >> > with remotely serious AWS needs being able to consider Foreman as
>> a
>> > >> useful
>> > >> > provisioning tool.
>> > >> >
>> > >> > Jim,
>> > >> >
>> > >> > I'm truly sad to hear that, I hope that someone in the development
>> > >> > community could address your issues sooner than later.
>> > >> >
>> > >> > I know you have been patiently waiting and I'll try to find some
>> free
>> > >> time
>> > >> > to hack something myself.. Maybe at worse we could find some time
>> around
>> > >> > fosdem to get you back on a happy path :)
>> > >> >
>> > >> > Ohad
>> > >> > >
>> > >> > > Jim
>> > >> > >
>> > >> > >
>> > >> > > On 8 January 2014 08:51, Dominic Cleal >> > >> > > <dcl...@redhat.com> >> > >> wrote:
>> > >> > >>
>> > >> > >> We've got the following major changes that I was considering
>> blockers
>> > >> > >> for Foreman 1.4, but aren't yet complete. I think we'll
>> probably
>> > >> need
>> > >> > >> to bump our expected RC/branch date of Thursday somewhat to
>> > >> accommodate
>> > >> > >> them, or drop them. Thoughts?
>> > >> > >>
>> > >> > >> - #3178/##1119 - hardware profiles, very close to being merged
>> > >> > >> - #3912/##1105 - taxonomy inheritance, mid-review
>> > >> > >> - replacing SCL packages with RHSCL/CentOS SCL etc
>> > >> > >> waiting on
>> https://github.com/theforeman/puppet-foreman/pull/138an
>> > >> > >> then some untagging + rebuilding
>> > >> > >> - #812 - authorization rewrite, in progress, unsure of %
>> completion
>> > >> > >>
>> > >> > >> I think we can get profiles and SCL changes in if we do
>> Thursday,
>> > >> maybe
>> > >> > >> also inheritance. Anything else is nice to have?
>> > >> > >>
>> > >> > >> The following features would not make 1.4:
>> > >> > >>
>> > >> >
>> > >>
>> http://projects.theforeman.org/projects/foreman/issues?utf8=%E2%9C%93&set_filter=1&f[]=fixed_version_id&op[fixed_version_id]=%3D&v[fixed_version_id][]=38&f[]=status_id&op[status_id]=o&f[]=tracker_id&op[tracker_id]=%3D&v[tracker_id][]=2&f[]=&c[]=tracker&c[]=status&c[]=priority&c[]=subject&c[]=author&c[]=assigned_to&c[]=updated_on&c[]=category&c[]=fixed_version&group_by=
>> > >> > >>
>> > >> > >> --
>> > >> > >> Dominic Cleal
>> > >> > >> Red Hat Engineering
>> > >> > >>
>> > >> > >> --
>> > >> > >> You received this message because you are subscribed to the
>> Google
>> > >> > Groups "foreman-dev" group.
>> > >> > >> To unsubscribe from this group and stop receiving emails from
>> it,
>> > >> send
>> > >> > an email to foreman-dev...@googlegroups.com .
>> > >> > >> For more options, visit
>> https://groups.google.com/groups/opt_out.
>> > >> > >
>> > >> > >
>> > >> > > --
>> > >> > > You received this message because you are subscribed to the
>> Google
>> > >> Groups
>> > >> > "foreman-dev" group.
>> > >> > > To unsubscribe from this group and stop receiving emails from
>> it,
>> > >> send an
>> > >> > email to foreman-dev...@googlegroups.com .
>> > >> > > For more options, visit https://groups.google.com/groups/opt_out.
>>
>> > >> >
>> > >> > --
>> > >> > You received this message because you are subscribed to the Google
>> > >> Groups
>> > >> > "foreman-dev" group.
>> > >> > To unsubscribe from this group and stop receiving emails from it,
>> send
>> > >> an
>> > >> > email to foreman-dev...@googlegroups.com .
>> > >> > For more options, visit https://groups.google.com/groups/opt_out.
>> > >> >
>> > >>
>> > >
>> > >
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "foreman-dev" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to foreman-dev...@googlegroups.com.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>> >
>>
>
